Обработка сообщений

У разработчиков ПО есть выбор, но не стандарт

 

ETF (Internet Engineering Task Force  -  специальная группа по технологии Internet) и коммерческие производители предложили несколько проектов стандартов, но единого стандарта безопасной электронной почты на базе Internet пока нет.

 

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

 

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

 

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

 

Когда электронная почта Internet была чисто текстовой средой, существовало два способа шифрования сообщений: PEM (Privacy Enhanced Mail  -  почта с улучшенной секретностью) и PGP (Pretty Good Privacy  -  весьма хорошая секретность). Затем, когда возможности почты, основанной на протоколе SMTP, были расширены за счет введения поддержки сообщений, состоящих из нескольких частей, с использованием стандарта MIME (Multipurpose Internet Mail Extensions  -  многоцелевые расширения почты Internet), были предложены новые методы "упаковки" данных, а также новые системы безопасности.

 

PGP/MIME и MOSS (MIME Object Security Services  -  объектные службы безопасности MIME) представляют собой примеры безопасных упаковок, предназначенных для работы в рамках архитектуры MIME, тогда как MSP (Message Security Protocol  -  протокол безопасности сообщений) и S/MIME (Secure MIME  -  безопасный MIME) являются системами безопасности, не приспособленными специально для использования средств MIME.

 

ВОЖАК СТАИ

 

S/MIME в последнее время имеет наибольшую поддержку производителей: такие компании, как корпорация Netscape Communications и фирмы Network Computing Devices, Qualcomm, Frontier Software Development и FTP Software, обязались включить поддержку S/MIME в следующие версии своих пакетов электронной почты.

 

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

 

Тем временем Internet Mail Consortium (Консорциум по почте Internet, адрес в Web: http://www.imc.org), который проводил в феврале семинар для экспертов по безопасности электронной почты, старается собрать вместе разработчиков всех направлений, чтобы они могли определить и, хотелось бы надеяться, устранить различия между разнообразными реализациями.

 

Такой шаг мог бы привести как к совершенствованию безопасной электронной почты, так и к улучшению возможностей совместной работы разных систем.

 

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

 

ВНУТРИ MIME

 

Одним из принципиальных расширений архитектуры MIME, обеспечивающим поддержку безопасной электронной почты, стала разработка IETF спецификации Security Multiparts (RFC1847). Этот метод отделяет данные, снабжаемые цифровой подписью, от самой подписи, так что они представляют собой две части объекта MIME (типа multipart/signed), состоящего из многих частей. Первая часть представляет собой данные, снабжаемые подписью, а вторая  -  цифровую подпись. Аналогичным образом зашифрованные сообщения представляются как объекты MIME типа multipart/encrypted.

 

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

 

Части типов multipart/signed и multipart/encrypted должны рассматриваться агентами передачи сообщений как непрозрачные, т. е. данные не должны никак изменяться. Многие существующие почтовые шлюзы, однако, проверяют, поддерживает ли следующий пункт назначения 8-разрядные данные, и при необходимости преобразуют данные в другую кодировку (Quoted-Printable или Base64). Такое преобразование делает подпись неверной.

 

Некоторые из предлагаемых схем обеспечения безопасности поддерживают часть архитектуры Security Multiparts, связанную с типом multipart/signed, которая среди прочего облегчает для программы электронной почты поддержку различных подключаемых модулей шифрования. Ни одно из предложений, однако, пока не поддерживает тип multipart/encrypted.

 

PGP/MIME пытается расширить схему аутентификации PGP на MIME, используя Security Multiparts. MOSS делает то же самое со схемой PEM. С другой стороны, MSP и S/MIME включают сообщение и подпись в единое тело сообщения.

 

ВЫРАВНИВАЯ ПРЕДЛОЖЕННЫЕ СТАНДАРТЫ

 

PGP и PEM  -  это первые стандарты обеспечения безопасности текстовой электронной почты. PEM представляет собой ранний стандарт IETF, описанный в RFC 1421-1424, который основывается на 7-разрядных текстовых сообщениях и определяет иерархическую структуру для распространения и проверки цифровых сертификатов. Используемая PEM иерархия органов сертификации (Certificate Authorities) оказалась довольно запутанной и сложной для практической реализации.

 

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

 

Версия 3.0 будет использовать другие стандарты шифрования и аутентификации, не основанные на алгоритмах RSA, и даст возможность пользователям назначать доверенное третье лицо для аутентификации цифровых сертификатов, хотя она также по-прежнему поддерживает и схему "паутины доверия".

 

ВСЕ О MOSS

 

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

 

Между MOSS и PEM имеются следующие отличия:

 

1) при работе с PEM пользователи должны иметь сертификат. При использовании MOSS им нужна только пара ключей  -  открытый (public) и секретный (private);

 

2) MOSS расширяет набор допустимых форм имен, применяемых для идентификации открытых ключей, включая произвольные строки, адреса электронной почты или отличительные имена;

 

3) MOSS полностью интегрирован с MIME.

 

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

 

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

 

Комбинация PGP/MIME

 

PGP/MIME идет по пути, сходному с MOSS, пытаясь интегрировать более ранний протокол (в данном случае PGP) в архитектуру MIME. Этот подход может опереться на популярность PGP, особенно с учетом изменений, которые произойдут в PGP 3.0.

 

Однако поддержка обратной совместимости с обычным форматом PGP при одновременной поддержке схемы Security Multiparts дополнительно усложняет реализацию PGP/MIME.

 

Не существует стандартного формата для отправления электронной почты с использованием кодировки PGP. Есть несколько специальных форматов, и некоторые почтовые программы стараются понять их все, но это не всегда возможно. Существуют также трудности использования PGP с мультимедийными типами данных.

 

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

 

Взгляд на MSP и S/MIME

 

MSP вырос из спецификации Secure Data Network System (система безопасной сети передачи данных), используемой Министерством обороны США, и в нем заметно сильное влияние X.400. Протокол был написан так, чтобы функционировать внутри архитектуры MIME, но, как и S/MIME, MSP использует тип приложения MIME (application/x-msp), чтобы поместить сообщение и подпись в одну часть тела письма.

 

S/MIME представляет собой подход, позволяющий привить поддержку MIME к поддерживаемому RSA стандарту PKCS (Public-Key Cryptographic Standard  -  стандарт криптографии с открытым ключом). Один из его недостатков заключается в том, что любопытные могут определить, кем подписано сообщение. Это не является проблемой при использовании PGP, PGP/MIME или MOSS  -  эти схемы не раскрывают подписавших.

 

Кроме того, S/MIME определяет тип приложения MIME (application/x-pkcs7-mime), который содержит либо подписанные данные, либо подписанные и/или зашифрованные данные. Тем самым зашифрованная часть сообщения кодируется и готовится как часть тела сообщения MIME без отделения цифровой подписи.

 

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

 

Дэйв Косиур