Безопасность на прикладном уровне: PGP и S/MIME

6.1. Электронная почта

Сначала обсудим электронную почту (e-MAIL) как систему.

Архитектура E-MAIL

Рис. 6.1 показывает самый общий сценарий при одностороннем почтовом обмене. Предположим, что Алиса работает в организации, которую обслуживает почтовый сервер. Каждый служащий связан с почтовым сервером через местную сеть связи (LAN). Или, альтернативно, Алиса могла быть связана с почтовым сервером провайдера (ISP - Information Server Provider) через региональную сеть связи (телефонная линия или кабельная линия). Боб находится также в одной из вышеупомянутых ситуаций.

увеличить изображение
Рис. 6.1. Архитектура E-MAIL

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

Когда Алиса должна передать сообщение Бобу, она вызывает агента пользователя программы (UA), чтобы подготовить сообщение. Она использует другую программу- почтовый агент (MTA), -чтобы передать сообщение серверу почты на ее стороне. Обратите внимание, что MTA - программа "клиент-сервер" с клиентом, который, установлен в компьютере Алисы и на сервере, который установлен на сервере почты.

Сообщение, полученное на сервере почты на стороне Алисы, поставлено в очередь со всеми другими сообщениями; очередь создается для каждого направления в соответствующий пункт назначения. В случае Алисы ее сообщение поступает на сервер почты Боба. Клиент-сервер MTA отвечает за почтовую передачу между этими двумя серверами. Когда сообщение достигает сервера почты пункта назначения, оно попадает в почтовый ящик Боба в виде специального файла, который сохраняет сообщение, пока оно не будет извлечено Бобом.

Когда Боб должен извлечь свои сообщения (файл), включая сообщение, передаваемое Алисой, он вызывает другую программу, которую мы называем агентом доступа к сообщению (MAA - Message Access Agent). MАА также разработан как программа "клиент-сервер", установленная и в компьютере Боба, и на сервере почты.

Есть несколько важных положений об архитектуре почтовой системы.

• Передаваемая электронная почта от Алисы к Бобу накапливается в памяти. Алиса может передать электронную почту сегодня; Боб, будучи занятым, может проверить свою электронную почту три дня спустя. Всё это время электронная почта сохраняется в почтовом ящике Боба, пока он не возьмет ее.
• Главная связь между Алисой и Бобом проходит две прикладных программы: MTA-клиента в компьютере Алисы и клиента ААС в компьютере Боба.
• MTA -программа клиента - принимающая программа; клиент помещает сообщение, когда Алиса должна его передать. Программа клиента MАА - выдающая программа; клиент перемещает сообщение, когда Боб готов извлечь свою электронную почту.
• Алиса и Боб не могут непосредственно в данный момент связать MTA-клиента, используемого на стороне передатчика, и MTA -сервер, используемый на стороне приемника. Поэтому требуется, чтобы MTA -сервер функционировал все время, потому что Боб не знает, когда сообщение прибудет. Это практически невозможно, потому что Боб, вероятно, выключает свой компьютер, когда не нуждается в нем.

Почтовая безопасность

Передача электронной почты - одноразовая активность. Характер этой активности отличается от тех, которые мы увидим в следующих двух лекциях. В IPSec или SSL мы предполагаем, что две стороны создают сеанс между собой и обмениваются данными в обоих направлениях. В электронной почте нет никакого сеанса. Алиса и Боб не могут создать сеанс. Алиса передает сообщение Бобу, а когда-нибудь позже Боб читает сообщение и, может быть, сразу не способен передать ответ. Мы будем рассматривать безопасность однонаправленного сообщения, потому что Алиса передает сообщения Бобу полностью независимо от того, что Боб передает Алисе.

Криптографические алгоритмы

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

Имеется одно решение для основного протокола - выбирать один алгоритм из заданного множества для каждой криптографической операции и заставить Алису использовать только эти алгоритмы. Это решение очень сужает возможности и ограничивает действия двух сторон.

Лучшее решение для основного протокола - определить множество алгоритмов для каждой операции, которые пользователь может применить в его системе. Алиса включает название (или идентификаторы) алгоритмов, которые она использовала в электронной почте. Например, Алиса может выбрать трехкратный DES для шифрования/дешифрования и MD5 для хэширования. Когда Алиса передает сообщение Бобу, она включает соответствующие идентификаторы для трехкратного DES и MD5 в свое сообщение. Боб получает сообщение и сначала извлекает идентификаторы. Тогда он знает, какой алгоритм использовать для дешифрования и какой - для хэширования.

Криптографическая секретность

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

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

Сертификаты

Прежде чем мы обсудим любой почтовый протокол безопасности, нужно рассмотреть в еще одну проблему: некоторые очевидные алгоритмы общедоступного ключа, которые должны использоваться для почтовой безопасности. Например, мы должны зашифровать ключ засекречивания или подписать сообщение. Для того чтобы зашифровать ключ засекречивания, Алиса нуждается в открытом ключе Боба; для подписи и верификации сообщения Боб нуждается в открытом ключе Алисы. Так что для того, чтобы посылать маленькое заверенное и конфиденциальное сообщение, необходимы два открытых ключа. Как Алиса может быть уверена в открытом ключе Боба, и как Боб может быть уверен в открытом ключе Алисы? Каждый почтовый протокол безопасности имеет различные методы сертификации ключей.