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

Разбить на страницы

Показывать лекцию целиком

Электронная подпись

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

Рассмотрим сначала, от каких действий злоумышленника должна защищать система идентификации.

Отказ от выполненных действий. Субъект утверждает, что он не посылал некоторый документ, хотя на самом деле он его послал.

Модификация документа. Получатель модифицирует полученный документ и утверждает, что именно такую версию документа он и получил.

Подделка. Субъект фабрикует сообщение и утверждает, что оно ему прислано.

Перехват. Злоумышленник С перехватывает сообщение, посланное А к В с целью модификации.

Маскировка. Посылка сообщения от чужого имени.

Повтор. Злоумышленник С посылает повторно сообщение от А к Б, перехваченное им ранее.

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

Пусть имеются секретные коды ) генерирует дайджест своего сообщения длиной 160 бит (5 слов). Затем с помощью своего секретного ключа он шифрует дайджест и формирует электронную подпись. При этом А не может отказаться от того, что именно он послал сообщение, так как только он знает свой секретный ключ. Электронную подпись нельзя использовать повторно и подписанный документ нельзя модифицировать, так как любые модификации неизбежно изменят его дайджест, а, следовательно, и электронную подпись. Получатель с помощью открытого ключа отправителя дешифрует код электронной подписи, а затем с использованием дайджеста проверяет ее корректность.

Национальный институт стандартов США принял стандарт ), в основу которого легли алгоритмы Эль-Гамаля и RSA. В России для этой цели используется алгоритм ГОСТ Р 34.10-2001.

Рассмотрим алгоритмы вычисления дайджеста сообщения, электронной подписи и идентификации отправителя. Начнем с алгоритма SHA (Secure Hash Algorithm).

Сначала сообщение разбивается на блоки длиной 512 бит. Если длина сообщения не кратна 512, к последнему блоку приписывается справа 1, после чего он дополняется нулями до 512 бит. В конец последнего блока записывается код длины сообщения. В результате сообщение приобретает вид n 16-разрядных двоичных слов M₁,M₂,…,M_n. M₁ содержит первый символ.

Алгоритм SHA использует 80 логических функций f₀,f₁,…,f₇₉, которые производят операции над тремя 32-разрядными словами ( B,C,D ):

f_t(B,C,D) = (B AND C) OR ((NOT B) AND D)        для  0 <= t <= 19
f_t(B,C,D) = B XOR C XOR D                       для 20 <= t <= 39
f_t(B,C,D) = (B AND C) OR (B AND D) OR (C AND D) для 40 <= t <= 59
f_t(B,C,D) = B XOR C XOR D                       для 60 <= t <= 79

В алгоритме используется также 80 констант K₁,K₂,…, K₇₉:

K_t = 5A827999     для  0 <= t <= 19
K_t = 6ED9EBA1     для 20 <= t <= 39
K_t = 8F1BBCDC     для 40 <= t <= 59
K_t = CA62C1D6     для 60 <= t <= 79

Вводится 5 переменных H_i, инициализируемых как:

H₀ = 67452301
H₁ = EFCDAB89
H₂ = 98BADCFE
H₃ = 10325476
H₄ = C3D2E1F0

Массив M делится на группы из 16 слов W₀, W₁,…,W₁₅ ( W₀ самое левое слово).

Для t = 16 - 79 w_t = S¹(W_t-3 XOR W_t-8 XOR W_t-14 XOR W_t-16)

A^k означает операцию циклического сдвига влево на k разрядов.

Пусть теперь A = H₀, B = H₁, C = H₂, D = H₃, E = H₄.

for t = 0 to 79 do

TEMP = S⁵(A) + f_t(B,C,D) + E + W_t + K_t. ( TEMP — временная переменная).

E = D; D = C; C = S³⁰(B); B = A; A = TEMP;

Пусть H₀ = H₀ + A; H₁ = H₁ + B; H₂ = H₂ + C; H₃ = H₃ + D; H₄ = H₄ + E.

В результате обработки массива .

(рис 15.1) Схема вычисления и верификации электронной подписи (DSS)

DSS использует следующие параметры (http://www.itl.nist.gov/div897/pubs/fip186.htm):

p — простое число, которое при 512<= L <= 1024 удовлетворяет условию 2^L-1 < p < 2^L, L кратно 64.

q — простой делитель p-1, где 2¹⁵⁹ < q < 2¹⁶⁰.

g = h^(p-1)/q mod p, где h — любое целое, для которого 1 < h < p-1 и h^(p-1)/q mod p > 1.

x равно случайному или псевдослучайному целому числу, для которого 0 < x < q.

y = g^x mod p.

k равно случайному или псевдослучайному целому числу, для которого 0 < k < q.

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

Подпись сообщения M представляет собой два числа r и s, вычисленные согласно формулам:

r = (gk mod p) mod q

s = (k^-1(SHA(M) + xr)) mod q. (здесь k^-1 — величина, обратная k).

SHA(M) представляет собой дайджест сообщения M (160-битовая строка). После вычисления r и s следует проверить, не равно ли одно из них нулю.

Для верификации электронной подписи проверяющая сторона должна иметь параметры p, q и g, а также открытый ключ отправителя (подписанта) y.

Пусть M', r' и s' представляют собой полученное сообщение и электронную подпись. Получатель начинает верификацию с проверки условия 0 < r' < q и 0 < s' < q. Если хотя бы одно из условий не выполнено, электронная подпись некорректна. Далее производится вычисление:

w = (s')^-1 mod q
u1 = ((SHA(M')w) mod q
u2 = ((r')w) mod q
v = (((g)^u1 (y)^u2) mod p) mod q.

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

Алгоритм Диффи-Хелмана

Алгоритм Диффи-Хелмана (1976 год) использует функцию дискретного возведения в степень и похож на метод Эль-Гамаля (см. RFC-2631).

Сначала генерируются два больших простых числа n и q. Эти два числа не обязательно хранить в секрете. Далее один из партнеров P1 генерирует случайное число x и посылает другому участнику будущих обменов P2 значение

A = q^x mod n

По получении А партнер P2 генерирует случайное число у и посылает P2 вычисленное значение

B = q^y mod n

Партнер P1, получив В, вычисляет K_x = B^x mod n, а партнер P2 вычисляет K_y = A^y mod n. Алгоритм гарантирует, что числа K_y и K_x равны и могут быть использованы в качестве секретного ключа для шифрования. Ведь даже перехватив числа А и В, трудно вычислить K_x или K_y.

Алгоритм Диффи-Хелмана, обеспечивая конфиденциальность передачи ключа, не может гарантировать, что он прислан именно тем партнером, который предполагается. Для решения этой проблемы был предложен протокол STS (station-to-station). Этот протокол для идентификации отправителя использует технику электронной подписи. Подпись шифруется общим секретным ключом, после того как он сформирован. Подпись включает в себя идентификаторы как P1, так и P2. (см. также RFC-2786 "Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000".)

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

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

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

Установление виртуального канала двунаправленного обмена сообщениями между двумя субъектами, работающими на разных ЭВМ.

Установление однонаправленного обмена, который, например, имеет место при отправке почты. Здесь ситуация осложняется тем, что субъекты могут не быть одновременно доступны через сеть и не могут непосредственно обмениваться сообщениями.

Коммуникация, при которой источник информации и ее целостность может гарантироваться третьей стороной.

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

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

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

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

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

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

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

A -> AS: (A, B, I_A1)^KA

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

AS -> A: (I_A1, 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: {I_B}^CK

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

A -> B: {I_B-1}^CK

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

A -> B: {CK, A}^KB, {I_A2}^CK

B -> A: {I_A2 -1, I_B}^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: {I_A, A}^PKB

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

B -> AS: B, A

AS -> B: {PKA, A}^SKAS

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

B -> A: {I_A, I_B}^PKA

A -> B: { I_B }^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, I_A1)

ASB -> ASA: (CK, A)^KB, I_A1, 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.

Протокол безопасного доступа SSH

Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump или sniffer), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены "посторонние" машины. Чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа "безопасная оболочка" SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH применяет для шифрования как открытый ключ, так и симметричные схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы, как telnet, rlogin, rsh и rcp. Эта программа шифрует также и сессии X Windows для ЭВМ, на которых установлена. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или http. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты. Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата. В стандартный набор входит и программа безопасного удаленного копирования файлов SCP, заменяющая FTP. SSH по умолчанию использует порт 22.

Для формирования SSH -прокси на удаленном WEB-сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию –L:

SSH –L5678:www.pod.potol.com:80 www.pod.potol.com

Аргумент, следующий после флага опции -L имеет формат:

<локальный порт>:<удаленная ЭВМ>:<удаленный порт>.

Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду .

В последнее время остро встала проблема надежной аутентификации пользователей в сети. Здесь приходится искать компромисс между однозначным распознаванием пользователя и требованиями конфиденциальности.

Протокол SSL. Безопасный уровень соединителей

Протокол SSL спроектирован для обеспечения конфиденциальности обмена между двумя прикладными процессами клиента и сервера (см. http://www.netscape.com). Он предоставляет возможность аутентификации сервера и, опционно, клиента. SSL требует применения надежного транспортного протокола (например, TCP).

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

Все протокольные прикладные данные в SSL передаются зашифрованными с гарантией конфиденциальности.

Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства.

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

Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская — аутентифицируется опционно.

Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC – Message Authentication Code).

Спецификация протокола записей SSL Формат заголовка записи SSL

В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка.

Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным. При равенстве 1, посылаемый рекорд является security escape (в настоящее время не определено ни одного значения security escapes ; это зарезервировано для будущих версий протокола).

Код длины рекорда не включает в себя число байт заголовка (2 или 3). Для 2-байтового заголовка его длина вычисляется следующим образом (используется Си-подобная нотация):

RECORD-LENGTH = ((byte[0]  0x7F << 8)) | byte[1];

где byte[0] представляет собой первый полученный байт, а byte[1] — второй полученный байт. Когда используется 3-байтовый заголовок, длина рекорда вычисляется следующим образом:

RECORD-LENGTH = ((byte[0]  0x3F) << 8)) | byte[1];
IS-ESCAPE = (byte[0]  0x40) != 0;
PADDING = byte[2];

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

Отправитель "заполненного" рекорда добавляет заполнитель после имеющихся данных, а затем шифрует все это, благо длина этого массива кратна размеру блока используемого шифра. Содержимое заполнителя не играет роли. Так как объем передаваемых данных известен, заголовок сообщения может быть корректно сформирован с учетом объема субполя PADDING.

Получатель этого рекорда дешифрует все поле данных и получает исходную информацию. После этого производится вычисление истинного значения RECORD-LENGTH (с учетом наличия опционного PADDING ), при этом заполнитель из поля данные удаляется.

Формат информационных записей SSL

Часть данных рекорда SSL состоит из трех компонентов (передаваемых и получаемых в приведенном ниже порядке):

MAC-DATA[MAC-SIZE]
ACTUAL-DATA[N]
PADDING-DATA[PADDING]

ACTUAL-DATA представляет собой реальные переданные данные (поле данных сообщения). PADDING-DATA — это данные заполнителя, посылаемые когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения ( Message Authentication Code ).

Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:

M A C - D A T A = H A S H [ S E C R E T, A C T U A L -
 D A T A ,  P A D D I N G - DATA,SEQUENCE-NUMBER]

где SECRET передается хэш-функции первым, далее следует ACTUALDATA и PADDING-DATA, за которыми передается SEQUENCENUMBER. Порядковый номер ( SEQUENCE-NUMBER ) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи — big endian ).

MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).

Значение SECRET зависит оттого, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC ). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITEKEY для генерации MAC ).

SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются.

Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE ). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай "I/O Error" (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).

Окончательная проверка соответствия выполняется, когда приме- няется блочный шифр и соответствующий протокол шифрования. Объем данных в рекорде ( RECORD-LENGTH ) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место "I/O Error" (что вызовет разрыв соединения).

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

Для двухбайтового заголовка максимальная длина рекорда равна 32767 байтов. Для трехбайтового заголовка максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL.

Прежде чем послать первый рекорд SSL, все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVERHELLO.

Спецификация протокола диалога SSL Протокол диалога SSL

Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая служит для аутентификации клиента (смотри также http://book.itep.ru/6/ssl_65.htm).

Фаза 1

Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения hello. Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер, получив это сообщение, обрабатывает его и откликается сообщением SERVER-HELLO.

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

Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).

Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один — для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY ) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY ). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.

Наконец, после того как мастерный ключ определен, сервер посылает клиенту сообщение SERVER-VERIFY. Этот заключительный шаг аутентифицирует сервер, так как только сервер, который имеет соответствующий общедоступный ключ, может знать мастерный ключ.

Фаза 2

Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.

Раз партнер послал сообщение finished он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера. Как только оба партнера послали и получили сообщения finished, протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол.

Типовой протокол обмена сообщениями

В несколько упрощенном варианте диалог SSL представлен на рис 15.2.

(рис 15.2) Алгоритм работы SSL

Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах задействованы два участника диалога: клиент ( С ) и сервер ( S ). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что "нечто" зашифровано с помощью ключа key.

При отсутствии идентификатора сессии
Client-hello	C $$\to$$ S:	challenge, cipher_specs
server-hello	S $$\to$$ C:	connection-id,server_certificate,cipher_specs
client-master-key	C $$\to$$ S:	{master_key}server_public_key
client-finish	C $$\to$$ S:	{connection-id}client_write_key
server-verify	S $$\to$$ C:	{challenge}server_write_key
server-finish	S $$\to$$ C:	{new_session_id}server_write_key

Идентификатор сессии найден клиентом и сервером
сlient-hello	C $$\to$$ S:	challenge, session_id, cipher_specs
server-hello	S $$\to$$ C:	connection-id, session_id_hit
client-finish	C $$\to$$ S:	{connection-id}client_write_key
server-verify	S $$\to$$ C:	{challenge}server_write_key
server-finish	S $$\to$$ C:	{session_id}server_write_key

Использован идентификатор сессии и аутентификация клиента
сlient-hello	C $$\to$$ S:	challenge, session_id, cipher_specs
server-hello	S $$\to$$ C:	connection-id, session_id_hit
client-finish	C $$\to$$ S:	{connection-id}client_write_key
server-verify	S $$\to$$ C:	{challenge}server_write_key
request-certificate	S $$\to$$ C:	{auth_type,challenge’}server_write_key
client-certificate	C $$\to$$ S:	{cert_type,client_cert, response_data}client_write_key
server-finish	S $$\to$$ C:	{session_id}server_write_key

В последнем обмене response_data является функцией auth_type.

Ошибки

Обработка ошибок в протоколе соединений SSL весьма проста. Когда ошибка детектирована, обнаруживший его посылает своему партнеру сообщение. Ошибки, которые являются неустранимыми, требуют от клиента и сервера разрыва соединения. Серверы и клиент должны "забыть" все идентификаторы сессии, сопряженные с разорванным соединением. Протокол диалога SSL определяет следующие ошибки.

NO-CIPHER-ERROR

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

NO-CERTIFICATE-ERROR

Когда послано сообщение REQUEST-CERTIFICATE, эта ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима.

BAD-CERTIFICATE-ERROR

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

UNSUPPORTED-CERTIFICATE-TYPE-ERROR

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

Сообщения протокола диалога SSL

Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol).

После того как каждый из партеров определил пару ключей сессии, тела сообщений кодируются с помощью этих ключей. Для клиента это происходит после того, как он верифицировал идентификатор сессии, сформировал новый ключ сессии и послал его серверу. Для сервера это происходит после того, как идентификатор сессии признан корректным, или сервер получил сообщение клиента с ключом сессии. Для сообщений SSLHP (SSL Handshake Protocol) используется следующая нотация:

char MSG-EXAMPLE
char FIELD1
char FIELD2
char THING-MSB
char THING-LSB
char THING-DATA[(MSB<<8)|LSB];
...

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

Для записи THING-DATA, значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении. Например, если THING-MSB был равен нулю, а THING-LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт.

Длина кодов характеризуется целым числом без знака, и когда MSB и LSB объединяются, результат также является целым числом без знака. Если не указано обратного, длины полей измеряются в байтах.

Протокольные сообщения клиента

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

CLIENT-HELLO (Фаза 1; посылается открыто)
char MSG-CLIENT-HELLO
char CLIENT-VERSION-MSB
char CLIENT-VERSION-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char SESSION-ID-LENGTH-MSB
char SESSION-ID-LENGTH-LSB
char CHALLENGE-LENGTH-MSB
char CHALLENGE-LENGTH-LSB
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
char SESSION-ID-DATA[(MSB<<8)|LSB]
char CHALLENGE-DATA[(MSB<<8)|LSB]

Когда клиент впервые подключается к серверу, он должен послать сообщение CLIENT-HELLO. Сервер ожидает это сообщение от клиента первым. Любое другое сообщение от клиента в данных обстоятельствах рассматривается как ошибка.

Клиент посылает серверу свою версию SSL, спецификацию шифров, некоторые данные вызова ( challenge data ), и данные идентификатора сессии. Данные идентификатора сессии посылаются клиентом только в том случае, когда в его кэше имеется идентификатор сессии, а значение SESSION-ID-LENGTH не равно нулю. Когда идентификатора сессии нет, то значение SESSION-ID-LENGTH должно быть равно нулю. Данные вызова используются для аутентификации сервера. После того как клиент и сервер согласовали пару ключей сессии, сервер присылает сообщение SERVER-VERIFY с зашифрованной формой CHALLENGEDATA.

Заметим также, что сервер не пошлет сообщения SERVER-HELLO, пока не получит сообщения CLIENT-HELLO. Это делается так, чтобы сервер мог в первом сообщении клиенту определить состояние идентификатора сессии клиента (т.e. улучшить эффективность протокола и уменьшить объем обменов).

Сервер рассматривает сообщение CLIENT-HELLO и проверяет, поддерживает ли он версию программы клиента и хотя бы одну позицию в спецификации шифров клиента. Сервер может опционно отредактировать спецификацию шифров, удалив записи, которые он решил не поддерживать. Отредактированная версия будет прислана в сообщении SERVER-HELLO, если идентификатор сессии не находится в кэше сервера.

Значение CIPHER-SPECS-LENGTH должно быть больше нуля и кратно 3. Код SESSION-ID-LENGTH должен быть равен нулю или 16. Значение CHALLENGE-LENGTH должно быть больше 16 и $$\le$$ 32.

Это сообщение должно быть первым, посланным клиентом серверу. После его посылки клиент ждет сообщения SERVER-HELLO. Любое другое сообщение, присланное сервером (кроме ERROR ), не допустимо.

CLIENT-MASTER-KEY (Фаза 1; посылается вначале открыто)

char MSG-CLIENT-MASTER-KEY
char CIPHER-KIND[3]
char CLEAR-KEY-LENGTH-MSB
char CLEAR-KEY-LENGTH-LSB
char ENCRYPTED-KEY-LENGTH-MSB
char ENCRYPTED-KEY-LENGTH-LSB
char KEY-ARG-LENGTH-MSB
char KEY-ARG-LENGTH-LSB
char CLEAR-KEY-DATA[MSB<<8|LSB]
char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
char KEY-ARG-DATA[MSB<<8|LSB]

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

Поле CIPHER-KIND указывает, какой шифр выбран из спецификации CIPHER-SPECS сервера.

Данные CLEAR-KEY-DATA содержат открытую часть MASTERKEY.CLEAR-KEY-DATA комбинируются с SECRET-KEY-DATA, чтобы образовать MASTER-KEY, при этом SECRET-KEY-DATA составляет младшие байты MASTER-KEY.ENCRYPTED-KEY-DATA содержит секретные части MASTER-KEY, зашифрованные с использованием общедоступного ключа сервера. Шифруемые блоки формируются с использованием блоков типа 2 PKCS#1 [15.5]. Информационная часть блока имеет следующий формат:

char SECRET-KEY-DATA[SECRET-LENGTH]

SECRET-LENGTH равно числу байт каждого из ключей сессии. SECRET-LENGTH плюс CLEAR-KEY-LENGTH равно числу байт в ключе шифра (как это определено CIPHER-KIND ). Если после дешифрования SECRET-LENGTH окажется неравным ожидаемому значению, регистрируется ошибка. Ошибкой считается и ситуация, когда CLEARKEY-LENGTH не равно нулю и CIPHER-KIND является не экспортным шифром.

Если алгоритм ключа требует аргумента (например, вектора инициализации DES-CBC ), тогда поле KEY-ARG-LENGTH будет ненулевым и KEY-ARG-DATA будет содержать соответствующую информацию. Для алгоритмов SSL_CK_RC2_128_CBC_WITH_MD5, SSL_CK_RC2_128_CBC_ EXPORT40_WITH_MD5, SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 и SSL_CK_DES_192_EDE3_CBC_WITH_MD5 должны присутствовать данные KEY-ARG с длиной 8 байт.

Вычисление ключей сессии клиента и сервера является функцией CIPHER-CHOICE:

SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]

где KEY-MATERIAL-0[0-15] означает первые 16 байт данных KEYMATERIAL-0, с KEY-MATERIAL-0[0], образующим старший байт CLIENT-READ-KEY.

Данные передаются хэш-функции MD5, начиная с MASTERKEY, далее следует 0 или 1, затем вызов ( CHALLENGE ) и, наконец, CONNECTION-ID.

Заметим, что 0 означает ASCII -символ нуль (0x30), а не значение нуль. 1 означает ASCII -символ 1 (0x31). MD5 выдает 128 бит выходных данных, которые используются в качестве ключа алгоритма шифрования (старший байт хэша MD5 становится старшим байтом ключевого материала).

SSL_CK_DES_64_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]

Для DES-CBC 16-байтовый ключевой материал формируется с помощью MD5. Первые 8 байт дайджеста MD5 используются в качестве CLIENT-READ-KEY, в то время как оставшиеся 8 байт используются в качестве CLIENT-WRITE-KEY. Вектор инициализации берется из KEYARG-DATA.

SSL_CK_DES_192_EDE3_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE,
CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE,
CONNECTION-ID ]
CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]

Данные передаются хэш-функции MD5 в указанном порядке, слева направо: первым поступает MASTER-KEY, затем 0, 1 или 2, далее CHALLENGE и, наконец, CONNECTION-ID (идентификатор сессии).

Заметим, что 0 означает ASCII -символ нуль (0x30), а не код нуль. 1 означает ASCII -символ 1 (0x31). 2 означает ASCII -символ 2 (0x32).

Всего генерируется 6 ключей, 3 ключа читающей стороны для шифра DES-EDE3 и 3 — для пишущей стороны для функции DES-EDE3. Вектор инициализации формируется в KEY-ARG-DATA.

Вспомним, что MASTER-KEY передан серверу в сообщении CLIENTMASTER-KEY.CHALLENGE выдается серверу клиентом в сообщении CLIENT-HELLO.CONNECTION-ID передается клиенту от сервера в сообщении SERVER-HELLO. Это делает получаемые в результате ключи зависящими от исходной и текущей сессии. Заметим, что мастерный ключ никогда не используется для шифрования данных и, следовательно, не может быть легко раскрыт.

Сообщение CLIENT-MASTER-KEY должно быть послано после сообщения CLIENT-HELLO и до сообщения CLIENT-FINISHED. Сообщение CLIENT-MASTER-KEY должно быть послано, если сообщение SERVER-HELLO содержит значение SESSION-ID-HIT равное 0.

CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)

char MSG-CLIENT-CERTIFICATE
char CERTIFICATE-TYPE
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char RESPONSE-LENGTH-MSB
char RESPONSE-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char RESPONSE-DATA[MSB<<8|LSB]

Это сообщение посылается клиентом SSL в ответ на сообщение сервера REQUEST-CERTIFICATE.CERTIFICATE-DATA содержит данные, определенные значением CERTIFICATE-TYPE. Сообщение об ошибке ERROR посылается с кодом NO-CERTIFICATE-ERROR, если данный запрос не может быть обработан корректно (например, получатель сообщения не имеет зарегистрированного сертификата). CERTIFICATETYPE является одним из:

SSL_X509_CERTIFICATE

CERTIFICATE-DATA содержит подписанный сертификат X.509 (1988) [15.3].

RESPONSE-DATA несет в себе аутентификационные данные отклика. Эти данные зависят от значения AUTHENTICATION-TYPE, посланного сервером.

Когда код AUTHENTICATION-TYPE равен SSL_AT_MD5_WITH_RSA_ ENCRYPTION, тогда RESPONSE-DATA содержит цифровую подпись следующих компонентов (в указанном порядке):

KEY-MATERIAL-0

KEY-MATERIAL-1 (только если определено типом шифра)

KEY-MATERIAL-2 (только если определено типом шифра)

CERTIFICATE-CHALLENGE-DATA (из сообщения REQUESTCERTIFICATE )

Сертификат, подписанный сервером (из сообщения SERVERHELLO ).

Цифровая подпись формируется с привлечением MD5. Полученный хэш шифруется с использованием общедоступного ключа клиента, формат подписи согласуется со стандартом PKCS#1 [5]. Сервер аутентифицирует клиента путем верификации его цифровой подписи. Допускается добавление нового типа AUTHENTICATION-TYPE или идентификатора алгоритма цифровой подписи.

Это сообщение должно быть послано клиентом только в ответ на сообщение REQUEST-CERTIFICATE сервера.

CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)

char MSG-CLIENT-FINISHED
char CONNECTION-ID[N-1]

Клиент посылает это сообщение после успешной обработки соответствующего сообщения сервера. Заметим, что клиент должен быть готов к приему сообщений от сервера, пока не получит сообщение SERVER-FINISHED. Данные CONNECTION-ID представляют собой исходный идентификатор соединения сервера, посланный в его сообщении SERVER-HELLO и зашифрованный посредством согласованного ключа сессии.

N равно числу байт в посланном сообщении, таким образом, N-1 равно числу байт в сообщении за вычетом одного байта заголовка.

Для версии протокола 2 клиент должен посылать это сообщение после получения сообщения SERVER-HELLO. Если в сообщении SERVER-HELLO флаг SESSION-ID-HIT не равен нулю, тогда сообщение CLIENT-FINISHED посылается немедленно, в противном случае сообщение CLIENT-FINISHED посылается после сообщения CLIENTMASTER-KEY.

Протокольные сообщения сервера

Существует несколько сообщений, которые генерируются только серверами.

SERVER-HELLO (Фаза 1; посылается открыто)

char MSG-SERVER-HELLO
char SESSION-ID-HIT
char CERTIFICATE-TYPE
char SERVER-VERSION-MSB
char SERVER-VERSION-LSB
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char CONNECTION-ID-LENGTH-MSB
char CONNECTION-ID-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char CIPHER-SPECS-DATA[MSB<<8|LSB]
char CONNECTION-ID-DATA[MSB<<8|LSB]

Сервер посылает это сообщение после получения CLIENT-HELLO. Сервер возвращает флаг SESSION-ID-HIT, указывающий, известен ли серверу полученный идентификатор сессии (т.e. хранится ли он в кэше сервера). Флаг SESSION-ID-HIT будет не равен нулю, если клиент посылает серверу идентификатор сессии (в сообщении CLIENT-HELLO с SESSION-ID-LENGTH != 0 ), а сервер обнаружит этот идентификатор в своем кэше. Если флаг SESSION-ID-HIT не равен нулю, то поля CERTIFICATE-TYPE, CERTIFICATE-LENGTH и CIPHER-SPECSLENGTH будут содержать код нуль.

Значение CERTIFICATE-TYPE, если оно не равно нулю, должно содержать одну из перечисленных выше величин (см. информацию о сообщении CLIENT-CERTIFICATE ).

Когда флаг SESSION-ID-HIT равен нулю, сервер укладывает свой сертификат, спецификацию шифров и идентификатор соединения и посылает их клиенту. Используя эту информацию, клиент может сформировать ключ сессии и послать его серверу в сообщении CLIENTMASTER-KEY.

Когда флаг SESSION-ID-HIT не равен нулю, как сервер, так и клиент вычисляют новую пару ключей сессии, базируясь на мастерном ключе MASTER-KEY, который они получили при создании идентификатора SESSION-ID.SERVER-READ-KEY и SERVER-WRITE-KEY получаются из исходных ключей MASTER-KEY тем же способом, что CLIENTREAD-KEY и CLIENT-WRITE-KEY:

SERVER-READ-KEY = CLIENT-WRITE-KEY
SERVER-WRITE-KEY = CLIENT-READ-KEY

Заметим, что когда ключи получены и установлен флаг SESSIONID-HIT, а сервер обнаружил идентификатор сессии клиента в своем кэше, тогда данные KEY-ARG-DATA используются с момента, когда определен идентификатор SESSION-ID. Это делается потому, что клиент не посылает новых данных KEY-ARG-DATA (напомним, что данные KEY-ARGDATA посланы в сообщении CLIENT-MASTER-KEY ).

CONNECTION-ID-DATA представляет собой строку случайных байт, используемых сервером и клиентом в разных местах протокола. Сообщение CLIENT-FINISHED содержит зашифрованную версию CONNECTION-ID-DATA. Длина CONNECTION-ID должна лежать между 16 и 32 байтами, включительно.

CIPHER-SPECS-DATA определяет тип шифра и длину ключа (в битах), которые поддерживает принимающая сторона. Каждая спецификация SESSION-CIPHER-SPEC имеет длину 3 байта и выглядит как:

char CIPHER-KIND-0
char CIPHER-KIND-1
char CIPHER-KIND-2

где CIPHER-KIND равен одному из:

SSL_CK_RC4_128_WITH_MD5

SSL_CK_RC4_128_EXPORT40_WITH_MD5

SSL_CK_RC2_128_CBC_WITH_MD5

SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5

SSL_CK_IDEA_128_CBC_WITH_MD5

SSL_CK_DES_64_CBC_WITH_MD5

SSL_CK_DES_192_EDE3_CBC_WITH_MD5

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

Шифр SSL_CK_RC4_128_EXPORT40_WITH_MD5 имеет тип RC4, где некоторые ключи сессии посылаются открыто, а остальные в зашифрованном виде. MD5 используется в качестве хэш-функции для получения MAC и ключей сессии. Этот тип шифра предлагается для поддержки "экспортных" версий (т.e. версий протокола, которые могут быть применены за пределами Соединенных Штатов) клиента или сервера.

Набор	Уровень безопасности	Описание
DES-CBC3-MD5	Очень высокий	Тройной DES в режиме CBC, хэш MD5, 168-битный ключ сессии
DES-CBC3-SHA	Очень высокий	Тройной DES в режиме CBC, хэш SHA, 168-битный ключ сессии
RC4-MD5	Высокий	RC4, хэш MD5, 128-битный ключ
RC4-SHA	Высокий	RC4, хэш SHA, 128-битный ключ
RC2-CBC-MD5	Высокий	RC2 в режиме CBC, хэш MD5, 128-битный ключ
DES-CBC-MD5	Средний	DES в режиме CBC, хэш MD5, 56-битный ключ
DES-CBC-SHA	Средний	DES в режиме CBC, хэш SHA, 56-битный ключ
EXP-DES-CBC-SHA	Низкий	DES в режиме CBC, хэш SHA, 40-битный ключ
EXP-RC4-MD5	Низкий	Экспортное качество RC4, хэш MD5, 40-битный ключ
EXP-RC2-CBC-MD5	Низкий	Экспортное качество RC2, хэш MD5, 40-битный ключ
NULL-MD5	–	Без шифрования, хэш MD5, только аутентификация
NULL-SHA	–	Без шифрования, хэш SHA, только аутентификация

Экспортные реализации протокола диалога SSL будут иметь длины секретных ключей не более 40 бит. Для неэкспортных реализаций длины ключей могут быть больше (рекомендуется, по крайней мере, 128 бит). Клиенты и серверы могут иметь неперекрывающийся набор поточных шифров. Но это означает, что они не могут общаться.

Версия 2 протокола диалога SSL определяет, что SSL_CK_RC4_128_WITH_MD5 должен иметь длину ключа 128 бит. SSL_CK_RC4_128_EXPORT40_WITH_MD5 также имеет длину ключа 128 бит. Однако только 40 бит являются секретными (другие 88 пересылаются от клиента к серверу открыто).

Сообщение SERVER-HELLO посылается после того, как сервер получит сообщение CLIENT-HELLO, и до того, как сервер пошлет SERVER-VERIFY.

SERVER-VERIFY (Фаза 1; посылается шифрованным)

char MSG-SERVER-VERIFY
char CHALLENGE-DATA[N-1]

Сервер посылает это сообщение после пары ключей сессии ( SERVER-READ-KEY и SERVER-WRITE-KEY ), согласованных посредством идентификатора сессии или явно через спецификацию сообщения CLIENT-MASTER-KEY. Сообщение содержит зашифрованную копию данных CHALLENGE-DATA, посланных клиентом в сообщении CLIENT-HELLO.

N равен числу байт в сообщении, которое было послано, таким образом, N-1 соответствует числу байт в CHALLENGE-DATA за вычетом байта заголовка.

Это сообщение используется для верификации сервера следующим образом. Настоящий сервер имеет секретный ключ, соответствущий общедоступному ключу, который содержался в его сертификате, переданном в сообщении SERVER-HELLO. Таким образом, настоящий сервер сможет извлечь и реконструировать пару ключей сессии ( SERVER-READ-KEY и SERVERWRITE-KEY ). Наконец, только сервер, который выполнил корректно извлечение и дешифрование, может правильно зашифровать CHALLENGEDATA. Это, по существу, доказывает, что сервер имеет секретный ключ, который образует пару с открытым ключом из сертификата сервера.

Данные CHALLENGE-DATA должны иметь в точности ту же длину, что и в сообщении клиента CLIENT-HELLO. Их значение должно в точности согласовываться с посланным клиентом открыто в сообщении CLIENT-HELLO. Клиент должен дешифровать это сообщение и сравнить полученный результат с тем, что было послано, и только в случае успешного сравнения сервер считается достойным доверия. Если длины не совпадают или не согласуются значения, клиент соединение разрывает.

Это сообщение должно быть послано сервером клиенту либо после обнаружения идентификатора сессии (при этом посылается отклик SERVER-HELLO с флагом SESSION-ID-HIT не равным нулю), или когда сервер получает сообщение CLIENT-MASTER-KEY. Это сообщение должно быть послано до любого сообщения фазы 2 или до сообщения SEVER-FINISHED.

SERVER-FINISHED (Фаза 2; посылается зашифрованным)

char MSG-SERVER-FINISHED
char SESSION-ID-DATA[N-1]

Сервер посылает это сообщение, когда он удовлетворен результатом диалога с клиентом по поводу безопасности и готов продолжить передачу/прием протокольных данных верхнего уровня. Кэши идентификаторов сессии должны содержать копию MASTER-KEY, посланного в сообщении CLIENT-MASTER-KEY, в качестве мастерного ключа, предназначенного для генерации всех последующих ключей сессии.

Здесь N имеет то же значение, что и в определениях, представленных выше. Это сообщение должно посылаться после сообщения SERVERVERIFY.

REQUEST-CERTIFICATE (Фаза 2; посылается шифрованным)

char MSG-REQUEST-CERTIFICATE
char AUTHENTICATION-TYPE
char CERTIFICATE-CHALLENGE-DATA[N-2]

Сервер может выдать этот запрос в любое время диалога второй фазы, требуя присылки сертификата клиента. Клиент немедленно откликается посылкой сообщения CLIENT-CERTIFICATE, если он имеет сертификат, в противном случае присылается уведомление об ошибке с кодом NO-CERTIFICATE-ERROR. CERTIFICATE-CHALLENGE-DATA представляет собой короткую строку байтов (с длиной $$\ge$$ 16 байт и $$\le$$ 32 байт), которую клиент использует для отклика на этот запрос.

Значение AUTHENTICATION-TYPE используется, чтобы выбрать конкретные средства для аутентификации клиента. Определены следующие типы:

SSL_AT_MD5_WITH_RSA_ENCRYPTION

Тип SSL_AT_MD5_WITH_RSA_ENCRYPTION требует, чтобы клиент сформировал MD5-дайджест сообщения, используя информацию, как это описано выше в разделе о сообщении CLIENT-CERTIFICATE. Раз дайджест сформирован, клиент шифрует его, используя свой секретный ключ. Сервер аутентифицирует клиента, когда получает сообщение CLIENT-CERTIFICATE.

Это сообщение может быть послано после сообщения SERVERVERIFY и до сообщения SERVER-FINISHED.

Протокольные сообщения Клиент/Сервер

Эти сообщения генерируются как клиентом, так и сервером.

ERROR (посылается открыто или зашифровано)

char MSG-ERROR
char ERROR-CODE-MSB
char ERROR-CODE-LSB

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

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

Приложение A. ASN.1 синтаксис сертификатов

Сертификаты используются SSL для аутентификации серверов и клиентов. SSL Сертификаты базируются в основном на X.509 [15.3]. Сертификат X.509 содержит следующую информацию (в нотации ASN.1 [15.1]):

X.509-Certificate ::= SEQUENCE { certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier, signature BIT STRING }
CertificateInfo ::= SEQUENCE { version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,
issuer Name, validity Validity, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo }
Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL }

Для целей SSL наложены ограничения на некоторые значения полей X.509:

Поля X.509- Certificate::signatureAlgorithm и CertificateInfo::signature должны иметь идентичные значения.

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

Сертификаты верифицируются в несколько шагов. Во-первых, проверяется подпись сертификата, и если она некорректна, некорректен и сертификат (произошла транспортная ошибка или попытка модификации). Далее верифицируется поле CertificateInfo::issuer. Там должна быть ссылка на эмитента, которому приложение доверяет. Поле CertificateInfo::validity проверяется на текущую дату и верифицируется.

Наконец, проверяется поле CertificateInfo::subject. Эта проверка опционна и зависит от уровня доверия, необходимого приложению, которое использует SSL.

Приложение B. Идентификаторы объектов и типов атрибутов

SSL использует субнабор X.520 типов атрибутов, а также несколько специфических идентификаторов объектов.

Выбранные типы атрибутов
commonName { attributeType 3 }	Общее имя, содержащееся в поле эмитента сертификата или субъекта сертификата.
countryName { attributeType 6 }	Название страны.
localityName { attributeType 7 }	Название местоположения.
stateOrProvinceName { attributeType 8 }	Название штата или провинции.
organizationName { attributeType 10}	Название организации.
organizationalUnitName { attributeType 11 }	Название подразделения.

Идентификаторы объекта

md2withRSAEncryption { ... pkcs(1) 1 2 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD2 и RSA. Применяется при SSL -верификации подписи сертификата.

md5withRSAEncryption { ... pkcs(1) 1 4 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD5 и RSA. Применяется при SSL -верификации подписи сертификата.

rc4 { ... rsadsi(113549) 3 4 }

Алгоритм симметричного поточного шифра RC4, используемый SSL для массового шифрования.

Атаки

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

Раскрытие шифров

SSL зависит от нескольких криптографических технологий. Шифрование с общедоступным ключом RSA [15.5] используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным.

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

Атака открытого текста

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

Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу, является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее, чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например, 128 бит, как этого требует RC4.

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

Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (например, в случае неэкспортного варианта).

Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей "дикого хакера".

Атака отклика

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

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

Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать "правильную" сессию, основываясь на коде nonce, посланном сервером в сообщении SERVER-HELLO. Однако коды nonce SSL имеют длину, по крайней мере 128 бит, таким образом, злоумышленник будет вынужден записать примерно 2⁶⁴ кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.

Человек посередине

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

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

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

Страницы: