Криптография 2е издание Протоколы, алгоритмы и исходные тексты на языке С
 Скачать 3.25 Mb.
|
|
двухпроходный или трехпроходный протокол проверки подлинности . Однопроходный протокол представляет собой простую передачу данных Бобу Алисой. Протокол устанавли- вает личности и Алисы, и Боба, а также целостность информации, передаваемой Бобу Алисой . Кроме того, он обеспечивает защиту от вскрытия линии связи с помощью повтора . В двухпроходном протоколе добавлен ответ Боба . Протокол устанавливает, что именно Боб, а не какой-то самозванец, посылает ответ. Он также обеспечивает безопасность обеих передач и защищает от вскрытия по- втором. И в однопроходных, и в двухпроходных алгоритмах используются метки времени . В трехпроходном прото- коле добавляется еще одно сообщение Алисы Бобу и позволяет избежать меток времени (и, следовательно, пр а- вильного единого времени). Однопроходный протокол: (1) Алиса генерирует случайное число R A (2) Алиса создает сообщение, M = (T A , R A , I B , d), где T A - метка времени Алисы, I B - идентификатор Боба, d - произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Боба E B (3) Алиса посылает Бобу (C A , D A (M)). (C A - это сертификат Алисы, D A - это общий узел дерева сертификации.) (4) Боб проверяет C A и получает E A . Он проверяет, что срок действия этих ключей еще не истек . (E A - это от- крытый ключ Алисы.) (5) Боб использует E A для дешифрирования D A (M). Этим действием он проверяет и подпись Алисы, и целос т- ность подписанной информации. (6) Боб для точности проверяет I B в M. (7) Боб проверяет T A в M и убеждается, что сообщение является текущим . (8) Дополнительно Боб может проверить R A в M по базе данных старых номеров, чтобы убедиться, что соо б- щение не является повторяемым старым сообщением . Двухпроходный протокол состоит из однопроходного протокола и последующего аналогичного однопрохо д- ного протокола от Боба к Алисе. После выполнения этапов (1)-(8) однопроходного протокола двухпроходный протокол продолжается следующим образом : (9) Боб генерирует случайное число R B (10) Боб создает сообщение M' = (T B , R B , I A , R A , d), где T B - метка времени Боба, I A - идентификатор Алисы, а d - произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Алисы E А . R A - случайное число Алисы, созданное на этапе (1). (11) Боб посылает Алисе sends D В (M'). (12) Алиса использует E B , чтобы расшифровать D В (M'). Таким образом одновременно проверяются подпись Боба и целостность подписанной информации . (13) Алиса для точности проверяет I A в M'. (14) Алиса проверяет T В в M' и убеждается, что сообщение является текущим . (15) Дополнительно Алиса может проверить R В в M', чтобы убедиться, что сообщение не является повторя е- мым старым сообщением. Трехпроходный протокол решает ту же самую задачу, но без меток времени . Этапы (1) - (15) такие же, как в двухпроходном алгоритме, но T A = T В = 0. (16) Алиса сверяет полученную версию R A с R A , которое было отправлено Бобу на этапе (3). (17) Алиса посылает Бобу D A (R В ). (18) Боб использует E А , чтобы расшифровать D А (R В ). Таким образом одновременно проверяются подпись Алисы и целостность подписанной информации . (19) Алиса сверяет полученную версию R В с R В , которое было отправлено Алисе на этапе (10 ). 24.10 Почта с повышенной секретностью 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 Certifica- tion Authorities, PCA), каждый из которых определяет и опубликовывает свою стратегию регистрации пользов а- телей и организаций. Каждый PCA сертифицирован IPRA. Следом за PCA идут CA, сертифицирующие пользо- вателей и и управляющие организационными подразделениями (департаментами, офисами, дочерними комп а- ниями). Первоначально предполагалось, что большинство пользователей будет регистрироваться в качестве членов организаций. Как ожидается, ряд PCA будет обеспечивать сертификацию пользователей, не входящих ни в одну организ а- цию. Предполагается выделить один или несколько PCA для регистрации пользователей, желающих воспольз о- ваться преимуществами секретности PEM и сохранить анонимность. Стратегия этих PCA будет позволять реги- стрировать пользователей, не желающих раскрывать свои личности . Сообщения PEM Сердцем PEM является формат сообщений. На 20-й показано зашифрованное сообщение при симметричном управлении ключами. На 19-й показано подписанное и зашифрованное сообщение при управлении ключами на базе открытых ключей, и на 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----- Рис. 24-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=, 66 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 не кодируются и могут быть прочитаны с помощью другого, не вход я- щего в PEM программного обеспечения. Для преобразования сообщений MIC-ONLY в удобочитаемую форму необходимо программное обеспечение PEM. Сообщение PEM подписывается всегда, а шифрование не является обязательным. Следующее поле, "Content-Domain", задает тип почтового сообщения. Оно не влияет на безопасность. Поле "DEK-Info" содержит информацию о ключе обмена данными (Data Exchange Key, DEK), алгоритме, исполь- зуемом для шифрования текста, и параметрах, связанных с алгоритмом шифрования . В настоящее время опре- делен единственный алгоритм - DES в режиме CBC, "DES-CBC" Второе подполе содержит IV. В будущем для PEM могут быть определены и другие алгоритмы, их использование будет запротоколировано в поле 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 в режиме ECB (этот способ обозначается "DES-ECB"), либо тройным DES ("DES-EDE"). Второе подполе определяет алгоритм MIC. Может использоваться MD2 (обозначается "RSA-MD2") или MD5 ("RSA- MD5"). Третье подполе, DEK, и четвертое подполе, MIC, шифруются с помощью IK. На 19-й и 18-й показаны сообщения, в которых используется управление ключами с помощью открытых ключей (в перечне PEM такой способ называется асимметричным ). Заголовки изменяются. В сообщениях EN- CRYPTED после поля "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----- Рис. 24-6. Пример встроенного MIC-ONLY сообщения (асимметричный случай). Следующие поля связаны с получателями. Каждому получателю соответствуют два поля : "Recipient-ID- Asymmetric" и "Key-Info". У поля"Recipient-ID-Asymmetric" два подполя. Первое определяет орган, выдавший открытый ключ получателя, а вторым является необязательное подполе Версия/Окончание срока . Поле "Key- Info'' задает параметры управления ключами: первое подполе определяет алгоритм, использованный для ши ф- рования сообщения, а вторым подполем служит DEK, зашифрованный открытым ключом получателя. Безопасность PEM Длина ключей RSA, используемых в PEM, может меняться в диапазоне от 508 до 1024 битов. Этого доста- точно практически для любого уровня безопасности . Более вероятно, что вскрытие будет направлено против протоколов управления ключами. Мэллори может украсть ваш закрытый ключ - не записывайте его нигде - или попытаться подсунуть вам фальшивый открытый ключ . Процедуры сертификации ключей в PEM делают это невозможным, если все пользователи строго следуют соответствующим процедурам , но, как известно, люди часто неаккуратны. |