Сообщения РЕМ

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

--- BEGIN PRIVACY-ENHANCED MESSAGE-

Proc-Type: 4,ENCRYPTED

Content-Domain: RFC822

DEK-Info: DES-CBC,F8143EDE5960C597

Originator-ID-Symmetric: [email protected],,

Recipient-ID-Symmetric: schnelergchinet.com,ptf-kmc,3

Key-Info:

DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCDA60195DB94F727D3

Recipient-ID-Symmetric: [email protected],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-

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

--- BEGIN PRIVACY-ENHANCED MESSAGE-

Proc-Type: 4,ENCRYPTED

ContentDomain: RFC822

DEK-Info: DESCBC,BFF968AA74691AC1

Originator - Certificate: MIIBlTCCAScCAWuwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCWMxIDAeBgNV BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEmZCZXRhIDExDzAN BgNVBAsTBk5PVEESWTAeFw05MTA5MDQxODM4MTdaFmO5MzA5MDMxODM4MTZaMEUx CzAJBgNVBAYTAlVTMSAmHgYDVQQKExdSUOEgRGFOYSBTZWNlcmlOeSwgSW5jLjEU MBIGAIUEAxMLVGVzdCBVc2VyIDEmHTAKBgRVCAEBAglCAANLADBIAkEAwHZHI7i+ yJcqDtjJComzTdBJrdAiLAnSC+CnnjOJEEyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F LZPVtzlrldhYFJQI DAQABMAOGCSqGSIb3DQEBAgUAAIkACKrOPqphJYwlj+YPtc iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2mfX5byM_P2X3U/

5XIJXGx7qlJsDgHQGs7Jk9H8CHlfuSHUgN4w==

Key-Info: RSA, I3rRIGXUGWAF8js5wCzRTkdh034PTHdRZY9Tuvm03M+NM7fx6qc5uIxps2LrlgO+

wGrtiUm/ovtKdlnzeZQ/aQ==

Issuer-Certificate: MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAIUEBhMCWMxIDAeBgNV BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8mDQYDVQQEEwZCZXRhIDExDTAE BgNVBAsTBFRMQOEwHhcNOTEmOTAxMDgwMDAwWhcNOTlwOTAxMDclOTU5HjBRMQsw CQYDVQQGEwJVUzEgMB4GAIUEChMXUINBIERhdGEgU2VjdXJpdHksIEIuYy4xDzAN BgNVBAsTBkJIdGEgMTEPMA0GAIUECxMGTk9UQVJZMHAmCgYEVQgBAQICArmDYgAm XwJYCsnp61QCxYykNIODwutF7jMJ3kE+3PjYyHOwk+79rLg6X65B/ED4bJHt05XH cqAz/7R7XhjYCmOPcqbdzoACZtIIETrKrcJiDYoP+DkZ8klgCk7hQHpbImIDAQAB MAOGCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx dD2jMZ/3HsyWKHgSFOeH7AJB3qr9zosG47pyMnTf3aSy2nB07CMxpUHRBcXUpE+x EREZd9++32ofGBIXaIaInOgVUnOOzSYgugiQ077nJLDUjOhQehCizEs5wUJ35a5h

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

AjRFbHoNPzBuxwnlOAFeAOHJszE4yBvhG

Recipient-ID-Asymmetric: MFExCzAJBgNVBAYTAIVTMSAmHgYDVQQKExdSU0EgRGF0YSBTZHNlcmI0eSwgSH5j

LjEPMA0GAIUECxMGQftiV0YSAxMQ81tfDQYDVQQLEwZ0TIRBUIk=,

Key-Info: RSA, 06BSIww9CTyHPtS3bMLD+EOhejdvX6QvlHK2ds2sQPEaXhX8EhvVphHYTjmekdHv

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

jIqCJAxvld2xgqQimUzoSla4r7kQQ5c/Iua4LqKeq3clFzEv7MbZhA==

--- END PRIVACY ENHANCED MESSAGE-

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

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

вано и подписано. Спецификатор "MIC-ONLY" и "MIC-CLEAR" указывают, что сообщение подписано, но не зашифровано. Сообщения MIC-CLEAR не кодируются и могут быть прочитаны с помощью другого, не входя­щего в РЕМ программного обеспечения. Для преобразования сообщений MIC-ONLY в удобочитаемую форму необходимо программное обеспечение РЕМ. Сообщение РЕМ подписывается всегда, а шифрование не является обязательным.

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

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

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

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

На 19-й и 18-й показаны сообщения, в которых используется управление ключами с помощью открытых ключей (в перечне РЕМ такой способ называется асимметричным). Заголовки изменяются. В сообщениях EN­CRYPTED после поля "DEK-Info" идет поле "Originator-Certificate". Форма сертификата соответствует стандар­ту Х.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-0NLY

Content-Domain: RFC822

Originator - Certificate: MIIBITCCAScCAHUwDQYJKoZIhvcNAQECBQAwTzELMAkGAIUEBhMCWMxlDAeBgNV BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN BgNVBAsTBk5PVEFSHTAeEw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx CzAJBgNVBAYTAIVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZMNlcml0eSwgSW5jLjEU MEIGAIUEAxMLVGVzdCBVc2VylDEwHTAKBgRVCAEBAgICAANLADBIAkEAmHZHI71+ yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAAIkACKr0PqphJYwlj+YPtcIq ItJIFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2mfX5bMp2X3U/

5XUXGx7qusDgHQGs7Jk9W8CWlfuSI4UgN4w==

Issuer-Certificate: MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAkTzELMAkGAIUEBhMCWMxlDAeBgNV BAoTFIJTQSBEYXRhIFNIY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEIZCZXRhIDExDTAE BgNVBAsTBFRMQ0EwHhcN0TEw0TAxMDgwMDAmkmcN0TIm0TAxMDcl0TU5HjBRMQsw CQYDVQQGEwJVUzEgMB4GAIUEChMXUINBIERhdGEgU2VjdXJpdHksIEIuYywxDzAN BgNVBAsTBkJIdGEgMTEPMA0GAIUECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw XwJYCsnpelQCxYkNIODwlltF/jMJ3kE+3PjYjHOwk+/9rEg6X65B7LD4bJHt05XH cqAz77R7XhjYCmOPcqbdzoACZHETrKrcJIDYoP+DkZ8klgCk7hQHpbltflDAQAB MAOGCSqGSIb3DQEBAgUAA38AAICPv4f9Gx7tY4+p+4DB7MV+tKZrlvBo8zgoMGOx dD2jMZ73Hs*kl4gSFOeH7AJB3qr9zosG47pyMnTf3aS2nB07CMxpUkfRBcXUpE+x EREZd9++32otGBIXaIalnOgVUnOOzSYgljglQ077nJEDUOhQehCizEs5mUJ35a5h

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

EtE7K2QDeVMCj/XsdJIA8fA== LSBBIGIIc3NhZ2UgZrti91HVzZSBpbBOZXNOaH5nLgOKESBGb2xsb3dpbmcgaXMg

YSBibGFuaj/Bsakf510gOKDQpUaGIzIGIzIHRoZSBIbrnQuDQo=

--- END PRIVACY-ENHANCED MESSAGE-

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

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

Безопасность РЕМ

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

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

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

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

TIS/PEM

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

Хотя спецификации РЕМ определяют для 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: [email protected].

RIPEM

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

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

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

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

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

24.11 Протокол безопасности сообщений

Протокол безопасности сообщений (Message Security Protocol, MSP) - это военный эквивалент РЕМ. Он был разработан NSA в конце 80-х годов при работе по программе создания Безопасной системы передачи данных по сети (Secure Data Network System, SDNS) program. Это совместимый с Х.400 протокол уровня приложения для закрытия электронной почты. MSP планируется использовать в разрабатываемой сети оборонных сообщений (Defense Message System, DMS) Министерства обороны.

Предварительный протокол безопасности сообщений (Preliminary Message Security Protocol, PMSP), который предполагается использовать для "несекретных, но важных" сообщений, представляет собой адаптированную для использования с Х.400 и TCP/IP версию MSP. Этот протокол также называют Mosaic.

Как и РЕМ, программные реализации MSP и PMSP достаточно гибки, их конструкция позволяет подстро­иться под использование различных алгоритмов для осуществления функций безопасности, таких как подпись, хэширование и шифрование. PSMP будет работать с микросхемой Capstone (см. раздел 24.17).

24.12 PRETTY GOOD PRIVACY (PGP)

Pretty Good Privacy (PGP, весьма хорошая секретность) - это свободно распространяемая программа безопас­ной электронной почты, разработанная Филипом Циммерманном (Philip Zimmermann) [1652]. Для шифрования данных она использует IDEA, для управления ключами и цифровой подписи - RSA (длина ключа до 2047 би­тов), а для однонаправленного хэширования - MD5.

Для получения случайных открытых ключей PGP использует вероятностную проверку чисел на простоту, используя для получения стартовых последовательностей интервалы между нажатиями пользователем клавиш на клавиатуре. PGP генерирует случайные ключи IDEA с помощью метода, в ANSI X9.17, Appendix С (см. раз­дел 8.1) [55], используя вместо DES в качестве симметричного алгоритма IDEA. PGP также шифрует закрытый ключ пользователя с помощью хэшированной парольной фразы, а не пароля непосредственно.

Сообщения, зашифрованные PGP, имеют несколько уровней безопасности. Единственная вещь, известная криптоаналитику о зашифрованном сообщении, - это получатель сообщения при условии, что криптоаналитику известен ID ключа получателя. Только расшифровав сообщение, получатель узнает, кем оно подписано, если оно подписано. Это резко отличается от сообщения РЕМ, в заголовке которого немало информации об отправи­теле, получателе и самом сообщении хранится в незашифрованном виде.

Самой интересной особенностью PGP является распределенный подход к управлению ключами (см. раздел 8.12). Центров сертификации ключей нет, вместо этого в PGP поддерживается "сеть доверия". Каждый пользо­ватель сам создает и распространяет свой открытый ключ. Пользователи подписывают ключи друг друга, соз­давая взаимосвязанное сообщество пользователей PGP.

Например, Алиса может физически передать Бобу свои открытый ключ. Боб лично знает Алису, поэтому он

подписывает ее открытый ключ. Одну подписанную копию он возвращает Алисе, а другую оставляет. Когда Алисе нужно связаться с Кэрол, она посылает Кэрол подписанную Бом копию ключа. Кэрол, у которой каким-то образом уже есть ключ Боба (она получила его раньше), и которая доверяет Бобу заверить ключ другого ч е-ловека, проверяет его подпись под ключом Алисы и убеждается, что она правильна. Таким образом, Боб знако­мит Алису и Кэрол.

PGP не определяет стратегию установки доверительных связей, пользователи сами решают, кому верить, а кому нет. PGP обеспечивает механизмы для поддержки ассоциативного доверия открытым ключам и для и с-пользования доверия. Каждый пользователь хранит набор подписанных открытых ключей в виде файла кольца открытых ключей (public-key ring). Каждый ключ кольца обладает полем законности ключа, определяющим уровень доверия к ключу конкретного пользователя. Чем больше уровень доверия, тем больше пользователь уверен в законности ключа. Поле доверия к подписи измеряет, насколько пользователь верит тому, кто подп и-сал открытые ключи других пользователей. И наконец поле доверия к владельцу ключа задает уровень, опред е-ляющий, насколько конкретный пользователь верит владельцу ключа, подписавшему другие открытые ключи. Это поле вручную устанавливается пользователем. PGP непрерывно обновляет эти поля по мере появления но­вой информации.

На 17-й показано, как выглядит эта модель для конкретного пользователя, Алисы. Ключ Алисы находится в самом верху иерархии, владелец ключа абсолютно надежен. Алиса подписывает ключи Боба, Кэрол, Дэйва, Элен и Фрэнка. Она доверяет Бобу и Кэрол подписывать открытые ключи других людей, кроме того, она час­тично доверяет Дэйву и Элен подписывать открытые ключи других людей. И она доверяет Гейл подписывать открытые ключи других людей, хотя сама не подписывала ключ Гейл.

Двух частично доверяемых подписей может оказаться достаточным для сертификации ключа. Алиса счита­ет, что ключ Курта законен, так как Дэйв и Элен подписали его. Уровень доверия устанавливается в PGP вруч­ную, Алиса может выбрать устраивающую ее степень паранойи.

Алиса не должна автоматически доверять ключам других людей только потому, что они подписаны ключом, который она считает правильным. Алиса Она не доверяет Фрэнку Она подписывать другие ключи, хотя она собственноручно подписывала его ключ. Кроме того, она не доверяет подписи Ивана под ключом Мартина или подписи Курта под ключом.

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

Конечно, ничто не мешает Алисе использовать ключи, которым она не доверяет. Задача PGP - предупредить Алису о подозрительности ключа, а не помешать ей устанавливать соединения.

Самым слабым звеном этой системы является отзыв ключей: гарантировать, что кто-нибудь не воспользует­ся скомпрометированным ключом, невозможно. Если закрытый ключ Алисы украден, она может послать некий сертификат отзыва ключа (key revocation certificate), но, так как некое распределение ключей уже произошло, нельзя гарантировать, что это сообщение будет получено всеми, использующими ее открытый ключ в своем кольце ключей. И так как Алиса должна будет подписать свой сертификат отзыва ключа своим закрытым кл ю-чом, то если она потеряет ключ, она не сможет и отозвать его.

Х

У

х подписывает ключ у

Алиса считает ключ законным

Алиса доверяет владельцу ключа право подписывать другие ключи

Алиса частично доверяет владельцу ключа право подписывать другие ключи

Алиса считает ключ незаконным

(V) (V)

Рис. 24-7. Модель доверия в PGP.

Текущей версией PGP является 2.6.2. Появление новой версии, PGP 3.0, ожидается к концу 1995 года. В 3.0 включены опции тройного DES, SHA, другие алгоритмы с открытыми ключами, разделение пар "открытый ключ/закрытый ключ" для шифрования и для подписи, расширенные процедуры отзыва ключей, улучшенные функции управления кольцом ключей, API для интегрирования PGP в другие программы и полностью перепи­санные исполняемые модули.

PGP доступна для MS-DOS, UNIX, Macintosh, Amiga и Atari. В личных, некоммерческих целях ее можно использовать свободно, скачав со многих узлов ftp в Internet. Чтобы скопировать PGP с узла MIT с помощью telnet подключитесь к net-dist.mit.edu, войдите в систему как getpgp, ответьте на вопросы, затем используйте ftp для соединения с net-dist.mit.edu и перейдите в каталог, указанный в сессии telnet. Эту программу также можно получить ftp.ox.ac.uk, ftp.dsi.unimi.it, ftp.funet.fi, ftp.demon.co.uk, CompuServe, AOL, и т.п. Для коммерческого использования в США PGP можно приобрести - полностью, вместе с лицензиями - примерно за 100 долларов в компании ViaCrypt, 9033 N 24th Ave., Phoenix, AZ, 85021; (602) 944-0773; [email protected]. Существуют раз­личные средства, помогающие интегрировать PGP в MS-DOS, Microsoft Windows, Macintosh и UNIX.

О PGP написано несколько книг [601,1394,1495]. Исходный код был даже опубликован в печатном виде в [1653] при попытке обойти Госдепартамент США, который продолжает считать, что исходный код можно экс­портировать только в бумажном, а не в электронном виде. Если вы доверяете IDEA, PGP позволит вам прибли­зиться к военному уровню шифрования.

24.13 Интеллектуальные карточки

Интеллектуальная карточка представляет собой пластиковую карточку, по размеру и форме как кредитная карточка, с встроенной компьютерной микросхемой. Идея стара - первые патенты были выданы лет 20 тому назад - но из-за практических ограничений возможность реализовать такие карточки появилась только приме р-но пять лет назад. С тех пор они стали популярны, главным образом в Европе. Во многих странах интеллекту­альные карточки используются для оплаты за телефоны. Существуют интеллектуальные кредитные карточки, интеллектуальные дебетные карточки, интеллектуальные карточки для чего угодно. Американские компании по выпуску кредитных карточек работают над технологией, и через несколько лет даже захудалые американцы будут носить интеллектуальные карточки в своих бумажниках.

Интеллектуальная карточка содержит маленький компьютер (обычно 8-битовый микропроцессор), ОЗУ (четверть килобайта), ПЗУ (примерно 6-8 килобайт), и несколько килобайт либо EPROM (стираемое програм­мируемое ПЗУ) или EEPROM (электронно стираемое программируемое ПЗУ). Объем памяти в интеллектуаль-

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

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

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

Интеллектуальные карточки - это очень интересная тема, на которую написано множество литературы. Хо­рошей обзорной статьей по криптографии в интеллектуальных карточках может служить [672]. Ежегодно про­водятся конференции: CARTES в октябре в Париже и CardTech в апреле в Вашингтоне, округ Колумбия. Труды двух других конференций по интеллектуальным карточкам можно найти в [342, 382]. В области интеллектуаль­ных карточек существуют сотни патентов, частью принадлежащие европейским компаниям. Интересные вопро­сы будущего использования интеллектуальных карточек - проверка целостности, аудиторский контроль, защита от копирования, электронные наличные, оплата почтовых расходов - описаны в [1628].

24.14 Стандарты криптографии с открытыми ключами

Стандарты криптографии с открытыми ключами (Public-Key Cryptography Standards, PKCS) - это попытка компании RSA Data Security, Inc обеспечить промышленный стандарт для криптографии с открытыми ключами. По традиции такими делами занимался ANSI, но, учитывая текущую ситуацию в криптографической политике, RSADSI решила, что лучше они все сделают сами. Работая со множеством компаний, RSADSI разра­ботала набор стандартов. Некоторые из них совместимы с другими стандартами, а некот орые - нет.

Эти стандарты не являются стандартами в общепринятом смысле этого слова, никто не собирался и не гол о-совал за PKCS. По своим собственным словам RSADSI "будет единственной организацией, правомочной при­нимать решения о каждом стандарте, и будет пересматривать эти стандарты по мере необходимости " [803].

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

Далее приведено краткое описание каждого PKCS (PKCS #2 и PKCS #4 были включены в PKCS #1).

PKCS #1 [1345] описывает способ шифрования и дешифрирования RSA, главным образом для создания циф­ровых подписей и цифровых конвертов, описанных в PKCS #7. Для цифровых подписей сообщение хэшируется, а затем хэш-значение шифруется закрытым ключом подписывающего. Совместное представление сообщения и хэш-значения подробно описано в in PKCS #7. Для цифровых конвертов (шифрованные сообщения) сообщение сначала шифруется симметричным алгоритмом, а затем ключ сообщений шифруется открытым ключом получ а-теля. Совместное представление шифрованного сообщения и шифрованного ключа должно соответствовать PKCS #7. Эти два метода совместимы со стандартами РЕМ. Для структуры сертификатов (или их подобия) от­крытых и закрытых ключей RSA и трех алгоритмов подписи - MD2 и RSA, MD4 и RSA, MD5 и RSA - PKCS #1 также описывает синтаксис, идентичный синтаксису Х.509 и РЕМ.

PKCS #3 [1346] описывает способ реализации обмена ключами по схеме Diffie-Hellman.

PKCS #5 [1347) описывает способ шифрования сообщений секретным ключом, полученным из пароля. Стандарт использует MD2 или MD5 для получения ключа из пароля и шифрует сообщения с помощью DES в режиме СВС. Этот метод предназначен главным образом для шифрования закрытых ключей при их передаче от одной компьютерной системы другой, но может быть использован и для шифрования сообщений.

PKCS #6 [1348] описывает стандартный синтаксис сертификатов открытых ключей. Синтаксис является надмножеством сертификата Х.509, при необходимости можно извлечь и сертификат Х.509. Дополнительные атрибуты не ограничивают процесс сертификации только открытым ключом. Они содержат и другую информ а-цию, например, адрес электронной почты.

PKCS # 7 [1349] представляет собой общий синтаксис для подписываемых или шифруемых данных, напр и-мер, цифровых подписей или цифровых конвертов. Синтаксис является рекурсивным, поэтому можно организ о-вать вложенность конвертов или поставить чью-то подпись под ранее зашифрованными данными. Синтаксис также разрешает вместе с содержанием сообщения проверку подлинности других атрибутов, например, меток

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

PKCS #8 [1350] описывает синтаксис информации о закрытых ключах, включая закрытый ключ и набор а т-рибутов, и синтаксис шифрованных закрытых ключей. Для шифрования информации о закрытых ключах мож­но использовать PKCS #5.

PKCS #9 [1351] определяет избранные типы атрибутов для расширенных сертификатов PKCS #6, сообщений с цифровой подписью PKCS #7 и информации о закрытых ключах PKCS #8.

PKCS #10 [1352,] описывает стандартный синтаксис запросов сертификации. Сертификация включает инди­видуальное имя, открытый ключ и (необязательно) набор атрибутов, которые подписаны лицом, приславшим запрос. Запросы сертификации присылаются в сертифицирующий орган, который преобразует запрос либо в сертификат открытого ключа Х.509, либо в сертификат PKCS #6.

PKCS #11 [1353], Стандарт API криптографической метки (Cryptographic Token API Standard), определяет интерфейс программирования, называемый "Cryptoki", для портативных криптографических устройств всех типов. Cryptoki представляет собой обобщенную логическую модель, позволяющую приложениям выполнять криптографические операции на портативных устройствах, не зная деталей используемой технологии. Этот стандарт также определяет профили приложения: наборы алгоритмов, которые может поддерживать устройство.

PKCS #12 [1354] описывает синтаксис хранения в программном обеспечении открытых ключей пользоват е-лей, защищенных закрытых ключей, сертификатов и другой связанной криптографической информации. Целью этого является стандартизация единого фала ключей, используемого многими приложениями.

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

24.15 Универсальная система электронных платежей

Универсальная система электронных платежей (Universal Electronic Payment System, UEPS) представляет собой банковское приложение, использующее интеллектуальные карточки, первоначально разработанное для сельской Южной Африки, но позднее принятое основными банковскими группами этой страны. К началу 1995 года в ЮАР было выпущено около 2 миллионов карточек. Эта система также принята в Намибии, и разверты­вается по крайней мере одним российским банком.

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

Вот как выглядит протокол связи между покупателем Алисой и продавцом Бобом (В действительности, Али­са и Боб просто вставляют свои карточки в машину и ожидают выполнения транзакции.) Когда Алиса впервые получает свою карточку, она получает и пару ключей, К_г и К₂, банк вычисляет их, используя ее имя и некото­рую секретную функцию. Только в карточки продавцов встроены секретные средства, необходимые для вычи с-ления ключей пользователей.

(1) Алиса посылает Бобу свое имя, А, его имя, В, и случайное число R_A, шифруя их с помощью DES: сначала
ключом К₂, затем К_ъ Она также посылает свое имя открытым текстом.

A,E_K(E_K(A,B,R_A))

(2) Боб вычисляет К_х и К₂ по имени Алисы. Он расшифровывает сообщение, убеждается, что А и В правиль­
ны, затем шифрует незашифрованную вторую половину сообщения Алисы ключом К₂.

E_Ki (A,B,Ra)

Боб не посылает это сообщение Алисе, 56 битов шифротекста становятся ключом К₃. Боб посылает Алисе свое имя, ее имя и случайное число, R_B, шифруя их с помощью DES: сначала ключом К_ъ, затем К_г.

E_Ki(E_Ki(B,A,Rb))

(3) Алиса аналогичным образом вычисляет К₃ и расшифровывает сообщение Боба, убеждаясь, что А и В пра-

вильны, затем шифрует незашифрованную вторую половину сообщения Боба ключом К_ъ. Е_Къ (В,АЛв)

Алиса не посьшает это сообщение Бобу, 56 битов шифротекста становятся ключом К₄. Затем Алиса посы­лает Бобу свое имя, его имя проверочное значение С. Это проверочное значение содержит имена отпра­вителя и получателя, дату, контрольную сумму, количество и два MAC. Все это шифруется DES: сначала ключом К₄, затем К_г. Один из MAC может быть проверен банком Алисы, а второй может быть проверен только расчетно-кассовым центром. Алиса уменьшает свой счет на соответствующее значение.

Е_К(Е_К(А,В,С))

(4) Боб аналогичным образом вычисляет К₄. При условии, что все имена совпадают, и правильно выполнена проверка, он принимает платеж.

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

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

Обе карточки сохраняют записи каждой транзакции. Когда карточки рано или поздно установят диалоговое соединение с банком (продавец - положить деньги на счет, а покупатель - снять со счета), банк извлечет эти з а-писи для последующего контроля.

Аппаратура изготавливается устойчивой к взлому, чтобы помешать любому из участников испортить да н-ные. Алиса не сможет изменить значение своей карточки. Подробная запись обеспечивает данные для обнару­жения и запрещения мошеннических транзакций. В карточках используются универсальные секреты - ключи MAC в карточках покупателей, функции для преобразования имен пользователей в К_х и К₂ - но считается, что решение обратной задачи для этих секретов достаточно трудно.

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

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