Компьютерные сети. 6-е изд.

8.8. Управление открытыми ключами

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

Между тем мы обошли один важный вопрос: если Алиса и Боб друг друга не знают, как они обменяются открытыми ключами перед началом общения? Очевидное решение — выложить ключ на веб-сайте. Однако так делать нельзя, и вот почему. Представьте, что Алиса хочет найти открытый ключ Боба на его сайте. Как она это делает? Набирает URL сайта. Браузер ищет DNS-адрес домашней страницы Боба и передает запрос GET (илл. 8.25). К сожалению, Труди в этот

Илл. 8.25. Способ вторжения в систему с открытыми ключами

момент перехватывает запрос и отсылает Алисе фальшивую страницу, например копию страницы Боба, на которой вместо его ключа выложен открытый ключ Труди. После того как Алиса зашифрует свое первое сообщение с помощью ET, Труди расшифрует его, прочтет, зашифрует с помощью открытого ключа Боба и перешлет ничего не подозревающему Бобу. Но гораздо хуже то, что Труди может менять сообщения перед повторным шифрованием и отправкой Бобу. Очевидно, необходим механизм секретного обмена открытыми ключами.

8.8.1. Сертификаты

Конечно, можно попытаться решить эту проблему с помощью центра распространения ключей (Key Distribution Center, KDC), круглосуточно доступного в интернете и предоставляющего открытые ключи по требованию. Однако у этого решения есть множество недостатков; в частности, оно не поддается масштабированию — такой центр очень быстро станет узким местом. А если он не выдержит нагрузки, вся интернет-безопасность в один момент сойдет на нет.

По этой причине возникло новое решение, не требующее постоянного доступа к центру распространения ключей. На самом деле даже не обязательно, чтобы центр вообще работал онлайн. Вместо этого на него возлагается обязанность сертификации открытых ключей, принадлежащих как физическим, так и юридическим лицам. Организация, выполняющая эту задачу, в настоящее время называется центром сертификации (Certification Authority, CA).

В качестве примера рассмотрим такую ситуацию: Боб хочет разрешить Алисе и другим лицам, с которыми он не знаком, устанавливать с ним защищенные соединения. Он приходит в CA со своим открытым ключом, а также паспортом или другим удостоверением личности и просит зарегистрировать ключ. CA выдает ему сертификат (похожий на тот, что показан на илл. 8.26) и подписывает хеш SHA-2 своим закрытым ключом. Затем Боб оплачивает услуги CA и получает документ, содержащий сертификат и его подписанный хеш (который в идеале должен передаваться по надежным каналам).

Настоящим удостоверяю, что открытый ключ

19836A8B03030CF83737E3837837FC3s87092827262643FFA82710382828282A

принадлежит

Роберту Джону Смиту

12345, Юниверсити-авеню

Беркли, Калифорния 94702

Дата рождения: 4 июля 1958 г.

Email: bob@superdupernet.com

Хеш SHA-2 данного сертификата подписан закрытым ключом CA

Илл. 8.26. Пример сертификата и подписанного хеша

Основная задача сертификата — связать открытый ключ с именем принципала (физического или юридического лица). Сами сертификаты никак не защищаются и не хранятся в тайне. Боб может выложить его на свой сайт и поставить ссылку: «Здесь находится сертификат моего открытого ключа». Перейдя по ссылке, пользователь увидит и сертификат, и блок с подписью (подписанный хеш SHA-2 сертификата).

Теперь снова рассмотрим сценарий, показанный на илл. 8.25. Что может сделать Труди, перехватив запрос страницы Боба, отправленный Алисой? Она может выложить свой сертификат и блок с подписью на подложной странице, однако Алиса сразу догадается, что разговаривает не с Бобом: его имени в этом сертификате просто нет. Труди может изменить домашнюю страницу Боба на лету, заменив его открытый ключ своим собственным. Но Алиса может проверить сертификат алгоритмом SHA-2. Тогда она получит значение хеш-функции, которое не согласуется со значением, вычисленным по открытому ключу CA и блоку подписи. Труди не имеет доступа к закрытому ключу CA и никак не может сгенерировать блок подписи, содержащий хеш модифицированной страницы с открытым ключом Труди. Таким образом, Алиса может не беспокоиться о подлинности ключа Боба. Как мы и обещали, при такой схеме не требуется, чтобы CA постоянно работал онлайн. Тем самым ликвидируется потенциально узкое место системы.

Сертификат используется для связывания открытого ключа не только с принципалом, но и с атрибутом. Например, он может содержать такую информацию: «Данный открытый ключ принадлежит лицу старше 18 лет». Этим можно подтвердить статус принципала или убедиться в том, что ему разрешен доступ к некоторым специфическим данным, на которые накладываются возрастные ограничения. При этом имя владельца может и не раскрываться. Обычно владелец отсылает сертификат на веб-сайт, принципалу или процессу, запрашивающему информацию о возрасте клиента. В ответ генерируется случайное число, шифруемое с помощью открытого ключа (считываемого с сертификата). Если клиент (то есть владелец) сможет расшифровать его и отослать обратно, это будет служить подтверждением тому, что он действительно обладает указанными в сертификате характеристиками. Кроме того, это случайное число может быть использовано в качестве сеансового ключа для будущего соединения.

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

8.8.2. X.509

Если бы все желающие подписать что-либо обращались в CA за сертификатами различных видов, обслуживание разнообразных форматов вскоре стало бы проблемой. Во избежание этого МСЭ разработал и утвердил специальный стандарт сертификатов. Он называется X.509 и широко применяется в интернете. Начиная с 1988 года вышло уже три версии X.509; мы рассмотрим новейшую из них — третью.

На стандарт X.509 сильное влияние оказала система OSI, из которой он позаимствовал худшие ее свойства, в частности принцип кодирования и именования. Удивительно, что IETF согласился с данной концепцией, учитывая, что практически во всех областях, начиная с машинных адресов и заканчивая транспортными протоколами и форматами электронных писем, IETF всегда игнорировал OSI и пытался сделать что-нибудь более толковое. IETF-версия X.509 описана в RFC 5280.

По сути, X.509 — это способ описания сертификатов. Основные поля сертификата перечислены на илл. 8.27. Из описаний, приведенных в правой колонке, должно быть понятно, для чего служит соответствующее поле. За дополнительной информацией обращайтесь к RFC 2459.

Поле

Значение

Version

Версия X.509

Serial number

Это число вместе с именем CA однозначно идентифицирует сертификат

Signature algorithm

Алгоритм генерации подписи сертификата

Issuer

X.500-имя CA

Validity period

Начало и конец периода годности

Subject name

Сущность, ключ которой сертифицируется

Public key

Открытый ключ сущности и идентификатор использующего его алгоритма

Issuer ID

Необязательный идентификатор, единственным образом определяющий эмитента (создателя) сертификата

Subject ID

Необязательный идентификатор, единственным образом определяющий владельца сертификата

Extensions

Возможны многочисленные расширения

Signature

Подпись сертификата (генерируется с помощью закрытого ключа CA)

Илл. 8.27. Основные поля сертификата в стандарте X.509

Например, если Боб работает в отделе ссуд банка Money Bank, его X.500-адрес будет выглядеть так:

/C=US/O=MoneyBank/OU=Loan/CN=Bob/

где C — страна, O — организация, OU — отдел организации, CN — имя. CA и другие сущности именуются похожим образом. Серьезная проблема с системой именования X.500 заключается в том, что если Алиса пытается обратиться к Бобу по адресу bob@moneybank.com и имеет данные сертификата с именем в этом формате, для нее вовсе не очевидно, что этот сертификат относится именно к тому Бобу, который ей нужен. К счастью, начиная с третьей версии, появилась возможность использовать имена DNS вместо имен X.500, что позволяет наконец забыть об этой проблеме.

Сертификаты кодируются с помощью языка ASN.1 (Abstract Syntax Notation 1 — абстрактная синтаксическая нотация версии 1), используемого в модели OSI. Более подробную информацию о X.509 можно найти в книге Форда и Баума (Ford and Baum, 2000).

8.8.3. Инфраструктуры систем с открытыми ключами

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

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

По этим причинам был разработан альтернативный способ сертификации открытых ключей. Он известен под общим названием инфраструктуры открытых ключей (Public Key Infrastructure, PKI). В этом разделе мы рассмотрим только общие принципы действия PKI, поскольку было внесено множество предложений по ее модификации и некоторые детали могут со временем измениться.

PKI состоит из множества компонентов — пользователей, CA, самих сертификатов, а также каталогов. Она предоставляет возможность структурировать эти компоненты и определяет стандарты, касающиеся различных документов и протоколов. Одним из простейших видов PKI является иерархия CA (илл. 8.28). На рисунке представлены три уровня, но их может быть как больше, так и меньше. CA верхнего уровня (корневой центр сертификации) сертифицирует CA второго уровня — назовем их региональными (промежуточными) центрами сертификации (Regional Authorities, RA), так как они могут обслуживать некоторый географический регион (например, страну или континент). Этот термин не стандартизован. Названия для уровней иерархии вообще не оговариваются стандартом. RA занимаются легализацией реальных CA, эмитирующих сертификаты стандарта X.509 для физических и юридических лиц. Когда корневой центр авторизует RA, он генерирует подтверждающий полномочия RA сертификат X.509, включает в него открытый ключ нового RA, подписывает его и передает RA. Аналогичным образом RA взаимодействуют с CA: выдают и подписывают сертификаты, содержащие открытые ключи CA и признающие легальность их деятельности.

Илл. 8.28. (а) Иерархия PKI. (б) Цепочка сертификатов

Итак, наша PKI работает следующим образом. Допустим, Алисе, чтобы пообщаться с Бобом, нужен его открытый ключ. Она находит сертификат, в котором содержится нужный ключ. Этот сертификат подписан CA 5. Однако Алиса никогда ничего не слышала о CA 5. Этим «CA» вполне может оказаться десятилетняя дочка Боба. Алиса обращается к CA 5 за подтверждением его легитимности. Он предъявляет сертификат, полученный от RA 2 и содержащий открытый ключ CA 5. Теперь, вооружившись открытым ключом CA 5, Алиса может удостовериться в том, что сертификат Боба действительно подписан CA 5, а значит, является легальным.

Если только RA 2 не является двенадцатилетним сыном Боба. Что ж, следующим шагом Алисы будет запрос подтверждения легитимности RA 2. Ответом будет служить сертификат с подписью корневого центра сертификации, содержащий открытый ключ RA 2. Вот теперь Алиса может не сомневаться, что она получила открытый ключ Боба, а не кого-то еще.

А если Алиса хочет узнать открытый ключ корневого CA? Как это сделать? Загадка. Предполагается, что его знают все. Например, он может быть «вшит» в ее браузер.

Но наш Боб — добряк, он не хочет доставлять Алисе лишних хлопот. Он понимает, что она захочет проверить легитимность CA 5 и RA 2, поэтому сам собирает нужные сертификаты и отправляет их вместе со своим. Теперь, зная открытый ключ корневой организации, Алиса может проверить по цепочке все интересующие ее компоненты. Ей не придется никого беспокоить для подтверждения. Поскольку все сертификаты подписаны, она может запросто уличить любые попытки подлога. Цепочка сертификатов, восходящая к корню, иногда называется доверительной цепочкой (chain of trust) или путем сертификации (certification path). Описанный метод широко применяется на практике.

Конечно, остается проблема определения владельца корневой организации. Лучше всего иметь несколько таких структур, причем связать с каждой из них свою иерархию RA и CA. На самом деле в современные браузеры действительно «зашиваются» открытые ключи более 100 корневых CA, иногда называемые доверительными якорями (trust anchors). Как видите, можно избежать проблемы одного всемирного учреждения, занимающегося сертификацией.

Однако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. На самом деле все сводится к тому, насколько конечный пользователь доверяет разработчику браузера и уверен в том, что решения генерируются грамотно, а доверительные якоря не принимаются от всех желающих за умеренную плату. Большинство браузеров позволяют пользователям проверять корневые ключи (обычно в виде сертификатов, подписанных корневым CA) и удалять те, которые кажутся сомнительными. Более подробную информацию о PKI можно найти в книге Стэплтона и Эпштейна (Stapleton and Epstein, 2016).

Каталоги

PKI должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сертификаты у себя. Это безопасно (так как невозможно подделать подписанные сертификаты незаметно), но не слишком удобно. В качестве каталога для сертификатов было предложено использовать DNS. Скорее всего, прежде чем соединиться с Бобом, Алисе все равно придется узнать его IP-адрес с помощью DNS. Так почему бы DNS не возвращать вместе с IP-адресом всю цепочку сертификатов?

Кому-то это кажется выходом из положения, но некоторые считают, что лучше иметь специализированные серверы с каталогами для хранения сертификатов X.509. Такие каталоги могли бы обеспечить возможность поиска с помощью имен X.500. Например, теоретически можно представить себе службу сервера каталогов, позволяющую получать ответы на запросы типа «Дайте мне полный список всех сотрудников с именем Алиса, работающих в отделах продаж по всей стране».

Отзыв сертификата

Реальный мир полон разнообразных сертификатов — паспорта, водительские удостоверения и т.д. Иногда их необходимо аннулировать (например, водительское удостоверение объявляется недействительным за езду в нетрезвом виде). Та же проблема возникает и в мире цифровых технологий: лицо, предоставившее сертификат, может отозвать его за нарушение противоположной стороной каких-либо условий. Это необходимо делать и в том случае, если закрытый ключ сущности (а еще хуже, ключ CA) был рассекречен. Таким образом, PKI должна обеспечивать процедуру отзыва сертификата, хотя это все усложняет.

Прежде всего, CA должны периодически выпускать список отозванных сертификатов (Certificate Revocation List, CRL). В нем перечисляются их порядковые номера. Поскольку в сертификатах содержится дата окончания срока годности, в CRL следует включать номера только тех из них, срок годности которых еще не истек. По истечении срока годности сертификаты перестают быть действительными автоматически, это не то же самое, что отозванные сертификаты. В обоих случаях использовать их больше нельзя.

К сожалению, наличие CRL означает, что перед использованием сертификата нужно убедиться в том, что его нет в списке. В противном случае от него следует отказаться. При этом сертификат может быть отозван сразу после выпуска самого свежего варианта списка. Получается, что единственный надежный способ узнать о состоянии сертификата — обратиться непосредственно к CA. Эти запросы придется отсылать при каждом использовании сертификата, так как нет никакой гарантии, что его не отозвали несколько секунд назад.

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

Где же хранить списки недействительных сертификатов? Было бы удобно хранить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что CA периодически выпускает CRL и каталоги обновляются (отозванные сертификаты просто удаляются из них). Если для хранения сертификатов каталоги не используются, можно кэшировать их в разных местах в сети. Поскольку CRL сам по себе является подписанным документом, любые попытки подлога тотчас будут замечены.

Если у сертификатов большие сроки годности, CRL также будут довольно длинными. Аналогично, число заблокированных кредитных карточек будет гораздо выше, если их срок годности равен 5 годам, а не 3 месяцам. Стандартный способ борьбы с длинными списками — редко выпускать сами CRL, но часто их обновлять. Помимо прочего, это снижает необходимую для распространения CRL пропускную способность.