Криптография / Learn / book / safety
.htmБезопасность в открытых сетях 6. Безопасность в открытых сетях
6.1 Инфраструктура на основе криптографии с открытыми ключами (ИОК)
6.2 Задачи управления ключами
6.3 Электронный конверт
6.1 Инфраструктура на основе криптографии с открытыми ключами (ИОК)
Криптография с открытыми ключами требует наличия Инфраструктуры Открытых Ключей (PKI – Public Key Infrastructure) – неотъемлемого сервиса для управления электронными сертификатами и ключами пользователей, прикладного обеспечения и систем.
6.1.1 Верификация открытого ключа
Непосредственное использование открытых ключей требует дополнительной их защиты и идентификации для определения связи с секретным ключом. Без такой дополнительной защиты злоумышленник может представить себя как отправителем подписанных данных, так и получателем зашифрованных данных, заменив значение открытого ключа или нарушив его идентификацию. В этом случае каждый может выдать себя за английскую королеву. Все это приводит к необходимости верификации открытого ключа. Для этих целей используется электронный сертификат.
Электронный сертификат представляет собой цифровой документ, который связывает открытый ключ с определенным пользователем или приложением. Для заверения электронного сертификата используется электронная цифровая подпись доверенного центра – Центра Сертификации (ЦС). Исходя из функций, которые выполняет ЦС, он является основной компонентой всей Инфраструктуры Открытых Ключей. Используя открытый ключ ЦС, каждый пользователь может проверить достоверность электронного сертификата, выпущенного ЦС, и воспользоваться его содержимым.
6.1.2 Верификация цепочки сертификатов
Доверие любому сертификату пользователя определяется на основе цепочки сертификатов. Причем начальным элементом цепочки является сертификат центра сертификации, хранящийся в защищенном персональном справочнике пользователя.
Процедура верификации цепочки сертификатов проверяет связанность между именем Владельца сертификата и его открытым ключом. Процедура верификации цепочки подразумевает, что все “правильные” цепочки начинаются с сертификатов, изданных одним доверенным центром сертификации. Под доверенным центром понимается главный ЦС, открытый ключ которого содержится в самоподписанном сертификате. Такое ограничение упрощает процедуру верификации, хотя наличие самоподписанного сертификата и его криптографическая проверка не обеспечивают безопасности. Для обеспечения доверия к открытому ключу такого сертификата должны быть применены специальные способы его распространения и хранения, так как на данном открытом ключе проверяются все остальные сертификаты.
Алгоритм верификации цепочек использует следующие данные:
· X.500 имя Издателя сертификата;
· X.500 имя Владельца сертификата;
· открытый ключ Издателя;
· срок действия открытого (секретного) ключа Издателя и Владельца;
· дополнения, используемые при верификации цепочек (basicConstraints, nameConstraints);
· СОС (список отозванных сертификатов) для каждого Издателя (даже если он не содержит отзываемых сертификатов).
Цепочка сертификатов представляет собой последовательность из n сертификатов, в которой:
· для всех x в {1, (n-1)}, Владелец сертификата x есть Издатель сертификата x+1;
· сертификат x=1 есть самоподписанный сертификат;
· сертификат x=n есть сертификат конечного пользователя.
Одновременно с цепочкой сертификатов используется цепочка СОС, представляющая собой последовательность из n СОС, в которой:
· для всех СОС x в {1, n}, Издатель сертификата x есть Издатель СОС x;
· СОС x=1 есть СОС, изданный Владельцем самоподписанного сертификата;
· СОС x=n есть СОС, изданный Издателем сертификата конечного пользователя;
Сертификат
СОС
1 – самоподписанный сертификат (ROOT)
Издатель СОС = Владелец самоподписанного сертификата (ROOT)
…
…
x – Владелец сертификата x
Издатель СОС = Владелец сертификата x
x+1 – Издатель сертификата = Владелец сертификата x
Издатель СОС = Владелец сертификата x+1
…
…
n - сертификат конечного пользователя
После построения двух цепочек (сертификатов и СОС) выполняется:
· криптографическая проверка сертификатов и СОС в цепочках;
· проверка сроков действия сертификатов и СОС;
· проверка соответствия имен Издателя и Владельца с использованием дополнения nameConstraints;
· проверка длины цепочки с использованием дополнения basicConstraints;
· проверка на отзыв сертификатов, причем если сертификат промежуточного центра был отозван СОС вышестоящего центра, все сертификаты, изданные промежуточным центром, считаются недействительными;
· проверка приемлемых регламентов использования сертификата и приемлемых областей использования ключа с использованием дополнений certificatesPolicies и extendedKeyUsage.
6.1.3 Компоненты ИОК и их функции
В состав компонент ИОК входят следующие компоненты:
· Центр Сертификации;
· Центр Регистрации;
· Конечные пользователи;
· Сетевой справочник.
Центр Сертификации
Основная управляющая компонента ИОК, предназначенная для формирования электронных сертификатов подчиненного Центра Регистрации (или нескольких подчиненных центров) и конечных пользователей. Кроме сертификатов, ЦС формирует список отозванных сертификатов (СОС, X.509 CRL), с регулярностью, определенной Регламентом (Договором) системы.
К основным функциям ЦС относятся:
· Формирование собственного секретного ключа и сертификата ЦС;
· Регистрация подчиненных Центров Регистраций;
· Формирование сертификатов подчиненных Центров Регистраций;
· Формирование сертификатов открытых ключей конечных пользователей на основе данных, формируемых Центром Регистрации;
· Формирование списка отозванных сертификатов;
· Ведение базы данных всех изготовленных сертификатов и списков отозванных сертификатов в течение установленного срока хранения.
Центр Регистрации
Управляющая компонента ИОК, предназначенная для регистрации конечных пользователей. Основная задача ЦР – регистрация пользователей и обеспечение их взаимодействия с ЦС. В задачи ЦР может также входить публикация сертификатов и СОС в сетевом справочнике LDAP.
ЦР является единственной точкой входа и регистрации пользователей. Только зарегистрированный пользователь может получить сертификат на свой открытый ключ в Центре Сертификации.
Конечный пользователь
Пользователь, приложение или система, являющиеся Владельцами сертификата и использующие ИОК.
Сетевой справочник
Опциональная компонента ИОК, содержащая сертификаты и списки отозванных сертификатов и служащая для целей распространения этих объектов среди пользователей с использованием протокола LDAP (HTTP, FTP).
6.1.4 Использование ИОК в приложениях
ИОК используется для управления ключами и электронными сертификатами в приложениях (таких как электронная почта, Web приложения, электронная коммерция), использующих криптографию для установления защищенных сетевых соединений (S/MIME, SSL, IPSEC), или для формирования ЭЦП электронных документов, приложений и т.д. Кроме того, ИОК может быть использована для корпоративных приложений.
Электронная почта и документооборот
Защищенные электронная почта и документооборот используют криптографию для шифрования сообщений или файлов и формирования ЭЦП. Из наиболее известных и распространенных стандартов стоит отметить протокол S/MIME (Secure MultiProse Internet Mail Extensions), который является расширением стандарта Internet почты MIME (MultiProse Internet Mail Extensions).
Web приложения
Web броузеры и сервера используют ИОК для аутентификации и конфиденциальности сессии, а также для онлайновых банковских приложений и электронных магазинов. Наиболее распространенным протоколом в этой сфере является протокол SSL (Secure Sockets Layer). Протокол SSL не ограничивается применением только для защиты HTTP , а также может быть использован для FTP и Telnet.
ЭЦП файлов и приложений
Использование ЭЦП для подписи приложений и файлов позволяет безопасно распространять их по сети Internet. При этом пользователь уверен в корректности полученного приложения от фирмы-разработчика.
6.1.5 Стандарты в области ИОК
Стандарты в области ИОК делятся на две группы: часть из них описывает собственно реализацию ИОК, а вторая часть, которая относится к пользовательскому уровню, использует ИОК, не определяя ее. Стандартизация в области ИОК позволяет различным приложениям взаимодействовать между собой с использованием единой ИОК.
В особенности стандартизация важна в области:
· процедуры регистрации и выработки ключа;
· описания формата сертификата;
· описания формата СОС;
· описания формата криптографически защищенных данных;
· описания онлайновых протоколов.
Основным центром по выпуску согласованных стандартов в области ИОК является рабочая группа ИОК (PKI working group) организации IETF (Internet Engineering Task Force), известная как группа PKIX (от сокращения PKI for X.509 certificates).
Стандарты PKIX
Спецификации PKIX основаны на двух группах стандартов: X.509 ITU-T (Международный комитет по телекоммуникациям) и PKCS (Public Key Cryptography Standards) фирмы RSA Data Security. X.509 изначально был предназначен для спецификации аутентификации при использовании в составе сервиса X.500 директории. Фактически же, синтаксис электронного сертификата, предложенный в X.509 признан стандартом де-факто и получил всеобщее распространение независимо от X.500. Однако X.509 ITU-T не был предназначен для полного определения ИОК. В целях применения стандартов X.509 в повседневной практике пользователи, поставщики и комитеты по стандартизации обращаются к стандартам PKCS.
PKIX группа издала следующие стандарты Internet (RFC):
Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 2459)
Internet X.509 Public Key Infrastructure Certificate Management Protocols (RFC 2510)
Internet X.509 Certificate Request Message Format (RFC 2511)
Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 2527)
Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet (RFC 2528)
Internet X.509 Public Key Infrastructure Operation Protocols – LDAPv2 (RFC 2559)
Internet X.509 Public Key Infrastructure Operation Protocols: FTP and HTTP (RFC 2585)
Internet X.509 Public Key Infrastructure LDAPv2 (RFC 2587)
Internet X.509 Public Key Infrastructure Online Certificate Status Protocol – OCSP (RFC 2560)
X.509
Стандарт X.509 ITU-T является фундаментальным стандартом, лежащим в основе всех остальных, используемых в ИОК. Основное его назначение – определение формата электронного сертификата и списков отозванных сертификатов.
PKCS
Из серии стандартов, изданных фирмой RSA Data Security, наиболее важными и используемыми в ИОК являются:
PKCS#7 Cryptographic Message Syntax Standard;
PKCS#10 Certificate Request Syntax Standard;
PKCS#12 Personal Information Exchange Syntax Standard.
Стандарты, основанные на ИОК
Большинство стандартов, использующих криптографию, разработано с учетом использования ИОК.
S/MIME
Стандарт S/MIME определен IETF для обеспечения защищенного обмена сообщениями. S/MIME использует ИОК для формирования ЭЦП и шифрования информации. В группе стандартов S/MIME наиболее важными являются следующие: Cryptographic Message Syntax, Message Specification, Certificate Handling и Certificate Request Syntax.
SSL и TLS
Протокол SSL (разработанный фирмой Netscape) и соответствующий ему стандарт IETF TLS являются наиболее используемыми стандартами для обеспечения защищенного доступа к Web. Вместе с этим, SSL и TLS широко используются для создания клиент - серверных приложений, не использующих Web. Оба эти протокола в своей основе используют ИОК.
Secure Electronic Transactions (SET)
Протокол SET был разработан фирмами Visa и MasterCard и предназначен для обеспечения системы электронных банковских расчетов с использованием пластиковых карт. В данном протоколе ИОК является фундаментом, на котором базируется вся система аутентификации участников расчетов.
IPSEC
Протокол IPSEC (Internet Protocol Security Protocol) разработан IETF как протокол для шифрования IP и является одним из основных протоколов, используемых для построения VPN. ИОК в протоколе IPSEC используется для аутентификации и шифрования. В настоящее время протокол еще широко не распространен, но повсеместное развитие ИОК приводит к возрастанию количества реализаций IPSEC.
Заключение
Криптография с открытыми ключами и электронные сертификаты позволяют реализовать по настоящему защищенные системы и приложения, использующие современные технологии и сети передачи данных. Стандартизация в данной области позволяет различным приложениям взаимодействовать между собой, используя единую Инфраструктуру Открытых Ключей.
Распространение ключей В симметричных методологиях эта проблема распространения ключей стоит более остро, и поэтому в них ясно определяется, как передавать ключи между участниками взаимодействия до начала взаимодействия. Конкретный способ выполнения этого зависит от требуемого уровня безопасности. Если не требуется высокий уровень безопасности, то ключи можно рассылать с помощью некоторого механизма доставки (например, с помощью простой почты или курьерской службы). Банки, например, используют почту для рассылки PIN-кодов. Для обеспечения более высокого уровня безопасности более уместна ручная доставка ключей ответственными за это людьми, возможно по частям несколькими людьми.
Асимметричные методологии пытаются обойти эту проблему с помощью шифрования симметричного ключа и присоединения его в таком виде к зашифрованным данным. А для распространения открытых асимметричных ключей, используемых для шифрования симметричного ключа, в них используются центры сертификации ключей. CA (центр выдачи сертификатов), в свою очередь, подписывают эти открытые ключи с помощью секретного асимметричного ключа CA. Пользователи такой системы должны иметь копию открытого ключа CA. Теоретически это означает, что участникам взаимодействия не нужно знать ключей друг друга до организации безопасного взаимодействия.
Сторонники асимметричных систем считают, что такого механизма достаточно для обеспечения аутентичности абонентов взаимодействия.
Но проблема все равно остается. Пара асимметричных ключей должна создаваться совместно. Оба ключа, независимо от того, доступны они всем или нет, должны быть безопасно посланы владельцу ключа, а также центру сертификации ключей. Единственный способ сделать это - использовать какой-либо способ доставки при невысоких требованиях к уровню безопасности, и доставлять их вручную - при высоких требованиях к безопасности.
Проблема с распространением ключей в асимметричных системах состоит в следующем:
X.509 подразумевает, что ключи безопасно раздаются, и не описывает способ решения этой проблемы - а только указывает на существование этой проблемы. Не существует стандартов для решения этого. Для безопасности ключи должны доставляться вручную (независимо от того, симметричные они или асимметричные).
Нет надежного способа проверить, между какими компьютерами осуществляется взаимодействие. Есть вид атаки, при котором атакующий маскируется под CA и получает данные, передаваемые в ходе взаимодействия. Для этого атакующему достаточно перехватить запрос к центру сертификации ключей и подменить его ключи своими. Эта атака может успешно продолжаться в течение длительного времени.
Электронная подпись ключей центром сертификации ключей не всегда гарантирует их аутентичность, так как ключ самого CA может оказаться скомпрометированным. X.509 описывает способ электронной подписи ключей CA центрами сертификации ключей более высокого уровня и называет его "путь сертификации". X.509 рассматривает проблемы, связанные с проверкой корректности открытого ключа, предполагая, что эта проблема может быть решена только при отсутствии разрыва в цепочке доверенных мест в распределенном справочнике открытых ключей пользователей. Нет способа обойти это.
X.509 предполагает, что пользователь уже имеет доступ к открытому ключу CA. Как это осуществляется, в нем не определяется.
Компрометация центра сертификации ключей весьма реальная угроза. Компрометация CA означает. Что все пользователи этой системы будут скомпрометированы. И никто не будет знать об этом. X.509 предполагает, что все ключи, включая ключи самого CA, хранятся в безопасном месте. Внедрение системы справочников X.509 (где хранятся ключи) довольно сложно, и уязвимо к ошибкам в конфигурации. В настоящее время слишком мало людей обладают техническими знаниями, необходимыми для правильного администрирования таких систем. Более того, понятно, что на людей, занимающих такие важные должности, может быть оказано давление.
CA могут оказаться узким местом. Для обеспечения устойчивости к сбоям X.509 предлагает, чтобы база данных CA была реплицирована с помощью стандартных средств X.500; это значительно увеличит стоимость криптосистемы. А при маскараде под CA будет трудно определить, какая система была атакована. Более того, все данные из базы данных CA должны посылаться по каналам связи каким-то образом.
Система справочников X.500 сложна в установке, конфигурировании и администрировании. Доступ к этому справочнику должен предоставляться либо с помощью дополнительной службы подписки, либо организации придется самой ее организовывать. Сертификат X.509 предполагает, что каждый человек имеет уникальное имя. Выделение имен людям - задача еще одной доверенной службы - службы именования.
Сеансовые ключи, несмотря на то, что шифруются, все-таки передаются по незащищенным каналам связи.
Несмотря на все эти серьезные недостатки пользователь должен неявно доверять асимметричной криптосистеме.
Управлением ключами называется их распределение, аутентификация и регламентация порядка использования. Независимо от вида используемой криптосистемы ключами надо управлять. Безопасные методы управления ключами очень важны, так как многие атаки на криптосистемы имеют объектом атаки процедуры управления ключами.
Процедура
Комментарии
Физическая раздача
ключей
Курьеры и ручная выдача - вот два распространенных примера этой процедуры. Конечно, из них двоих лучше ручная выдача.
Серьезные организации имеют инструкции, описывающие порядок выдачи ключей.
Раздача ключей может аудироваться и протоколироваться, но это все-таки не защитит ее до конца от компрометации отдельными людьми.
Используется как симметричными, так и асимметричными криптосистемами. Несмотря на заявления о том, что в асимметричных криптосистемах не возникает проблем, связанных с физической доставкой ключей, на самом деле они есть. X.509 предполагает, что создатель ключей будет передавать асимметричный секретный ключ пользователю (и/или асимметричный открытый ключ CA) физически безопасным способом, и что предприняты соответствующие меры физической безопасности, чтобы защитить создателя и проводимые им операции с данными от атак.
Выдача общего
ключа участникам
взаимодействия
центром выдачи
ключей
Может использоваться как симметричными, так и асимметричными криптосистемами.
Так как при данном способе каждый пользователь должен каким-то образом безопасно взаимодействовать с центром выдачи ключей в самом начале работы, то это просто еще один случай, когда начальный обмен ключами является проблемой.
Если центр скомпрометирован, то обеспечение безопасности последующих запросов на выдачу ключей проблематично, а безопасность ранее выданных ключей зависит от криптосистемы.
Предоставление
центром
сертификации
ключей доступа к
открытым ключам
пользователей и
выдача секретных
ключей пользователям
Используется асимметричными криптосистемами.
Пользователи должны доверять всей этой системе.
Всего лишь одна успешная атака компрометирует всю систему.
Иерархическая система аттестации ключей приводит к появлению большего числа потенциальных уязвимых мест - CA должен публиковать свой асимметричный открытый ключ и предоставлять его сертификат, выданный CA более высокого уровня.
Асимметричные секретные ключи CA должны храниться в безопасном месте, так как их компрометация может привести к успешным атакам, которые нельзя будет обнаружить.
Сеть доверия
Используется в асимметричных криптосистемах.
Пользователи сами распространяют свои ключи и следят за ключами других пользователей; доверие заключатся в неформальном способе обмена ключами.
Метод
Диффи-Хеллмана
Обмен секретным ключом по незащищенным каналам связи между двумя пользователями, которые до этого не имели общего секретного ключа.
Не может использоваться для шифрования или расшифровки сообщений.
Основывается на сложности взятия логарифма в конечных полях. При правильном выборе достаточно больших элементов полей решить проблему расчета дискретного логарифма невозможно.
Уязвим к атаке "активное вмешательство в соединение".
Запатентован PKP (Public Key Partners)
6.2 Задачи управления ключами
В широком смысле под криптосистемой понимают не только совокупность процедур шифрования и дешифрования, но также и управление ключами. Управление ключами включает
· генерацию ключей;
· распределение ключей;
· хранение ключей и
· уничтожение ключей.
Ошибки в любой из этих 4 процедур могут привести к тому, что секретная информация или ее часть станут известными злоумышленнику без того, чтобы решать задачу криптоанализа. Ключ является тем элементом криптосистемы, на котором основывается ее стойкость. Если злоумышленнику секретный ключ становится известным, то он получает все привилегии законного пользователя. Ключ может стать известным различными путями, включая установку программных и аппаратных закладок. Принципиальным при рассмотрении криптосистем является способ раскрытия ключа, основанный на криптоанализе, поскольку остальные пути предотвращения перехвата ключевой информации связаны с организационными и техническими мероприятиями. Под раскрытием ключа путем криптоанализа здесь мы будем понимать также определение ключа путем его угадывания (подбора). Принципиально все криптосистемы подвержены такой атаке. Она является наиболее слабой, однако для того, чтобы нападающий не смог добиться успеха этим методом, требуется аккуратность в выборе длины ключа и процедур его генерации. В настоящее время длина ключа. Равная 80 бит, считается безопасной. В ряде шифров предусматривается использование ключа длиной 128 и 256 бит. Некоторые криптосистемы не ограничивают пользователя каким-либо фиксированным размером ключа и предоставляют ему право выбора длины ключа в широком диапазоне.
Основным принципом генерации ключа является равновероятность выбора по всему ключевому пространству (множеству возможных ключей). При генерации ключей используются электронные устройства, в которых протекает случайный физический процесс. Данные устройства называются датчиком шума (или генератором шума). Показания датчика шума замеряются через определенные интервалы времени и оцифровываются. (Причем желательно использовать такие датчики шума, для которых распределение вероятности цифровых показаний является примерно равномерным.) Полученный ряд чисел является несомненно случайным, однако вероятности появления различных значений могут весьма существенно отличаться. В некоторых случаях с течением времени или при изменении условий окружающей среды эти отличия вероятностей становятся более выраженными (или появляются, если таковых первоначально не было). Поэтому, чтобы выровнять вероятности выбора ключей, для формирования текущего ключа q снимаются показания датчика шума до тех пор, пока длина ряда случайных чисел не превысит значительно величину q. После этого вычисляется хэш-функция длины q от полученного случайного ряда и ее значение берется в качестве ключа. (Хэш-функция – это функция, значение которой зависит от каждого бита входной последовательности.)
Периодически механизм генерации ключей подвергается проверке, которая заключается в проведении тестов на случайность и равномерность показаний датчика шума, по которым формируются секретные ключи. В качестве статистических тестов на случайность могут быть использованы следующие: (1)тест хи-квадрат, (2)тесты на сжатие, (3)спектральные тесты, (4) тест инверсий, (5)тест серий.
Распределение ключей в криптосистеме является одной из дорогостоящих процедур. Рассмотрим распределение ключей в одноключевых (симметричных) системах. При использовании симметричной криптографии принципиальным является необходимость наличия в системе связи защищенного канала, по которому секретный ключ доставляется к приемнику и передатчику (в частном случае от передатчика к приемнику). В качестве передачи по защищенному каналу может служить доставка сообщения через доверенное лицо (курьера), предварительный контакт абонентов или другие способы, в том числе охраняемые линии связи. Методы двухключевой (асимметричной) криптографии позволяют осуществить передачу секретного ключа связи по открытому каналу. Вопрос распределения ключей является очень важным, поскольку обычным требованием является смена ключей от сеанса (связи) к сеансу или после передачи определенного объема информации. Нарушение этого правила упрощает задачу раскрытия шифра.
Простейшая схема двусторонней связи представлена на рисунке.
В этом случае каждый сеанс связи может осуществляться с использованием одного ключа. Если криптографическая система объединяет N абонентов в сеть, то необходимо распределить между пользователями по крайней мере N(N-1)/2 ключей. При достаточно большом N это становится проблематичным, так как число распределяемых ключей растет по квадратичному закону. Для решения этой используется ряд структурных решений, учитывающих то, что наиболее сложным и дорогостоящим является эксплуатация защищенного канала.
В одном из вариантов создается некоторый доверительный центр, называемый центром распределения ключей (ЦРК) и являющийся частью общей сети. ЦРК снабжает всех абонентов различными секретными ключами Ki (i =1,2,3, … , N), каждый из которых используется только для связи с центром. Секретная связь между любыми двумя абонентами i и g осуществляется следующим образом (см рис.).
Абонент Ai, связываясь с Aj , пересылает в центр выбранный им ключ связи kij , зашифрованный ключом Ki . ЦРК дешифрует послание, зашифровывает ключ kij ключом Ki и в таком виде пересылает сеансовый ключ абоненту