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

Расширенный SMTP (ESMTP)

ESMTP, или расширенные службы для простого протокола пересылки электронной почты (Extended Services for Simple Mail Transport Protocol), представляют структуру для расширения службы SMTP путем определения средств, с помощью которых сервер SMTP может информировать клиента SMTP о поддерживаемых им расширениях службы.

Расширения службы SMTP зарегистрированы в комитете по цифровым адресам в Интернете [Internet Assigned Numbers Authority (IANA)]. Примеры расширений SMTP включают: SMTP по TLS/SSL и уведомления о статусе доставки (Delivery Status notifications).

Расширение службы SMTP для аутентификации

Когда клиент передает сообщение серверу SMTP, который поддерживает расширение аутентификации SMTP (AUTH=LOGIN), это позволит клиенту произвести аутентификацию пользователя по отношению к серверу. Расширение также защищает подлинность аутентификации в том случае, когда сообщение пересылается от одного SMTP-сервера к другому (предполагая, что оба SMTP-сервера поддерживают расширение). Однако, как упоминалось ранее, эта комбинация имени и пароля закодирована только с использованием base64.

Расширение службы SMTP для безопасного SMTP по SSL и TLS

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

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

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

Примечание. Служба SMTP из состава Domino 6 поддерживает несколько расширений SMTP, включая SSL-передачу по TCP/IP.

Разрешите расширения SMTP, используя Lotus Domino Administrator или клиент Lotus Notes и выполнив следующие действия:

1. В Lotus Domino Administrator (или в окне Domino Directory в клиенте Notes) щелкните мышью на закладке Configuration (Конфигурация). Выберите Messaging (Обмен сообщениями), вид Configurations (Конфигурация).
2. Щелкните мышью либо на кнопке Add Configuration (Добавить конфигурацию), либо на кнопке Edit Configuration (Редактировать конфигурацию) для открытия документа Configuration (Конфигурация).
3. Щелкните мышью на закладке Router/SMTP (Маршрутизатор/SMTP), после чего на закладке Advanced (Расширенные). Это обеспечит доступ к расширенным параметрам конфигурации SMTP, как показано на рис. 6.25.
   

   
   увеличить изображение
   Рис. 6.25. Расширенные параметры конфигурации SMTP
4. Отсюда вы можете сконфигурировать свойства расширений SMTP на вашем сервере Domino.

Шифрование сообщений

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

Кроме того, само сообщение не зашифровано. Это может быть решено путем использования другого расширения SMTP, которое обеспечивает, что соединения SMTP (клиент/сервер или сервер/сервер) шифруются с использованием пары открытого/закрытого ключей. Однако это снова не гарантирует, что сообщение во время транзита будет зашифрованным на каждом отдельном двухточечном отрезке пути передачи сообщения на всем своем пути по направлению к получателю. Даже если было бы возможным гарантировать, что сообщение электронной почты было корректно аутентифицировано доверенными серверами SMTP и полностью зашифровано на двухточечных отрезках пути передачи сообщения на своем пути от отправителя к получателю, все равно это еще не позволит избежать возможности того, что сообщение не было сфальсифицировано (подделано) кем-то другим.

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

6.2.8 Безопасный обмен сообщениями при использовании PGP

PGP (Pretty Good Privacy), является высоко безопасной системой шифрования на основе открытых ключей, предназначенной для отправки безопасной почты по всему миру. Она была разработана Майком Циммерманом^{6Здесь ошибка: автор PGP – Филипп Циммерман (Phil Zimmermann). См.: http://www.pgp.com/company/history.html.} в 1991 г. и свободно опубликована в Интернете. Клиент PGP и информацию о PGP можно найти по следующему URL-адресу:

http://www.pgp.com/

Доступна также система GnuPG (Gnu Privacy Guard), которая является полной и бесплатной заменой PGP. Так как она не использует патентованный алгоритм IDEA, она может быть применена без каких-либо ограничений. GnuPG является приложением, совместимым с RFC2440 (OpenPGP). Версия 1.0.0 была выпущена 7 сентября 1999 г. На текущий момент постоянной является версия 1.2.2. GnuPG относится к бесплатному программному обеспечению. Система может свободно использоваться, модифицироваться и распространяться согласно условиям общедоступной лицензии (General Public License) GNU. Информацию о GPG можно найти по следующему URL-адресу:

http://www.gnupg.org

Информацию относительно общедоступной лицензии GNU можно найти по адресу:

http://www.gnu.org/copyleft/gpl.html

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

Более новый стандарт, называемый OpenPGP, разрешает иерархический подход для согласования работы центров сертификации, сертификатов X.509 и других уже принятых стандартов. За дополнительной информацией об OpenPGP обратитесь к следующему URL-адресу:

http://www.openpgp.org/

Формат сообщений OpenPGP разъяснен в RFC2440, доступном по адресу:

http://www.ietf.org/rfc/rfc2440.txt

Пока PGP рассматривается как некоторая хорошая альтернатива для принятия по всему миру, большинство корпораций увлечены реализацией протокола S/MIME для обеспечения обмена сообщениями как внутри, так и за пределами организации. Мы рассмотрим S/MIME в последующем разделе и подробно опишем, как он работает совместно с клиентом Lotus Notes и сервером Lotus Domino.

6.2.9 Безопасный обмен сообщениями при использовании S/MIME

S/MIME (Secure Multipurpose Internet Mail Extension) является технологией обеспечения безопасности электронной почты, разработанной компанией RSA для шифрования и цифрового подписания сообщений электронной почты.

Рабочая группа S/MIME завершила работу по пяти предложенным стандартам, которые были обобщены в спецификации S/MIME версии 3. Они приведены далее.

• Синтаксис криптографического сообщения (draft-ietf-smime-cms; ftp://ftp.ietf.org/rfc/rfc2630.txt).
• Спецификация сообщения S/MIME версии 3 (draft-ietf-smime-msg; ftp://ftp.ietf.org/rfc/rfc2633.txt).
• Обработка сертификата S/MIME версии 3 (draft-ietf-smime-cert; ftp://ftp.ietf.org/rfc/rfc2632.txt).
• Синтаксис запроса сертификата (draft-ietf-smime-crs; http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-smime-crs-00.txt).
• Улучшенные службы обеспечения безопасности для S/MIME ( draft-ietf-ietf-ess^{7Здесь ошибка: имеется в виду draft-ietf-smime-ess.} ; ftp://ftp.ietf.org/rfc/rfc2634.txt).

Lotus Notes и Domino 6 полностью поддерживают S/MIMEv3.

Шифрование сообщения происходит для всего контента сообщения или только для определенных частей MIME путем осуществления прогона их через алгоритм шифрования, который использует открытый ключ получателя. S/MIME применяет алгоритм открытых ключей для обмена ключами и для обеспечения цифровых подписей, предлагая для этого два симметричных алгоритма шифрования: Triple-DES и RC2. Регулируемый размер ключа в алгоритме RC2 делает его особенно полезным для приложений, предназначенных для экспорта за пределы США, когда требуемым алгоритмом открытых ключей является RSA.

Как работает S/MIME

В этом разделе мы более подробно рассмотрим то, как работает S/MIME. Нашей целью является помочь вам понять, как в Notes и Domino 6 осуществлена реализация и поддержка S/MIME. S/MIME предоставляет пользователям следующие основные возможности:

• шифрование в целях обеспечения секретности сообщения;
• определение фальсификации (подделки);
• подписание – аутентификация отправителя с помощью цифровых подписей;
• возможность взаимодействия с другим S/MIME-совместимым программным обеспечением;
• легкая интеграция в Netscape Messenger;
• межплатформенный обмен сообщениями.

С помощью этих возможностей достижимы следующие преимущества:

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

Шифрование для обеспечения секретности сообщения

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

Для отправки зашифрованного S/MIME-сообщения необходимо получить открытый ключ получателя сообщения и зашифровать сообщение с его использованием. Так как единственным человеком, который имеет связанный с этим ключом секретный ключ, является получатель, сообщение может быть безопасно отправлено с уверенностью в том, что только его получатель будет способен расшифровать это сообщение. Данный метод полностью подобен методу, используемому в Notes, и представлен на рис. 6.16 и 6.26.

Это практическое применение гибридного решения, которое мы рассматривали в лекции об основах безопасности. Пронумерованные на рис. 6.26 шаги описаны далее.

Рис. 6.26. Шифрование сообщения электронной почты в S/MIME

1. Алиса решает отправить зашифрованное S/MIME-сообщение Бобу. Клиент обмена сообщениями, видя, что сообщения нуждаются в шифровании, генерирует случайный ключ шифрования (секретный ключ, который обычно упоминается как ключ сеанса; впоследствии новый случайный ключ генерируется каждый раз, когда отправляется зашифрованное S/MIME-сообщение) и зашифровывает с его помощью сообщение.
2. Ключ шифрования сеанса шифруется (с применением либо Triple-DES, либо RC2) с помощью открытого ключа получателя и прикрепляется к сообщению, а это означает, что расшифровать его будет способен только открытый^{8Здесь ошибка: расшифровать сообщение можно только при помощи секретного ключа Боба.} RSA-ключ Боба.
3. Зашифрованный текст и зашифрованный ключ отправляются Бобу посредством SMTP.
4. Клиент обмена сообщениями Боба использует секретный RSA-ключ Боба для расшифровки зашифрованного ключа (снова с применением RC2) и получает расшифрованный ключ сеанса. Здесь гарантируется секретность, потому что для расшифровки ключа сеанса, необходимого для расшифровки сообщения, может быть использован только секретный ключ Боба.
5. Клиент обмена сообщениями Боба использует расшифрованный ключ сеанса для расшифровки почтового сообщения (с применением либо Triple-DES, либо RC2, в зависимости от того, с использованием какого алгоритма было зашифровано сообщение), результатом чего является расшифрованное исходное сообщение, которое было отправлено Алисой.

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

Рассматривая показанный на рис. 6.26 процесс, мы увидим, что на самом деле этот метод в S/MIME часто упоминают как "цифровой конверт" (digital envelope), в силу чего сообщение фактически шифруется с использованием более короткого симметричного шифра, после чего симметричный шифр шифруется с использованием более длинного асимметричного ключа и отправляется вместе с зашифрованным сообщением.

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

Обнаружение подделки

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