<< Предыдущая

стр. 50
(из 82 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

функционирует более одного ЦС, т. к. пользователь может не иметь
достоверной копии открытого ключа определенного ЦС, нужной,
чтобы проверить подлинность открытого ключа, содержащегося в
выданном сертификате. Эта проблема решается перекрестной сер­
тификацией, когда открытый ключ одного центра сертификатов
подписывается другим ЦС. Пользователь сначала проверяет откры­
тый ключ соответствующего ЦС, а затем ключ клиента, подписан­
ный этим ЦС.
При существовании достаточного количества
ЦС можно получать довольно длинные цепочки. Корневой ЦС
с помощью которых проверяется подлинность то- /\
го или иного открытого ключа, как показано на цс1 ЦС2
рис. 12.1. Предположим, что Алиса верит в подлип- / \
ность открытого ключа некоторого центра сер- ^
тификатов ЦС (назовем его р,ля определенности /
корневым), а открытый ключ Боба она получи- /
ла с подписью другого центра, ЦС2. Открытый
ключ ЦС2 Алиса может получить либо вместе с ци- Рис. 12.1. При-
фровым сертификатом Боба, либо каким-то дру- ^^Р иерархии сер-
гим путем. Если открытый ключ ЦС2 будет со- '^^Ф^^^^'^^^
держаться в сертификате, подписанном корневым
центром сертификатов, то Алиса сможет доверять всем свидетель­
ствам, подписанным ЦС2 и, в частности, открытому ключу Боба.
Обычно функции центра сертификатов состоят из двух частей:
первая из них связана с удостоверением личности пользователя, а
вторая — с подписыванием открытых ключей. Вторая функция осу­
ществляется собственно ЦС, в то время как первая передается цен­
тру регистрации (ЦР). Такое разделение полномочий — удачная
идея, поскольку при этом ЦС работает в более безопасной среде,
что усиливает защищенность его долгосрочного секретного ключа.
Основная проблема системы центров сертификатов возникает,
когда открытый ключ пользователя компрометируется или стано-
Глава 12. Получение аутентичного открытого ключа

вится недостоверным по каким-то другим причинам. Например,
- третья сторона получила информацию о частном ключе поль­
зователя;
- служащий с таким ключом увольняется из компании.
Поскольку скомпрометированному открытому ключу больше нельзя
доверять, все подписанные с его помощью сертификаты становят­
ся недействительными и должны быть аннулированы. Но они могут
быть распределены между большим числом слабо доступных пользо­
вателей, а каждому из них необходимо сообщить об истечении срока
действия сертификата. Таким образом, ЦС должен как-то инфор­
мировать пользователей о том, что все сертификаты, содержащие
данный открытый ключ, более не действительны. Этот процесс на­
зывается отзывом сертификатов.
Один из возможных путей распространения информации о не­
действительных сертификатах — список отозванных сертифика­
тов (СОС). Это сообщение, подписанное ЦС, содержащее серийные
номера всех сертификатов, которые были отозваны этим центром,
но чей период действия еще не истек. Очевидно, что сертификаты с
истекшим сроком действия в этот список включать не обязательно.
Читая список, пользователь должен быть уверен, что он достаточно
свежий. Поэтому СОС обновляется через регулярные промежутки
времени, даже если никаких реальных изменений в списке не про­
изошло. Такая система хорошо работает в больших корпорациях.
В других ситуациях абсолютно непонятно, как СОС можно дове­
сти до сведения каждого из пользователей, особенно если существу­
ет большое число ЦС, которым доверяет каждый из пользователей.
Подводя итог, скажем, что основными проблемами в криптогра­
фии с секретным ключом были распределение ключей и управление
ими. Эти проблемы могли решаться передачей ключей по закрытым
каналам. В криптографии с открытым ключом названные проблемы
замещаются проблемой аутентификации ключей. Другими слова­
ми, возникает вопрос: какой ключ кому принадлежит? Здесь ключи
должны передаваться по достоверным (или аутентичным) каналам.
Цифровые сертификаты как раз и предназначены Jщя обеспечения
таких надежных каналов распределения открытых ключей.
Система, состоящая из центров сертификатов и самих серти­
фикатов, обычно называется инфраструктурой открытых ключей.
Она по существу позволяет «перераспределять доверие»: необходи­
мость веры в подлинность каждого открытого ключа, которым Вы
обладаете, заменяется на доверие ЦС и его корректной работе.
12.3. Пример прилоэюения инфраструктуры открытых ключей

Будучи уверенным в корректной работе ЦС, Вы можете пола­
гаться на легальную систему, поддерживаемую ЦС, или на коммер­
ческую структуру, в которой ЦС не имеет деловой заинтересованно­
сти. Например, если при подписании Вашего ключа была допущена
ошибка, Вы могли бы публично требовать возмещения ущерба.
Закончим этот параграф таким замечанием: на данный момент
проблема распределения ключей полностью решена. Чтобы два поль­
зователя могли договориться об общем секретном ключе, они снача­
ла получают достоверный открытый ключ от ЦС. Затем секретный
сеансовый ключ вырабатывается, например, с помощью протокола
Диффи-Хеллмана с подписями:

Алиса Боб
(G^5г^nAлиca(G^))
^ {0\8гдпвоб[С^))

где Згдпвоб — процедура подписывания, принадлежащая Бобу.


12.3. Пример приложения инфраструктуры
открытых ключей
в этом параграфе мы познакомимся с некоторыми действующими
системами «перераспределения доверия», опирающимися на цифро­
вые сертификаты
- PGP,
- SSL,
- Х509 (или PKIX),
- SPKL

12.3.1. PGP
Программа шифрования электронной почты PGP (сокр. от Pretty
Good Privacy) использует подход снизу-вверх к «перераспределению
доверия». PGP была разработана с целью обеспечить всех пользо­
вателей недорогой системой шифрования и подписывания. Поэтому
громоздкая, идущая сверху вниз, глобальная инфраструктура от­
крытых ключей здесь не годилась. Вместо этого система использует
то, что обычно называют «сетью доверия».
Управление открытыми ключами осуществляется самими поль­
зователями по принципу снизу-вверх. Каждый из них берет на себя
Глава 12. Получение аутентичного открытого ключа

функции ЦС и подписывает открытые ключи других пользователей.
Так Алиса может подписать открытый ключ Боба, а затем Боб мо­
жет передать этот подписанный «сертификат» Чарли. В этом слу­
чае Алиса выступает как ЦС р,ля Боба. Если Чарли доверяет мне­
нию Алисы о достоверности ключей отдельных людей, то он будет
уверен, что подписанный ею ключ действительно принадлежит Бо­
бу. Поскольку пользователи постоянно делают такие перекрестные
свидетельства, то сеть достоверных открытых ключей растет снизу
вверх (отсюда и название).
Сама PGP как программа использует шифрование RSA для дан­
ных небольшого объема, таких, например, как сеансовый ключ. Для
передачи больших объемов закрытой информации применяется блоч­
ный шифр IDEA. Размер блока в этом шифре — 64 бита, а ключа —
128. Шифр эксплуатируется в режиме CFB. Цифровые подписи в
PGP можно ставить с помош;ью алгоритма RSA или DSA. При при­
еме сообш;ений используется MD5 или SHA-1.
Ключи, которым доверяет отдельный пользователь, объединя­
ются в так называемое кольцо ключей. Это означает, что пользо­
ватели самостоятельно контролируют свой локальный запас откры­
тых ключей. Такой способ не исключает централизованного хране­
ния открытых ключей, но говорит о его необязательности.
Отзыв ключей все еш;е остается нерешенной проблемой програм­
мы РОР^ как впрочем и других подобных систем. Метод «решения»
этой проблемы, применяемый в PGP^ заключается в том, что при
компрометации Вашего ключа необходимо сообп];ить всем друзьям,
что следует выбросить это ключ из их колец ключей. Оповещенные
Вами должны передать информацию дальше и т. д.

12.3.2. П р о т о к о л з а щ и щ е н н ы х с о к е т о в
В то время как проект POP был движим альтруистической иде­
ей обеспечить зап];иту информации р^ля широких масс, протокол
заш;ип];енных сокетов или SSL (Secure Socket Layer) был разрабо­
тан в коммерческих целях, а именно, для обеспечения безопасности
Интернет-магазинов и продаж по сети. По существу SSL усиливает
надежность ТСР^. Он обеспечивает безопасность данных и позво­
ляет нормально работать различным протоколам, таким как, на­
пример, HTTP, FTP, TELNET и т. д.
^Сокр. от Transmission Control Protocol протокол управления передачей (основ­
ной протокол транспортного и сеансового уровней в наборе протоколов Internet,
обеспечивающий надежные ориентированные на соединения полно дуплексные
потоки) — Прим. перев.
12.3. Пример прилооюенил инфраструктуры открытых ключей

Первоначальная его цель состояла в обеспечении безопасности
канала, по которому передаются подробности кредитных карточек
или паролей. Весь обмен сообщениями, кроме начальных, необходи­
мых для установления связи, зашифрован.
Сервер, обеспечивающий передачу информации, а именно, веб­
сайт или основной компьютер в сеансе Telnet^ всегда аутентифици-
рован для удобства клиента. Иногда может быть аутентифицирован
и клиент, но это редко делается при основных коммерческих сдел­
ках по сети Интернет.
Как и в PGP^ шифрование большого потока данных в SSL осу­
ществляется с помощью блочного или поточного шифра (обычно
DES^ или алгоритма семейства RC). Выбор шифра происходит на
начальной стадии установления связи. Сеансовый ключ, используе­
мый в этом обмене информацией, выбирается с помощью стандарт­
ных протоколов, таких как протокол Диффи-Хеллмана или основ­
ной протокол RSA передачи ключей.
Сервер аутентифицирутся, снабжая клиента сертификатом Х509
своего открытого ключа. Этот сертификат (для сделок по Интерне­
ту) подписывается глобальным ЦС, чей открытый ключ находится
на веб-браузере клиента. Для безопасности сеанса Telnet (который
часто называют SSH по имени программы, его осуществляющей)
сертификат сервера обычно подписывает сам основной компьютер.
Далее приведем упрощенную версию операций SSL.
- Клиент устанавливает связь с сервером через специальный порт,
что является сигналом о защищенном сеансе.
- Сервер высылает клиенту сертифицированный открытый ключ.
- Клиент проверяет сертификат и решает, верить ли этому от­
крытому ключу.
- Клиент выбирает случайный секретный ключ.
- Клиент шифрует выбранный секретный ключ с помощью от­
крытого ключа сервера и пересылает результат серверу.
- К этому моменту клиент и сервер обладают общим сеансовым
ключом.
- Сервер подтверждает клиенту свою подлинность, отвечая на
его запрос с помощью общего с ним сеансового ключа.
Определение сеансового ключа может быть дорогостоящей опе­
рацией как для сервера, так и р^ля клиента, особенно когда данные
входят в какие-нибудь крупные пакеты, например, при оформлении
сделок через Интернет или при использовании удаленного доступа
Глава 12. Получение аутентичного открытого ключа

к компьютеру. Поэтому создано некоторое усовершенствование, по-
зволяюш;ее повторное использование сеансовых ключей. Клиент мо­
жет предложить использовать ключ предыдуп1;его сеанса, а сервер
волен либо согласиться на это, либо потребовать создания нового.
Во избежание проблем, это усовершенствование ограничено двумя
правилами. Во-первых, сеансовый ключ имеет строго ограниченное
время жизни, а во-вторых, любая фатальная ошибка в любой ча­
сти протокола приводит к немедленной дискредитации сеансового
ключа и к созданию нового. При установлении связи в SSL достига­
ется соглашение между клиентом и сервером о шифруюш;ем алгорит­
ме, который будет использован при передаче основного потока данных.
Обычно он выбирается из RC4^ RS5^ DES или утроенного DES.

12.3.3. Сертификаты Х509
При обсуждении SSL мы упоминали об использовании сервером сер­
тификата Х509. Это стандарт, определяющий структуру сертифи­
катов открытых ключей. В настояш;ий момент Х509 — наиболее
широко эксплуатируемый стандарт сертификатов. ЦС присваивает
уникальное имя каждому пользователю и выдает подписанный сер­
тификат. Именем часто служит URL или электронный адрес (email).
При использовании последнего могут происходить различные ка­
зусы. Дело в том, что большинство пользователей имеют различные
версии одного и того же email'a. Например, Вы посылаете письмо с
Вашим сертификатом на свой email:
N.P.Smart@some.where.com,
а Ваша почтовая программа реально посылает эту информацию по
такому:
Nigel.Smart@some.where.com.
Поэтому, даже если с Вашей точки зрения оба адреса эквивалентны,
почтовая программа получателя может счесть подпись не действи­
тельной.
Различные ЦС объединены друг с другом в виде дерева, в ко­
тором каждый ЦС выдает сертификат ^\ля стоявшего ниже (в этом
дереве). Кроме того, возможны и перекрестные свидетельства меж­
ду ветвями дерева. Сертификаты Х509 определены в стандартах на
языке ASN.l'^. При первом знакомстве они могут показаться доволь-

^ASN.l — сокр. от Abstract Syntax Notation One — абстрактная синтаксическая
нотация версии 1. Это язык, используемый в рамках протоколов взаимодействия
открытых систем для описания абстрактных синтаксических структур. — Прим.
перев.
12.3. Пример прилоэюенил инфраструктуры открытых ключей

но сложными, а обработка всех возможных опций часто заканчива­
ется невероятным сообщением: «раздувание кодов» ('code bloat').
Структура базисного сертификата Х509 очень проста, но силь­
но услождяется в любом разумном приложении. Происходит так по­
тому, что в современных приложениях Х509 возникает необходи­
мость вставлять внутрь сертификатов дополнительную информа­
цию, обеспечивающую авторизацию и другие возможности. Тем не
менее, следующие записи всегда присутствуют в сертификате:
- Номер версии стандарта Х509^ которому соответствует дан­
ный сертификат.
- Серийный номер сертификата.
- Идентификатор подписывающего алгоритма ЦС, что дает ин­
формацию об алгоритме и его параметрах домена, если со­
ответствующий ЦС имеет возможность использовать разные
алгоритмы и параметры домена.
- Имя изготовителя сертификата, т.е. название ЦС.
- Срок действия сертификата в форме «не раньше - не позже».
- Имя субъекта, т. е. того, чей открытый ключ подписывается.
Именем может служить как email-адрес, так и имя, использу­
емое в домене.
- Открытый ключ субъекта, что включает в себя название ис­
пользуемого алгоритма, все необходимые параметры домена и
фактическое значение открытого ключа.
- Подпись ЦС на открытом ключе субъекта и всех сопутствую­
щих данных, например, имени субъекта.

<< Предыдущая

стр. 50
(из 82 стр.)

ОГЛАВЛЕНИЕ

Следующая >>