Скачиваний:
93
Добавлен:
18.10.2019
Размер:
14.08 Mб
Скачать

4. КРШlmографuческuепротоколы вэлекmрОll1lOU КОМ..,.,ерЦИII 1I вдОКУ,1fеl1mообороmе 239 Протокол SSL выполняет следующие функции' обеспечения

безопасности информации:

1)конфиденциальность: ДЛЯ этого в процессе выполнения про­ токола рукопожатия вырабатывается общий симметричный секрет­ ный ключ, на котором шифруются все последующие сообщения;

2)целостность: с этой целью для каждого сообщения генериру­ ется код аутентификации сообщения CМessage Authentication Code- МАе);

3)аутентичность: при выполнении протокола рукопожатия сервер проходит аутентификацию для клиента, используя симмет­ ричный секретный ключ либо открытый ключ (второй ключ обычно реализуется через сертификаты открытых ключей).

Протокол SSL требует зашифровки и расшифровки каждого со­ общения и, следовательно, дополнительно вносит значительную вы­

числительную нагрузку на участников протокола и увеличивает рас­

ход ресурсов.

Существуют две версии протокола SSL: SSL У2.0 и SSL VЗ.О, между которыми обеспечена обратная совместимость, т. е. сервер, реализующий SSL .0, должен быть способен устанавливать со­ единения и принимать запросы от клиентов, реализующих SSL У2.0. Основные различия между двумя реализациями протокола заклю­ чаются в следующем: во-первых, SSL У2.0 не поддерживает аутен­ тификацию клиента для сервера, а во-вторых, SSL У3.0 поддержива­ ет больше типов шифрования в спецификации шифров.

В соответствии с архитектурой ТСРЛР протокол SSL реализует­ ся на верхней границе транспортного уровня. Напомним, что и сам протокол SSL, в свою очередь, является уровневым. Функции SSL заключаются в том, что он берет данные с прикладнаго уровня, пе­ реформатирует их и передает на транспортный уровень. Протокол SSL управляет сообщениями таким образом:

отравитель выполняет следующие действия: берет сообщение с верхнего уровня;

разбивает (фрагментирует) данные на управляемые блоки; сжимает данные (эта функция - опциональная); генерирует МАе; зашифровывает данные;

передает результат обработки на нижний уровень;

240Запечкиков С. В. Криптографическиепротоколы u и'( примененив

получатель выполняет следующие действия:

берет данные с нижнего уровня; расшифровывает данные;

проверяет МАС при помощи общего для отправителя и

получателя секретного ключа; проводит декомпрессию данных (если применялось сжатие);

восстанавливает сообщение из фрагментов; пересылает сообщение на верхний уровень.

Сеанс SSL работает в одном ИЗ двух различных состояний: в се­ ансовом либо в состоянии соединения. Протокол рукопожатия SSL нР координирует состояния клиента и сервера. Вдобавок существу­ ют состояния чтения и записи, определенные для того, чтобы коор­ динировать шифрование в соответствии с сообщениями об измене­ ниях в спецификации шифров. Когда какая-либо сторона протокола посылает сообщение об изменении в спецификации шифров, она меняет состояние ожидаемой записи на состояние текущей записи. Опять-таки, если какая-либо из сторон получает сообщение об из­ менении в спецификации шифров, она изменяет состояние ожидае­

мого чтения на состояние текущего чтения.

Сеансовое состояние описывается структурой данных, которая

включает следующие компоненты:

идентификатор сеанса (Session identifier) - произвольная после­ довательность байтов, выбранная сервером ДЛЯ того, чтобы идентифицировать активное или возобновляемое сеансовое со­

стояние; ..

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

сжатия данных;

спецификация шифра - поле, которое специфицирует исполь­ зуемый протоколом алгоритм шифрования, а также алгоритм ге­ нерации и проверки МАС (если такой алгоритм не используется, устанавливается значение null);

мастер-секрет - поле, содержащее 48-байтовый общий секрет

для клиента и для сервера;

4. Криптографические протоколы в элеЮnРО/ll/ОЙ КО.Лt.мерЦIIU u вдОКУJllеllП200бороmе 241 флаг восстановления - флаг, индицирующий, может ли сеанс быть использован для новых соединений.

Состояние соединения описывается структурой данных, которая

включает следующие компоненты:

случайные величины сервера и клиента - произвольная последо­ вательность байтов, выбираемая клиентом и сервером для каж­

дого соединения;

секретный ключ. записи МАС сервера - секрет, используемый сервером для операций с МАС; секретный ключ записи МАС клиента - секрет, используемый клиентом для операций с МАе;

ключ записи сервера - ключ шифрования, используемый для за­ шифровки отправляемых сервером данных и расшифровки при­

нимаемых клиентом данных; ключ записи клиента - ключ шифрования, используемый для

зашифровки отправляемых клиентом данных и расшифровки

принимаемых сервером данных;

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

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

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

время этапа «переговоров» (это будет показано чуть ниже).

242 ЗапечииковС. В. Криптографическиепротоколы и ихпримененив

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

нения протокола рукопожатия.

.

 

Клиент

 

Сервер

 

 

~r_

___r

LClient----------Неllо

ertifi сO\te)

(Client Ке.у Exchange)

(CertificOIte Verify) Finished

Change Cipher Spec'S

Server Hello (Certificate)

(SelVer Кеу Ехс hi3nge) (Certific:tte Request) Server Hello Done

Finished

Change Cipher Specs

Пересылка данных

Пересыпка данных

Рис. 4.14. Протокол рукопожатия в SSL

Шаг 1. Клиент запрашивает установление соединения, посылая стартовое сообщение (Client Hello), которое содержит:

желаемый номер версии протокола; информацию о времени (текущее время и дата по системному

таймеру в стандартном 32-битовом формате, принятом в UNIX-

подобных ОС);

.

идентификатор сеанса (опционально): если он не специфициро­ ван) сервер будет пытаться восстановить предыдущие сеансы либо вернет сообщение об ошибке; пакет параметров шифрования - список криптографических оп­

ций, подцерживаемых клиентом: режимы аутентификации, ме-

4. Криптографические протоколы (J ::ыекmРОll1lОйКОJll.мерции 1/ (J док)щеJlJJtообороmе 243 тоды обмена ключами, алгоритмы шифрования, генерации и проверки МАе);

методы сжатия, поддерживаемые клиентом;

случайную величину.

Шаг 2. Сервер оценивает параметры, присланные в начальном сообщении клиента, и направляет ему свое начальное сообщение (Server Неflо), включающее следующие параметры, выбранные сер­ веромдля использованияв сеансе протоколаSSL:

номер версии;

информацию о времени (текущее время и дата по системному таймеру в стандартном 32-битовом формате, принятом в UNIX- подобных ОС); идентификатор сеанса; пакет параметров шифрования;

метод сжатия;

случайную величину.

После начального сообщения сервер посылает следующие сообщения:

сертификат сервера Certificate (если в протоколе требуется ау­ тентификация сервера);

сообщение сервера об обмене ключами Server Кеу Exchange (если сертификат недоступен или сертификат содержит только ключ подписи);

запрос сертификата Certificate Request (если в протоколе требу­ ется аутентификацияклиента).

Наконец, сервер посылает сообщение о завершении серии на­ чальных сообщений Server Hella Done и ожидает ответ клиента.

Шаг 3. Клиент посылает следующие сообщения:

если сервер посылал запрос сертификата, клиент должен послать

ему в ответ либо сертификат Certificate, либо сообщение об от-

сутствии сертификата;

.

если сервер посылал сообщение сервера об обмене ключами, клиент посылает сообщение клиента об обмене ключами Client Кеу Exchange, основываясь на асимметричном алгоритме, опре­ деленном в начальных сообщениях протокола;

244 Запечников С. В. Криптографическиепротоколы и IIX применепив

если клиент посылал сертификат, клиент проверяетсертификат сервера и посылает сообщение о проверке сертификатаCertifi· cate Verify, содержащее результат проверки.

Затем клиент посылает финальное сообщение Finished, свиде­ тельствующее о завершении согласовательной части протокола. Клиент также посылает сообщение об изменении спецификации шифра Change Cipher Specs, чтобы сгенерировать разделяемые секреты. Здесь необходимозаметить, что эта фаза не контролирует­

ся протоколомрукопожатия- она управляется протоколом измене­

ния спецификации шифра.

Шаг 4. Сервер посылает ответное финальное сообщение Finished, показывающее,что согласовательнаячасть протокола завер­ шилась. Затем он отправляетсообщение об изменении специфика­

ции шифраChange Cipher Specs.

Шаг 5. Наконец, партнеры по сеансу связи каждый по отдельности генерируют ключ шифрования, из которого они затем генерируют ключи, которые будут использовать для шифрования сеанса связи. Протокол рукопожатия изменяет состояние протокола SSL на состоя­ ние соединения. Теперь все данные, поступающие с прикладного уров­ ня, передаются как специальные сообщения другой стороне.

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

Во время выполнения протокола рукопожатия оба партнера по протоколу сгенерировали мастер-ключ. Из этого ключа они генери­

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

это означает следующее:

4. КРШIIJlOграфllчеСКllе протоколы в элеЮnРОllllOй КО,М,lIеРЦIllI Il в докумеl/lnообороmе 245 Протокол обеспечивает конфиденциальность,поскольку сооб­ щениезашифрованопри помощисимметричногоблочногошиф­ ра (например,DES или RC4).

Протоколом гарантирована целостность сообщения, поскольку оно содержит код аутентификации (МАС) самого сообщения и

ключевого материала, выведенного из мастер-ключа.

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

открытого ключа сервера.

Протокол записи (SSL RP). Если мастер-ключ уже был опреде­ лен, клиент и сервер могут использовать его ДЛЯ шифрования дан­ ных прикладных программ. Протокол записи специфицирует фор­ мат для этих сообщений. В общем случае он включает хеш-код со­ общений, гарантирующий, что они не были изменены в процессе передачи по каналу связи и что сообщение целиком было зашифро­ вано, используя симметричный алгоритм шифрования. Обычно здесь применяются алгоритмы RC2 или RC4, хотя спецификацией поддерживаются также алгоритмы DES, Triple-DES и IDEA.

Спецификация SSL предполагает использование для защиты тра­ фика блочных шифров в режиме сцепления блоков (cipher block chaining - СВС). Пусть р;;;; F:, .,., ~ - открытый текст с длиной каж­

дого 'блока Pj , равной длине блока открытого текста алгоритма блочного шифрования, используемого протоколом. Со = lV - век­ тор инициализации, sk - секретный ключ шифра. Блоки шифртек­ ста вычисляются в этом режиме следующим образом:

С, = Esk (~Ee СН}i = 1,1. Последовательность блоков Со'''''С1 И

является шифртекстом, хотя передавать Со нет необходимости, так

как получатель уже знает его или закон его получения - эта величи­ на не является секретной. Для расшифрования текста получатель

вычисляет Р; = »:(с,)Еес.;i = 1,1. Обычной практикойявляется

выбор нового, случайного значения вектора инициализации Со для

246 Запечников С. В. Криптографические протоколы u их применение

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

Необходимо иметь ввиду, что на такой протокол при опреде­ ленных условиях возможно осуществление атаки по выбранным от­ крытым текстам. В научной литературе описаны примеры таких атак. Предположим, что противник желает проверить свое предпо­ ложение о том, что определенный блок открытого текста принимает некоторое фиксированное значение, а именно противник, наблю­ дающий шифртекст СО' "', CJ , хочет определить, равен ли блок от­

крытого текста Р, величине Р*. При этом противник знает вектор инициализации, который будет использован при шифровании сле­ дующего сообщения: он равен последнему блоку шифртекста теку­ щего сообщения С/. Посмотрим, что будет, если противник вынудит отправителя, сообщения зашифровать сообщение г', первый блок

которого ~ равен Сj-l Ef) С, ffi Р *. Первый блок шифртекста бу-

дет вычислен отправителем следующим образом:

С1' ;::: Esk

(~' ЕВС[);::: Esk ( с., ЕВС} ЕВР*вэС});::: Esk *(f)Cj _1 ) •

Однако мы также знаем, что Cj ;::: E.sk ] (f) Cj _t ) . А это означает,

,

тогда и т?лько тогда, когда Pj ;::: Р*. Таким путем про-

что С1 ;::: С]

тивник может проверить свою догадку относительно того, что блок открытого текста Pj принимает значение Р*. В частности, если про­ тивник знает, ЧТО Р] - одна из двух возможных величин, то против­ ник сможет определить истинное значение этого блока открытого текста всего за одну попытку. Если же блок может принимать одно из N возможных значений, противник сможет узнать его значение в среднем за NI2 попытки.

4. КРUllтографическиепротоколы в :JЛекmрОIlJIOU КОАшерЦII" и в дОКУАfе"Л100бороmе 247 Такая атака показывает, что протокол SSL не в полной мере удовлетворяет принятому в криптографии определению безопасно­ сти схем шифрования и, например, в случае, если открытым текстом является короткий пароль, противник может раскрыть его полно­ стью, осуществляя словарную атаку (т. е. перебирая наиболее веро­ ятные значения этого пароля). Рассмотрим условия, при которых та­ кая атака на пароль или РIN-код становится возможной. Во-первых, злоумышленник должен знать номер j блока открытого текста, со­ держащего интересующую его информацию. Для этого достаточно, например, знать формат сообщений протокола НТТРS. Во-вторых, противник должен знать блок шифртекста Cj - 1 - его он получает из открытого канала связи. В-третьих, противник должен знать значе­ ние вектора инициализации для следующего сообщения: он получа­ ет его из наблюдения предыдущего сеанса связи. Наконец, нужно иметь возможность подставить выбранный открытый текст в первый блок следующего передаваемого отправителем сообщения. Это, по­ жалуй, самое трудновыполнимое для противника условие. Однако и это условие осуществимо, если противник сумеет убедить пользова­ теля установить дополнительный компонент веб-браузера, реали­ зующий такую программную закладку. При выполнении всех пере­ численных условий такая атака становится вполне реальной. из на­ учной литературы известны и другие, более «тонкие» примеры атак на стандартные режимы работы блочных шифров, которые стано­ вятся возможными не в силу неправильной или неудачной конст­ рукции самих режимов шифрования, а именно в силу технических

особенностей их реализации.

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

следующие:

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

248 Запечников С. В. Криптографическиепротоколы 11 их примененив

сконфигурирована. Это создает дополнительные преграды для злоумышленника, который пытается осуществить несанкциони­ рованный доступ к сети.

Архитектура IPSec относится к сетевому уровню коммуникаци­ онной модели OSI, инкапсулируя обычные IР-пакеты. Поскольку при этом образуется туннельное соединение, любая ПП (веб­ приложение, электронная почта, FТР-сервис, протокол telnet, го­ лосовой протокол VoIP и др.) может использовать его без огра­ ничений. Это может быть большим преимуществом для сред со множеством ПП, но может стать недостатком в том случае, если удаленный клиент будет скомпрометирован.

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

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

на архитектуру TCPIIP, поскольку сами IP-пакеты при этом не

подвергаются внешним изменениям.

Вместе с этим нельзя не отметить следующие несомненные пре- имущества решений, основанных на спецификации SSL:

SSL - это общепринятая, повсеместно реализуемая специфика­ ЦИЯ, и большинство неб-браузеров уже имеют встроенную реа­

лизацию SSL, т. е. почти каждый компьютер, имеющий выход в

Интернет, имеет готовЫЙ «клиентскЫЙ компонент», реали­

зующий этот метод.

SSL допускает более точный контроль доступа к ресурсам сис­ темы. Во-первых, он реализует туннели для каждой отдельно взятой ПП, а не для всей корпоративной локальной сети. Таким образом, пользователи SSL-соединений могут иметь доступ только к тем ПЛ, к которым им был разрешен доступ, а не ко всей сети. Во-вторых, в этом случае гораздо легче присваиватъ

различным пользователям различные права доступа и осуществ­

лять более тонкий контроль над каждой попыткой доступа. SSL удобна для «разовых» соединений с пользователями, работаю-