Криптографические протоколы, ранние протоколы согласования ключей. Лекция 10

1.

Криптографические
протоколы,
ранние протоколы
согласования ключей

2.

Протоколы распространения
ключей на симметричных шифрах
Задача распространения ключей является одной из множества задач построения надёжной сети общения многих
абонентов. Задача состоит в получении в нужный момент времени двумя легальными абонентами сети секретного
сессионного ключа шифрования (и аутентификации сообщений). Хорошим решением данной задачи будем
считать такой протокол распространения ключей, который удовлетворяет следующим условиям:
В результате работы протокола между двумя абонентами должны быть сформирован секретный сессионный
ключ.
Успешное окончание работы протокола распространение ключей должно означать успешную взаимную
аутентификацию абонентов. Не должно возникать такой ситуации, что протокол успешно завершился с точки
зрения одной из сторон, а вторая сторона при этом представлена злоумышленником.
К участию в работе протокола должны допускаться только легальные пользователи сети. Внешний
пользователь не должен иметь возможность получить общий сессионный ключ с кем-либо из абонентов.
Добавление нового абонента в сеть (или исключение из неё) не должно требовать уведомления всех
участников сети.
Большая часть решений состоит в том, что в сети выделяется один или несколько доверенных центров T (Trent),
которые владеют информацией о всех легальных участниках сети и их ключах. Они же будут явно или неявно
выступать одним из участников протоколов по формированию сеансовых ключей.
Важным моментом при анализе решений данной задачи является то, что сессионные ключи, вырабатываемые в
конкретный момент времени, являются менее надёжными, чем мастер-ключи, используемые для генерации
сессионных. В частности, нужно предполагать, что хотя злоумышленник не может получить сессионный ключ во
время общения абонентов, он может сделать это по прошествии некоторого времени (дни, недели, месяцы). И
хотя знание этого сессионного ключа поможет злоумышленнику расшифровать старые сообщения, он не должен
иметь возможность организовать новую сессию с использованием уже известного ему сессионного ключа.

3.

Основные обозначения в
протоколах:
Alice, Bob — легальные абоненты сети, для которых формируется общий
сеансовый ключ. Алиса является инициатором.
Trent — доверенный центр сети.
A, B — некоторые идентификаторы легальных абонентов Алисы и Боба
соответственно.
EA, EB — результат шифрования некоторого блока данных с использованием
секретных ключей легальных абонентов сети Алисы и Боба соответственно.
Такое шифрование могу осуществить либо сами легальные абоненты, либо
доверенный центр, которому известны все секретные ключи.
RA, RB, RT — случайные числа, генерируемые Алисой, Бобом и Трентом
соответственно.
TA, TB, TT— метки времени, генерируемые Алисой, Бобом и Трентом
соответственно.
K — секретный сеансовый ключ, получение которого и является одной из
целью протоколов.

4.

Протокол Wide-Mouth Frog
(Лягушка с широким ртом)
Протокол Wide-Mouth Frog является, самым простым протоколом с доверенным центром.
Протокол состоит из следующих шагов:
1. Алиса генерирует новый сеансовый ключ K и отправляет его вместе с меткой времени,
идентификатором Боба и своим незашифрованным идентификатором доверенному
центру:
Alice→{A, EA(TA,B,K)}→Trent
2. Доверенный центр, используя полученный незашифрованный идентификатор A,
находит у себя в базе данных легальных абонентов секретный ключ Алисы и
расшифровывает им пакет данных. Проверяет метку времени (что пакет не очень старый).
Далее он отправляет похожий пакет данных Бобу, зашифрованный его секретным ключом:
Trent→{EB(TT,A,K)}→Bob
Боб, кроме расшифрования пакета, также проверяет метку времени доверенного центра.
По окончании протокола у Алисы и Боба есть общий сеансовый ключ K.
Схема взаимодействия абонентов и довереного
центра в протоколе Wide-Mouth Frog

5.

Недостатки протокола
Wide-Mouth Frog
Генератором ключа является инициирующий абонент. Если
предположить, что Боб — это сервер, предоставляющий некоторый
сервис, а Алиса — это тонкий клиент, запрашивающий данный сервис,
получается, что задача генерации надёжного сессионного ключа
взваливается на плечи абонента с наименьшими мощностями.
В протоколе общение с вызываемым абонентом происходит через
доверенный центр. Как следствие, второй абонент может стать мишенью
для DDOS-атаки с отражением (англ. distributed denial-of-service attack),
когда злоумышленник будет посылать пакеты на доверенный центр, а тот
формировать новые пакеты и посылать их абоненту. Если абонент
подключён к нескольким сетям (с несколькими доверенными центрами),
это позволит злоумышленнику вывести абонента из строя. Хотя
защититься от подобной атаки достаточно просто, настроив
соответствующим образом доверенный центр.

6.

Атаки на Wide-Mouth Frog
1. В 1995 году Рос Андерсон и Роджер Нидхем предложили вариант атаки на протокол, при котором
злоумышленник (Ева) может бесконечно продлевать срок действия конкретного сеансового ключа. Идея атаки в
том, что после окончания протокола злоумышленник будет посылать доверенному центру назад его же пакеты,
дополняя их идентификаторами якобы инициирующего абонента.
При повторении шагов 3 и 5, по прошествии определенного времени наступит расшифрование ключа K.
С точки зрения доверенного центра шаги 1, 3 и 5 являются корректными пакетами, инициирующие общение
абонентов между собой. Метки времени в них корректны (если Ева будет успевать вовремя эти пакеты посылать). С
точки зрения легальных абонентов каждый из пакетов является приглашением другого абонента начать общение. В
результате произойдёт две вещи:
Каждый из абонентов будет уверен, что закончился протокол создания нового сеансового ключа, что второй
абонент успешно аутентифицировал себя перед доверенным центром. И что для установления следующего
сеанса связи будет использоваться новый (на самом деле — старый) ключ K.
После того, как пройдёт время, нужное злоумышленнику Еве для взлома сеансового ключа K, Ева сможет и
читать всю переписку, проходящую между абонентами, и успешно выдавать себя за обоих из абонентов.

7.

Атаки на Wide-Mouth Frog
2. Атака 1997 года Гэвина Лоу проще в реализации. В результате этой атаки Боб уверен, что Алиса
аутентифицировала себя перед доверенным центром и хочет начать второй сеанс общения. Что, конечно,
не является правдой, так как второй сеанс инициирован злоумышленником.
В той же работе Лоу предложил модификацию протокола, вводящую явную взаимную аутентификацию
абонентов с помощью случайной метки RB и проверки, что Алиса может расшифровать пакет с меткой,
зашифрованной общим сеансовым ключом абонентов K. Однако данная модификация приводит к тому, что
протокол теряет своё самое главное преимущество перед другими протоколами — простоту.

8.

Протокол Нидхема—Шрёдера
Первый абонент получает от доверенного центра специальный пакет, который он без
всякой модификации отправляет второму абоненту.
Схема взаимодействия абонентов и довереного центра в
протоколе Нидхема—Шрёдера

9.

Недостатки протокола
Нидхема—Шрёдера
Протокол обеспечивает двустороннюю аутентификацию сторон и защиту
от атак с повторной передачей (replay attack) с помощью введения
случайных меток RA и RB. Действительно, без знания ключа
злоумышленник не сможет выдать себя за Алису перед Бобом (так как не
сможет расшифровать пакет с зашифрованной меткой RB). Однако,
поскольку сессионный ключ не может считаться надёжным длительное
время, если злоумышленник сумеет в какой-то момент времени получить
ранее использованный сессионный ключ K, он сможет убедить Боба, что
он является Алисой, и что это новый сессионный ключ. Для этого ему
понадобится переданный ранее по открытому каналу пакет из пункта 3
протокола.
Относительно мелкий недостаток протокола состоит ещё и в том, что во
втором пакете доверенный центр в зашифрованном виде передаёт то, что
в третьем шаге пересылается по открытому каналу (ЕB(K,A)).

10.

Протокол Отвея-Рииса
Симметричный протокол аутентификации и обмена ключами с
использованием доверенной стороны.
Условия работы протокола:
Доверенный центр ТТР
2 пользователя: Алиса и Боб, которые получили от ТТР –
соответствующие совместные секретные ключи КAS и KBS
Алиса передает сообщение M, выбирает случайное число NA,
Боб выбирает случайное число NB.

11.

Протокол Отвея-Рииса
1. Алиса формирует сообщение для Боба, в котором открытым текстом передает M, A, B, а
также те же самые M, A, B с NA, зашифрованные общим с ТТР ключом КAS.
M, A, B, КAS(NA, M, A, B)
2. Боб получает сообщение, вторую часть которого он расшифровать не может, добавляет в
него еще одну строчку, которую шифрует ключом EB и отправляет ТТР.
M, A, B, КAS(NA, M, A, B), КBS(NB, M, A, B).
3. Доверенный центр ТТР, зная оба ключа, может расшифровать сообщения Алисы и Боба.
Теперь его цель — подтвердить, что он — ТТР и сформировать ключ КAB для дальнейшего
общения Алисы и Боба.
4. Доверенный центр ТТР генерирует ключ КAB и посылает Бобу сообщение.
M, КAS(NA, КAB), КBS(NB, КAB).
5. Первую часть, зашифрованную ключом Алисы, Боб расшифровать не может, а вторую
часть расшифровывает и, считав уникальное число NB, удостоверяется, что сообщение
пришло от ТТР. Затем принимает сгенерированный ключ КAB. Теперь Боб готов к общению с
Алисой, осталось только доставить ей ключ. Боб отправляет Алисе первую часть сообщения
от ТТР.
M, КAS(NA, КAB)
Алиса принимает сообщение, удостоверяется, что оно от ТТР (считав уникальное число
NA), и считывает ключ КAB.
Алиса и Боб готовы к общению.

12.

Протокол Kerberos
Сетевой протокол аутентификации
клиента и сервера перед установлением
связи между ними, причём в протоколе
учтён тот факт, что начальный обмен
информацией между клиентом и сервером
происходит в незащищенной среде, а
передаваемые пакеты могут быть
перехвачены и модифицированы.

13.

Основные концепции
Основная концепция протокола Kerberos — если есть секрет,
известный только двоим, то любой из его хранителей может
удостовериться, что имеет дело со своим напарником. Для
этого ему достаточно проверить, знает ли его собеседник
общий секрет.
Вместо того, чтобы сообщать друг другу пароль, участники
сеанса связи обмениваются криптографическим ключом,
знание которого подтверждает личность собеседника. Но
чтобы такая технология оказалась работоспособной,
необходимо, чтобы общий ключ был симметричным, т.е., он
должен обеспечивать как шифрование, так и дешифрование
информации. Тогда один из участников использует его для
шифрования данных, а другой с помощью этого ключа
извлекает их.

14.

Аутентификаторы
Для начала работы протокола аутентификации с секретным ключом
необходимо, чтобы пользователь А инициировал общение. Он
предъявляет аутентификатор (authenticator) в виде набора данных,
зашифрованного секретным ключом. Получив аутенитификатор,
получатель расшифровывает его и проверяет полученную
информацию, чтобы убедиться в успешности дешифрования.
Может случиться, что пользователь захочет провести взаимную
аутентификацию. В этом случае используется тот же самый
протокол, но с некоторыми изменениями и в обратном порядке.
Теперь получатель извлекает из исходного аутентификатора часть
информации, а затем шифрует её, превращая в новый
аутентификатор, и передаёт обратно отправителю. Тот, в свою
очередь, расшифровывает информацию и сравнивает её с
исходной. Если всё совпадает — значит, получатель знает
секретный ключ.

15.

Управление ключами
Само название протокола Kerberos говорит о том, как здесь решена проблема управления
ключами. Кербер (или Цербер) — персонаж классической греческой мифологии. Этот
свирепый пёс о трёх головах, по поверьям греков, охраняет врата подземного царства
мёртвых. Трём головам Кербера в протоколе Kerberos соответствуют три участника
безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника
здесь играет так называемый центр распределения ключей Key Distribution Center, KDC.
KDC представляет собой службу, работающую на физически защищённом сервере. Она
ведёт базу данных с информацией об учётных записях всех главных абонентов
безопасности своей области. Вместе с информацией о каждом абоненте безопасности в
базе данных KDC сохраняется криптографический ключ, известный только этому абоненту
и службе KDC. Этот ключ, который называют долговременным, используется для связи
пользователя системы безопасности с центром распределения ключей. В большинстве
практических реализаций протокола Kerberos долговременные ключи генерируются на
основе пароля пользователя, указываемого при входе в систему.

16.

Управление ключами
Когда клиенту нужно обратиться к серверу, он прежде всего направляет
запрос в центр KDC, который в ответ направляет каждому участнику
предстоящего сеанса копии уникального сеансового ключа (session key),
действующие в течение короткого времени. Назначение этих ключей —
проведение аутентификации клиента и сервера. Копия сеансового ключа,
пересылаемая на сервер, шифруется с помощью долговременного ключа
этого сервера, а направляемая клиенту — долговременного ключа данного
клиента.

17.

Сеансовые мандаты
В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC
направляет обе копии сеансового ключа клиенту. Сообщение, предназначенное
клиенту, шифруется посредством долговременного ключа, общего для данного
клиента и KDC, а сеансовый ключ для сервера вместе с информацией о клиенте
вкладывается в блок данных, получивший название сеансового мандата (session
ticket). Затем сеансовый мандат целиком шифруется с помощью долговременного
ключа, который знают только служба KDC и данный сервер. После этого вся
ответственность за обработку мандата, несущего в себе шифрованный сеансовый
ключ, возлагается на клиента, который должен доставить его на сервер.

18.

Сеансовые мандаты
Функции службы KDC ограничиваются генерацией мандата.
Получив ответ KDC, клиент извлекает из него мандат и свою копию сеансового ключа,
которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной
памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему
сообщение, состоящее из мандата, который по-прежнему зашифрован с применением
долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного
посредством сеансового ключа. Этот мандат в комбинации с аутентификатором как раз и
составляет удостоверение, по которому сервер определяет "личность" клиента.
Сервер, получив "удостоверение личности" клиента, прежде всего с помощью своего
секретного ключа расшифровывает сеансовый мандат и извлекает из него сеансовый ключ,
который затем использует для дешифрования аутентификатора клиента. Клиент может
потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с
помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента
и в таком виде пересылает ее клиенту в качестве собственного аутентификатора.
У клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с
конкретным сервером. Сеансовые мандаты можно использовать многократно. На случай же
их хищения устанавливается срок годности мандата, который KDC указывает в самой
структуре данных. Это время определяется политикой Kerberos для конкретной области.
Обычно срок годности мандатов не превышает восьми часов, то есть, стандартной
продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее,
кэш-память удостоверений обнуляется и все сеансовые мандаты вместе с сеансовыми
ключами уничтожаются.

19.

Формальное описание
1. Алиса направляет доверенной стороне KDC свой идентификатор и Боба:
{A;В}
2. KDC генерирует два сообщения:
Первое включает метку времени TD, время жизни ключа L,сеансовый ключ для Алисы и
Боба KAB и идентификатор Боба B. Это сообщение шифруется общим ключом Алисы и
KDC.
ЕА(TD, L, KAB, В)
Второе включает метку времени TD, время жизни ключа L,сеансовый ключ для Алисы и
Боба KAB и идентификатор Алисы А. Это сообщение шифруется общим ключом Боба и
KDC.
ЕВ(TD, L, KAB, А)
Оба сообщения пересылаются Алисе.
3. Алиса генерирует сообщение из собственного идентификатора А и метки TD, шифрует
его ключом KAB и отправляет его Бобу вместе со втором сообщением от KDC.
КАВ(TD, А)
ЕВ(TD, L, KAB, А)
4. Боб расшифровывает ключом ЕВ второе сообщение и получает KAB, который позволяет
расшифровать первое сообщение и получить аутентификатор Алисы, а также продолжить
процесс обмена сообщениями с Алисой на основании общего секретного сеансового
ключа.

20.

Часы
В криптографии часы имеют несколько
областей применения:
Функции управления ключами часто
привязаны к предельным срокам.
Текущее время может быть использовано
в качестве уникального значения.
Текущее время может быть использовано
для упорядочения событий.

21.

Часы в криптографии
Довольно часто требуется ограничить срок действия документа. Стандартный способ
ограничить срок действия цифрового документа - включить время истечения срока действия
в сам документ. Но, чтобы проверить, не истек ли срок действия документа, необходимо
знать текущее время.
Еще одной удобной особенностью текущего времени является возможность применять его
в качестве уникального значения в рамках одного компьютера, например для создания
оказии в режимах работы блочных шифров. Важным свойством оказии является то, что
никакое ее значение не используется дважды, что и обеспечивают часы.
Монотонность. Время, как известно, всегда идет вперед, оно никогда не останавливается и
не обращает свой ход вспять. Это весьма полезное свойство применяется в некоторых
криптографических протоколах. Включив текущее время в криптографический протокол, мы
мешаем злоумышленнику пересылать старые сообщения, сгенерированные в рамках
предыдущих сеансов работы протокола, под видом новых.
Еще одной важной областью применения часов является аудит и ведение журналов. В
любой системе управления транзакциями очень важно вести журнал всего происшедшего.
Если в системе когда-нибудь возникнет спорная ситуация, журналы аудита позволят
отследить точную последовательность происшедших событий. В каждую запись о событии
очень важно включать точное время; не имея временной метки, сложно определить, какие
события принадлежали к одной и той же транзакции и в каком порядке они выполнялись.
Если часы различных компьютеров хорошо синхронизированы и их показания не
отклоняются (или практически не отклоняются) друг от друга, наличие временных меток
позволяет соотносить события из различных журналов, находящихся на разных машинах.

22.

Виды угроз.
Перевод часов назад.
Предположим, злоумышленнику удалась перевести часы на какое-нибудь
произвольное время в прошлом. Эта может повлечь за собой caмыe разные
неприятности. Компьютер ошибочно предполагает, что находится в прошлом.
Если злоумышленник имел доступ к определенным данным, но сейчас срок
действия этого доступа истек, компьютер, часы которого показывают
неправильное время, может предоставить злоумышленнику доступ к важным
данным. Эта проблема возникает всякий раз, когда у пользователя отбирают
какие-нибудь права доступа.
Еще одна проблема, касающаяся перевода часов назад, свойственна
финансовым системам. В подобных системах очень важно знать правильное
время выполнения транзакции, поскольку расчеты процентов дают разные
результаты в зависимости от того, когда была выполнена транзакция. Вы
можете убедить компьютер вашего банка в том, что осуществленный
несколько минут назад электронный платеж на самом деле произошел на
шесть месяцев раньше. Это бы избавило вас от уплаты процентов за целых
шесть месяцев.

23.

Виды угроз.
Остановка часов.
Каждый разработчик живет с инстинктивным пониманием того, что
время не стоит на месте. Но, если часы останавливаются, время
будто бы замирает. Многие процессы не будут завершены, а
многие системы начнут вести себя непредсказуемо.
Наиболее простые проблемы, вызываемые остановкой часов, - это
ошибки наподобие неправильного указания времени в отчетах и
журналах ayдита. Точное время транзакции может иметь большие
финансовые последствия и отправка официального документа с
неправильной датой и временем может привести к серьезным
осложнениям.

24.

Виды угроз.
Перевод часов вперед.
Перевод часов вперед заставляет компьютер думать, что он живет
в будущем. Это приводит к появлению множества простых атак
типа "отказ в обслуживании". Если часы будут переведены на
четыре года вперед, все транзакции с участием кредитных
карточек будут неожиданно отклонены, так как карточки окажутся
недействительными. Вы также не сможете заказать авиабилеты
через Internet, поскольку расписания полетов на четыре года
вперед еще не существует.
Существуют и прямые угрозы безопасности, связанные с
переводом часов вперед. Довольно часто определенные данные
должны храниться в секрете до заданного момента времени, в
автоматизированной системе перевод часов вперед позволяет
получить доступ к таким данным.