В результате работы протокола Handshake Protocol формируются криптографические параметры. Когда клиент и сервер начинают взаимодействие, то согласовывают версию протокола, криптографические алгоритмы, аутентифицируют друг друга (по желанию) и используют криптографию с открытыми ключами для разделения общего секрета. Работа протокола Handshake Protocol выполняется за шесть шагов [70].
* 1-й шаг. Обмен приветственными сообщениями для согласования алгоритмов и обмена случайными числами.
* 2-й шаг. Обмен криптографическими параметрами для согласования начального секрета.
* 3-й шаг. Опциональный обмен сертификатами и криптографической информацией для взаимной аутентификации клиента и сервера.
* 4-й шаг. Генерация главного секрета на основе начального секрета и обмен случайными числами.
* 5-й шаг. Формирование параметров безопасности для протокола передачи записей.
* 6-й шаг. Оповещение о расчете тех же самых параметров безопасности и корректном завершении соединения.
Когда клиент желает установить новое соединение на основе данного сеанса или повторить этот сеанс, то отправляет свое приветственное сообщение с идентификатором сеанса, который должен быть возобновлен. Если сервер все еще хранит в кэш-памяти параметры сеанса и желает восстановить соединение, то в ответ отправляет свое приветственное сообщение с тем же самым идентификатором сеанса. В этот момент клиент и сервер обмениваются сообщениями о смене параметров шифрования и завершении формирования соединения.
При обмене сертификатами и ключами передаются данные, необходимые для генерации начального секрета. Если используется алгоритм RSA, то клиент генерирует случайное начальное число и шифрует его при помощи открытого RSA-ключа сервера. Если применяется алгоритм Диффи-Хэллмана, клиент и сервер обмениваются открытыми ключами, а затем в качестве начального секрета используется результат вычисления ключа согласования ключей по алгоритму Диффи-Хэллмана.
Главный секрет и симметричные ключи генерируются при помощи псевдослучайной функции PRF (PseudoRandom Function), полученной на основе алгоритмов SHA-1 и MD5. Чтобы гарантировать безопасность, применяются две разные однонаправленные хэш-функции. При первом применении функции PRF генерируется главный секрет из начального секрета и случайных чисел, полученных на основе приветственных сообщений клиента и сервера. В результате повторного применения функции PRF к тем же самым исходным данным получают два симметричных ключа, два значения начального вектора и два значения MAC (кода аутентификации сообщения) секрета. При возобновлении сеанса используется уже известное для данного сеанса значение главного секрета, но генерируются новые случайные числа на основе новых приветственных сообщений клиента и сервера, поэтому в результате формируется новый ключевой материал.
Протокол передачи записей использует один симметричный ключ, одно значение начального вектора и один MAC секрета для защиты трафика "клиент-сервер", а также другие значения перечисленных параметров для защиты трафика "сервер-клиент", - в целом, для корректной работы протокола передачи записей требуется шесть секретных чисел.
Протокол передачи записей
Протокол передачи записей Record Protocol состоит из нескольких подуровней. Обработка данных протокола прикладного уровня заключается в их разбиении на управляемые блоки, сжатии, снабжении имитовставкой, шифровании и последующей передаче результата. Полученные данные обрабатываются в обратном порядке: расшифровываются, проверяются на целостность, подвергаются декомпрессии, сборке, а затем доставляются приложению [6].
На подуровне фрагментации информация разбивается на записи, длина каждой записи не превышает 16384 байтов. Допускается агрегирование нескольких однотипных сообщений в одну запись, а также разбиение одного сообщения протокола прикладного уровня на несколько записей. На подуровне сжатия выполняется сжатие или декомпрессия всех фрагментов. Очевидно, что при компрессии не должно быть потери данных. Затем вычисляется имитовставка, то есть проверяется целостность сжатой записи, а полученное значение и сжатая запись шифруются. Проверка целостности осуществляется при помощи кода аутентификации сообщения (MAC) или кода аутентификации, полученного на основе хэш-кода сообщения (HMAC).
После принятия данных текст расшифровывается, для проверки его целостности повторно вычисляется MAC, причем вычисления выполняются с использованием порядкового номера записи с целью обнаружения потерянных, лишних или повторно сжатых записей.
Поддержка безопасности транспортного уровня на основе PKI
Сертификаты являются центральным компонентом всех сервисов аутентификации и управления ключами, предлагаемых как TLS, так и SSL. Эти сервисы полагаются на связывание идентичности субъекта с его открытым ключом. Для идентификации web-серверов рекомендуется использовать DNS-имена (типа www.alpha.com) и указывать их в дополнении сертификатов Subject Alternative Name (параметр dNSName ). Если DNS-имя не представлено в сертификате, то для идентификации используется отличительное имя субъекта.
Обычно при взаимодействии клиента и сервера сервер предъявляет сертификат, а клиент - нет, в результате чего происходит односторонняя аутентификация сервера клиентом, который сохраняет свою анонимность. Сервер может потребовать от клиента аутентификации, запрашивая сертификат по протоколу Handshake Protocol. В этом случае клиент должен иметь сертификат и предоставить его серверу. Обычно клиент предъявляет сертификат ключа подписи. В процессе верификации заверенного цифровой подписью сообщения, отправленного по протоколу Handshake Protocol, выясняется, способен ли клиент сгенерировать подпись при помощи своего секретного ключа, соответствующего открытому ключу подписи, который содержится в сертификате.
Сертификаты, используемые для поддержки безопасности транспортного уровня, также должны содержать дополнение Key Usage, отражающее соответствующее назначение открытого ключа, который содержится в сертификате:
* цифровая подпись, если необходимо выполнять верификацию подписей;
* шифрование ключей, чтобы обеспечить RSA-шифрование;
* согласование ключей, если необходима поддержка согласования ключей методом Диффи-Хэллмана.
Клиент должен быть уверен, что открытый ключ принадлежит серверу. Если используется некорректный открытый ключ, то постороннее лицо может получить начальный секрет и возможность сгенерировать главный секрет и все другие секретные параметры, вычисляемые с его помощью. Сертификат подтверждает принадлежность открытого ключа серверу.
При аутентификации клиента сервер полагается на принадлежность открытого ключа клиенту и принимает решение о возможности доступа. Если используется некорректный открытый ключ, то доступ к серверу может получить постороннее лицо, а не та сторона, которой доступ необходим. Сертификат обеспечивает необходимое связывание открытого ключа с идентичностью клиента.
Средства безопасности IP-уровня
Совокупность механизмов IPsec обеспечивает основу для защиты сетевого трафика на IP-уровне, безопасности IP-пакетов, защищенного взаимодействия мобильных систем с корпоративной сетью, реализации виртуальных частных сетей (Virtual Private Networks - VPN) и т.п. Семейство спецификаций IPsec представлено серией из 10 документов, разработанных рабочей группой IP Security Protocol организации IETF и содержащих сведения об архитектуре IPsec [143], формировании контекстов безопасности, управлении ключами и базовых протоколах. Ядро IPsec составляют три протокола: протокол аутентифицирующего заголовка (Authentication Header, AH) [144], протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload, ESP) [145] и протокол обмена ключами в Интернете (Internet Key Exchange, IKE) [147]. Функции по поддержанию защищенного канала передачи данных по сетям IP распределяются между этими протоколами следующим образом:
* протокол AH обеспечивает целостность IP-пакетов, аутентификацию источника данных, а также защиту от воспроизведения ранее переданных IP-пакетов;
* протокол ESP поддерживает конфиденциальность, аутентификацию и целостность IP-пакетов, а также частичную защиту от анализа трафика;
* протокол IKE позволяет взаимодействующим сторонам автоматически генерировать и безопасно распределять симметричные секретные ключи.
Контексты безопасности
Контексты безопасности (Security Associations) образуют основу криптографических сервисов безопасности на базе протоколов IPsec. Для защиты двусторонней связи между узлами сети необходимы два контекста безопасности: один - для входящих потоков, другой - для исходящих. Контексты безопасности содержат информацию об IP-адресах, типе защитного протокола ( AH или ESP ), криптографических алгоритмах, ключах для аутентификации и шифрования и периоде их действия.