- Защищенные многоцелевые расширения e-mail
Защищенные многоцелевые расширения электронной почты S/MIME.
- RFC 822 и многоцелевые расширения электронной почты.
- Типы содержимого и кодировки MIME.
- Функции и алгоритмы S/MIME.
RFC 822 и Многоцелевые расширения электронной почты
Система S/MIME (Secure/Multipurpose Internet Mail Extension) – защищенные многоцелевые расширения электронной почты. Это усовершенствованный с точки зрения защиты формат MIME.
И PGP и S/MIME являются стандартами IETF (Internet Engineering Task Force – Проблемная группа проектирования Интернет).
Но PGP больше предназначена для защиты личной электронной почты. А S/MIME претендует на стандарт коммерческого и промышленного использования.
Чтобы понять структуру S/MIME необходимо сначала познакомиться с MIME и с RFC 822.
RFC 822 – традиционный стандарт формата электронной почты, который все еще широко используется.
Документ RFC 822 определяет формат текстовых сообщений, которые пересылаются по электронной почте.
Каждое сообщение состоит из конверта, заголовка и тела сообщения.
Рекомендуемые материалы
Конверт содержит информацию, необходимую для пересылки и доставки сообщения. Стандарт RFC 822 описывает только содержимое сообщения, т.е. заголовок и тело письма, - это поток текста ASCII.
Заголовок может использоваться программой электронной почты для формирования конверта. Согласно RFC 822 заголовок отделяется от тела сообщения пустой строкой.
Строка заголовка состоит из ключевого слова и :, за которым следуют параметры.
Чаще всего используются следующие ключевые слова: From(От) To(Кому) Subject(Тема) Date(Дата) Cc(Копия) Bcc(Скрытая копия), Message-ID(Идентификатор сообщения) – уникальный идентификатор с данным сообщением.
Стандарт MIME является расширением базового стандарта RFC 822.
Существует множество проблем, которые не решает RFC 822: (например)
· SMTP не позволяет передавать исполняемые файлы и другие объекты в двоичном формате. Существует ряд схем преобразования двоичных файлов в текстовые (например, Uuencode/Uudecode для UNIX), однако ни одна из них не является стандартом или стандартом де-факто.
· SMTP не позволяет передавать текстовые данные, включая символы национальных языков (только 7-битовые коды ASCII до 128).
· Серверы SMTP могут отвергнуть электронное сообщение, превышающее размер.
· Шлюзы SMTP могут иметь разные таблицы перевода из ASCII в EBCDIC.
Стандарт MIME должен решать эти проблемы, сохраняя совместимость с RFC 822.
MIME описан в документе RFC 2045-:-2049.
Стандарт MIME определяет:
1. 5 новых полей заголовка, которые несут информацию о теле сообщения.
2. Стандарты кодировок передаваемых данных
3. Форматы содержимого для представления мультимедийных данных.
5 полей заголовка, определяемых MIME:
обязательные:
1. MIME-Version – (версия MIME). Параметр должен иметь значение 1.0 (т.е. соответствовать RFC 2045, 2046).
2. Content-Type – (тип содержимого). Описывает данные, помещенные в тело сообщения.
3. Content-Transfer-Encoding (кодировка передаваемого содержимого). Указывает тип преобразования, использовавшегося для пересылки.
могут игнорироваться:
4. Content-ID (идентификатор содержимого).
5. Content-Description (описание содержимого). Текстовые описания объекта в теле сообщения. Полезно, когда объект имеет форму, недоступную для прочтения (например, звуковые данные).
Типы содержимого и кодировки MIME.
Существует семь основных типов содержимого и в общей сумме 15 подтипов.
Тип определяет общий тип данных, а подтип – конкретный формат, используемый для представления этого типа данных.
| Тип | Подтип | Описание |
| Text (текст) | Plain (простой) Enriched (расширенный) | Неформатированный текст в кодировке ASCII или ISO8859 Обеспечивает более гибкий формат |
| Multipart (многокомпонентный) – указывает на то, что тело сообщения состоит из нескольких независимых частей. При этом поле заголовка Content – Type включает параметр boundary (граница), задающий разделитель, отделяющий части сообщения, друг от друга. Разделитель начинается с новой строки. --simple boundary | Mixed (смешанный) Parallel (параллельный) Alternative (альтернативный) Digest (реферативный) | Разные части сообщения независимы, но должны передаваться вместе и быть представлены получателю в том же порядке. Не определяется порядок, в котором части сообщения должны быть представлены получателю. Если система получателя позволяет, то все части могут быть представлены параллельно, например, текст + голос + видео. Разные части являются альтернативными вариантами одной и той же информации. Они располагаются в порядке возрастания точности соответствия оригиналу. Почтовая система получателя должна выбрать «лучший» вариант, если может. Подобен смешанному. Применяется, когда каждая часть тела сообщения интерпретируется как сообщение RFC 822 со своим заголовком. Позволяет создавать сообщения, части которого являются отдельными сообщениями. Например, модератор группы собирает сообщение участников в одно и пересылает их вместе. |
| Message (сообщение) | rfc 822 Partial (фрагментарный) External-body (внешний) | Указывает, что тело сообщения является инкапсулированным сообщением, включающим заголовок и тело сообщения. Дает возможность разделить большое сообщение на несколько частей, которые снова должны быть собраны в системе получателя. Указывает на то, что фактических данных в теле сообщения нет. Вместо этого содержит информацию, необходимую для получения доступа к этим данным. |
| Image (изображение) | jpeg gif | |
| Video (видео) | mpeg | Формат MPEG |
| Audio (звук) | Basic (основной) | Одноканальная 8-битовая кодировка ISDN с частотой выборки 8КГц |
| Application (приложение) | Post Script Octet–Stream (поток байтов) | Формат Adobe PostScript Двоичные данные, состоят из 8 – битовых байтов. |
Кодировки MIME
Другим основным компонентом спецификаций MIME (кроме типа содержимого) является кодировка тела сообщения.
Поле Content-Transfer-Encoding может принимать 6 различных значений.
| 7 bit | Все данные представляются 7-битными символами ASCII и короткими строками. |
| 8 bit | Данные могут содержать символы, не являющиеся символами ASCII (байты с нулевыми старшими битами). Короткие строки. |
| binary | Строки не обязательные короткие (ASCII и не ASCII). |
| quoted-printable | Используется, когда большинство байтов соответствует печатаемым символам ASCII. Непечатаемые символы переводит в шестнадцатеричные представления их кодов и вставляет мягкие переходы на новую строку, чтобы ограничить длины строк до 76 символов. Текст в закодированном виде остается читаем. |
| base 64 | 6-битовые входные блоки кодируются в 8-битовые выходные блока, все из которых являются печатаемыми символами ASCII. Это кодировка radix-64. Используется в PGP. Произвольные данные из двоичного формата преобразуются в формат, который не искажается, при обработке прямой пересылки почты. |
| x-token | Нестандартное кодирование с указанием его имени. |
Функции и алгоритмы S/MIME
С точки зрения общих функциональных возможностей S/MIME и PGP очень схожи.
S/MIME обеспечивает использование следующих функций:
1. Шифрование сообщений (упакованные данные)
2. Цифровая подпись (подписанные данные)
3. Открытые подписанные данные (шифруются только ЦП)
4. Подписанные и упакованные данные (шифрованные данные могут быть подписаны)
S/MIME используют 3 алгоритма ассиметричного шифрования:
· DSS – стандарт ЦП является обязательным для шифрования ЦП.
· RSA – рекомендуемый (шифрование сеансового ключа, шифрование ЦП).
· Диффи–Хеллмана (Эль-Гамеля) – для распределения сеансовых ключей (обязательный).
Для функции хеширования используется SHA-1 (основной, обязательный) и MD5 (рекомендуемый).
Традиционное шифрование применяет для шифрования сообщения: 3DES – обязательный, RC2 – рекомендуемый.
| Функция хеш-кода | Требование |
| Создание профиля сообщения для формирования ЦП. | Обязательна поддержка SHA-1 и MD5. Рекомендуется использование SHA-1. |
| Шифрование профиля сообщения (стандарт ЦП). | Для агентов отсылки и приема обязательна поддержка DSS. Для агента отсылки рекомендуется поддержка RSA. Для агента приема рекомендуется поддержка верификации подписей RSA с длиной ключа от 512 до 1024 битов. |
| Шифрование сеансового ключа для передачи с сообщением. | Обязательная поддержка Диффи-Хеллмана. Рекомендуется RSA. |
| Шифрование сообщений для передачи с использованием сеансового ключа. | Для агента отсылки рекомендуется 3DES и RC2/40. Для агента приема обязательно 3DES и рекомендуется RC2/40 |
В S/MIME определен ряд новых типов содержимого.
| Тип | Подтип | Параметр smime | Описание |
| Multipart (многокомпонентный) | Signed (подписанный) | Открытое подписанное сообщение из 2-х частей: сообщение и его ЦП | |
| Application (приложение) | pkes7-mime | envelopedData | Шифрованный объект S/MIME |
| pkes7-mime | SignedData | Подписанный объект S/MIME | |
| pkes7-mime | olegenerate | Объект, содержащий только сертификаты открытых ключей. | |
| pkes10-mime | Запрос регистрации сертификата | ||
| pkes7-signature | Тип подписи, являющейся частью (открытого подписанного сообщения) сообщения типа multipart/signed. |
Упакованные данные (application/pkes7-mime/enverlopedData).
1. Генерируется псевдослучайный сеансовый ключ Ks.
2. Для каждого получателя сеансовый ключ шифруется с помощью открытого ключа получателя по RSA.
3. Для каждого получателя готовится блок (RecipientInfo – информация для получателя) данных, содержащий:
a. сертификат открытого ключа отправителя (X.509);
b. идентификатор алгоритма шифрования Ks;
c. шифрованный Ks.
4. Содержимое сообщения шифруется Ks, добавляется блок RecipientInfo.
5. Вся информация кодируется в формате base 64.
Чтобы восстановить исходное сообщение, получатель сначала снимает кодировку base 64, затем открывает сеансовый ключ с помощью своего личного ключа, дешифрует сообщение с помощь Ks.
Подписанные данные (signedData):
1. Выбирается алгоритм создания профиля сообщения (SHA или MD5).
2. Вычисляется профиль сообщения.
3. Профиль сообщения шифруется с помощью личного ключа стороны, подписывающей документ.
4. Для получателя подготавливается блок (SignedInfo) – информация подписавшей стороны, содержащий
a. сертификат открытого ключа подписывающей стороны;
b. идентификатор алгоритма шифрования профиля сообщения;
c. шифрованного профиля сообщения.
Объект signedData состоит из блоков следующей структуры:
· идентификатор алгоритма;
· само сообщение;
· блок SignedInfo.
Вся информация кодируется base 64.
Запрос регистрации (application/pkes10) сертификата
Объект этого типа служит для передачи запроса центру сертификации по поводу получения сертификатов открытых ключей.
Сообщение, содержащее только (pkes7-mime degenerate) сертификаты или список отозванных сертификатов (CRL). Могут посылаться в ответ на запрос регистрации. 
Обработка сертификатов S/MIME
S/MIME использует сертификаты открытых ключей, соответствующие версии 3 стандарта X.509. Схема управления ключами в S/MIME является гибридом строгой иерархии сертификатов X.509 и сети доверия PGP.
Как и PGP администраторы и/или пользователи S/MIME должны обеспечить каждому клиенту список надежных ключей и список отозванных сертификатов. Т.о. ответственность за поддержку сертификатов ложится на локальную систему. Сами сертификаты подписываются уполномоченными центрами сертификации. Пользователь S/MIME должен выполнять следующие функции управления ключами:
· Генерирование ключей (открытый, секретный);
· Регистрация. Открытый ключ пользователя должен быть зарегистрирован с помощью уполномоченного центра сертификации для того, чтобы получить сертификат этого ключа стандарта X.509.
· Хранение и поиск сертификатов. Пользователю требуется доступ к локальному списку сертификатов, чтобы иметь возможность проверить поступающие подписи и шифровать отправляемые сообщения. Такой список может поддерживаться пользователем или администратором от имени пользователя.
Существует несколько компаний, которые предоставляют услуги центра сертификации: фирма Nortel, VeriSign, GIE, V.S. Postal Service.
VeriSign одна из наиболее популярных служб сертификации в Internet.
Она обеспечивает сервис сертификации, который совместим с S/MIME и выдает сертификаты стандарта X.509, называемые цифровыми удостоверениями VeriSign (VeriSign Digital ID).
Каждое цифровое удостоверение содержит обязательные следующие элементы:
· открытый ключ владельца;
· имя владельца;
· дата истечения срока выдачи удостоверения;
· № цифрового удостоверения;
· имя центра сертификации, выдавшего удостоверение;
· цифровую подпись центра сертификации, выдавшего удостоверение.
Люди также интересуются этой лекцией: 2.1. Основные принципы инженерной защиты населения.
Информация, содержащаяся в цифровом удостоверении, зависит от типа, использования и той организации, которая его выдала.
S/MIME развивается, появляются дополнительные службы.
Источники дополнительной информации:
1. Хартия S/MIME (самые последние RFC и проекты стандартов S/MIME для Internet).
2. Централ S/MIME (посвященный S/MIME Web-узел RSA Inc.
