S/MIME

англ. RFC 1847 (1995)^[1] определяет два типа интернет-контента для S/MIME: multipart/signed для подписи сообщений электронной почты и multipart/encrypted для их шифрования. Электронное сообщение может быть только подписано, только зашифровано или одновременно подвергнуто обеим операциям. Как S/MIME (англ. RFC 2633^[2]), так и OpenPGP (англ. RFC 2440^[3]), спецификации которых появились позднее, используют multipart/signed, однако multipart/encrypted применяется только в OpenPGP. Для целей шифрования S/MIME определяет также новый тип содержимого — application/pkcs7-mime. Современные почтовые клиенты в основном поддерживают S/MIME. Для его работы необходимы сертификаты на основе X.509.

Формат содержит ровно два блока. Первый включает данные, вместе с MIME-заголовком, на которые создаётся электронная подпись. Второй блок содержит информацию, необходимую для проверки подписи. При этом письмо остаётся читаемым даже в почтовых клиентах без поддержки S/MIME. Поэтому multipart/signed считается рекомендуемым среди нескольких возможных подходов S/MIME.

Тип содержимого application/pkcs7-mime имеет необязательный параметр smime-type, описывающий тип данных (без декодирования): enveloped-data (шифрование), signed-data (подпись), certs-only (сертификат). Кроме того, имя файла в необязательной, но рекомендуемой записи заголовка Content-Disposition указывает на тип данных: smime.p7m (подписанные или зашифрованные данные), smime.p7c (сертификат), smime.p7s (подпись).

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

Пример зашифрованного сообщения:

   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
           name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m

   rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
   7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
   f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   0GhIGfHfQbnj756YT64V

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

Поставщики сертификатов для защищённой e-mail-коммуникации обычно классифицируют их по четырём нарастающим классам:

• Класс 1: удостоверяется только подлинность e-mail-адреса заявителя сертификата посредством центра сертификации (CA).
• Класс 2: дополнительно вместе с e-mail-адресом в сертификат вносятся имя (CN) и, при необходимости, организация или компания (OU).
• Класс 3: данные класса 2, а также дополнительная верификация через внешние базы данных, копии удостоверения, выписки из торгового реестра и др.
• Класс 4: заявитель обязан также лично подтвердить свою личность при получении сертификата.

Некоторые компании и некоммерческие организации предоставляют S/MIME-сертификаты бесплатно. Обычно после регистрации может быть выдано несколько сертификатов, которые будут содержать имя пользователя только после определённого уровня подтверждения личности. Такое подтверждение может быть получено от членов Web of Trust или других доверенных лиц, например, адвокатов или аудиторов. Важно понимать, что выдача сертификата без проверки личности заявителя подрывает идею защищённого обмена информацией между компьютерами в сети. В отдельных случаях возможно получение сертификата для чужого сайта с вымышленными данными администратора. Пользователь не будет уведомлён о подмене сайта или электронной подписи, если центр сертификации был заранее признан доверенным производителем браузера^[4].

CAcert, некоммерческий центр сертификации, организованный сообществом (CA), также выпускает бесплатные сертификаты. Однако во многих почтовых клиентах и браузерах он не включён в стандартные доверенные хранилища сертификатов. То есть, если пользователь получает e-mail с подписью или сертификатом CAcert, программа предупредит о недостоверности источника сертификата, если только CAcert не был заранее вручную добавлен в список доверенных.

Кроме того, бесплатные сертификаты класса 1 (иногда со сроком действия менее года, например, как тестовые) выдаются также компаниями, которые в отличие от CAcert входят в реестр доверенных центров сертификации популярных программных продуктов. Эти бесплатные S/MIME-сертификаты обладают полной функциональностью. Примеры бесплатных сертификатов, как правило предназначенных для частного использования:

• ACTALIS S.p.A^[5]. (1 год действия; ВНИМАНИЕ: приватный ключ генерируется на сервере и доступен провайдеру)
• free secure email eID от WISeKey^[6] (3 месяца действия; ВНИМАНИЕ: приватный ключ в некоторых конфигурациях формируется на сервере и доступен провайдеру)
• Secorio S/MIME^[7] (1 месяц действия; используются сертификаты Comodo)
• GlobalSign, пробный сертификат Free Trial PersonalSign 1 Certificate^[8] (30 дней действия)
• Volksverschlüsselung (сервис завершает работу 31 января 2026 года^[9]; 3 года действия; не входит в список доверенных в популярных программах^[10]; только для личного пользования)

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

С помощью SMIMEA администратор домена может публиковать (корневой) сертификат через DNS и самостоятельно подтверждать его подлинность^[11].

Для использования S/MIME-сертификатов при шифровании и подписи требуется пара ключей — публичный и приватный, в соответствии с принципами криптографии с открытым ключом. Оба ключа могут быть сгенерированы через сервисного провайдера. Если приватный ключ создаёт провайдер — это требует доверия к нему в части отсутствия копий, резервных версий или журналов с приватным ключом после передачи его пользователю. Надёжные центры сертификации предлагают процесс, при котором приватный ключ формирует сам пользователь, и он никогда не передаётся CA. Пользователь подаёт в CA свой изначальный публичный ключ как запрос на подписание сертификата, а центр сертификации выпускает всемирно проверяемый публичный сертификат.

В зависимости от требований к защите приватный ключ и CSR-файл могут быть сгенерированы либо в браузере на сайте CA, либо, в случае повышенных мер безопасности, на отдельном компьютере, специально купленном и используемом для этих целей через командную строку. Финальный публичный сертификат обычно доставляется пользователю по электронной почте. Солидные CA публикуют все свои выданные сертификаты в публичном реестре и ведут список отозванных сертификатов.

Организациям, которым нужно большое число S/MIME-сертификатов, CA могут предложить специальные программы для централизованного управления такими ключами с учётом высокого уровня конфиденциальности.

В 2018 и 2019 годах группа немецких специалистов по безопасности провела ряд исследований, посвящённых безопасности подписанных и зашифрованных e-mail-сообщений с использованием S/MIME и PGP:

• Криптографические алгоритмы остаются безопасными, однако протокол S/MIME имеет ряд концептуальных уязвимостей из-за некоторых опциональных вариантов. Эти слабые стороны стали известны как Efail и были широко освещены в СМИ. В RFC 8551^[12] рекомендации по их устранению были включены в спецификацию S/MIME 4.0, где Efail также упомянут поимённо.
• В 2019 году исследования были продолжены в части возможности обхода проверки подписи в популярных почтовых клиентах, если подпись применяется то к CMS, то только к вложению, либо если e-mail содержит две подписи. Обнаруженные уязвимости были сообщены разработчикам в рамках ответственного раскрытия, что позволило им выпустить обновления до публикации проблем^[13][14].

S/MIME обеспечивает высокий уровень безопасности только при одновременном применении и шифрования, и подписи. Если зашифрованные письма не подписаны цифровой подписью, нельзя гарантировать целостность содержания или то, что все получатели видят один и тот же текст. Это связано с отсутствием функциональности Key Commitment: получатель не может гарантировать, что он использует "правильный" ключ, что позволяет создавать зашифрованные сообщения, раскрывающиеся по-разному в зависимости от ключа получателя^[15].

Альтернативой S/MIME может быть PGP или OpenPGP на базе собственной инфраструктуры открытых ключей (PKI). Эти технологии несовместимы между собой, несмотря на использование некоторых схожих криптографических алгоритмов, поскольку применяют разные форматы данных. Наиболее распространены форматы PGP/INLINE и PGP/MIME. Разработка Pretty Easy privacy направлена на автоматизацию и упрощение использования S/MIME и PGP.