Ольга Полянская - Инфраструктуры открытых ключей
* заверенные цифровой подписью квитанции;
* метки безопасности;
* списки рассылки;
* гибкое управление ключами.
Заверенные цифровой подписью квитанции позволяют отправителю сообщения удостовериться в том, что оно было получено адресатами без изменений. Получатель сообщения не может сгенерировать валидную квитанцию до тех пор, пока не проверит подпись отправителя на полученном сообщении.
Метки безопасности позволяют отправителю задавать управляющие требования к содержанию сообщения. Чаще всего метка безопасности свидетельствует о включении в содержание сообщения частной или конфиденциальной информации.
Обычно отправитель сообщения шифрует его один раз при помощи симметричного ключа. Затем отправитель должен зашифровать симметричный ключ отдельно, используя открытый ключ того адресата, которому он направляет свое сообщение. Если количество адресатов велико, возникает необходимость делегировать функции шифрования доверенному серверу. Такой сервер называют агентом списка рассылки (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 ) на основе текущего сеанса.
Эти характеристики затем используются для установки параметров безопасности в протоколе передачи записей. Возможность установить несколько защищенных соединений во время одного сеанса особенно важна, когда клиенту и серверу необходимо установить несколько кратковременных соединений.
