Инфраструктуры открытых ключей

Спецификация Secure Multipurpose Internet Mail Extension (S/MIME) предназначена для защиты наиболее популярного Интернет-сервиса - электронной почты. В силу важности этого сетевого сервиса предпринималось много попыток стандартизовать решения защищенной электронной почты. Одна из первых схем защиты - Privacy Enhanced Mail (PEM) - была предложена в 1985 году. Следующая схема защиты появилась в 1995 году и получила название MIME Object Security Services (MOSS). Несмотря на то, что в них содержалось множество хороших идей, негибкость и отсутствие совместимости отодвинули PEM и MOSS на вторые роли в сфере создания защищенного обмена сообщениями и были вытеснены системами Secure/MIME (S/MIME) и Pretty Good Privacy (PGP).

Протоколы S/MIME и PGP поддерживаются большинством программных продуктов, предназначенных для коллективной работы и защиты электронной почты. Наиболее распространенным и широко признанным стандартом обмена сообщениями стал разработанный в 1996 году стандарт S/MIME. Первоначально компанией RSA Data Security была предложена вторая версия спецификации S/MIME v2 [169], [170], позднее она была доработана рабочей группой организации IETF и в результате появилась новая, третья версия - S/MIME v3 [158], [159].

S/MIME обеспечивает защиту от трех типов нарушений безопасности: "подслушивания", или перлюстрации, искажения сообщений и фальсификации [22]. Защита от перлюстрации достигается путем шифрования сообщений. Для защиты от искажения почтового сообщения или фальсификации в S/MIME применяют цифровые подписи. Цифровая подпись гарантирует, что сообщение не было изменено в процессе передачи. Кроме того, ее наличие не позволяет отправителю сообщения отказаться от своего авторства.

Однако цифровая подпись не гарантирует конфиденциальность сообщения. В S/MIME эту функцию выполняет цифровой конверт. Шифрование осуществляется с помощью симметричного криптографического алгоритма типа DES, Triple-DES или RS2. Симметричный ключ шифруется с помощью открытого ключа получателя, а зашифрованное сообщение и ключ передаются вместе.

Спецификация S/MIME определяет два типа MIME-конверта: один для цифровых подписей, другой - для шифрованных сообщений. Оба типа базируются на синтаксисе криптографических сообщений стандарта PKCS#7 [198]. Если сообщение должно быть зашифровано, а шифртексту должны быть присвоены некоторые атрибуты, используются вложенные конверты. Внешний и внутренний конверт предназначаются для защиты цифровых подписей, а промежуточный конверт - для защиты шифртекста.

Помимо обеспечения целостности сообщения во время передачи, S/MIME идентифицирует обладателя конкретного открытого ключа с помощью сертификата X.509. Цифровой сертификат удостоверяет, что открытый ключ действительно принадлежит тому, кто является субъектом сертификата.

S/MIME v3 поддерживает следующие важные свойства, которые отсутствуют в S/MIME v2:

* заверенные цифровой подписью квитанции;

* метки безопасности;

* списки рассылки;

* гибкое управление ключами.

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

Метки безопасности позволяют отправителю задавать управляющие требования к содержанию сообщения. Чаще всего метка безопасности свидетельствует о включении в содержание сообщения частной или конфиденциальной информации.

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

Если адресаты сообщения территориально распределены (например, находятся на разных континентах), то отправитель посылает зашифрованное сообщение главному агенту MLA, главный агент пересылает его региональным агентам MLA, и, наконец, каждый региональный агент доставляет зашифрованное сообщение локальным получателям [70]. В этом случае сообщение участвует в каждой межконтинентальной коммуникации только один раз. Правда, если в списки рассылки каждого регионального MLA включены адреса всех других региональных агентов, может происходить многократная пересылка сообщения по кругу. Для обнаружения циклов анализируется атрибут "история распространения списка рассылки", содержащийся во внешнем конверте сообщения. Когда агент MLA получает сообщение, то проверяет историю распространения, чтобы определить, не обрабатывалось ли уже данное сообщение. Если сообщение обрабатывалось, оно просто удаляется. Внешний конверт с цифровой подписью обеспечивает целостность истории распространения списка рассылки.

S/MIME v2 обеспечивает только транспортировку ключей шифрования сообщений, а S/MIME v3 дополнительно поддерживает механизмы согласования ключей и внешнего распространения симметричных ключей шифрования ключей.

Поддержка защищенной электронной почты на основе PKI

Все сервисы, предлагаемыми S/MIME (обеих версий), полагаются на сертификаты и надежность связывания электронного адреса субъекта с его открытым ключом. Адрес электронной почты (часто называемый адресом RFC 822 [130]) должен быть представлен в дополнении сертификата Subject Alternative Name (альтернативное имя субъекта). Если используется вторая версия S/MIME, то адрес электронной почты указывается в качестве отличительного имени субъекта ( emailAddress ).

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

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

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

Протокол безопасности транспортного уровня Transport Layer Protocol (TLS) [142] обеспечивает защиту коммуникаций между приложениями, разработанными в архитектуре "клиент-сервер", в основном между web-браузером и web-сервером. Всемирная Паутина World Wide Web является наиболее популярным Интернет-сервисом после электронной почты. TLS наиболее часто применяется для защиты web-контента, но может использоваться с любым протоколом прикладного уровня. Спецификация TLS базируется на популярном протоколе Secure Socket Layer (SSL) [109], разработанном корпорацией Netscape. Эти протоколы создавались для обеспечения аутентификации, целостности и конфиденциальности данных, которыми обмениваются взаимодействующие друг с другом приложения. Оба протокола имеют двухуровневую организацию: протокол установления соединения (Handshake Protocol) и протокол передачи записей (Record Protocol).

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

Протоколы SSL и TLS независимы от протоколов прикладного уровня, поэтому любой протокол прикладного уровня может прозрачно оперировать поверх SSL и TLS. Протоколы SSL и TLS обеспечивают три сервиса безопасности [70]:

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

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

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

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

Протокол установления соединений

Протокол установления соединений Handshake Protocol состоит как бы из трех подпротоколов, которые позволяют выполнить аутентификацию сторон, согласовать алгоритмы и параметры безопасности для протокола передачи записей [19].

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

* идентификатора сеанса ( Session identifier ), то есть произвольной последовательности битов, выбранной сервером для идентификации сеанса;

* сертификата соединения ( Peer certificate ), представляющего собой сертификат X.509; этот элемент может отсутствовать, если аутентификация не требуется;

* метода сжатия ( Compression method ), то есть алгоритма сжатия данных перед их шифрованием;

* спецификатора шифрования ( Cipher spec ), который задает идентификаторы алгоритма шифрования данных и алгоритма хэширования, а также некоторые криптографические атрибуты (например, размер хэш-кода);

* главного секрета ( Master secret ), представляющего собой секретное значение, разделенное между клиентом и сервером;

* признака установления нового соединения ( Is resumable ) на основе текущего сеанса.

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

В результате работы протокола 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-шифрование;

* согласование ключей, если необходима поддержка согласования ключей методом Диффи-Хэллмана.

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

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

Совокупность механизмов 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 ), криптографических алгоритмах, ключах для аутентификации и шифрования и периоде их действия.

Контекст безопасности уникально идентифицируется тремя элементами:

* индексом параметров безопасности ( Security Parameters Index - SPI );

* целевым IP-адресом;

* идентификатором защитного протокола.

Итак, индекс SPI - это идентификатор контекста безопасности, который указывается в протоколе AH или ESP. Целевой IP-адрес идентифицирует соединение IPsec, он может быть индивидуальным или групповым адресом либо диапазоном адресов. В настоящее время обмен ключами IKE реализован только для индивидуальных адресов, а для групповых адресов или диапазонов распределение ключей выполняется вручную.

| | Хост | Маршрутизатор или межсетевой экран |

|Хост | Транспортный режим или туннельный режим | Туннельный режим |

|Маршрутизатор или межсетевой экран | Туннельный режим | Туннельный режим |

Таблица 17.1.Режимы, используемые для разных типов соединений

Протоколы обеспечения аутентичности и конфиденциальности могут применяться в двух режимах: транспортном и туннельном. Обычно транспортный режим используется хостами, при этом защищается только содержимое IP-пакетов и опционально - некоторые поля заголовков. В туннельном режиме защищается весь пакет: он инкапсулируется в другой IP-пакет, при этом происходит как бы "обертывание", или заключение в конверт, передаваемой порции данных [6]. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах, в роли которых могут выступать маршрутизаторы или межсетевые экраны (см. рис. 17.1).

Рис. 17.1. Стеки протоколов в разных режимах

В транспортном режиме заголовок протокола ( AH или ESP ) располагается в стеке протоколов после заголовка исходного IP-пакета и перед заголовками протоколов более высокого уровня [70]. В туннельном режиме заголовок протокола ( AH или ESP ) располагается в стеке протоколов между двумя заголовками: после заголовка внешнего IP-пакета и перед заголовком внутреннего исходного IP-пакета (см. рис. 17.1).

Протокол аутентифицирующего заголовка AH

протокол аутентифицирующего заголовка AH обеспечивает:

* целостность IP-пакетов, данных протоколов более высокого уровня и определенных полей IP-заголовков;

* аутентификацию источника данных (на основе IP-адреса узла сети или имени конечного пользователя);

* защиту от ложного воспроизведения ранее переданных IP-пакетов.

Контроль целостности базируется на проверке кода аутентификации хэшированного сообщения Hashed Message Authentication Code (HMAC), вычисляемого при помощи хэш-функции MD5 или SHA-1 с секретным симметричным ключом, который известен обеим взаимодействующим сторонам.

Рис. 17.2 иллюстрирует типичные поля данных протокола AH. Протокол содержит пять полей: Next Header, Length, SPI, Sequence Number и Authentication Data.

Рис. 17.2. Поля данных протокола AH

Поле Next Header (следующий заголовок) указывает, какой протокол более высокого уровня инкапсулируется при помощи AH. В туннельном режиме это поле обычно содержит IP v4 или IP v6, а в транспортном режиме - TCP, UDP или ICMP.

Поле Length (длина) задает размер заголовка протокола AH. Размер зависит от типа используемой хэш-функции, значение HMAC содержится в единственном поле переменной длины.

Поле SPI (индекс параметров безопасности) содержит 32-разрядное произвольное значение, которое идентифицирует контекст безопасности.

Поле Sequence Number (порядковый номер) используется для задания значения счетчика IP-пакетов (32-разрядного монотонно возрастающего) и защиты от воспроизведения пакетов. Отправитель пакета должен задавать это значение, а получатель пакета может либо обрабатывать его, либо игнорировать.

Поле Authentication Data (аутентификационные данные) содержит значение HMAC для данного IP-пакета. Это поле имеет переменную длину, которая должна быть кратна 32 разрядам.

При передаче пакета его порядковый номер, указываемый в поле Sequence Number, увеличивается, а затем поля IP-заголовка и протокола более высокого уровня хэшируются для создания HMAC на основе общего секретного симметричного ключа. После получения IP-пакета получателем выполняется та же самая последовательность операций. Если вычисленное им значение HMAC не соответствует значению, полученному по протоколу AH, то пакет не принимается. Кроме того, если контекст безопасности содержит информацию о применении средства защиты от воспроизведения пакетов, то значение поля Sequence Number уменьшается на единицу, то есть восстанавливается прежнее значение счетчика IP-пакетов.

Протокол инкапсулирующей защиты содержимого ESP

Протокол инкапсулирующей защиты содержимого ESP поддерживает конфиденциальность, аутентификацию и целостность IP-пакетов. Конфиденциальность обеспечивается путем шифрования содержимого IP-пакетов, а также части заголовка и трейлера (хвостовой части) протокола ESP ; надежность шифрования зависит, прежде всего, от используемого алгоритма шифрования. Аутентификация источника данных и защита целостности осуществляется на основе HMAC (как и в протоколе AH ). Хотя сервисы конфиденциальности и аутентификации (который включает целостность) являются опциональными, в каждом контексте безопасности должен быть задан, по крайней мере, один сервис безопасности.

В качестве алгоритмов шифрования в протоколе ESP используются алгоритмы DES и Triple-DES, для вычисления HMAC применяется хэш-функция типа MD5 или SHA-1. Рис. 17.3 иллюстрирует типичные поля данных протокола ESP. Заголовок ESP содержит два поля: SPI и Sequence Number, их синтаксис и семантика совпадает с одноименными полями протокола AH. Трейлер ESP состоит из четырех полей: Padding, Pad Length, Next Header и Authentication Data.

Поле Padding (заполнитель) используется для того, чтобы размер шифруемых данных был кратен размеру криптографического блока.

Рис. 17.3. Поля данных протокола ESP

Поле Pad Length (длина заполнителя) характеризует размер заполнителя и зависит от используемого алгоритма шифрования и заданного уровня конфиденциальности IP-трафика.

Поле Next Header (следующий заголовок) содержит информацию о том, какой протокол более высокого уровня инкапсулируется при помощи ESP. В туннельном режиме это поле обычно содержит IP v4 или IP v6, а в транспортном режиме - TCP, UDP или ICMP.

Поле Authentication Data (аутентификационные данные) содержит значение HMAC для данного IP-пакета. Это поле имеет переменную длину, которая должна быть кратна 32 разрядам. Если аутентификация источника данных или защита целостности не требуется, то это поле отсутствует или имеет нулевую длину.

При передаче пакета его порядковый номер, указываемый в поле Sequence Number, увеличивается, а затем поля заголовка ESP, протокола более высокого уровня и трейлера ESP хэшируются для создания HMAC на основе общего секретного симметричного ключа. Затем поля протокола более высокого уровня и трейлер ESP (за исключением аутентификационных данных) шифруются; если необходим начальный вектор, то он предваряет шифртекст. После получения IP-пакета получателем выполняется расшифрование и расчет того же самого значения HMAC. Если вычисленное им значение HMAC не соответствует значению, полученному в трейлере ESP, то пакет не принимается. Кроме того, если контекст безопасности содержит информацию об использовании средства защиты от воспроизведения пакетов, то значение поля Sequence Number уменьшается на единицу, то есть восстанавливается прежнее значение счетчика IP-пакетов.

Протокол обмена ключами IKE

Широкое использование IPsec требует масштабируемого, автоматизированного управления контекстами безопасности. Формирование контекстов безопасности по запросу и использование средств защиты от воспроизведения пакетов в протоколах AH и ESP невозможно без работы протокола обмена ключами в Интернете IKE [147]. Протокол IKE разработан на основе протокола управления ключами и контекстами безопасности Интернета - Internet Security Associations and Key Management Protocol (ISAKMP) [146] и протокола вычисления ключей - OAKLEY Key Determination Protocol (OAKLEY) [148]. Протокол ISAKMP обеспечивает независимую от криптографического механизма аутентификацию и задает структуру обмена ключами. Протокол IKE базируется на функциональности протокола ISAKMP, а для формирования симметричного ключа использует возможности протокола OAKLEY. В качестве алгоритма согласования ключей применяется алгоритм Диффи-Хэллмана.

Работа протокола IKE выполняется за два этапа. На первом этапе устанавливается аутентифицируемый и шифруемый канал связи. Это требует формирования двух контекстов безопасности - по одному для связи в одном направлении. Для аутентификации сторон используются сертификаты открытых ключей подписи (в качестве алгоритма цифровой подписи применяется DSA). На втором этапе формируются контексты безопасности для AH и ESP.

Поддержка безопасности IP-уровня на основе PKI

Сертификаты служат главными компонентами аутентификации на основе IKE. Когда идентифицируется хост или защитный шлюз, наиболее предпочтительной формой идентификационных данных являются DNS-имена или IP-адреса, которые указываются в дополнении сертификата Subject Alternative Name (параметры dNSName и iPAddress соответственно). При идентификации пользователя рекомендуется использовать адрес электронной почты или обычное имя. Адрес электронной почты содержится в дополнении сертификата Subject Alternative Name, а обычное имя входит в состав отличительного имени субъекта. Невозможность связать идентичность субъекта с его открытым ключом делает аутентификацию невозможной. Неправильная аутентификация на основе протокола IKE может привести к ложному связыванию ключа и реализации IPsec, в результате неавторизованный пользователь (или даже группа компьютеров) может получить доступ, например, к виртуальной частной сети.

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

Итак, сертификаты являются базовым компонентом сервисов безопасности, предоставляемых S/MIME, TLS и IPsec.

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

TLS при помощи сертификатов идентифицирует пользователей и серверы. От сертификатов зависят сервисы аутентификации, целостности и конфиденциальности. Сертификаты поддерживают шифрование потока, аутентификацию потока и целостность потока.

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