S/MIME

From CryptoWiki
Jump to: navigation, search

S/MIME (Secure/Multipurpose Internet Mail Extensions) — усовершенствованный стандарт формата MIME для шифрования и подписи электронной почты с помощью открытого ключа.

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

Contents

Функциональные возможности S/MIME

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

  • Упакованные данные. Состоят из ключей шифрованного содержимого и шифрованного содержимого любого формата.
  • Подписанные данные. ЦП получается с помощью вычисления профиля для требующего подписи сообщения и последующего шифрования с использованием закрытого ключа подписывающей стороны. Далее содержимое и ЦП переводятся в base64. Сообщение с данными может быть просмотрено только получателем с использованием возможностей S/MIME.
  • Открытые подписанные данные. Формируется ЦП содержимого. В данном случае с использованием base64 кодируется только ЦП. В результате получатели могут просмотреть содержимое, но не могут проверить подпись без возможностей S/MIME.
  • Подписанные и упакованные данные. Возможности упаковки и подписи вложены одна в другую, так что шифрованные данные могут быть подписаны, а подписанные или открытые подписанные данные могут быть зашифрованы.

Шифрование в S/MIME

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

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

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

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

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

Используемые криптоалгоритмы

S/MIME использует терминологию, принятую в RFC 2119:

  • ОБЯЗАТЕЛЬНО - определяет, является ли абсолютным требованием спецификации. Любая реализация должна включать это свойство или функцию.
  • РЕКОМЕНДУЕТСЯ - могут существовать причины игнорировать это свойство, однако рекомендуется его присутствие.

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

Функция Требование
Создание профиля сообщения, который используется при формировании ЦП ОБЯЗАТЕЛЬНА поддержка SHA-1 и MD5.
РЕКОМЕНДУЕТСЯ использование SHA-1.
Шифрование профиля сообщения для формирования цифровой подписи Для агентов отсылки и приема ОБЯЗАТЕЛЬНА поддержка DSS.
Для агентов отсылки РЕКОМЕНДУЕТСЯ поддержка RSA.
Для агентов приема РЕКОМЕНДУЕТСЯ поддержка верификации подписей RSA с длиной ключа от 512 до 1024 битов.
Шифрование сеансового ключа для передачи с сообщением Для агентов отсылки и приема ОБЯЗАТЕЛЬНА поддержка алгоритма Диффи-Хелмана.
Для агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования RSA с длиной ключа от 512 до 1024 битов.
Для агента приема РЕКОМЕНДУЕТСЯ поддержка дешифрования RSA.
Шифрование собщения для передачи с использованием сеансового ключа Для агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования 3DES и RC2/40.
Для агента приема ОБЯЗАТЕЛЬНА поддержка дешифрования 3DES и РЕКОМЕНДУЕТСЯ поддержка дешифрования RC2/40.

Сообщения в S/MIME

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

Тип Подтип Параметр smime Описание
Multipart (многокомпонентный) Signed (подписанный) Открытое подписанное сообщение. Состоит из 2-х частей: сообщение и подпись.
Application (приложение) pkcs7-mime signedData Подписанный объект S/MIME
envelopedData Шифрованный объект S/MIME
degenerate signedData Объект, содержащий только сертификаты открытых ключей
pkcs7-signature Тип подписи, являющейся частью сообщения типа multipart/signed
pkcs10-mime Сообщение запроса регистрации сертификата

Защита объекта MIME в S/MIME

Защита объекта MIME в S/MIME обеспечивается ЦП, шифрованием или и тем, и другим одновременно. Объектом может выступать как все сообщение, так и отдельные его части. Объект MIME готовится в соответствии с правилами подготовки сообщений в MIME. Затем объект вместе со связанными с ним данными обрабатывается S/MIME. В результате получается объект PKCS. С объектом PKCS обращаются как с содержимым сообщения, которое упаковывают в MIME. Отдельного замечания требует использование кодировок. Зачастую, при применении алгоритмов защиты получается объект, который представляется двоичными данными. Далее полученный результат упаковывается во внешнее сообщение MIME и при этом может использоваться некоторая соответствующая кодировка, обычно base64. Однако при подписи многокомпонентного сообщения само содержимое сообщения в одной из частей остается без изменения после использования средства защиты. Если сообщение не является набором 7-битовых символов, оно должно передаваться в кодировке base64 или quoted-printable во избежание изменения содержимого, к которому относилась подпись.

Упакованные данные

Подтип application/pkcs7-mime необходим для одного из видов обработки S/MIME, каждый со своим уникальным параметром. Полученная в результате форма представляется в формате BER (Basic Encoding Rules), определенном в X.209 [1]. Рассмотрим объект envelopedData (упакованные данные). В ходе подготовки данных в envelopedData выполняются следующие действия.

  • Генерация псевдослучайного ключа.
  • Шифрование сеансового ключа на открытом ключе получателя и RSA.
  • Для всех получателей приводится блок данных называемый RecipientInfo, который содержит сертификат открытого ключа отправителя, шифрованный сеансовый ключ и идентификатор алгоритма шифрования.

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

Подписанные данные

SignedData предназначен для документов, которые подписываются одной или несколькими сторонами. Для определенности в данном контексте ограничимся случаем одной ЦП. В ходе подготовки объекта signedData необходимо выполнить следующие действия.

  • Выбирается алгоритм создания профиля сообщения (SHA-1/MD5).
  • Вычисляется профиль сообщения для подписываемого содержимого.
  • Шифруется профиль сообщения секретным ключом подписывающей стороны.

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

  • идентификатор создания профиля сообщения;
  • подписываемое сообщение;
  • блок SingedInfo.

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

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

ghyHhHUujjhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyghyHhHUujjhJhjH77n8HHGTrfvbn
j756tbB9HGrfvbnjn8HHGTrfvJhjH776tbB9HG4VQbnj7567GhIGfHfYT6gh
yHhHUujpfyF47GhIGfHfYT64VQbnj756

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

Открытое подписанное сообщение

Открытое подписанное сообщение получается при использовании для содержимого типа multipart и подтипа signed. Такое процесс не шифрует открытое сообщение и оно пересылается в открытом виде, ввиду этого получатель с возможностями работы с MIME может прочитать сообщение. Multipart/signed сообщение состоит из двух частей. Первая представляет собой сообщение любого типа MIME, но подготовленная таким образом, чтобы не была изменена в пути следования сообщения. Это означает, что если первая часть не в кодировке 7bit, то необходимо кодирование данных в формат quoted-printable и base64. Далее эта часть обрабатывается как и signedData, однако в такой ситуации создается объект формата signedData, поле содержимого которого остается пустым. Затем он кодируется в base64. Эти данные представляют собой вторую часть многокомпонентного сообщения. Для типа MIME этой второй части выбирается значение application, а для подтипа - pkcs7-signature. Ниже приведен пример такого сообщения.

Content-Type: multipart/signed;
    protocol="application/pkcs7-signature";
    micalg=sha1; boundary=boundary42

--boundary42
Content-Type: text/plain

Это открытый текст подписанного сообщения.

--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujjhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyghyHhHUujjhJhjH77n8HHGTrfvbn
j756tbB9HGrfvbnjn8HHGTrfvJhjH776tbB9HG4VQbnj7567GhIGfHfYT6gh
yHhHUujpfyF47GhIGfHfYT64VQbnj756
--boundary42--

Параметр protocol указывает на то что этот объект представляет собой двухфакторное открытое подписанное сообщение. Micalg обозначает тип используемого профиля сообщения. Получатель проверяет подпись, вычисляя профиль сообщения из первой части и сравнивая с профилем, который получается из второй части.

Запрос регистрации

Для получения сертификатов открытых ключей приложение или пользователь обычно обращаются к удостоверяющему центру. Объект application/pkcs10 необходим для передачи запроса на получение сертификата. Запрос включает блок certificationRequestInfo, за которым следует идентификатор алгоритма шифрования, который завершается подписью блока certificationRequestInfo на секретном ключе отправителя. CertificationRequestInfo включает в себя:

  • имя объекта сертификации;
  • открытый ключ пользователя в виде битовой строки.

Сообщение, содержащее только сертификаты

В ответ на запрос регистрации могут посылаться сообщения, которые содержат только сертификаты или список отозванных сертификатов. Application/pkcs7-mime с параметром degenerate для smime-типа будет типом/подтипом такого сообщения. Действия при этом аналогичны тем, что и при создании signedData, за исключением того что в данном случае нет содержимого сообщения и поле signerInfo пустое.

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

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

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

Обработка сертификатов в S/MIME

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

Роль агента пользователя

В S/MIME пользователь выполняет следующие функции управления сертификатами.

  • Генерация ключей. Для использования утилиты администрирования ОБЯЗАТЕЛЬНО должна быть поддержка возможности генерации пар ключей Диффи-Хеллмана и DSS, так же РЕКОМЕНДУЕТСЯ наличие возможности генерировать ключи RSA. Ключи ОБЯЗАТЕЛЬНО должны генерироваться с использованием случайных значений, а так же быть защищены. РЕКОМЕНДУЕТСЯ генерировать пары ключей RSA, с длиной от 768 до 1024 битов и не генерировать ключи длиной менее 512 битов.
  • Регистрация. Открытый ключ регистрируется с помощью уполномоченного удостоверяющего центра.
  • Хранение и поиск сертификатов. Пользователь должен иметь доступ к локальному списку сертификатов.

Сервис усовершенствованной защиты

Ниже представлено описание трех известных сервисов усовершенствованной защиты.

  • Подписанные подтверждения получения. Может быть запрошено в объекте SignedData. Возврат подписанного подтверждения получения отправителю дает уверенность в том, что получатель получил сообщение, а так же возможность продемонстрировать это третьей стороне. В общем получатель подписывает оригинальное сообщение полностью и присоединяет новую подпись, тем самым формируя новое сообщение S/MIME.
  • Ярлыки защиты. Может включаться в SIgnedData. Ярлыки защиты применяются для управлением доступом, указывая каким из пользователей разрешен доступ к содержимому. Так же возможно указание приоритета (секретный, конфиденциальный и т.д.) или ролевого назначения (например группа администраторов, разработчиков и т.д.).
  • Защищенные списки рассылки. Для избавления от необходимости отправителя указывать на каком открытом ключе зашифровано то или иное сообщение, могут применяться списки рассылки S/MIME. Агент списка рассылки берет сообщение и выполняет необходимые операции шифрования для каждого из получателей, а затем передает сообщение далее. Отправитель должен только отправить сообщение агенту списков рассылки, которое зашифровано с использованием открытого ключа MLA.

Ограничения, связанные с использованием S/MIME

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

  • Отправителю и получателю необходимо согласовать применение клиентских приложений электронной почты, которые поддерживают данный стандарт. В противном случае, почтовый клиент получателя отображает в письмах файлы-вложения «smime.p7s», которые получатель обычно не может корректно интерпретировать.
  • Эффективное применение S/MIME требует комплексного подхода к обеспечению безопасности. Это означает, что необходимо обеспечивать защиту сообщений не только по пути следования от отправителя к получателю, но и в рабочей среде отправителя и получателя. В частности, несоблюдение этого требования может привести к утечке конфиденциальной информации либо несанкционированой модификации сообщений, равно как и компрометации секретных ключей непосредственно на компьютерах пользователей.
  • S/MIME принципиально несовместим с веб-почтой. Это обусловлено тем, что криптография открытых ключей, лежащая в основе стандарта S/MIME, обеспечивает защиту конфиденциальности и целостности сообщений на пути от отправителя до получателя. В то же время конфиденциальность и целостность сообщений недостижимы при традиционном использовании веб-почты, так как провайдер сервиса веб-почты имеет возможность как читать сообщения, так и модифицировать их. В то же время попытки использования подписи или шифрования сообщений на стороне сервера являются компрометацией секретных ключей пользователей. Кроме того, основное преимущество веб-почты, - её доступность с любого компьютера, где есть веб-обозреватель, противоречит требованию контроля защищенности рабочей среды при использовании S/MIME [GoBe08].

См. также


Субботин А. А., Мельников Р. Е., 2013