Безопасность на прикладном уровне: 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 в свое сообщение. Боб получает сообщение и сначала извлекает идентификаторы. Тогда он знает, какой алгоритм использовать для дешифрования и какой - для хэширования.

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

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

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

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

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

Сертификаты

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

6.2. PGP

Первый протокол, который мы обсудим в этой лекции, называется Очень хорошей конфиденциальностью (PGP - Pretty Good Privacy). PGP был изобретен Филом Цимерманном (Phil Zimmermann), чтобы обеспечить секретность, целостность и установление подлинности электронной почты. PGP может использоваться, чтобы создать безопасное почтовое сообщение или надежно сохранить файл для будущего извлечения.

Сценарии

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

Открытый текст

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

(рис 6.2) Сообщение с обычным текстом

Целостность сообщения

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

(рис 6.3) Сообщение с подтверждением подлинности передатчика

Сжатие

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

(рис 6.4) Сообщение со сжатым текстом

Конфиденциальность с одноразовым ключом сеанса

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

(рис 6.5) Конфиденциальное сообщение

Преобразование кода

Другая услуга, предоставляемая PGP, - преобразование кода. Большинство почтовых систем позволяет передать сообщение, состоящее только из символов ASCII. Чтобы перевести символы, не входящие в множество ASCII, PGP использует преобразование Radix-64. Каждый посылаемый символ (после того как будет зашифрован) преобразуется в код Radix-64, который мы обсудим позже в этой лекции.

Сегментация

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

Кольца ключей

Во всех предыдущих сценариях мы предполагали, что Алиса должна передать сообщение только Бобу. Но это не единственный вариант передачи. Возможно, Алиса должна передать сообщения многим людям; ей нужны кольца ключей. В этом случае Алиса нуждается в кольце открытых ключей, включающем ключ(и), принадлежащий каждому человеку, которому Алиса должна передать или от которого может получить сообщение. PGP -разработчики определили кольцо частных/открытых ключей. Алиса может иметь причины время от времени изменить пару ключей. Другой случай: Алиса, возможно, желает, чтобы ее ключи соответствовали различным группам людей (друзья, коллеги и так далее). Поэтому каждый пользователь должен иметь два множества колец: кольцо частных/общедоступных ключей и кольца общедоступных ключей других людей. рис. 6.6 показывает сообщество четырех человек, где каждый имеет кольцо пары частных/открытых ключей и, в то же самое время, изображены кольца открытых ключей, принадлежащих другим людям в этом сообществе.

(рис 6.6) Кольца ключей в PGP

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

Алиса должна передать сообщение другому человеку в сообществе.

Она использует свой секретный ключ, чтобы подписать дайджест.

Она использует открытый ключ приемника, чтобы зашифровать недавно созданный ключ сеанса.

Она шифрует сообщение и подписанный дайджест с созданным ключом сеанса.

Алиса получает сообщение от другого человека, состоящего в этом сообществе.

Она использует свой секретный ключ, чтобы расшифровать ключ сеанса.

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

Она использует свой открытый ключ, чтобы проверить дайджест.

PGP -алгоритмы

В PGP используются нижеследующие алгоритмы.

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

Алгоритмы общедоступного ключа
ID	Описание
1	RSA (для шифрования и подписи)
2	RSA (только для шифрования)
3	RSA (только для подписи)
16	Эль-Гамаль (только для шифрования)
17	DSS
18	Зарезервировано для эллиптической кривой
19	Зарезервировано для ECDSA
20	Эль-Гамаль (для шифрования и подписи)
21	Зарезервировано для Диффи-Хеллмана
100-110	Секретные алгоритмы

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

Алгоритмы с симметричными ключами
ID	Описание
0	Не зашифровано
1	IDEA
2	Тройной DES
3	CAST-128
4	Blowfish
5	SAFER-SK128
6	Зарезервировано для DES/SK
7	Зарезервировано для AES-128
8	Зарезервировано для AES-192
9	Зарезервировано для AES-256
100-110	Частные алгоритмы

Хэш-алгоритмы.Хэш-алгоритмы, которые используются для создания хэша в PGP, показаны в табл. 6.3.

Хэш-алгоритмы
ID	Описание
1	MD5
2	SHA-1
3	RIPE-MD/160
4	Зарезервировано для SHA двойной ширины
5	MD2
6	TIGER/192
7	Зарезервировано для HAVAL
100-110	Частные алгоритмы

Алгоритмы сжатия.Алгоритмы сжатия, которые используются для сжатия текста, показаны в табл. 6.4.

Методы сжатия
ID	Описание
0	Без сжатия
1	ZIP
2	ZLIP
100-110	Частные методы

PGP-сертификаты

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

Сертификаты X.509

Протоколы, которые используют сертификаты X.509, зависят от иерархической структуры доверия. Есть заранее заданная цепочка доверия от корня до любого сертификата. Каждый пользователь полностью доверяет администрации CA на заданном уровне корня. Корень вырабатывает сертификаты для второго уровня, второй уровень CA вырабатывает сертификаты для третьего уровня, и так далее. Каждый партнер, который хочет быть доверенным для выдачи сертификатов, должен быть представлен на одной из ветвей дерева какого-либо CA. Если Алиса не доверяет выпускающему сертификат для Боба, она может обратиться к администрации более высокого уровня вплоть до корня (которому необходимо доверять для того, чтобы система работала). Другими словами, есть один-единственный путь к сертификату от CA, которому полностью доверяют.

В X.509 есть единственный путь от администрации, которому полностью доверяют, к любому сертификату.

PGP-Сертификаты

В PGP нет никакой потребности в CA - любой в кольце может подписать сертификат для кого-либо другого в кольце. Боб может подписать сертификат для Теда, Джона, Алисы и так далее. В PGP нет иерархии доверия; нет дерева. Отсутствие иерархической структуры может привести к тому, что Тед может иметь один сертификат от Боба и другой сертификат - от Джона. Если Алиса хочет исследовать линию получения сертификатов для Теда, у нее есть два пути: начинать от Боба и начинать от Джона. Интересно, что Алиса может полностью доверять Бобу, но только частично доверяет Джону. Может быть много путей доверия, приводящих к сертификату от администрации, которой доверяют полностью или частично. В PGP выпускающего сертификат обычно называют поручителем.

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

Доверие и законность

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

Уровни доверия поручителя. При отсутствии центральной администрации очевидно, что кольцо не может быть очень большим, если каждый пользователь в кольце PGP -пользователей не имеет полного доверия к каждому члену сообщества. (Даже в реальной жизни мы не можем полностью доверять каждому человеку, которого мы знаем.). Чтобы решить эту проблему, PGP позволяет различные уровни доверия. Число уровней, главным образом, зависит от реализации, но для простоты давайте назначим три уровня доверия к любому поручителю: никакой, частичный и полный. Уровень доверия поручителя определяет уровни доверия, выработанные поручителем для других людей в кольце. Например, Алиса может полностью доверять Бобу, частично доверять Анне и не доверять Джону. Вообще, в PGP нет механизма, чтобы решить, как принять решение поручителя о заслуживающем доверия партнере; это может сделать только пользователь.

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

Боб вырабатывает два сертификата, один для Линды (с открытым ключом K1) и один для Лесли (с открытым ключом K2). Алиса хранит открытый ключ и сертификат для Линды под названием "Линда" и назначает полный уровень доверия этому сертификату. Алиса также хранит сертификат и открытый ключ для Лесли под названием "Лесли" и назначает полный уровень доверия этому сертификату.

Анна вырабатывает сертификат для Джона (с открытым ключом K3). Алиса хранит этот сертификат и открытый ключ под названием "Джон", но назначает уровень для этого сертификата - частичный.

Джанетт вырабатывает два сертификата: один для Джона (с общедоступным ключом K3) и один для Ли (с открытым ключом K4). Алиса хранит сертификат Джона под его именем и сертификатом "Ли" под этим именем (Ли), каждый с частичным уровнем доверия. Обратите внимание, что Джон теперь имеет два сертификата: один от Анны и один от Джанетт, каждый с частичным уровнем доверия.

Джон вырабатывает сертификат для Лиз. Алиса может отказаться или сохранить этот сертификат с надписью " не доверяю".

Законность ключей. Цель использования поручителя и сертификата доверия - определить законность открытого ключа. Алиса должна знать, насколько законны открытые ключи Боба, Джона, Лиз, Анны и так далее. PGP определяет очень ясную процедуру для того, чтобы определить законность ключей. Уровень законности ключей для пользователя - это взвешенные уровни доверия пользователя. Например, предположим, что мы назначаем следующие веса на уровни доверия сертификата:

вес 0 - сертификату, которому не доверяют;

вес 1/2 - сертификату с частичным доверием;

вес 1 - сертификату с полным доверием.

Тогда для полного доверия объекту Алиса нуждается в одном сертификате, которому доверяет полностью, или в двух частичных сертификатах доверия для этого объекта. Например, Алиса может использовать открытый ключ Джона в предыдущем сценарии, потому что и Анна, и Джанетт выработали сертификат для Джона, каждый с уровнем доверия сертификата 1/2. Обратите внимание, что законность общедоступного ключа, принадлежащего объекту, не имеет никакого отношения к уровню доверия других людей к этому человеку. Хотя Боб может использовать открытый ключ Джона, чтобы передать сообщение ему, Алиса может не принять ни одного сертификата, выпущенного Джоном, потому что для Алисы Джон имеет уровень " нет доверия".

Старт кольца

Вы, возможно, нашли серьезную проблему в вышеупомянутом обсуждении. А если никто не передал сертификат, что он полностью или частично доверяет объекту? Например, как можно решить проблему законности общедоступного ключа Боба, если никто не передал сертификат Боба? В PGP законность ключа, которому доверяют, или объекта, которому частично доверяют, может быть также определена другими методами.

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

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

Лучшее решение, предложенное PGP для Боба, - передать его открытый ключ Алисе электронной почтой. И Алиса, и Боб делают дайджест ключа 16 байтов MD5 (или 20 байтов SHA-1). Дайджест обычно отображается как восемь групп по 4 цифры (или десять групп по 4 цифры) в шестнадцатеричном виде и называется отпечатком пальца. Алиса может тогда вызвать Боба и проверить отпечаток пальца по телефону. Если ключ изменился или изменен во время почтовой передачи, два отпечатка пальца не будут соответствовать друг другу. Для того чтобы сделать проверку более удобной, PGP создал список слов, каждое из которых представляет комбинацию из 4-х цифр. Когда Алиса вызывает Боба, Боб может объявить эти восемь слов (или десять слов) для Алисы. Слова тщательно выбраны PGP, чтобы избежать путаницы при произношении; например, если печь находится в списке, то слово речь не включается в список.

В PGP ничто не препятствует Алисе получать открытый ключ Боба от CA по отдельной процедуре. Она может тогда вставить открытый ключ в кольцо открытого ключа.

Таблица кольца ключей

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

(рис 6.7) Формат таблицы кольца секретного ключа.

Рис.6.7 показывает формат таблицы кольца секретного ключа.

Пользовательский ID. Пользовательский ID - обычно адрес электронной почты пользователя. Однако пользователь может определять уникальный адрес электронной почты или псевдоним для каждой ключевой пары. Таблица перечисляет пользовательские ID, связанные с каждой парой.

ID ключа. Этот столбец уникально определяет открытый ключ среди открытых ключей пользователя. В PGP ID ключа для каждой пары - первые (самые младшие) 64 бита открытого ключа. Другими словами, ключ ID вычисляется как - ключ mod 2⁶⁴). Ключ ID необходим для работы PGP, потому что Боб может иметь несколько открытых ключей, принадлежащих Алисе, в его кольце открытого ключа. Когда он получает сообщение от Алисы, Боб должен знать, какой ID ключа надо использовать, чтобы проверить сообщение. Ключ ID, который передают с сообщением, как мы увидим, дает возможность Бобу использовать заданный открытый ключ для Алисы из своего открытого кольца. Можно спросить, почему не передают полностью открытый ключ. Ответ на это вопрос такой: в криптографии открытого ключа размер открытого ключа может быть очень большой. Передавая только 8 байт, мы уменьшаем размер сообщения.

Открытый ключ. Этот столбец только перечисляет открытые ключи, принадлежащие конкретной паре "секретный ключ / открытый ключ".

Зашифрованный секретный ключ. Этот столбец показывает зашифрованное значение секретного ключа в паре "секретный ключ / открытый ключ". Хотя Алиса - единственный человек, имеющий доступ к своему секретному кольцу, PGP сохраняет только зашифрованную версию секретного ключа. Мы увидим позже, как зашифровывается и расшифровывается секретный ключ.

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

Пример 6.1

Покажем пример таблицы кольца секретного ключа для Алисы. Мы предполагаем, что Алиса имеет только два пользовательских ID: alice@some.com и alice@anet.net. Мы также предполагаем, что Алиса имеет два множества пар секретных/открытых ключей, один для каждого пользовательского ID. табл. 6.5 показывает таблицу кольца секретных ключей для Алисы.

Таблица кольца секретных ключей для примера 6.1
ID пользователя	Ключ ID	Общедоступный ключ	Секретный ключ шифрования	Метка времени
alice@anet.net	AB13...45	AB13...45...59	32452398...23	031505-16:23
alice@some.com	FA23...12	FA23...12...22	564A4923...23	031504-08:11

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

Рис.6.8 показывает формат таблицы кольца общедоступного ключа.

(рис 6.8) Формат таблицы кольца открытого ключа

Пользовательский ID. Как и в табл. 6.7 кольца секретного ключа, пользовательский ID - обычно адрес электронной почты объекта.

Ключ ID. Как и в табл. 6.7 кольца секретного ключа, ключ ID - первые (самые младшие) 64 бита общедоступного ключа.

Открытый ключ. Это - открытый ключ объекта.

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

Сертификат(ы). Этот столбец содержит сертификат или сертификаты, подписанные другим объектам для этого объекта. Пользовательский ID может иметь больше чем один сертификат.

Сертификат(ы) доверия. Этот столбец представляет сертификат доверия (или просто доверие). Если Анна передает сертификат за Джона, PGP ищет вход строки Анны, находит значение доверенного поставщика для Анны, копирует это значение и вставляет его в поле сертификата доверия для Джона.

Законность ключей. Это значение вычисляется PGP, на основе значения сертификата доверия и заранее заданного веса для каждого сертификата доверия.

Метка времени. Этот столбец содержит дату и время создания столбца.

Пример 6.2

Ряд шагов показывает, как формируется таблица кольца открытого ключа для Алисы.

Как показано в табл. 6.6, заполнение начинается со строки, где Алиса указывает уровень доверия поставщика, используя N (не доверяю), P (доверяю частично) и F (доверяю полностью). Для простоты принято, что каждый участник (включая Алису) имеет только один пользовательский ID.

Пример 2, стартовая таблица
ID пользователя	Ключ ID	Ключ открытый	Доверие к поставщику	Сертификат (ы)	Сертификат доверия	Законность ключа	Метка времени
Алиса $$\dots$$..	AB...	AB.......	F			F	$$\dots$$ $$\dots$$.

Обратите внимание: на основании этой таблицы мы предполагаем, что Алиса выпустила сертификат для себя (неявно). Алиса, конечно, доверяет сама себе полностью. Уровень доверия к поставщику также полный и законность ключей - тоже. Хотя Алиса никогда не использует эту первую строку, это необходимо для операции PGP.

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

Пример 2 после добавления в таблицу Боба
ID пользователя	Ключ ID	Ключ открытый	Доверие к поставщику	Сертификат (ы)	Сертификат доверия	Законность ключа	Метка времени
Алиса $$\dots$$..	AB...	AB.......	F			F	$$\dots$$ $$\dots$$.
Боб $$\dots$$..	12 $$\dots$$	12 $$\dots$$ $$\dots$$	F			F	$$\dots$$ $$\dots$$.

Обратите внимание, что значение доверия для Боба полное, потому что Алиса полностью доверяет Бобу. Значение поля сертификата пусто - это показывает, что этот ключ был получен косвенно, а не в соответствии с сертификатом.

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

Пример 2 после добавления Теда в таблицу
ID пользователя	Ключ ID	Ключ открытый	Доверие к поставщику	Сертификат (ы)	Сертификат доверия	Законность ключа	Метка времени
Алиса $$\dots$$..	AB...	AB.......	F			F	$$\dots$$ $$\dots$$.
Боб $$\dots$$..	12 $$\dots$$	12 $$\dots$$ $$\dots$$	F			F	$$\dots$$ $$\dots$$.
Тэд	48 $$\dots$$	48 $$\dots$$ $$\dots$$.	F	Боба	F	F	$$\dots$$ $$\dots$$ $$\dots$$

Обратите внимание: значение поля сертификата показывает, что сертификат был получен от Боба, значение сертификата доверия скопировано PGP с поля доверия к поставщику Боба. Значение поля законности ключей - значение сертификата доверия, умноженного на 1 (вес).

Теперь Алиса добавляет к списку Анну. Алиса доверяет Анне частично, но Боб передает сертификат для Анны с отметкой, что полностью доверяет. табл. 6.9 показывает новое событие.

Пример 2 после добавления Анны в таблицу
ID пользователя	Ключ ID	Ключ открытый	Доверие к поставщику	Сертификат (ы)	Сертификат доверия	Законность ключа	Метка времени
Алиса $$\dots$$..	AB...	AB.......	F			F	$$\dots$$ $$\dots$$.
Боб $$\dots$$..	12 $$\dots$$	12 $$\dots$$ $$\dots$$	F			F	$$\dots$$ $$\dots$$.
Тед	48 $$\dots$$	48 $$\dots$$ $$\dots$$.	F	Боба	F	F	$$\dots$$ $$\dots$$ $$\dots$$
Анна	71 $$\dots$$.	71	P	Боба	F	F	$$\dots$$ $$\dots$$

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

Теперь Анна представляет Джона, которому не доверяет Алиса. табл. 6.10 показывает новое событие.

Пример 2 после добавления в таблицу Джона
ID пользователя	Ключ ID	Ключ открытый	Доверие к поставщику	Сертификат (ы)	Сертификат доверия	Законность ключа	Метка времени
Алиса $$\dots$$..	AB...	AB.......	F			F	$$\dots$$ $$\dots$$.
Боб $$\dots$$..	12 $$\dots$$	12 $$\dots$$ $$\dots$$	F			F	$$\dots$$ $$\dots$$.
Тэд	48 $$\dots$$	48 $$\dots$$ $$\dots$$.	F	Боба	F	F	$$\dots$$ $$\dots$$ $$\dots$$
Анна	71 $$\dots$$.	71 $$\dots$$ $$\dots$$..	P	Боба	F	F	$$\dots$$ $$\dots$$
Джон	31 $$\dots$$..	31 $$\dots$$ $$\dots$$.	N	Анны	P	P	$$\dots$$ $$\dots$$..

Обратите внимание, что PGP скопировал значение доверия к поставщику Анны (P) и добавил к таблице сертификата доверия поле для Джона. Значение поля законности ключей для Джона - 1/2 (P) в этот момент; это означает, что Алиса не должна использовать ключ Джона, пока он не изменится на 1 (F).

Теперь Джанетт, неизвестная Алисе, передает сертификат для Ли. Алиса полностью игнорирует это сертификат, потому что она не знает Джанетт.

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

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

Пример 2 после того, как для Джона был получен сертификат
ID пользователя	Ключ ID	Ключ общедоступный	Доверие к поставщику	Сертификат (ы)	Сертификат доверия	Законность ключа	Метка времени
Алиса $$\dots$$..	AB...	AB.......	F			F	$$\dots$$ $$\dots$$.
Боб $$\dots$$..	12 $$\dots$$	12 $$\dots$$ $$\dots$$	F			F	$$\dots$$ $$\dots$$.
Тэд	48 $$\dots$$	48 $$\dots$$ $$\dots$$.	F	Боба	F	F	$$\dots$$ $$\dots$$ $$\dots$$
Анна	71 $$\dots$$.	71	P	Боба	F	F	$$\dots$$ $$\dots$$
Джон	31 $$\dots$$.	31 $$\dots$$..	N	Анны Боба	P F

Модель доверия в PGP

Как предложил Циммерман, мы можем создать модель доверия для любого пользователя в кольце, с пользователем в качестве центра активности. Такая модель может выглядеть как показано на рис. 6.9. Рисунок показывает модель доверия для Алисы в некоторый момент. Диаграмма может измениться с любыми изменениями таблицы кольца общедоступного ключа.

(рис 6.9) Модель доверия

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

Боб, Анна и Марк сделали свои ключи законными, посылая их электронной почтой и подтверждая отпечатками пальцев по факсу. Елена передала сертификат от CA, потому что ей не доверяет Алиса и проверка по телефону невозможна. Хотя Теду полностью доверяют, он дал Алисе сертификат, подписанный Бобом. Джон передал Алисе два сертификата, один - подписанный Тедом и один - Анной. Кевин передал два сертификата Алисе, один - подписанный Анной и один - Марком. Каждое из этих удостоверений дает Кевину половину уровня законности; поэтому ключ Кевина законен. Дюк передал два удостоверения Алисе, одно - подписанное Марком и другое - Еленой. Так как Марку "полудоверяют", а Елене не доверяют, Дюк не имеет законного ключа. Дженни передала четыре сертификата, один - подписанный объектом, которому "полудоверяют", два - незаконными объектами и один - неизвестным объектом. Дженни имеет не много шансов, чтобы ее ключ признали законным. Луиза передала один сертификат, подписанный неизвестным объектом. Заметим, что Алиса может сохранить имя Луизы в таблице в случае, если в будущем прибудет сертификат для Луизы.

Сеть доверия

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

Аннулирование ключей

Аннулирование ключей может стать необходимым для объекта, если надо отменить его или ее общедоступный ключ в кольце. Это может случиться, если владелец ключа чувствует, что ключ скомпрометирован (например, украден) или слишком старый, чтобы быть безопасным. Чтобы отменять ключ, владелец может передать сертификат аннулирования, подписанный им самим. Сертификат аннулирования должен быть подписан старым ключом и распространен всем людям в кольце, которые использовали общедоступный ключ.

Распаковка информации из колец

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

Сторона передатчика

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

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

(рис 6.10) Распаковка информации из колец на стороне передатчика

Алиса также нуждается в секретном ключе сеанса. Ключ сеанса в PGP - случайное число с размером, который определен в алгоритме шифрования/дешифрования. PGP использует генератор случайных чисел, чтобы создать случайный ключ сеанса; начальное число - множество произвольных нажатий клавиши, напечатанных Алисой на ее клавиатуре. Каждое нажатие клавиши преобразовано в 8 бит, а каждая пауза между нажатиями клавиши преобразована в 32 бита. Комбинация проходит сложный генератор случайных чисел, чтобы создать очень достоверное случайное число как ключ сеанса. Обратите внимание, что ключ сеанса в PGP - одноразовый случайный ключ (см. приложение K), используемый только один раз.

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

Сторона приемника

На стороне приемника Бобу нужны три части информации: секретный ключ Боба (расшифровывает ключ сеанса), ключ сеанса (чтобы расшифровать данные) и ключ Алисы (чтобы проверить подпись) (см. рис. 6.11).

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

Зашифрованный ключ сеанса передали с сообщением; Боб применяет свой расшифрованный секретный ключ, чтобы расшифровать ключ сеанса.

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

(рис 6.11) Распаковка информации из колец на стороне приема

PGP-пакеты

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

(рис 6.12) Формат заголовка пакета

Метка (тег). Нынешний формат для этого поля определяет метку как флажок на 8 битов; первый бит (самый старший) - всегда 1. Второй бит - 1, если мы используем последнюю версию. Остающиеся шесть бит могут определить до 64 различных типов пакетов, как показано в табл. 6.12.

Длина. Поле длины определяет длину полного пакета в байтах. Размер этого поля является переменным; он может быть 1, 2 или 5 байтов.

Некоторые обычно используемые типы пакетов
Значение	Тип пакета
1	Ключ сеанса, зашифрованный открытым ключом
2	Пакет подписи
5	Пакет секретного ключа
6	Пакет открытого ключа
8	Пакет сжатых данных
9	Пакет данных, зашифрованный секретным ключом
11	Пакет литеральных (буквенных данных)
13	Пакет пользовательского ID

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

Если значение байта после поля метки меньше, чем 192, то поле длины - только один байт. Длина текстового блока (пакет минус заголовок) вычисляется как

длина текстового блока = первый байт

Если значение байта после поля метки между 192 и 223 (включая крайние значения), то поле длины - два байта. Длина текстового блока может быть вычислена как

длина текстового блока = (первый байт - 192) << 8 + второй байт + 192

Если значение байта после поля метки между 224 и 254 (включая крайние значения), то поле длины - один байт. Этот тип поля длины определяет только длину части текстового блока (частичная длина текстового блока). Частичная длина текстового блока может быть вычислена как

Длина текстового блока = второй байт <<24 | третий байт << 16| четвертый байт << 8 |пятый байт

Обратите внимание, что формула означает 1 2 ^{(первый байт 0x1F)}. Степень - это фактически значение пяти самых правых битов. Поскольку поле - между 224 и 254 включительно значение пяти самых правых битов - между 0 и 30 включительно. Другими словами, частичная длина текстового блока может быть между единицей ( 2⁰ ) и 1 073 741 824 ( 2³⁰ ). Когда пакет представлен несколькими частичными текстовыми блоками, применима частичная длина текстового блока. Каждая частичная длина текстового блока определяет одну часть длины. Последнее поле длины не может быть частичной длиной текстового блока созданного сообщения. Например, если пакет имеет четыре части, он может иметь три частичных поля длины и одно поле длины другого типа.

Если значение байта после поля метки - 255, то поле длины состоит из пяти байтов. Длина текстового блока вычисляется как

Пакет литеральных данных. Пакет буквенных данных переносит или содержит текущие данные, которые передаются или сохраняются. Этот пакет - самый элементарный тип сообщения; то есть, он не может нести никакой другой пакет. Формат пакета показан на рис. 6.13.

(рис 6.13) Пакет буквенных данных

Режим. Это однобайтовое поле определяет, как данные написаны в пакете. Значение этого поля может быть "b" для двоичных данных, "t" - для текста, или любое другое значение, определенное для собственных целей.

Длина следующего поля. Это однобайтовое поле определяет длину следующего поля (поля имени файла).

Имя файла. Это поле переменной длины определяет название файла или сообщения в виде строки ASCII.

Метка времени. Это четырехбайтовое поле определяет время создания или последней модификации сообщения. Значение может быть 0 - это означает, что пользователь выбирает опцию "не определять время".

Литеральные данные. Это поле переменной длины, переносящее фактические данные (файл или сообщение) в тексте или двоичном виде (в зависимости от значения поля режима).

Сжатый пакет данных. Этот пакет, переносящий пакеты сжатых данных. рис. 6.14 показывает формат пакет сжатых данных.

(рис 6.14) Пакет сжатых данных

Метка (метод сжатия). Это однобайтовое поле определяет метод сжатия, используемый для сжатия данных (следующее поле). Значения, определенные для этого поля, пока 1 (ZIP) и 2 (ZLIP). Также реализация может применять другие экспериментальные методы сжатия. Метод ZIP обсуждается в приложении М.

Сжатые данные. Это поле переменной длины переносит данные после сжатия. Обратите внимание, что в этом поле может быть один пакет данных или последовательное соединение двух или более пакетов. Общая ситуация - единственный пакет литеральных данных или комбинация пакета подписи, сопровождаемого пакетом литеральных данных.

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

(рис 6.15) Пакет зашифрованных данных

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

(рис 6.16) Пакет подписи(рис 6.13) Пакет подписи

Некоторые значения подписи
Значение	Подпись
0x00	Подпись двоичного документа (сообщение или файл)
0x01	Подпись текстового документа (сообщение или файл)
0x10	Общий сертификат пользовательского ID и пакета открытого ключа. Подписывающее лицо не указывает никаких данных о владельце ключа
0x11	Персональный сертификат пользовательского ID и пакет открытого ключа. Не проводится верификация владельца ключа
0x12	Случайный сертификат пользовательского ID и пакет открытого ключа. Некоторая случайная верификация владельца ключа
0x13	Положительный сертификат пользовательского ID и пакет открытого ключа. Делается существенная верификация
0x30	Подпись аннулирования сертификата. Она удаляет более ранний сертификат (от Ox10 до Ox13)

Версия. Это однобайтовое поле определяет используемую версию PGP.

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

Тип подписи. Это однобайтовое поле определяет цель подписи. Оно документирует подпись. табл. 6.13 показывает некоторые типы подписи.

Метка времени. Это четырехбайтовое поле, которое определяет время, когда подпись была вычислена.

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

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

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

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

Подпись. Это поле переменной длины. Оно содержит зашифрованный дайджест, подписанный передатчиком.

Пакет ключа сеанса, зашифрованный открытым ключом.

Этот пакет используется, чтобы передать ключ сеанса, зашифрованный открытым ключом приемника. Формат пакета показан на рис. 6.17.

(рис 6.17) Пакет ключа сеанса

Версия. Это однобайтовое поле определяет используемую версию PGP.

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

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

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

симметричный алгоритм шифрования с одним октетом;

ключ сеанса;

контрольная сумма с двумя октетами равняется сумме октетов ключей предыдущих сеансов.

Пакет открытого ключа.Этот пакет содержит общедоступный ключ отправителя. Формат пакета показан на рис. 6.18.

(рис 6.18) Пакет открытого ключа

Версия. Эта однобайтовая область определяет используемую версию PGP.

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

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

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

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

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

(рис 6.19) Пакет пользовательского ID

Пользовательский ID. Эта строка переменной длины определяет пользовательский ID передатчика. Это обычно имя пользователя, сопровождаемое адресом электронной почты.

PGP-сообщения

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

Зашифрованное сообщение

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

(рис 6.20) Зашифрованное сообщение

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

Подписанное сообщение

Подписанное сообщение может быть комбинацией пакета подписи и литерального пакета, как это показано на рис. 6.21.

(рис 6.21) Подписанное сообщение

Сертифицирующее сообщение

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

(рис 6.22) Сертифицирующее сообщение

Приложения PGP

PGP широко применялся для персональной электронной почты. Это использование, вероятно, продолжится.

6.3. S/MIME

Другая служба безопасности разработана для электронной почты Безопасное/ Многоцелевое расширение почты (S/MIME - Secure/Multipurpose Internet Mail Extension). Этот протокол является расширением Многоцелевого расширения почты (MIME - Multipurpose Internet Mail Extension). Для лучшего понимания S/MIME кратко изложим MIME. Затем обсудим S/MIME как дополнение к MIME.

MIME

Электронная почта имеет простую структуру. Однако за эту простоту приходится платить. Почта может передать сообщения только в формате NVT ASCII на 7 битов. Другими словами, она имеет некоторые ограничения. Например, она не может работать с языками, которые не поддержаны символами ASCII (такими как арабский язык, китайский, французский, немецкий, иврит, японский, русский). Также она не может использоваться для передачи двоичных файлов или видео- и аудиоданных.

MIME - это дополнительные протоколы, которые позволяют данным, непередаваемым с помощью ASCII, проходить по электронной почте. MIME преобразовывает такие данные на стороне передатчика к данным NVT ASCII и поставляет их клиенту MTA по сети Интернет. Сообщение на приемной стороне преобразуется снова к первоначальному виду.

Мы можем представлять себе MIME как множество программных функций, которые преобразовывают данные, не передаваемые в ASCII, к данным ASCII, и наоборот, как показано на рис. 6.23.

(рис 6.23) MIME

MIME определяет пять заголовков (содержания), которые можно добавить к первоначальной электронной почте, чтобы определить параметры преобразования:

Version - MIME (версия);

Content - Type (Содержание - тип);

Content - Transfer - Encoding (Содержание - Передача - Шифрование);

Content - ID (Содержание - ID);

Content - Description (Содержание - Описание).

Рис. 6.24 показывает заголовки MIME. Далее дается более подробное описание каждого из заголовков.

(рис 6.24) MIME заголовок

MIME-версия

Этот заголовок определяет версию используемого MIME. Текущая версия имеет номер 1.1.

Version MIME: 1.1

Content-Type

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

Content - Type: <type/ subtype; parameters>

MIME позволяет семь различных типов данных. Они перечислены в табл. 6.14 и ниже описаны более подробно.

Текст. Первоначальное сообщение находится в формате ASCII на 7 битов, и преобразование MIME не требуется. Есть два подтипа, в настоящее время используемые: исходное и HTML.

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

Для этого типа определены четыре подтипа: смешанный, параллельный, дайджест и альтернатива.

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

Типы и подтипы данных в MIME
Тип	Подтип	Описание
	Обычный (Plain)	Неформатированный
	HTML	Формат HTML ;
Многоэлементный (Multipart)	Смешанный (Mixed)	Блок содержит упорядоченные части данных различного типа.
	Параллельный (Parallel)	То же самое, что выше, но неупорядоченное.
	Дайджест (Digest)	Тот же самый, что смешанный, но по умолчанию тип- Message /RFC822 RFC822.
	Альтернативный (Alternative)	Части различных версий одного и того же сообщения.
Сообщение (Message)	RFC822	В блоке инкапсулировано сообщение.
	Частичное (Partial)	Блок - это фрагмент другого - большего сообщения.
	Внешний текст (External-Body)	Блок - это ссылка на другое сообщение.
Изображение (Image)	JPEG	Изображение в формате JPEG .
Изображение (Image)	GIF	Изображение в формате GIF .
Видео (Video)	MPEG	Видео в формате MPEG.
Аудио (Audio)	Основное (Basic)	Одиночный канал голосового сообщения в полосе 8 КГц.
Приложение (Application)	Язык описание (PostScript)	Язык описания - Adobe PostScript.
Приложение (Application)	Поток октетов (Octet-stream)	Обычные двоичные данные (восьми - битовые байты).

Каждая часть имеет различный тип и определяет границы. Параллельный подтип подобен смешанному подтипу, за исключением того, что порядок следования частей не играет роли. Подтип дайджеста также подобен смешанному подтипу за исключением того, что по умолчанию тип/подтип ( type/subtype ) имеет значение сообщение ( message )/RFC822, как это определено ниже. В альтернативном подтипе то же самое сообщение повторено, используя различные форматы. Далее - пример многоэлементного сообщения, использует смешанный подтип:

Content-Type: multipart/mixed; boundary=xxxx
--xxxx
Content -Type: text/plain;
--xxxx
Content -Type: image/gif;
...............................
--xxxx--

Сообщение. В типе сообщения содержание - полное самостоятельное сообщение почты, либо часть сообщения почты, либо указатель на сообщение. В настоящее время используются три подтипа ( RFC822, частичные (partial) и внешнее тело (external-body)). Подтип RFC822 применяется, если в содержание включено сообщение, формирующее другое сообщение (включая заголовок и тело). Частичный подтип используется, если первоначальное сообщение было фрагментировано в несколько различных почтовых сообщений и данное сообщение почты - это один из фрагментов. Фрагменты должны быть повторно собраны в пункте назначения MIME. К сообщению добавляются три параметра: ID, номер и общее количество. ID идентифицирует сообщение и присутствует во всех фрагментах. Номер определяет порядок и число фрагментов, которые включает в себя первоначальное сообщение. Ниже приводится пример сообщения с тремя фрагментами:

Content-Type: message/partial;
id="forouzan@challenger.atc.flida.edu";
number=1;
total=3;
............
............

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

Content- Type: message/ external-body; name="report.text";
site="fhda.edu";
access-type="ftp";
..............
...............

Изображение. Первоначальное сообщение - неподвижное изображение - указывает на то, что нет никакой мультипликации. В настоящее время используется два подтипа: Объединенная Экспертная группа по фотографии (JPEG - Joint Photographic Expert Group), который позволяет сжать изображение, и Формат Обмена Графическими Файлами (GIF - Graphics Interchange Format).

Видео. Первоначальное сообщение - изменяющееся по времени изображение (мультипликация). Единственный подтип - Группа экспертов по движущимся изображениям (MPEG - Moving Picture Experts Group). Если движущееся изображение сопровождается звуковым рядом, его нужно послать отдельно, используя звуковой (audio) заголовок "содержание - тип".

Аудио. Первоначальное сообщение является звуковым. Основным является единственный подтип, который использует стандартный аудиоканал на 8 кГц.

Приложение. Первоначальное сообщение - тип данных, не определенных предварительно. В настоящее время применяется только два подтипа: PostScript и поток октетов. PostScript (язык описания страниц) используется, когда данные находятся в формате Adobe PostScript. Поток октетов нужен, когда данные должны интерпретироваться как последовательность байтов по 8 битов (двоичный файл).

Content - Transfer - Encoding (Содержание - Передача - Кодирование)

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

Content - Transfer - Encoding: <type>

Пять типов методов шифрования приведены в табл. 6.15.

Content - Transfer - Encoding (Содержание - Передача - Шифрование)
Тип	Описание
7 бит	NVT ASCII символы и короткие строки
8 бит	Символы, не отображаемые в ASCII (Non-ASCII); символы и короткие линейки
Двоичный	Символы, не отображаемые в ASCII (Non-ASCII); символы и нелимитированные линейки
Radix-64	6-битовые блоки, зашифрованные по 8 бит, в символы ASCII, использующие преобразование Radix-64 conversion
Ограниченная печатная строка	Символы, не отображаемые в ASCII (Non-ASCII) и зашифрованные как эквивалентные знаки кода ASCII

7bit. Это 7 бит, закодированные в NVT ASCII. Хотя никакого специального преобразования здесь не требуется, но необходимо, чтобы длина линейки не превышала 1000 символов.

8bit. Это закодированные по 8 битов символы не-ASCII, которые можно передать по каналу, но длина линейки не должна превышать 1000 символов. MIME в этом случае ничего не кодирует; основной SMTP позволяет передачу 8-битовых символов не-ASCII . Поэтому этот тип не рекомендуется. Предпочтительней применять типы Radix 64 и "приспособленный для печати".

Двоичный. Это закодированные по 8 битов символы не-ASCII, которые можно передать по каналу, но разрешается длина линейки более 1000 символов. MIME в этом случае ничего не кодирует; основной протокол SMTP позволяет передачу двоичных данных. Поэтому этот тип не рекомендуется. Предпочтительней применять типы Radix 64 и "ограниченную печатную строку".

RADIX 64. Этот тип позволяет передавать данные, состоящие из байтов, когда самый высокий разрядный бит - не обязательно равный нулю. Корень 64 преобразовывает этот тип данных к символам типа "пригодный для печатания", которые можно тогда послать как символы ASCII или любой тип символов, поддерживаемый основными алгоритмами передачи почты.

RADIX-64 разделяет двоичные (потоки бит) в блоки по 24 бита. Каждый блок затем разделяется на четыре секции, каждая состоит из 6 бит (см. рис. 6.25). Каждая секция на 6 битов интерпретируется как один символ согласно табл. 6.16.

(рис 6.25) Преобразование Radix-64

Ограниченная печатная строка (Quoted-printable). Radix-64 - избыточная схема кодирования: то есть 24 бита преобразуются в четыре символа и в конечном счете посылаются как 32 бита. Мы имеем избыточность 25 процентов. Если данные состоят главным образом из символов ASCII с небольшой маленькой частью не-ASCII, мы можем использовать кодирование типа Quoted-printable (" ограниченная печатная строка "). Если это символ ASCII, то его посылают без преобразования. Если символ - не ASCII, его посылают как три символа. Первый символ - знак равенства (=). Следующие два символа - шестнадцатеричное представление байта. На рис. 6.26 показан пример.

(рис 6.26) Ограниченная печатная строка (Quoted printable)(рис 6.16) Ограниченная печатная строка (Quoted printable)

Таблица кодирования Radix-64
Значение	Код	Значение	Код	Значение	Код	Значение	Код	Значение	Код	Значение	Код
0	A	11	L	22	W	33	h	44	S	55	3
1	B	12	M	23	X	34	i	45	t	56	4
2	C	13	N	24	Y	35	J	46	u	57	5
3	D	14	0	25	Z	36	k	47	V	58	6
4	E	15	P	26	a	37	1	48	W	59	7
5	F	16	Q	27	b	38	m	49	x	60	8
6	G	17	R	28	c	39	n	50	y	61	9
7	H	18	S	29	d	40	0	51	Z	62	+
8	I	19	T	30	e	41	P	52	0	63	/
9	J	20	U	31	f	42	q	53	1
10	K	21	V	32	g	43	r	54	2

Content-Id (Содержание-Id)

Этот заголовок уникально идентифицирует целое сообщение среди многих сообщений

Content-Id : id = <content-id> (содержание id)

Content-Description (Содержание-Описание)

Этот заголовок определяет, является ли блок информации неподвижным изображением, аудио или видео.

Content - Description : < описание >

S/MIME

S/MIME добавляет некоторые новые типы заголовков-содержания, чтобы включить службы безопасности в MIME. Все эти новые типы включают параметр "application/pkcsP-mime", в котором "pkcs (Public Key Cryptography Specification)" определяет "Спецификацию криптографии открытого ключа".

Синтаксис криптографического сообщения

Чтобы определять услуги безопасности, такие как конфиденциальность или целостность, можно добавить к типам содержания MIME, S/MIME определитель Криптографический синтаксис сообщения (СМS -Cryptographic Message Syntax). Синтаксис в каждом случае определяет точную схему кодирования каждого типа содержания. Ниже рассматриваются типы сообщения и различные подтипы, которые могут быть созданы из этих сообщений.

Тип содержания данных - произвольная строка. Созданный объект называется Данными.

Signed - Data Content Type (Тип содержания - подписанные данные).Этот тип обеспечивает только целостность данных. Он содержит любой тип и нулевое или большее количество подписей. Кодируемый результат - объект, называемый signedData. рис. 6.27 показывает процесс создания объекта этого типа. В процессе используются следующие шаги:

(рис 6.27) Содержание типа "подписанные данные"

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

Каждый дайджест сообщения подписывается секретным ключом подписывающего лица.

Содержание, значения подписи и сертификата, а также алгоритмы затем собираются для создания объекта signedData.

Enveloped - Data Content Type (Тип содержания - конверт данных).Этот тип используется, чтобы обеспечить секретность сообщения. Он содержит любой тип от нуля и далее зашифрованных ключей и сертификатов. Кодируемый результат - объект, называемый envelopedData. рис. 6.28 показывает процесс создания объекта этого типа.

(рис 6.28) Содержание типа "конверт данных"

Создается псевдослучайный ключ сеанса для алгоритмов с симметричными ключами.

Для каждого получателя копия ключа сеанса зашифрована с открытым ключом каждого получателя.

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

Зашифрованное содержание, зашифрованный ключ сеанса. Использованный алгоритм и сертификаты кодируются с использованием RADIX-64.

Digest-Data Content Type ( Содержание типа "дайджест данных" ).Этот тип используется, чтобы обеспечить целостность сообщения. Результат обычно используется как содержание типа "конверт данных". Кодируемый результат - объект, называемый digestedDate. рис. 6.29 показывает процесс создания объекта этого типа.

(рис 6.29) Содержание типа дайджест данных

Дайджест сообщения вычислен на основании содержания.

Дайджест сообщения, алгоритм и содержание добавляются вместе, чтобы создать digestData.

Encrypted-Data Content Type (Тип содержания "зашифрованные данные").Этот тип используется, чтобы создать зашифрованную версию содержания любого типа. Хотя он похож на тип содержания "конверт данных", но не имеет информации о получателе. Он может использоваться, чтобы хранить зашифрованные данные, вместо того, чтобы передавать их. Процесс очень прост: пользователь использует любой ключ (нормально, исходя из пароля) и любой алгоритм, чтобы зашифровать содержание. Зашифрованное содержание сохраняется без записи ключа или алгоритма. Созданный объект называется encryptedData.

Authenticated-Data Content Type (Тип содержания - подтверждение подлинности данных). Этот тип используется, чтобы обеспечить установление подлинности данных. Объект называется authenticatedData. Рис. 6.30 показывает процесс.

(рис 6.30) Содержание типа "подтверждение подлинности"

С применением псевдослучайного генератора для каждого получателя генерируется ключ кода, подтверждающий подлинность сообщения (MAC - Message Authentication Code).

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

Код, подтверждающий подлинность сообщения, создан для содержания.

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

Управление ключами

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

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

S/MIME определяет несколько криптографических алгоритмов, как это показано в табл. 6.17. Термин "должен" означает абсолютное требование; термин "может" означает рекомендацию.

Криптографические алгоритмы для S/MIME
Алгоритм	Передатчик должен поддерживать	Приемник должен поддерживать	Передатчик может поддерживать	Приемник может поддерживать
Алгоритм зашифрованного содержания	Triple DES	Triple DES		l. AES 2. RC2/40
Алгоритм шифрования ключа сеанса	RSA	RSA	Diffie-Hellman (Диффи-Хеллман)	Diffie-Hellman (Диффи-Хеллман)
Хэш-алгоритм	SHA-1	SHA-1		MD5
Алгоритм шифрования дайджеста	DSS	DSS	RSA	RSA
Алгоритм определения подлинности		HMAC с SHA-1

Ниже показан пример конверта данных, в котором маленькое сообщение зашифровано с использованием трехкратного DES.

Content-Type: application/pkcs7-imme; mime-type==enveloped-data 
Content-Transfer-Encoding: Radix-64 
Content-Description: attachment 
Name= "report.txt";
cb32ut67f4bhijHU21oi87eryb0287hmnklsgFDoY8bc659GhIGfH6543mhjkdsaH23YjBnmN 
ybmlkzjhgfdyhGe23Kjk34XiuD678Esl6se09jy76jHuytTMDcbnmlkjgfFdiuyu67.S543mOn3ti 
G34un12P2454Hoi87e2rybOH2MjN6KuyrlsgFDoY897fk923jljk1301 XiuD6gh78EsUyT23y

Приложения S/MIME

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

6.4. Рекомендованная литература

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

Книги

Электронная почта рассматривается в [For06] и [For07]. PGP рассматривается в [Sta06], [KPS02] и [Rhe03]. S/MIME рассматривается в [Sta06].

Сайты

Нижеследующие сайты дают больше информации о темах, обсужденных в этой лекции.

http://axion.physics.ubc.ca/pgp-begin.html

csrc.nist.gov/publications/nistpubs/800-49/sp800-49.pdf

www.faqs.org/rfcs/rfc2632.html

6.5. Итоги

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

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

В PGP Алиса нуждается в кольце открытых ключей для каждого человека, с которым она переписывается. Она также нуждается в кольце принадлежащих ей частных/открытых ключей.

В PGP не нужны Центры Сертификации; любой в кольце может подписать сертификат для кого-либо еще в этом кольце. В PGP нет иерархии доверия; нет дерева иерархии. Может быть много путей от администрации, которой полностью или частично доверяют, к любому объекту.

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

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

В PGP мы имеем несколько типов сообщений: зашифрованное сообщение, подписанное сообщение и сообщение сертификата.

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

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

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

6.6. Набор для практики

Обзорные вопросы

Объясните, как Боб, когда он получает PGP -сообщение от Алисы, узнает, какие криптографические алгоритмы она использовала.

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

Объясните, как Боб и Алиса в PGP обмениваются секретным ключом шифрования сообщений.

Объясните, как Боб и Алиса обмениваются секретным ключом шифрования сообщений.

Сравнить сходство и различия сертификатов в PGP и S/MIME. Объясните сеть доверия, которая применяется для сертификации в PGP и в S/MIME.

Назовите семь типов пакетов, используемых в PGP, и объясните их цели.

Назовите три типа сообщений в PGP и объясните их цели.

Назовите все типы содержания, определенные CMD, и их цели.

Сравните совпадения и отличия управление ключами в PGP и S/MIME.

Упражнения

Боб получает PGP -сообщение. Как он может узнать тип пакета, если значение метки:

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

Ответьте на следующие вопросы о значениях метки в PGP.

Может пакет со значением метки 1 содержать другой пакет?

Может пакет со значением метки 6 содержать другой пакет?

Какие типы пакетов нужно передать в PGP, чтобы обеспечить следующие услуги безопасности:

Конфиденциальность

Целостность сообщения

Определение подлинности

Исключение отказа от факта принятия сообщения

Комбинация а и б

Комбинация а и в

Комбинация а, б и в

Комбинация а, б, в и г.

Какой тип содержания в S/MIME обеспечивает следующие услуги безопасности:

конфиденциальность

целостность сообщения

установление подлинности

исключение отказа от факта принятия сообщения

комбинация а и б

комбинация а и в

комбинация а, б и в

комбинация а, б, в и г.

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

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

Составьте таблицу сравнения и отличий алгоритмов хэширования, используемых в PGP и S/MIME.

Составьте таблицу сравнения и отличий алгоритмов цифровой подписи PGP и S/MIME.

Кодируйте сообщение "This is test", используя следующее кодирование:

Radix-64

Quoted Printable ( ограниченная печатная строка )

Страницы: