S/MIME

S/MIME ( безопасные/многоцелевые расширения почты Интернета это стандарт шифрования с открытым ключом и подписи данных MIME ) — . S/MIME находится на IETF пути стандартов и определен во многих документах, что наиболее важно. RFC   8551 . Первоначально он был разработан RSA Data Security , а в исходной спецификации использовалась спецификация IETF MIME. с де-факто отраслевым стандартом безопасного формата сообщений PKCS #7 . С тех пор контроль над переходом на S/MIME был передан IETF, и теперь спецификация основана на синтаксисе криптографических сообщений (CMS), спецификации IETF, которая во многих отношениях идентична PKCS #7. Функциональность S/MIME встроена в большинство современных программ электронной почты и обеспечивает взаимодействие между ними. Поскольку MIME создан на основе CMS, он также может содержать расширенную цифровую подпись.

Функция

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

• Аутентификация
• Целостность сообщения
• Неотказ от происхождения (с использованием цифровых подписей)
• Конфиденциальность
• Безопасность данных (с использованием шифрования)

S/MIME указывает тип MIME. application/pkcs7-mime (тип smime «enveloped-data») для упаковки (шифрования) данных, при котором весь (подготовленный) объект MIME, подлежащий конвертированию, шифруется и упаковывается в объект, который впоследствии вставляется в объект MIME application/pkcs7-mime.

Сертификаты S/MIME

Прежде чем S/MIME можно будет использовать в любом из вышеперечисленных приложений, необходимо получить и установить индивидуальный ключ/сертификат либо из собственного центра сертификации (CA), либо из общедоступного центра сертификации. Принятая передовая практика заключается в использовании отдельных закрытых ключей (и связанных с ними сертификатов) для подписи и шифрования, поскольку это позволяет депонировать ключ шифрования без ущерба для свойства неотказуемости ключа подписи. Для шифрования требуется наличие сертификата стороны назначения в хранилище (что обычно происходит автоматически при получении сообщения от стороны с действительным сертификатом подписи). Хотя технически возможно отправить сообщение в зашифрованном виде (с использованием сертификата стороны-получателя) без наличия собственного сертификата для цифровой подписи, на практике клиенты S/MIME потребуют от пользователя установки собственного сертификата, прежде чем они разрешат шифрование другим. Это необходимо для того, чтобы сообщение могло быть зашифровано как для получателя, так и для отправителя, а копия сообщения могла быть сохранена (в папке «Отправленные») и доступна для чтения отправителю.

Типичный базовый персональный сертификат («класс 1») проверяет «личность» владельца только в той мере, в какой он заявляет, что отправитель является владельцем адреса электронной почты «От:» в том смысле, что отправитель может получать электронную почту, отправленную на этот адрес. и таким образом просто доказывает, что полученное электронное письмо действительно пришло с указанного адреса «От:». Он не проверяет имя человека или название компании. Если отправитель желает предоставить получателям электронной почты возможность проверять личность отправителя в том смысле, что полученное имя сертификата содержит имя отправителя или название организации, отправителю необходимо получить сертификат («класс 2») от центра сертификации, который выполняет более углубленный процесс проверки личности, который включает в себя запросы о потенциальном держателе сертификата. Более подробную информацию об аутентификации см. в разделе «Цифровая подпись» .

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

Рабочая группа S/MIME форума CA/Browser

В 2020 году рабочая группа по сертификатам S/MIME Форума CA/Browser Forum был создан для создания базовых требований, применимых к центрам сертификации, выдающим сертификаты S/MIME, используемые для подписи, проверки, шифрования и расшифровки электронной почты. Эти усилия направлены на создание стандартов, включая:

• Профили сертификатов для сертификатов S/MIME и центров сертификации, которые их выдают.
• Проверка контроля над адресами электронной почты
• Проверка личности
• Управление ключами, жизненный цикл сертификатов, методы работы ЦС и т. д.

Версия 1 «Базовых требований к выдаче и управлению публично доверенными сертификатами S/MIME» была опубликована 1 января 2023 года форумом CA/Browser Forum. Он определил четыре типа стандартов сертификатов S/MIME. Подтверждено почтовым ящиком, проверено организацией, проверено спонсором и проверено отдельным лицом.

для практического внедрения S

• Иногда считается, что S/MIME не подходит для использования через клиенты веб-почты . Хотя поддержка может быть взломана в браузере, некоторые методы обеспечения безопасности требуют, чтобы закрытый ключ оставался доступным для пользователя, но недоступным с сервера веб-почты, что усложняет главное преимущество веб-почты: обеспечение повсеместной доступности. Эта проблема не полностью специфична для S/MIME: другие безопасные методы подписи веб-почты также могут потребовать от браузера выполнения кода для создания подписи; исключениями являются PGP Desktop и версии GnuPG , которые извлекают данные из веб-почты, подписывают их с помощью буфера обмена и помещают подписанные данные обратно на страницу веб-почты. С точки зрения безопасности это более безопасное решение.
• S/MIME создан для обеспечения сквозной безопасности. Логически невозможно, чтобы третья сторона проверяла электронную почту на наличие вредоносного ПО и одновременно обеспечивала безопасную сквозную связь. Шифрование позволяет зашифровать не только сообщения, но и вредоносное ПО. Таким образом, если почта не сканируется на наличие вредоносного ПО нигде, кроме конечных точек, таких как шлюз компании, шифрование преодолеет детектор и успешно доставит вредоносное ПО. Единственное решение этой проблемы — выполнить сканирование на вредоносное ПО на станциях конечных пользователей после расшифровки. Другие решения не обеспечивают сквозного доверия, поскольку требуют передачи ключей третьей стороне в целях обнаружения вредоносного ПО. Примеры такого рода компромисса:
  • Решения, которые хранят закрытые ключи на сервере шлюза, чтобы расшифровка могла произойти до сканирования шлюза на наличие вредоносных программ. Эти незашифрованные сообщения затем доставляются конечным пользователям.
  • Решения, которые хранят закрытые ключи на сканерах вредоносных программ, чтобы они могли проверять содержимое сообщений, а затем зашифрованное сообщение передается по назначению.
• Из-за необходимости наличия сертификата для реализации не все пользователи могут воспользоваться преимуществами S/MIME, поскольку некоторые могут захотеть зашифровать сообщение без участия или административных затрат на сертификаты, например, путем шифрования сообщения с помощью открытого/закрытого ключа. вместо этого пара.

Любое сообщение, которое почтовый клиент S/MIME хранит в зашифрованном виде, не может быть расшифровано, если закрытый ключ соответствующей пары ключей недоступен или непригоден по иным причинам (например, сертификат был удален или утерян или пароль закрытого ключа был забыт). Однако сертификат с истекшим сроком действия, отозванный или ненадежный сертификат останется пригодным для использования в криптографических целях. Индексирование открытого текста зашифрованных сообщений может быть невозможно для всех почтовых клиентов. Ни одна из этих потенциальных дилемм не характерна для S/MIME, а скорее для зашифрованного текста в целом и не применима к сообщениям S/MIME, которые только подписаны, а не зашифрованы.

Подписи S/MIME обычно являются «отдельными подписями»: информация о подписи отделена от подписываемого текста. Тип MIME для этого: multipart/signed вторая часть имеет подтип MIME application/(x-)pkcs7-signature. Программное обеспечение списков рассылки печально известно тем, что изменяет текстовую часть сообщения и тем самым делает подпись недействительной; однако эта проблема не характерна для S/MIME, а цифровая подпись показывает только то, что подписанный контент был изменен.

Проблемы безопасности

13 мая 2018 года Electronic Frontier Foundation (EFF) объявила о критических уязвимостях в S/MIME, а также об устаревшей форме PGP, которая до сих пор используется во многих почтовых клиентах. Эта ошибка, получившая название EFAIL , потребовала значительных скоординированных усилий со стороны многих поставщиков почтовых клиентов. С тех пор способы устранения обеих уязвимостей Efail были рассмотрены в разделе «Вопросы безопасности». RFC   8551 .

См. также

• КриптоГраф
• Идентифицированная почта DomainKeys для подписи сообщений электронной почты, обрабатываемой сервером.
• Шифрование электронной почты
• EFAIL , проблема безопасности в S/MIME.
• Защита конфиденциальности GNU (GPG)
• Довольно хорошая конфиденциальность (PGP), особенно «Безопасность MIME с OpenPGP» ( RFC   3156 ).
• Global TrustPoint ( https://www.globaltrustpoint.com ) — независимая метапоисковая система Trustcenter для сертификатов OpenPGP и X.509.

Внешние ссылки

• RFC   5652 : Синтаксис криптографического сообщения (CMS)
• RFC   3370 : Алгоритмы синтаксиса криптографических сообщений (CMS)
• RFC   5751 : Безопасные/многоцелевые расширения почты Интернета (S/MIME) версии 3.2. Спецификация сообщений.
• RFC   8551 : Спецификация сообщений безопасной/многоцелевой почты Интернета (S/MIME) версии 4.0.
• Microsoft Exchange Server: понимание S/ MIME (обзор высокого уровня).