Электронная подпись. Протоколы SSH, SSL

Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования

Протокол Нидхэма-Шрёдера предназначен для решения проблемы аутентификации (см., например, http://www.cs.sunysb.edu/~zhaoming/np.html, http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/node14.html, а также [1]). Протоколу уже более 20 лет. Алгоритм предназначен для организации аутентифицированного канала между разными ЭВМ в сети по схеме точка-точка. Задача решается с помощью одного или двух серверов аутентификации с использованием общедоступных или общих секретных ключей. Данный протокол предоставляет децентрализованную услугу аутентификации.

Операция аутентификации может охватывать несколько процессов.

1. Установление виртуального канала двунаправленного обмена сообщениями между двумя субъектами, работающими на разных ЭВМ.
2. Установление однонаправленного обмена, который, например, имеет место при отправке почты. Здесь ситуация осложняется тем, что субъекты могут не быть одновременно доступны через сеть и не могут непосредственно обмениваться сообщениями.
3. Коммуникация, при которой источник информации и ее целостность может гарантироваться третьей стороной.

Безопасная передача данных по сети, которая сама не является безопасной, предполагает шифрование передаваемой информации. Будем предполагать, что каждая из сторон, участвующих в обмене, способна шифровать и дешифровать данные. Протокол Нидхэма-Шрёдера может работать как для симметричной, так и для несимметричной схем шифрования (с общим секретным ключом и с двумя парами ключей, соответственно). Будем также считать, что злоумышленник может подключить свою ЭВМ в любую точку пути, по которому происходит обмен, и таким образом способен перехватить, воспроизвести или исказить любое сообщение. ЭВМ же субъектов обмена и сервер аутентификации предполагаются защищенными от вторжения.

Сервер аутентификации может предоставить идентификационную информацию, вычисляемую на основе секретного ключа субъекта аутентификации. Сначала рассмотрим вариант с использованием симметричного шифрования/дешифрования (один ключ).

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

В начале предположим, что оба субъекта находятся в области действия общего сервера аутентификации ( AS ). AS знает секретные ключи субъектов А и В ( KA и KB, соответственно).

Обмен начинается с того, что субъект А генерирует свой идентификатор I_A1, который будет использоваться только один раз. Первое сообщение, посылаемое от A к AS, содержит:

A -> AS: (A, B, IA1)

Здесь предполагается, что сообщение послано открытым текстом, но, в принципе, оно может быть и зашифровано с использованием ключа KA.

A -> AS: (A, B, IA1)KA

Получив это сообщение AS, извлекает из базы данных секретные ключи KA и KB, а также вычисляет новый ключ CK (ключ сессии), который будет использован для осуществления процедуры аутентификации. Этот новый ключ должен быть непредсказуемым, он применяется только для одной операции аутентификации. Далее AS посылает субъекту А следующее сообщение:

AS -> A: (IA1, B, CK, {CK, A}KB)KA

Верхний индекс в данном выражении означает, что содержимое в скобках зашифровано с использованием ключа-индекса. КА и КВ — секретные ключи субъектов А и В, соответственно.

Так как выражение (I_A1, B, CK, {CK, A}^KB) зашифровано ключом КА, то только субъект А может его дешифровать и прочесть. Субъект А проверяет наличие идентификатора I_A1 (это подтверждает, что данное сообщение является откликом на сообщение А ), и имени субъекта, с которым А намерен обмениваться данными ( В ). В результате дешифровки сообщения от AS А получает во владение рабочий ключ СК. Наличие В в сообщение является обязательным. В противном случае злоумышленник может заменить В на, например, Х в сообщении (1), и в дальнейшем А будет взаимодействовать с Х, а не с В, сам того не подозревая. Заметим, что часть текста {CK, A}^KB субъект А прочесть не может.

Если все прошло нормально, субъект А посылает В следующее сообщение:

A -> B: {CK, A}KB

Нетрудно видеть, что содержимое {CK, A}^KB является частью сообщения, полученного от AS. Дешифровать это послание может только субъект В, так как оно зашифровано его секретным ключом. После дешифровки В также становится владельцем ключа сессии CK. Наличие А в сообщении подтверждает факт, что код получен именно от данного субъекта. Все обмены между А и В далее будут выполняться с использованием ключа шифрования СK. Чтобы сделать схему симметричной и уменьшить вероятность атаки воспроизведения, В следует послать А свой идентификатор:

B -> A: {IB}CK

зашифрованный ключом СК. При этом ожидается отклик:

A -> B: {IB-1}CK

Таким образом, в данной версии протокола используется 5 сообщений. Злоумышленник не может имитировать такой обмен, так как не владеет ключом CK. Число сообщений для регулярно взаимодействующих партнеров можно сократить до трех, убрав обмен сообщениями 1.1 и 1.2. При этом ключ СК будет использоваться многократно. Здесь желательно заменить обмены 1.3 и 1.4 на:

A -> B: {CK, A}KB, {IA2}CK

B -> A: {IA2 -1, IB}CK

Теперь рассмотрим вариант протокола для случая асимметричного шифрования (двух ключевая схема).

Предполагается, что субъекты А и В вычислили пары ключей ( PKA-SKA ) и ( PKB-SKB ), соответственно. Имена ключей, начинающиеся с буквы P, относятся к общедоступным ключам (public), а имена, начинающиеся с буквы S, — к секретным. Инициатором, как и в предыдущем случае, будем считать субъект А. Обмен начинается с посылки AS запроса открытого ключа В ( PKB ).

A -> AS: (A, B)

AS откликнется сообщением:

AS -> A: (PKB, B)SKAS

Сообщение зашифровано секретным ключом AS ( SKAS ). Открытый ключ AS ( PKAS ) предполагается А известным, что позволяет А успешно дешифровать данное сообщение. Здесь предполагается, что подмена ключей ( SKAS-PKAS ) злоумышленником-посредником невозможна.

Шифрование данных с использованием ключа SKAS не гарантирует конфиденциальности, но исключает модификацию сообщения по дороге (ведь никто посторонний не знает ключ SKAS ). Важно, чтобы субъект А был уверен, что он получил именно PKB, а не что-то иное. Следующим шагом будет посылка сообщения от А к В:

A -> B: {IA, A}PKB

Это сообщение может быть дешифровано только субъектом В. Смысл его заключается в том, что А уведомляет В о намерении установить с ним связь и передает ему свой одноразовый идентификатор I_A. Далее В запрашивает у AS открытый ключ А:

B -> AS: B, A

AS -> B: {PKA, A}SKAS

После этого производится взаимная аутентификация субъектов, завершающая сессию, для чего посылаются сообщения:

B -> A: {IA, IB}PKA

A -> B: { IB }PKB

Таким образом, в этом варианте аутентификация потребовала семи шагов, но 4 из них (2.1, 2.2, 2.4 и 2.5) могут быть устранены, если партнеры помнят общедоступные ключи друг друга. В этом случае схема становится эквивалентной приведенной выше версии с симметричным шифрованием.

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

{{сообщение}SKA}SKB.

В реальной жизни субъекты не всегда могут находиться в пределах зоны ответственности одного общего сервера аутентификации. По этой причине в общем случае каждый из субъектов может иметь свой сервер аутентификации ( ASA и ASB ), так как и в этом варианте перед субъектом А стоит задача сформировать для В сообщение типа {CK, A}^KB (шаг 1.3). В вычисление таких выражений будут вовлечены оба сервера, так как только ASA может шифровать объекты посредством ключа КА и только ASB может воспользоваться ключом КВ. Не исключается необходимость обеспечения безопасного обмена между AS. Примерами такого обмена могут служить операции, завершающие сессию аутентификации:

ASA -> ASB: (CK, A, B, IA1)

ASB -> ASA: (CK, A)KB, IA1, A

I_A1 передается для того, чтобы сохранить состояние ASA между сообщениями 1.11 и 1.12.

При работе с открытыми ключами возможно непосредственное обращение А к ASB, если субъект А владеет общедоступным ключом PKASB. По минимуму аутентификация при асимметричной схеме шифрования требует пересылки трех сообщений.

Протокол Нидхэма-Шрёдера пригоден и для работы с электронными подписями. Электронная подпись, как обычно, формируется на основе дайджеста D (например, MD5 ) пересылаемого документа. Сначала рассмотрим вариант с традиционной схемой шифрования. Субъект А начинает передачу с посылки AS сообщения:

A -> AS: (A, {D}KA)

AS откликается, послав:

AS -> A: {A, D}KAS

Сообщение 3.2 зашифровано ключом AS и, следовательно, не может быть дешифровано А. Субъект А шлет документ субъекту В с блоком подписи, следующим за текстом. При получении В сначала дешифрует текст и вычисляет дайджест документа CD, затем посылает блок подписи в AS для дешифровки.

B -> AS: B, {A, D}KAS

Сервер дешифрует блок подписи и возвращает результат В:

AS -> B: {A, D}KB

Если возвращенный дайджест D соответствует CD, тогда субъект, упомянутый в 3.4, является отправителем подписанного текста. Если соответствия нет, это означает, что на этапах 3.1 - 3.4 произошло искажение блока подписи или самого текста.

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

A -> B: { (текст)SKA }PKB

Субъект-получатель В дешифрует полученный текст сначала с помощью своего секретного ключа ( SKB ), а затем с привлечением общедоступного ключа А ( PKA ). При такой схеме А не сможет отказаться от того, что именно он послал текст, так как только он владеет секретным ключом SKA. Прочесть же текст может только субъект В, так как только он владеет секретным ключом SKB.

В настоящее время разработан улучшенный протокол Нидхэма-Шрёдера (см. http://dimacs.rutgers.edu/Workshops/Security/program2/dedecker/node4.html).

[1] Roger M. Needham and Michael D. Schroeder, Using Encryption for Authentication in Large Networks of Computers. Communication of the ACM, V.21, N12, December 1978.