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

Подпись: аутентификация отправителя с использованием цифровых подписей

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

Рис. 6.27. Используемые в S/MIME цифровые подписи

1. Алиса решает отправить Бобу S/MIME-сообщение электронной почты. Клиент обмена сообщениями, видя, что сообщение должно быть подписано, генерирует хеш (используя MD5 или SHA-1) сообщения Алисы (результат в сборнике d - "digest").
2. Хеш шифруется клиентом обмена сообщениями с использованием секретного RSA-ключа Алисы (с применением RC2), и это означает, что только ее открытый RSA-ключ будет способен расшифровать хеш.
3. Зашифрованный хеш вместе с сообщением отправляется Бобу.
4. Клиент обмена сообщениями Боба использует открытый RSA-ключ Алисы для расшифровки хеша (снова с применением RC2) и получает расшифрованный хеш (результат в сборнике d).
5. Клиент обмена сообщениями Боба вычисляет новый хеш на основе отправленного Алисой текста (используя MD5, результат в сборнике d').
6. После этого клиент обмена сообщениями Боба сравнивает расшифрованный хеш (сборник d) и заново вычисленный хеш (сборник d'), что позволяет Бобу узнать, является ли цифровая подпись действительной или нет. Если два хеша одинаковы, то сообщение действительно пришло от Алисы и не было сфальсифицировано (подделано) в процессе транзита. Если они различаются, то либо сообщение не от Алисы, либо оно было сфальсифицировано (подделано) в процессе транзита.

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

Процесс цифровой подписи гарантирует две вещи:

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

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

Подробности проведения аутентификации

Давайте более подробно рассмотрим, как отправитель при использовании S/MIME фактически устанавливает подлинность того, что сообщение получено от того, от имени кого оно заявлено.

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

Что произойдет, если центр сертификации ( CA ), который подписал открытый ключ отправителя, не является доверенным? S/MIME решает эту проблему путем применения того, что известно как цепочка доверия (chain of trust). Это означает, что, когда отправитель посылает зашифрованное сообщение вместе с собственным сертификатом отправителя (который содержит его открытый ключ, подписанный CA третьей стороны), он отправляет также сертификат CA третьей стороны. Этот другой сертификат сам может быть подписан другим CA либо на самом деле может являться корневым сертификатом. До тех пор пока можно доверять какому-либо из сертификатов CA в этой иерархии, можно доверять CA, который подписал открытый ключ отправителя.

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

1. Подписанное сообщение.
2. Сертификат отправителя.
3. Информацию о CA, который подписал сертификат отправителя.

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

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

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

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

Означает ли это необходимость содержания трех наборов из пар открытого/секретного ключей и сертификатов? В этом нет необходимости, так как существует возможность экспорта S/MIME из одного клиента обмена сообщениями в другой с использованием стандарта PKCS#12, который мы кратко опишем.

Прозрачное и непрозрачное подписание

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

Если сообщение отправлено как непрозрачное (opaque), это означает, что подпись отправлена как тип MIME "application/pkcs7-signature" (приложение/подпись pkcs7). Соответственно несовместимый с S/MIME клиент не будет способен прочесть тип "pkcs7-signature" (подпись pkcs7). Клиент S/MIME сперва разобьет входящее сообщение, после чего проверит достоверность подписи.

Если сообщение отправлено как прозрачное (clear), это означает, что подпись вставлена как часть типа объекта MIME "multipart/signed" (многоэлементный/подписанный). Подпись генерируется из сообщения путем его хеширования, а тип "application/pkcs7-signature" вставляется во вторую часть типа MIME. Это означает, что любой получающий сообщение клиент будет способен получить обе части типа MIME – неподписанное сообщение и в виде прикрепления тип MIME "application/pkcs7-signature".

Возможность взаимодействия с другим S/MIME-совместимым программным обеспечением

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

Соответственно целью стандарта PKCS #12 является обеспечить возможность взаимодействия пары открытого/закрытого ключей и сертификатов с другими, способными поддерживать S/MIME, клиентами обмена сообщениями. Это довольно важно, так как в противном случае если бы пользователь запрашивал с помощью Internet Explorer сертификат от такого сетевого CA как VeriSign, то этот пользователь был бы способен применять его только в связке с Outlook Express. Аналогично если бы пользователь запрашивал сертификат с помощью Netscape Navigator, то этот пользователь был бы способен применять его только в связке с Netscape Messenger.

Получение сертификата клиента для S/MIME

Чтобы клиент был способен отправлять подписанные и зашифрованные сообщения электронной почты с использованием S/MIME, необходимо иметь сертификат X.509. Нынешнее поколение способных работать с S/MIME клиентов обмена сообщениями обеспечивает возможность генерирования запроса сертификата с помощью находящегося в Сети CA. После того как сертификат клиента был запрошен (и утвержден), он устанавливается в способный работать с S/MIME клиент обмена сообщениями таким образом, что клиент может подписывать и шифровать любые сообщения электронной почты.

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

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

увеличить изображение
Рис. 6.28. Циркуляция сертификатов и S/MIME-сообщений

Шаги, требуемые для запроса сертификата клиента в S/MIME-клиент, как показано на рис. 6.28, приведены далее.

1. Из клиента обмена сообщениями, способного работать с S/MIME, пользователь осуществляет запрос сертификата клиента. Применяемый пользователем совместно с клиентом обмена сообщениями браузер предложит клиенту заполнить форму запроса сертификата на Web-сайте доверенного центра сертификации.
2. 1. По мере передачи запроса на рассмотрение он инициирует генерирование браузером секретного ключа и его локальное сохранение. (Этот процесс имеет свойство отличаться от браузера к браузеру, и по этой причине лучше всего прочесть документацию именно по вашему браузеру для изучения специфики того, как это делается.)
   2. Соответствующий открытый ключ включается в заголовок HTTP как часть запроса сертификата (в формате PKCS #10), адресуемого Web-центру сертификации.
3. Центр сертификации (CA) обрабатывает запрос и возвращает инструкции относительно того, как принять сертификат посредством электронной почты. Инструкции предусматривают URL-адрес и ID для приема в целях использования в том месте, где может быть получен подписанный сертификат клиента.
4. Пользователь заходит по назначенному URL-адресу, вводит ID для получения и забирает подписанный сертификат клиента.
5. Подписанный сертификат клиента устанавливается в клиент обмена сообщениями, способный работать с S/MIME.
6. 1. Существует возможность пойти на один шаг дальше и опубликовать сертификат пользователя путем отправки его одному из поставщиков услуг по предоставлению открытых каталогов. Зачастую сами центры сертификации будут иметь возможность предоставить подобную услугу.
   2. В качестве альтернативы существует также возможность использовать для опубликования сертификата клиента одним из поставщиков услуг по предоставлению открытых каталогов сам клиент обмена сообщениями, способный работать с S/MIME.

Получение сертификата получателя в интересах S/MIME

В нынешнем поколении клиентов обмена сообщениями, способными работать с S/MIME, существует несколько методов получения сертификата получателя.

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

Второй метод заключается в обеспечении доступа к LDAP в целях предоставления пользователям возможностей поиска в онлайновых каталогах (таких, как Four11, Bigfoot, Switchboard и т. д.). Если требуемый сертификат сохранен в одном из этих каталогов, пользователь будет способен добавить его в персональный адресный список клиента обмена сообщениями, способного работать с S/MIME.

6.2.10 Использование Lotus Notes 6 в качестве S/MIME-клиента

Раз в интересах сообщества пользователей Lotus Notes существует инфраструктура на основе CA внутри организации, то для пользователей так же просто отправлять и получать S/MIME-сообщения, как и отправлять и получать почтовые сообщения Notes. В этом разделе мы покажем, как объединены в одно целое клиент Lotus Notes 6, сервер Domino Server 6 и S/MIME.

Как реализован протокол S/MIME в Notes R5.0

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

В версии 6 файл Notes ID, который содержит собственные сертификаты Notes, также используется в качестве контейнера для хранения сертификатов X.509 v3. Когда сертификат запрашивается Web-центром сертификации (либо центром сертификации Domino, если он реализован внутри организации, либо центром сертификации третьей стороны), он запрашивается через браузер Notes. Когда запрос на сертификат клиента утвержден, он сохраняется в файле ID пользователя Notes.

Notes имеет возможность создания безопасных копий файлов ID пользователей Notes. Безопасная копия представляет собой, по существу, открытый ключ и связанные с ним подписанные сертификаты. В текущей версии Notes не существует возможностей создания безопасных копий сертификатов X.509. Поэтому невозможно осуществлять импорт или экспорт сертификатов S/MIME-клиента в Notes или из него за исключением случаев использования стандарта PKCS #12.

Для подписания электронной почты с применением S/MIME пользователь должен установить свой сертификат X.509 в свой файл Notes ID. Для пользователя существует возможность применять либо сертификат, выпущенный Notes, сертификат, выпущенный центром сертификации Domino, либо сертификат, выпущенный любым другим, представляющим третью сторону, коммерческим центром сертификации. Эта процедура в точности соответствует той, которая описана в разделе о центре сертификации Domino.

Перед тем как осуществить шифрование сообщения, как было описано ранее, пользователю необходимо получить сертификат получателя. Клиент Notes зашифрует сообщение с применением открытого ключа получателя. В Lotus Notes 6 сертификаты клиента получателей хранятся в каталоге Domino (Domino Directory).

Отправка и получение зашифрованных S/MIME-сообщений

Когда пользователь Lotus Domino 6 предпринимает попытку отправить зашифрованное сообщение, применяется сертификат X.509 получателя, причем на основе произведенного пользователем выбора относительно того, применять ли формат MIME либо формат Notes для отправки почты напрямую в Интернет или для сообщений, которые адресованы по интернет-адресам. И наоборот, пользователи также могут управлять форматом входящей почты согласно своим пользовательским предпочтениям. Формат сообщения определяет выбор метода шифрования.

Notes использует S/MIME-шифрование для исходящей почты в следующих ситуациях:

• Пользователь выбирает опцию directly to Internet (напрямую в Интернет) в поле Send outgoing mail (Отправить исходящую почту) закладки Mail (Почта) текущего документа расположения Location (как показано на рис. 6.29). Почтовые сообщения, которые отправляются из этого расположения, будут употреблять формат MIME.
  

  
  увеличить изображение
  Рис. 6.29. Текущий документ Location пользователя: закладка Mail
• Пользователь выбирает опцию MIME format (формат MIME) в поле Format for messages addressed to Internet addresses (Формат для сообщений, адресованных по интернет-адресам) закладки Mail (Почта) текущего документа расположения Location. Почтовые сообщения, отправляемые из этого расположения по интернет-адресам, которые не могут быть найдены в персональной адресной книге (Personal Address Book) или каталоге Domino, будут использовать S/MIME.
• Пользователь ставит разрешение в поле When receiving unencrypted mail, encrypt before storing in your mail file (При получении незашифрованной почты шифровать перед сохранением в своем почтовом файле) закладки Basics (Основные) документа Person пользователя. Почта, отправляемая этому пользователю, будет применять MIME.
• Пользователь создает сообщение с применением формы, в которой поле тела сообщения Body конструкции формы имеет установленной в свойствах поля опцию Store contents as HTML and MIME (Сохранять содержимое как HTML и MIME). Если получатель может принять либо формат Notes, либо формат MIME (или если Notes не может найти для получателя документ Person), сообщение будет использовать формат MIME.

Помимо требований, определенных для S/MIME, сертификат X.509 получателя должен быть доступен в персональной адресной книге или в каталоге Domino. Если Notes не может найти сертификат получателя, то пользователь увидит отображенным окно сообщения об ошибке.

Если параметры установлены должным образом, то отправка зашифрованного сообщения сведется только к выполнению пользователем щелчка мыши на кнопке Delivery Options (Опции доставки) и выборе позиции для отметки Encrypt (Шифровать). В противном случае все было бы так, как если бы пользователь отправлял почту Notes.

увеличить изображение
Рис. 6.30. Диалоговое окно безопасности: закладка Mail

Пользователь может также выбрать вариант шифрования всех отправляемых почтовых сообщений. Это выполняется в клиенте Lotus Notes 6 путем выбора пунктов меню File – Security – User Security (Файл – Безопасность – Безопасность пользователя), выбора после этого закладки Mail (Почта) в новом диалоговом окне безопасности пользователя (User Security) и далее выбора в ней позиции для отметки Encrypt mail that you send (Шифровать почту, которую вы отправляете), как показано на рис. 6.30.

Отправка подписанных S/MIME-сообщений

Для пользователей существует возможность подписывать либо отдельные почтовые сообщения, либо все отправляемые ими почтовые сообщения. Перед подписанием сообщений пользователи должны убедиться в том, что ими получены свои собственные сертификаты X.509 в их файлах ID пользователя Notes.

Для осуществления подписи отдельного почтового сообщения при завершении его написания пользователь щелкает мышью на кнопке Delivery Options (Опции доставки) и выбирает позицию для отметки Sign (Подписать).

В качестве альтернативы для подписания всех отправляемых пользователем почтовых сообщений пользователь может выбрать пункты меню File – Security – User Security (Файл – Безопасность – Безопасность пользователя), после чего выбрать закладку Mail (Почта) в новом диалоговом окне безопасности пользователя (User Security) и далее в ней выбрать позицию для отметки Sign mail that you send (Подписывать почту, которую вы отправляете).

Получение подписанных S/MIME-сообщений

После получения подписанной электронной почты Notes попытается проверить достоверность подписи.

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

" Signed By: Bob, at 10:52 AM, According To: TestCertAuthority".

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

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

Наконец, для пользователя существует также возможность вручную сохранять адрес отправителя и сертификаты X.509 в своей персональной адресной книге. При просмотре подписанной S/MIME-почты пользователь должен выбрать пункты меню Actions – Tools – Add Sender to Address Book (Действия – Инструменты – Добавить отправителя в адресную книгу). Здесь важно обратить внимание на то, что этот сертификат не является перекрестным сертификатом Интернета. Это значит, что он не применяется при отправке и получении подписанной S/MIME-почты, а употребляется для шифрования сообщений от пользователя к отправителю.

6.3 Краткие выводы

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

Данная лекция показала роль, которую могут играть инфраструктуры открытых ключей в установлении подобного доверия и обеспечении уверенности в его сохранности. Это выполняется путем использования сертификатов X.509 совместно с установленными протоколами (к примеру, SSL) и стандартами обмена сообщениями (к примеру, S/MIME). Также в этой лекции показано, как в Notes и Domino реализованподдержка сертификатов X.509 и то как эти сертификаты запрашиваются, утверждаются, генерируются и устанавливаются в инфраструктуре Notes и Domino.