Система S/MIME (Secure/MultipurposeInternetMailExtension – защищённые многоцелевые расширения электронной почты) является усовершенствованием с точки зрения защиты стандарта формата MIMEэлектронной почты в Internet, базирующимся на использовании технологии RSADataSecurity.Существуют основания полагать, что S/MIMEстанет стандартом коммерческого и промышленного использования, в то время как PGPостанется альтернативой для защиты личной электронной почты большинства индивидуальных пользователей.
Стандарт MIMEявляется расширением базового стандарта RFC 822, призванным решить некоторые проблемы и преодолеть ограничения протокола SMTP или некоторого другого протокола передачи почты, и RFC 822.
Ограничениями протокола SMTP, которые решает MIMEявляются:
1. SMTPне позволяет передавать исполняемые файлы и другие объекты в двоичном формате. Существует ряд схем преобразования двоичных файлов в текстовые (к ним относятся Uuencode/Uudecodeдля UNIX), которые затем могут быть использованы различными почтовыми системами SMTP/ Однако ни одна из таких схем не является стандартом.
2. SMTP не позволяет предавать текстовые данные, включающие символы национальных языков.
3. Шлюзы SMTP, выполняющие трансляцию кодов ASCII в коды EBCDICи обратно, могут иметь разные таблицы перевода, что выливается в проблемы трансляции.
Исходя из этих недостатков технические спецификации MIMEвключают следующие элементы:
1. Определяется пять новых полей заголовка сообщения, которые могут включаться в заготовок RFC 822. Эти поля несут в себе информацию о теле сообщения.
2. Определяется несколько форматов содержимого, задающих стандарты представления документов мультимедиа в сообщениях электронной почты.
3. Определяются стандарты кодировок передаваемых данных, позволяющие защитить содержимое сообщения от изменения при осуществлении почтовыми системами преобразования передаваемых данных из одного формата в другой.
Стандарт MIMEопределяет пять полей заголовка сообщения, любые или все из которых могут включаться в заголовок RFC 822:
MIME-Version (версия MIME). Соответствующий параметр должен иметь значение 1.0. Это поле указывает, что сообщение соответствует стандартам RFC 2045 и 2046.
Content-Type (тип содержимого). Описывает данные, помещённые в тело сообщения, достаточно подробно для того, чтобы агент получателя смог выбрать соответствующий агент или механизм, позволяющий представить полученные данные пользователю или обработать их каким-то иным соответствующим образом.
Content-Transfer-Encoding (кодировка передаваемого содержания). Указывается тип преобразования, использовавшегося для того, чтобы представить тело сообщения в виде, приемлемом для пересылки почтой.
Сontent-ID (идентификатор содержимого). Служит для того, чтобы уникальным образом идентифицировать объекты MIMEсреди множества контекстов.
Content-description (описание содержимого). Текстовые описания объекта в теле сообщения; полезно тогда, когда объект имеет форму, недоступную для прочтения (например, звуковые данные).
Любая реализация, как минимум, должна поддерживать обработку полей MIME-Version, Content-Typeи Сontent-Transfer-Encoding.
В S/MIMEзащита объекта MIMEобеспечивается подписью, шифрованием или и тем, и другим одновременно. Объектом MIMEможет быть как всё сообщение (за исключением его заголовков RFC 822) или, в случае многокомпонентного содержимого MIME, одно или несколько частей сообщения. Объект MIMEготовится в соответствии с обычными правилами подготовки сообщений MIME. Затем объект MIMEвместе с некоторыми связанными с ним данными защиты (например, идентификаторами алгоритма и сертификатов) обрабатывается S/MIME, чтобы в результате получить то, что обычно называют объектом PKCS (Public-KeyCryptographySpecification– спецификация криптографии с открытым ключом). С объектом PKCS затем обращаются как с содержимым сообщения, которое упаковывают в MIME (добавляя соответствующие заголовки MIME).
Помимо типов содержимого стандарта MIME, в стандарте S/MIMEиспользуются ряд новых типов содержимого, перечисленные в таблице. Все эти типы содержимого используют обозначения PKCS, опубликованные RSALaboratoriesи доступные для S/MIME.
| Тип | Подтип | Параметр S/MIME | Описание |
| Multipart (многокомпонентный) | Signed(подписанный) | Открытое подписанное сообщение из двух частей: сообщения и его подписи | |
| Application (приложение) | pkcs7-mime | signedData | Подписанные объект S/MIME |
| pkcs7-mime | envelopedData | Шифрованный объект S/MIME | |
| pkcs7-mime | Degenerate signedData | Объект, содержащий только сертификаты открытых ключей | |
| pkcs7-signature | - | Тип подписи, являющейся частью сообщения типа multipart/signed | |
| pkcs10-mime | - | Сообщение запроса регистрации сертификата. |
Формирование объекта envelopedData (упакованные данные).
При подготовке объекта envelopedDataMIMEдолжны быть выполнены следующие действия:
1. Генерируется псевдослучайный сеансовый ключ для конкретного алгоритма симметричной схемы шифрования (RC2/40 или 3DES).
2. Для каждого получателя сеансовый ключ шифруется с помощью открытого ключа получателя и RSA.
3. Для каждого получателя готовится блок данных, называемый RecipientInfo (информация для получателя), содержащий сертификат открытого ключа отправителя, идентификатор алгоритма, использовавшегося для шифрования сеансового ключа, и шифрованный сеансовый ключ.
4. Содержимое сообщения шифруется с помощью сеансового ключа.
Блоки RecipientInfo, за которыми следует шифрованное содержимое сообщения, вместе составляют блок envelopedData. Эта информация затем кодируется в формате base64 (radix-64).
Пример такого файла:
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Rfvbn765BghyHhUjfewqwnvdCDC7
Формирование объекта signedData (подписанные данные).
1. Выбирается алгоритм создания профиля сообщения (SHA или MD5).
2. Вычисляется профиль сообщения (значение хэш-функции) для содержимого, которое должно быть подписано.
3. Профиль сообщения шифруется с помощью личного ключа стороны, подписавшей документ.
4. Подготавливается блок, называемый SignedInfo (информация подписавшей стороны), содержащий сертификат открытого ключа подписавшей документ стороны, идентификатор алгоритма, использовавшегося для шифрования профиля сообщения и шифрованного профиля сообщения.
Объект signedDataформируется из ряда блоков, включающих идентификатор алгоритма создания профиля сообщения, само подписываемое сообщение и блок SignerInfo. Вся эта информация кодируется в base64. Пример такого сообщения (с исключёнными заголовками RFC 822):
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Rfvbn765BghyHhUjfewqwnvdCDC7
Открытое подписанное сообщение.
Открытое подписанное сообщение получается тогда, когда для содержимого используется тип multipartи подтип signed. Сообщение типа multipart/signedвключает две части.
Первая часть может быть любого типа MIME, но должна быть подготовлена так, чтобы она не была изменена в пути следования от источника к адресату. Это значит, что если первая часть не представлена в 7-битовой кодировке, то данные надо кодировать в формат base64. В первой части располагается открытый текст сообщения.
Вторая часть представляет собой отделённую подпись. Она формируется по алгоритму объекта signedData. В результате создаётся объект в формате signedData, поле содержимого которого оказывается пустым. Затем этот объект кодируется в формат base64, чтобы стать второй частью многокомпонентного сообщения. Для типа MIMEэтой второй части выбирается значение application, а для подтипа - pkcs7-signature. Пример такого сообщения:
Content-Type: multipart/signed;
Protocol=”application/pkcs7- signature”;
Micalg=shal; boundary=boundary42
-- boundary42
Content-Type: text/plain
Это открытый текст подписанного сообщения.
-- boundary42
Content-Type: application/pkcs7- signature; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Rfvbn765BghyHhUjfewqwnvdCDC7
-- boundary42 --
Значение параметра protocolуказывает но то, что этот объект является двухкомпонентным открытым подписанным сообщением. Значение параметра micalgуказывает тип используемого профиля сообщения. Получатель может проверить подпись, вычислив профиль сообщения из первой части и сравнив его с профилем сообщения, который восстанавливается из подписи во второй части.
Криптографические алгоритмы.
В таблице представлены криптографические алгоритмы, используемы в системе S/MIME.
В S/MIMEпринята терминология, предложенная в документе RFC 2119 и позволяющая указать уровень требований.
ОБЯЗАТЕЛЬНО (MUST). Определение является абсолютным требованием спецификации. Любая реализация должна включать это свойство или функцию, чтобы соответствовать данной спецификации.
РЕКОМЕНДУЕТСЯ (SHOULD). В конкретном окружении могут существовать причины игнорировать это свойство или функцию, но рекомендуется, чтобы реализация всё же имела соответствующее свойство или функцию.
| Функция | Требование |
| Создание профиля сообщения, используемого при формировании цифровой подписи. | ОБЯЗАТЕЛЬНА поддержка SHA-1 и MD5РЕКОМЕНДУЕТСЯ использование SHA-1 |
| Шифрование профиля сообщения для формирования цифровой подписи | Для агентов отсылки и приёма ОБЯЗАТЕЛЬНА поддержка DSSДля агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования RSAДля агента приёма РЕКОМЕНДУЕТСЯ поддержка верификации подписей RSAс длиной ключа от 512 до 1024 битов. |
Шифрование сеансового ключа для передачи с сообщением | Для агентов отсылки и приёма ОБЯЗАТЕЛЬНО поддержка алгоритма Диффи-Хеллмана.Для агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования RSAс длиной ключа от 512 до 1024 битов.Для агента приёма РЕКОМЕНДУЕТСЯ поддержка дешифрования RSA |
| Шифрование сообщения для передачи с использованием сеансового ключа | Для агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования tripleDESи RC2/40.Для агента приёма ОБЯЗАТЕЛЬНА поддержка дешифрования tripleDESи РЕКОМЕНДУЕТСЯ поддержка дешифрования RC2/40. |
S/MIMEобъединяет три алгоритма, использующих открытые ключ. Стандарт цифровой подписи (алгоритм DSS) является предпочтительным алгоритмом создания цифровой подписи. Предпочтительным алгоритмом шифрования сеансовых ключей в S/MIMEназывается алгоритм Диффи-Хеллмана, но фактически в S/MIMEиспользуется вариант алгоритма Диффи-Хеллмана, обеспечивающий шифрование/дешифрование и известный как алгоритм Эль-Гамаля. В качестве альтернативы как для подписей, так и для шифрования сеансовых ключей может использоваться алгоритм RSA.