Почта с повышенной секретностью PRIVACY-ENHANCED MAIL (PEM)

Почта с повышенной секретностью (Privacy-Enhanced Mail, PEM) представляет собой стандарт Internet для почты с повышенной секретностью, одобренный Советом по архитектуре Internet (Internet Architecture Board, IAB) для обеспечения безопасности электронной почты в Internet. Первоначальный вариант был разработан Группой секретности и безопасности (Privacy and Security Research Group, PSRG) Internet Resources Task Force (IRTF), а затем их разработка была передана в Рабочую группу PEM Internet Engineering Task Force (IETF) PEM Working Group. Протоколы PEM предназначены для шифрования, проверки подлинности, проверки целостности сообщения и управления ключами.

Полностью протоколы PEM сначала были детально описаны в ряде RFC (Requests for Comment, Запросы комментариев) в [977] и затем пересмотрены в [978]. Третья итерация протоколов [979, 827, 980] сведена в [177, 178]. Протоколы были изменены и улучшены, и окончательные протоколы детально описываются в другом наборе RFC [981, 825, 76, 802]. В другой статье Мэтью Бишопа (Matthew Bishop) [179] подробно описаны все изменения. Попытки реализации PEM рассматриваются в [602, 1505, 1522, 74, 351, 1366, 1367]. См. также [1394].

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

PEM поддерживает только определенные алгоритмы, но позволяет добавлять и более поздние алгоритмы. Сообщения шифруются алгоритмом DES в режиме CBC. Проверка подлинности, обеспечиваемая средством Проверки целостности сообщения (Message Integrity Check,MIC), использует MD2 или MD5. Симметричное управление ключами может применять либо DES в режиме , либо тройной DES с двумя ключами (так называемый режим EDE). Для управления ключами PEM также поддерживает сертификаты открытых ключей, используя RSA (длина ключа до 1024 битов) и стандарт X.509 для структуры сертификатов.

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

Документы PEM

PEM определяется в следующих четырех документах:

— RFC 1421: Часть I, Процедуры шифрования и проверки подлинности сообщений. В этом документе определяются процедуры шифрования и проверки подлинности сообщений, которые должны обеспечить функции почты с повышенной секретностью для передачи электронной почты в Internet.

— RFC 1422: Часть II, Управление ключами с помощью сертификатов. В этом документе определяется архитектура и инфраструктура управления ключами, которые основаны на методе сертификатов открытых ключей, предоставляющих информацию о ключах отправителям и получателям сообщений.

— RFC 1423: Часть III, Алгоритмы, режимы и идентификаторы. Этот документ содержит определения, форматы, ссылки и цитаты для криптографических алгоритмов, режимов использования и связанных идентификаторов и параметров.

— RFC 1424: Часть IV, Сертификация ключей и родственные функции. В этом документе описываются три типа функций, поддерживаемых PEM: сертификация ключей, хранение и извлечение списка отозванных сертификатов (certificate revocation list, CRL).

Сертификаты

PEM совместим со схемой проверки подлинности, описанной в [304], см. также [826]. PEM представляет собой надмножество X.509, определяя процедуры и соглашения для инфраструктуры управления ключами, используемой с PEM и в будущем другими протоколами (включая стеки TCP/IP и OSI).

Инфраструктура управления ключами использует общий корень для всей сертификации Internet. Центр регистрационной политики (Internet Policy Registration Authority, IPRA) определяет глобальную стратегию, применимую ко всей иерархии. Ниже корня - IPRA - находятся Центры сертификационной политики (Policy Certification Authorities, PCA), каждый из которых определяет и опубликовывает свою стратегию регистрации пользователей и организаций. Каждый PCA сертифицирован IPRA. Следом за PCA идут CA, сертифицирующие пользователей и и управляющие организационными подразделениями (департаментами, офисами, дочерними компаниями). Первоначально предполагалось, что большинство пользователей будет регистрироваться в качестве членов организаций.

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

Сообщения PEM

Сердцем PEM является формат сообщений. На Рис. 22-4 показано зашифрованное сообщение при симметричном управлении ключами. На Рис. 22-5 показано подписанное и зашифрованное сообщение при управлении ключами на базе открытых ключей, и на Figure 24.6 показано подписанное (но незашифрованное) сообщение при управлении ключами на базе открытых ключей.

-----BEGIN PRIVACY-ENHANCED MESSAGE-----

Proc-Type: 4,ENCRYPTED

Content-Domain: RFC822

DEK-Info: DES-CBC,F8143EDE5960C597

Originator-ID-Symmetric: schneler@counterpane.com,,

Recipient-ID-Symmetric: schneler@chinet.com,ptf-kmc,3

Key-Info :
DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCDA60195DB94F727D3

Recipient-lD-Symmetric: penl-dev@tis.com,ptf-kmc,4

Key-Info :
DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF79F83A2658132DB47
LLrHBOeJzyhP+/fSStdH8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoHlnvNSIHE9M
8tEjmF/zxB+bATMtPjCUHbz8Er9wloxIkjHUlBEpvXROUrUzYbkNpkOagV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlKlZ6720dcBHGGsDLpTpSCnpot

dXd/H5LMDHnonNvPCmQUHt==

-----END PRIVACY ENHANCED MESSAGE-----

Рис. 22-4. Пример встроенного сообщения (симметричный случай)

-----BEGIN PRIVACY-ENHANCED MESSAGE-----

Proc-Type: 4,ENCRYPTED

ContentDomain: RFC822

DEK-Info: DESCBC,BFF968AA74691AC1

0riginator - Certificate :
MIIBlTCCAScCAWuwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEmZCZXRhIDExDzAN
BgNVBAsTBk5PVEESWTAeFw05MTA5MDQxODM4MTdaFmO5MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAmHgYDVQQKExdSUOEgRGFOYSBTZWNlcmlOeSwgSW5jLjEU
MBIGAIUEAxMLVGVzdCBVc2VyIDEmHTAKBgRVCAEBAglCAANLADBIAkEAwHZHI7i+
yJcqDtjJComzTdBJrdAiLAnSC+CnnjOJEEyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F
LZPVtzlrldhYFJQI DAQABMAOGCSqGSIb3DQEBAgUAAIkACKrOPqphJYwlj+YPtc
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2mfX5byMp2X3U/

5XIJXGx7qlJsDgHQGs7Jk9H8CHlfuSHUgN4w==

Key-Info: RSA,
I3rRIGXUGWAF8js5wCzRTkdh034PTHdRZY9Tuvm03M+NM7fx6qc5uIxps2LrlgO+

wGrtiUm/ovtKdlnzeZQ/aQ==

Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAIUEBhMCVVMxIDAeBgNV
BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8mDQYDVQQEEwZCZXRhIDExDTAE
BgNVBAsTBFRMQOEwHhcNOTEmOTAxMDgwMDAwWhcNOTlwOTAxMDclOTU5HjBRMQsw
CQYDVQQGEwJVUzEgMB4GAIUEChMXUINBIERhdGEgU2VjdXJpdHksIEIuYy4xDzAN
BgNVBAsTBkJIdGEgMTEPMAOGAIUECxMGTk9UQVJZMHAmCgYEVQgBAQICArmDYgAm
XwJYCsnp61QCxYykNIODwutF7jMJ3kE+3PjYyHOwk+79rLg6X65B/ED4bJHt05XH
cqAz/7R7XhjYCmOPcqbdzoACZtIIETrKrcJiDYoP+DkZ8klgCk7hQHpbImIDAQAB
MAOGCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKHgSFOeH7AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUHRBcXUpE+x
EREZd9++32ofGBIXaIaInOgVUnOOzSYgugiQO77nJLDUjOhQehCizEs5wUJ35a5h

MIC-Info: RSA-MD5,RSA,
UdFJR8u/TIGhfH651eeme210H4tooa3vZCvVNGBZirf/7nrgzHDABz8m9NsXSexv

AjRFbHoNPzBuxwnlOAFeAOHJszE4yBvhG

Recipient-ID-Asymmetric :
MFExCzAJBgNVBAYTAIVTMSAmHgYDVQQKExdSUOEgRGFOYSBTZHNlcmIOeSwgSH5j

LjEPMAOGAIUECxMGQftiVOYSAxMQ81tfDQYDVQQLEwZOTIRBUIk=,

Key-Info: RSA,
06BSIww9CTyHPtS3bMLD+EOhejdvX6QvlHK2ds2sQPEaXhX8EhvVphHYTjmekdHv

7xOZ3Jx2vTAhOYHMcqqCjA==
qeWlj/YJ2Uf5ng9yznPbtDOmYloSwIuV9FRYx+gzY+81Xd/NQrXHfi6/MhPfPF3d

jIqCJAxvld2xgqQimUzoSla4r7kQQ5c/Iua4LqKeq3clFzEv7MbZhA==

-----END PRIVACY ENHANCED MESSAGE-----

Рис. 22-5. Пример встроенного шифрованного (ENCRYPTED) сообщения (асимметричный случай).

Первым полем является "Proc-Type", идентификатор типа обработки, которой подверглось сообщение. Существует три возможных типа сообщений. Спецификатор "ENCRYPTED" обозначает, что сообщение зашифровано и подписано. Спецификатор "MIC-ONLY" и "MIC-CLEAR" указывают, что сообщение подписано, но не зашифровано. Сообщения MIC-CLEAR не кодируются и могут быть прочитаны с помощью другого, не входящего в PEM программного обеспечения. Для преобразования сообщений MIC-ONLY в удобочитаемую форму необходимо программное обеспечение PEM. Сообщение PEM подписывается всегда, а шифрование не является обязательным.

Следующее поле, "Content-Domain", задает тип почтового сообщения. Оно не влияет на безопасность. Поле "DEK-Info" содержит информацию о ключе обмена данными (DataExchange Key, DEK), алгоритме, используемом для шифрования текста, и параметрах, связанных с алгоритмом шифрования. В настоящее время определен единственный алгоритм - DES в режиме CBC, "DES-CBC" Второе подполе содержит IV. В будущем для PEM могут быть определены и другие алгоритмы, их использование будет запротоколировано в поле DEK-Info и других полях, определяющих алгоритм.

В сообщениях с симметричным управлением ключами (см. Рис. 22-4) следующим полем будет "Originator-ID-Symmetric" с тремя подполями. Первое подполе с помощью уникального адреса электронной почты определяет отправителя. Второе поле не является обязательным и определяет орган, выдавший заменяемый ключ. Третьим является необязательное подполе Версия/Окончание срока.

Далее, при использовании симметричного управления ключами, у каждого получателя есть два поля: "Recipient-ID-Symmetric" и "Key-Info." Поле "Recipient-ID-Symmetric" содержит три подполя, которые определяют получателя также, как подполя поля "Originator- ID-Symmetric" определяют отправителя.

Поле "Key-Info" задает параметры управления ключами. У этого поля четыре подполя. Первое определяет алгоритм, использованный для шифрования DEK. Так как в рассматриваемом сообщении применяется симметричное управление ключами, то отправитель и получатель используют общий ключ. Он называется заменяемым ключом (Interchange Key,IK) и используется для шифрования DEK. DEK может быть зашифрован либо с помощью DES в режиме ECB (этот способ обозначается "DES-ECB"), либо тройным DES ("DES-EDE"). Второе подполе определяет алгоритм MIC. Может использоваться MD2 (обозначается "RSA-MD2") или MD5 ("RSA-MD5"). Третье подполе, DEK, и четвертое подполе, MIC, шифруются с помощью IK.

На Рис. 22-5 и Рис. 22-6 показаны сообщения, в которых используется управление ключами с помощью открытых ключей (в перечне PEM такой способ называется асимметричным). Заголовки изменяются. В сообщениях ENCRYPTED после поля "DEK-Info" идет поле "Originator-Certificate". Форма сертификата соответствует стандарту X.509 (см. раздел 24.9). Следующим полем является "Key-Info" с двумя подполями. Первое подполе определяет алгоритм с открытым ключом, использованный для шифрования DEK, в настоящее время поддерживается только RSA. Следующее подполе - DEK, зашифрованный открытым ключом отправителя. Это необязательное поле, которое позволяет отправителю расшифровать свое собственное сообщение, возвращенное почтовой системой. Следующим полем является "Issuer-Certificate", сертификат организации, подписавшей сертификат отправителя ("Originator-Certificate").

Далее при асимметричном управлении ключами следует поле "MIC-Info". Первое подполе задает алгоритм вычисления MIC, а второе - алгоритм, использованный для подписи MIC. Третье подполе содержит MIC, подписанный закрытым ключом отправителя.

-----BEGIN PRIVACY-ENHANCED MESSAGE-----

Proc-Type: 4,MIC-ONLY

Content-Domain: RFC822

0riginator - Certificate :
MIIBITCCAScCAHUwDQYJKoZIhvcNAQECBQAwTzELMAkGAIUEBhMCVVMxlDAeBgNV
BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSHTAeEw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAIVTMSAwHgYDVQQKExdSUOEgRGFOYSBTZMNlcmlOeSwgSW5jLjEU
MEIGAIUEAxMLVGVzdCBVc2VylDEwHTAKBgRVCAEBAgICAANLADBIAkEAmHZHI71+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F
LZPVtzlndhYFJQIDAQABMAOGCSqGSIb3DQEBAgUAAIkACKrOPqphJYwlj+YPtcIq
ItJIFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2mfX5bMp2X3U/

5XUXGx7qusDgHQGs7Jk9W8CW1fuSI4UgN4w==

Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAkTzELMAkGAIUEBhMCVVMxlDAeBgNV
BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEIZCZXRhIDExDTAE
BgNVBAsTBFRMQOEwHhcNOTEwOTAxMDgwMDAmkmcNOTImOTAxMDclOTU5HjBRMQsw
CQYDVQQGEwJVUzEgMB4GAIUEChMXUINBIERhdGEgU2VjdXJpdHksIEIuYywxDzAN
BgNVBAsTBkJIdGEgMTEPMAOGAIUECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnpelQCxYkNIODwlltF/jMJ3kE+3PjYjHOwk+/9rEg6X65B7LD4bJHt05XH
cqAz77R7XhjYCmOPcqbdzoACZIlETrKrcJIDYoP+DkZ8klgCk7hQHpbltflDAQAB
MAOGCSqGSIb3DQEBAgUAA38AAICPv4f9Gx7tY4+p+4DB7MV+tKZrlvBo8zgoMGOx
dD2jMZ73Hs*kl4gSFOeH7AJB3qr9zosG47pyMnTf3aS2nBO7CMxpUkfRBcXUpE+x
EREZd9++32otGBIXaIalnOgVUnOOzSYgljglQO77nJEDUOhQehCizEs5mUJ35a5h

MIC-Info: RSA-MD5,RSA,
jV20fH+nnXHU8bnE8kPAad7mSQITDZIbVuxvZAOVRZ5q5+EjI5bQvqNeqOUNQjr6

EtE7K2QDeVMCj/XsdJIA8fA==
LSBBIGIIc3NhZ2UgZrti9lHVzZSBpbBOZXNOaH5nLgOKESBGb2xsb3dpbmcgaXMg

YSBibGFuaj/Bsakf51OgOKDQpUaGIzIGIzIHRoZSBIbrnQuDQo=

-----END PRIVACY-ENHANCED MESSAGE-----

Рис. 22-6. Пример встроенного MIC-ONLY сообщения (асимметричный случай).

Следующие поля связаны с получателями. Каждому получателю соответствуют два поля: "Recipient-ID-Asymmetric" и "Key-Info". У поля"Recipient-ID-Asymmetric" два подполя. Первое определяет орган, выдавший открытый ключ получателя, а вторым является необязательное подполе Версия/Окончание срока. Поле "Key-Info'' задает параметры управления ключами: первое подполе определяет алгоритм, использованный для шифрования сообщения, а вторым подполем служит DEK, зашифрованный открытым ключом получателя.

Безопасность PEM

Длина ключей RSA, используемых в PEM, может меняться в диапазоне от 508 до 1024 битов. Этого достаточно практически для любого уровня безопасности. Более вероятно, что вскрытие будет направлено против протоколов управления ключами. Мэллори может украсть ваш закрытый ключ - не записывайте его нигде - или попытаться подсунуть вам фальшивый открытый ключ. Процедуры сертификации ключей в PEM делают это невозможным, если все пользователи строго следуют соответствующим процедурам, но, как известно, люди часто неаккуратны.

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

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

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

TIS/PEM

Доверенные информационные системы (TIS, Trusted Information Systems), частично поддерживаемые Управлением по передовым научным проектам правительства Соединенных Штатов, включают реализацию PEM (TIS/PEM). Разработанные для платформ UNIX, они были также перенесены на VMS, DOS и Windows.

Хотя спецификации PEM определяют для Internet один главный сертификационный центр, TIS/PEM поддерживает существование нескольких иерархий сертификации. Узлы могут определить набор сертификатов, которые будут считаться действительными, включая все сертификаты, выданные узлами. Для того, чтобы пользоваться TIS/PEM узлу не нужно присоединяться к иерархии Internet.

Все организации и граждане США и Канады при желании могут получить доступ к TIS/PEM, которая распространяется в виде исходного кода. Заинтересованные лица должны обращаться по следующему адресу: Privacy-Enhanced Mail, Trusted Information Systems, Inc., 3060 Washington Road IRte. 97), Glenwood, MD 2,1738; (301) 854-6889; fax: (301) 854-5363; Internet: pern-info@tis.com.

RIPEM

RIPEM - это программа, написанная Марком Риорданом (Mark Riordan) и реализующая протоколы PEM. Хотя эта программа не является свободно доступной, ей можно воспользоваться бесплатно для частного, некоммерческого использования. Лицензия на ее использование входит в документацию.

Код не может быть экспортирован. Конечно, законы правительства США не действуют за пределами Соединенных Штатов, и ряд людей игнорирует экспортные ограничения. Код RIPEM доступен по всему миру на электронных досках объявлений. Разрешена для экспорта версия, называемая RIPEM/SIC, реализующая только цифровые подписи.

К моменту написания этих строк RIPEM не полностью реализовала протоколы PEM, в ней нет возможности использовать сертификаты проверки подлинности ключей.

До RIPEM Риордан написал похожую программу RPEM. Подразумевалось, что это будет общедоступная программа электронной почты. Пытаясь обойти патентные проблемы, Риордан использовал алгоритм Rabin (см. раздел 19.5). Public Key Partners заявила, что их патенты распространяются на всю криптографию с открытыми ключами. Под угрозой судебного процесса Риордан прекратил распространение программы.

Сейчас RPEM не используется. Она не совместима с RIPEM. Так как можно использовать RIPEM, не встречая препятствий со стороны Public Key Partners, нет повода возвращаться к RPEM.