Лекция №17 — YZTM.RU

Ключевое соглашение

В протоколе Диффи-Хеллмана две стороны создают симметричный ключ сеанса без KDC. Перед установлением симметричного ключа эти две стороны должны выбрать два числа p и g.

Первое число, p, является большим простым числом порядка 300 десятичных цифр (1024 бита). Второе число, g, служит генератором порядка p – 1 в группе <

Шаги перечислены ниже.

1. Алиса выбирает большое случайное число x, такое, что 0 < x < p – 1, и вычисляет R₁ = g^x mod p.
2. Боб выбирает другое большое случайное число y, такое, что 0 < y < p – 1, и вычисляет R₂ = g^y mod p.
3. Алиса передает Бобу R₁. Обратите внимание, что Алиса не передает значение x ; она передает только R₁.
4. Боб передает Алисе R₂. Снова обратите внимание, что Боб не передает значение y, он передает только R₂.
5. Алиса вычисляет K = (R₂)^x mod p.
6. Боб также вычисляет K = (R₁)^y mod p.

   K = (g^x mod p)^y mod p = (g^ymod p)^x mod p = g^xy mod p

Боб вычисляет K = (R1)y mod p = (gx mod p)y mod p = gxy mod p

Алиса вычисляет K = (R2)x mod p = (gy mod p)x mod p = gxy mod p

и получает то же самое значение без Боба, знающего значение x. А Боб получил это значение без Алисы, знающей значение y.

Симметричный (общедоступный) ключ в методе Диффи-Хеллмана – K = gxy mod p

Пример 5.1

Приведем тривиальный пример, чтобы ясно понять процедуру. Наш пример использует маленькие числа, но заметим, что в реальной ситуации применяются очень большие числа. Предположим, что g = 7 и p = 23. Тогда процедура содержит следующие шаги.

1. Алиса выбирает x = 3 и вычисляет R₁ = 7³ mod 23 = 21.
2. Боб выбирает y = 6 и вычисляет R₂ = 7⁶ mod 23 = 4.
3. Алиса передает число 21 Бобу.
4. Боб передает число 4 Алисе.
5. Алиса вычисляет симметричный ключ K = 4³ mod 23 = 18.
6. Боб вычисляет симметричный ключ K = 21⁶ mod 23 = 18.

Значение K одно и то же и для Алисы, и для Боба: gx y mod p = 718 = 18 .

Пример 5.2

Давайте возьмем более реальный пример. Мы используем программу, чтобы создать случайное целое число 512 битов (идеально – 1024 бит). Целое число p – число с 159 цифрами. Мы также выбираем g, x и y, как показано ниже:

Следующая таблица показывает R1, R2 и K.

Анализ протокола Диффи-Хеллмана

Концепция Диффи-Хеллмана, показанная на
рис. 5.10, является простой, но изящной. Мы можем представить ключ засекречивания между Алисой и Бобом – он состоит из трех частей: g, x и y.

Первая часть общедоступна. Каждый знает 1/3 ключа
– g, общедоступное значение. Другие две части нужно узнать у Алисы и Боба. Каждый из них знает одну часть. Алиса добавляет x как вторую часть для Боба;

Боб добавляет y как вторую часть для Алисы. Когда Алиса получает 2/3 полного ключа от Боба, она добавляет последнюю часть, ее y,
чтобы завершить ключ. Когда Боб получает ключ от Алисы – законченный на 2/3, он добавляет последнюю часть, свое y, чтобы завершить ключ.

Обратите внимание, что хотя ключ Алисы состоит из g, y и x и ключ Боба состоит из g, x и y, эти два ключа – одни и те же, потому что gxy = gyx.

Обратите внимание также, что хотя два ключа те же самые, Алиса не может найти значение y, используемого Бобом, потому что вычисление сделано по модулю p. Алиса получает gy mod p от Боба, но не gy.

Безопасность протокола

Замена ключа Диффи-Хеллмана восприимчива к двум атакам: атаке дискретного логарифма и атаке посредника (man-in middle)

Атака дискретного логарифма. Безопасность ключевой станции базируется на трудности проблемы дискретного логарифма. Ева может перехватить R1 и R2.

Из R1 = gx mod p и y из R2 = gy mod p она может затем вычислить симметричный ключ: K = gxy mod p.

1. Простое число p должно быть очень большим (более чем 300 десятичных цифр).
2. Простое число p должно быть выбрано так, чтобы p – 1 имел по крайней мере один простой делитель (больше чем 60 десятичных цифр).
3. Генератор должен быть выбран из группы <Z_p*, x >.
4. Боб и Алиса должны уничтожить x и y после того, как они вычислили значение симметричного ключа. Значения x и y должны использоваться только единожды.

Атака “посредника”. Этот протокол имеет другую слабость. Еве не надо находить значения x и y, чтобы напасть на протокол. Она может использовать глупость Алисы и Боба, создающих два ключа:

1. Алиса выбирает x , вычисляет R ₁ = g^x mod p и передает R₁ Бобу.
2. Ева, злоумышленник, перехватывает R₁. Она выбирает z, вычисляет R ₂ = g^z mod p и передает R ₂ Алисе и Бобу.
3. Боб выбирает y, вычисляет R₃ = g^y mod p, передает R₃ Алисе. Ева перехватывает R₃, и Алиса никогда не получит это число.
4. Алиса и Ева вычисляют K₁ = g^xz mod p, который становится открытым ключом между Алисой и Евой. Алиса, однако, думает, что это -открытый ключ между ней и Бобом.
5. Ева и Боб вычисляют K₂ = g^zymod p, который становится открытым ключом между Евой и Бобом. Однако Боб думает, что это – открытый ключ между ним Алисой.

Другими словами, создаются два ключа вместо одного: один между Алисой и Евой и один между Евой и Бобом. Когда Алиса посылает данные Бобу, она зашифровывает их ключом K1 (совместный ключ Алисы и Евы). Эти данные могут быть расшифрованы и прочитаны Евой.

Ева может передать сообщение Бобу, зашифрованное K2 (совместный ключ между Евой и Бобом); или она может даже изменить сообщение или передать новое сообщение. Боб введен в заблуждение, поскольку уверен, что сообщение пришло от Алисы. Подобный сценарий может случиться и в другом направлении – с Алисой.

Эта ситуация называется
” атака посредника “, поскольку Ева находится между партнерами и перехватывает R1, передаваемый Алисой Бобу, и R3, передаваемый Бобом Алисой.

Следующий метод основан на протоколе Диффи-Хеллмана. Он использует методы установления подлинности, чтобы сорвать эту атаку.

Ключи сеанса

KDC создает ключ засекречивания для каждого абонента. Этот ключ засекречивания может использоваться только между абонентом и KDC, а не между двумя членами сообщества. Если Алиса должна связаться тайно с Бобом, она нуждается в ключе засекречивания между собой и Бобом. KDC может создать ключ сеанса между Алисой и Бобом, используя их ключи с центром.

Ключи Алисы и Боба используются, чтобы подтвердить доступность и полномочность Алисы и Боба к центру и друг к другу перед тем, как будет установлен ключ сеанса. После того как связь закончена, ключ сеанса больше не нужен.

Симметричный ключ сеансамежду двумя сторонами используется только однажды.

Были предложены несколько различных подходов, чтобы создать ключ сеанса, используя идеи, рассмотренные в

“Установление подлинности объекта”
для установления подлинности объекта.

Простой протокол, использующий KDC

Давайте посмотрим, как KDS может создать сеансовый ключ KAB между Алисой и Бобом.
рис. 5.4 показывает предпринимаемые шаги.

1. Алиса передает сообщение исходного текста KDC, чтобы получить симметричный ключ сеанса между собой и Бобом. Сообщение содержит ее зарегистрированный опознавательный код (слово Алиса или рисунок) и опознавательный код Боба (слово Боб или
   рисунок). Зашифровано ли сообщение или общедоступно – KDC это не беспокоит.
2. KDC получает сообщение и создает то, что называется билетом. Билет зашифрован с помощью ключа Боба ( К_B ). Билет содержит идентификаторы Алисы и Боба и ключ сеанса ( K_AB ). Билет с копией ключа сеанса передают Алисе. Алиса получает сообщение, расшифровывает его и извлекает ключ сеанса. Она не может расшифровать билет Боба; билет, предназначенный для Боба, недоступен Алисе. Обратите внимание, что сообщение содержит двойное шифрование: зашифрован билет, а также зашифровано полное сообщение. Во втором сообщении Алиса фактически зарегистрирована в KDC, поэтому только Алиса может открыть целое сообщение, используя свой ключ засекречивания с KDC.
3. Алиса передает билет Бобу. Боб открывает билет и знает, что Алиса должна передать ему сообщение, использующее K_AB как ключ сеанса. Обратите внимание, что в этом сообщении Боб зарегистрирован в KDC, поэтому только Боб может открыть билет. Поскольку Боб зарегистрирован в KDC, он также зарегистрирован Алисой, которая доверяет KDC. Тем же самым способом Алиса также зарегистрирована Бобом, потому что Боб доверяет KDC, и KDC передал Бобу билет, который включает опознавательный код Алисы.

К сожалению, этот простой протокол имеет недостаток. Ева может применить атаку ответа, рассмотренную раньше, – то есть она может сохранить сообщение шага 3 и использовать его позже.

Протокол Ниидома-Шрёдера

Другой подход – изящный протокол Ниидома-Шрёдера (Needham-Schreder), который является основой многих протоколов. Этот протокол использует множество действий вызова-ответа между сторонами, чтобы достигнуть безупречного протокола.

Ниидом и Шрёдер применяют два nonce: RА и RB.
рис. 5.5 показывает пять шагов, используемых в этом протоколе. Мы кратко представляем каждый шаг.

1. Алиса передает сообщение KDC, в которое включает свой nonce R_А, свой опознавательный код и опознавательный код Боба.
2. KDC передает зашифрованное сообщение Алисы, которое включает nonce Алисы, опознавательный код Боба, ключ сеанса и зашифрованный билет для Боба. Все сообщение зашифровано ключом Алисы.
3. Алиса передает билет Боба ему.
4. Боб передает свой запрос Алисе ( R_B ), зашифрованный ключом сеанса.
5. Алиса отвечает на запрос Боба. Обратите внимание, что ответ передается R_B – 1 вместо R_B.

Протокол Отвея-Рисса

Третий подход – протокол Отвея-Рисса (Otway-Rees)
– другой, не менее изящный протокол.
рис. 5.6 показывает этот протокол с пятью шагами.

Ниже кратко описываются шаги этого протокола.

1. Алиса передает сообщение Бобу, которое включает nonce R, идентификационные признаки Алисы и Боба и билет для KDC – в билет входят once Алисы R_A (свидетельство для пользования KDC), копия общего nonce R и идентификаторы Алисы и Боба.
2. Боб создает тот же самый тип билета, но с собственным его, Боба, nonce R_B. Оба билета передают KDC.
3. KDC создает сообщение, которое содержит R, общий nonce, билет для Алисы и билет для Боба; сообщение передают Бобу. Билеты содержат соответствующий once R_A или R_B и ключ сеансаK_AB.
4. Боб передает Алисе ее билет.
5. Алиса передает короткое сообщение, зашифрованное ее сеансовым ключомK_AB, чтобы показать, что она имеет ключ сеанса.

Логическая структура и компоненты pki

Инфраструктура открытых ключей PKI (Public Key Infrastructure) — это набор программных агентов и правил, предназначенных для управления ключами, политикой безопасности и собственно обменом защищенными сообщениями.

Основными задачами PKI являются:

• • поддержка жизненного цикла цифровых ключей и сертификатов (то есть генерация ключей, создание и подпись сертификатов, их распределение и прочее);
  • регистрация фактов компрометации и публикация черных списков отозванных сертификатов;
  • поддержка процессов идентификации и аутентификации пользователей таким образом, чтобы сократить по возможности время допуска каждого пользователя в систему;
  • реализация механизма интеграции (основанного на PKI) существующих приложений и всех компонентов подсистемы безопасности;
  • предоставление возможности использования единственного токена безопасности, единообразного для всех пользователей и приложений и содержащего все необходимые ключевые компоненты и сертификаты.

Токен безопасности — это индивидуальное средство безопасности, определяющее все права и окружение пользователя в системе, например, USB-ключ или смарт-карта.

Рис. 6. JaCarta ГОСТ – персональное средство электронной подписи с российской криптографией «на борту» для формирования усиленной квалифицированной ЭП с неизвлекаемым ключом ЭП и строгой аутентификации пользователей.

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

Для предоставления удаленного доступа мобильным пользователям центр управления должен допускать подключение компьютеров, IP-адрес которых ему заранее неизвестен. Участники информационного обмена опознаются по их криптографическим сертификатам. Так как криптографический сертификат пользователя является электронным паспортом, он, как и любой паспорт, должен соответствовать определенным стандартам. В криптографии это стандарт Х.509.

Рис. 7. Пример распределенной сети организации.

Рис. 8. Иерархическая структура сертификатов.

Иерархическая схема PKI предусматривает существование четырех типов сертификатов:

1. Сертификат конечного пользователя (описанный выше).
2. Сертификат Удостоверяющего Центра (СА). Должен быть доступен для проверки ЭЦП сертификата конечного пользователя и подписан секретным ключом СА верхнего уровня, причем эта ЭЦП также должна проверяться, для чего должен быть доступен сертификат СА верхнего уровня, и т. д.
3. Самоподписанный сертификат. Является корневым для всей PKI и доверенным по определению. Если в результате проверки цепочки сертификатов СА выяснится, что один из них подписан корневым секретным ключом, тогда процесс проверки ЭЦП сертификатов заканчивается.
4. Кросс-сертификат. Кросс-сертификаты позволяют расширить действие конкретной PKI путем взаимоподписания корневых сертификатов двух разных PKI.

Процедура проверки ЭЦП электронного документа происходит в системе PKI следующим образом. Сначала проверяется ЭЦП конкретного документа, а затем — ЭЦП сертификата, с помощью которого проверялась предыдущая ЭЦП. Последняя проверка повторяется в цикле до тех пор, пока цепочка сертификатов не приведет к корневому.

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

Заметим, что корневых сертификатов может быть несколько: каждая организация (или организационная единица) вправе устанавливать свои корневые сертификаты (один или несколько). Стандартом предусмотрено и наличие корневого сертификата для всего сообщества пользователей Интернета.

Логическая структура и основные компоненты инфраструктуры управления открытыми ключами PKI приведены на рис. 9.

Компоненты этой структуры имеют следующее назначение:

Каталог сертификатов — общедоступное хранилище сертификатов пользователей. Доступ к сертификатам производится обычно по стандартизованному протоколу доступа к каталогам LDAP (Lightweight Directory Access Protocol).

Центр регистрации RA (Registration Authority) — организационная единица, назначение которой — регистрация пользователей системы.

Рис. 9. Структура PKI

Пользователь — владелец какого-либо сертификата (такой пользователь подлежит регистрации) или любой пользователь, запрашивающий сертификат, хранящийся в каталоге сертификатов.

Центр сертификации СА (Certification Authority) — организационная единица, назначение которой — сертификация открытых ключей пользователей (здесь из открытого ключа получается сертификат формата Х.509) и их опубликование в каталоге сертификатов.

Общая схема работы центра сертификации СА выглядит следующим образом:

• СА генерирует собственные ключи и формирует сертификаты СА, предназначенные для проверки сертификатов пользователей;
• пользователи формируют запросы на сертификацию и доставляют их СА тем или иным способом;
• СА на основе запросов пользователей формирует сертификаты пользователей;
• СА формирует и периодически обновляет списки отмененных сертификатов CRL (Certificate Revocation List);
• сертификаты пользователей, сертификаты CA и списки отмены CRL публикуются CA (рассылаются пользователям либо помещаются в общедоступный справочник).

Функции, выполняемые PKI в целом, можно условно разделить на несколько групп:

1. функции управления сертификатами;
2. функции управления ключами;
3. дополнительные функции (службы).

Кратко рассмотрим эти основные группы функций.

В состав функций управления сертификатами входят:

• регистрация пользователей. Пользователем может быть физический пользователь, прикладная программа, сетевое устройство и прочее;
• сертификация открытых ключей. По существу, процесс сертификации состоит в связывании имени пользователя и открытого ключа. СА подписывает сертификаты пользователей и СА более низкого уровня;
• сохранение закрытого ключа СА. Это главная болевая точка системы. Компрометация закрытого ключа СА разрушает всю систему;
• содержание базы сертификатов и их распределение. Все сертификаты пользователей и промежуточных СА (кроме СА самого верхнего уровня!) обычно выкладываются на общедоступный сервер — сервер сертификатов;
• обновление сертификата. Процесс активируется в случае истечения срока действия сертификата и состоит в передаче нового сертификата для открытого ключа пользователя;
• обновление ключей. При генерации новой пары ключей пользователем либо третьей стороной необходима генерация нового сертификата;
• отзыв сертификата. Этот процесс возможен, например, при компрометации ключей, изменении имени, прекращении доступа и прочем;
• определение статуса отзыва сертификата. Пользователь проверяет наличие сертификата в каталоге открытых ключей PKD (Public Key Directory) и в списке отзыва сертификатов CRL.

Функции управления ключами делятся на следующие основные подгруппы:

• генерация ключей;
• распределение ключей.

В состав группы дополнительных функций (служб) входят:

• взаимная сертификация (кросс-сертификация в различных СА);
• проверка открытого ключа с целью убедиться в соответствии открытого ключа арифметическим требованиям для таких ключей;
• проверка сертификата по просьбе пользователя;
• служба архивирования и др.

Взаимодействие компонентов инфраструктуры открытых ключей

В состав системы управления инфраструктурой открытых ключей могут входить дополнительные компоненты:

• модули интеграции — программные агенты для прикладных и клиентских систем, программные интерфейсы к сетевым приложениям и веб-сервисам;
• средства хранения ключевой информации и сертификатов пользователя — чаще всего в качестве таких средств выступают аппаратные токены, смарт-карты, USB-ключи.

Интеграция компонентов инфраструктуры открытых ключей со службой каталога, например, Microsoft Active Directory позволяет автоматизировать множество задач, связанных с управлением PKI:

• автоматическое создание сертификатов для объектов каталога, управляемое политиками;
• автоматическая публикация списков отозванных сертификатов и сертификатов CA.

Кроме того, служба каталога может служить доверенным источником информации о сертификатах других участников криптографического обмена.

Физически система управления инфраструктурой открытых ключей может состоять из нескольких уровней:

• корневой узел в составе центра сертификации, хранилища сертификатов (служба каталогов) и средств администрирования;
• периферийный узел, включающий центр регистрации, используется при географической распределенности подразделений организации и большом количестве пользователей;
• клиентские станции с необходимыми программными компонентами.

Система управления инфраструктурой открытых ключей и ее компоненты являются основой для создания ряда подсистем комплексной системы обеспечения безопасности организации:

подсистема управления жизненным циклом отчуждаемых ключевых носителей — подсистема, предназначенная для управления и учета аппаратных средств аутентификации пользователей (USB-ключей и смарт-карт) в масштабах предприятия. Эта подсистема является связующим звеном между пользователями, средствами аутентификации, приложениями информационной безопасности и корпоративной политикой безопасности;

подсистема генерации ключей шифрования и ЭЦП, используемая для:

• создания систем юридически значимой электронной цифровой подписи в системах электронного документооборота (в соответствии с Федеральным законом РФ об электронной цифровой подписи № 1-ФЗ от 10.01.2002 г.);
• реализации систем однократной и многофакторной аутентификации при доступе к автоматизированным информационным системам;

подсистема безопасного хранения и управления ключевой информацией, реализующая следующие функции:

• контроль целостности электронных документов;
• контроль целостности публичных информационных ресурсов;
• проверку подлинности взаимодействующих программных компонентов и конфиденциальности передаваемых данных при информационном взаимодействии;
• обеспечение безопасности и разграничение доступа при взаимодействии субъектов автоматизированных информационных систем;

подсистема защищенного проставления меток времени, формирующая штампы времени в электронном документообороте, что позволяет создавать доказательство факта существования документа на определенный момент времени.

На рис. 10 приведена схема инфраструктуры открытых ключей на базе продуктов Microsoft Active Directory и Microsoft Certification Authority. Удостоверяющие центры образуют в приведенном решении двухуровневую иерархию.

Изолированный корневой удостоверяющий центр физически отключен от сети. Этот удостоверяющий центр издает сертификаты только для нижестоящих УЦ. Применение изолированного корневого УЦ позволяет уменьшить риск компрометации всей инфраструктуры открытых ключей в случае успешной атаки на УЦ.

Рис. 10. Схема инфраструктуры открытых ключей на базе продуктов Microsoft Active Directory и Microsoft Certification Authority

Издающий удостоверяющий центр в данном решении интегрирован в среду MS Active Directory, что позволяет ему автоматически публиковать списки отозванных сертификатов в службе каталога, а также автоматически обслуживать клиентов Active Directory.

Публикация списков отозванных сертификатов производится как в службу каталога, так и на корпоративный веб-сервер (для внешних клиентов, не имеющих доступа к службе каталога организации).