Так что Бог включает Алисин сертификат в список аннулированных сертификатов, или CRL (certificaterevocationlist). (Вспомним, как 20 лет назад торговцы публиковали списки номеров недействительных кредитных карт. Это CRL.) Бог выпускает CRL регулярно (компании кредитных карт делают это раз в неделю), и это уж дело Боба – удостовериться, что Алисин сертификат не находится в последнем списке, прежде чем он использует его. Он должен также убедиться, что сертификат не просрочен и что он в действительности принадлежит Алисе.
Каким образом Боб может осуществить последнее? Он сравнит имя Алисы с указанным на сертификате. Если они совпадают, сертификат принадлежит ей. Это звучит просто, однако ж не работает.
Это отдельная проблема. Во-первых, никто не может выступать в роли Бога. Или, более точно, не существует организации или объекта, с которым может договориться каждый и чье правосудие не подлежит сомнению. Во-вторых, Алиса может не иметь уникального имени, относительно которого все согласились.
Разберемся со всем по порядку. Сначала первая проблема. Вспомним, чтобы система в целом работала, Алиса должна получить свой сертификат от кого-либо, кому и она, и Боб доверяют. В действительности существует иерархия доверенных лиц, определяющая ценность выданного сертификата. Военная организация, возможно, лучший пример такого рода системы. Командир взвода подписывает сертификат каждому бойцу в своем взводе. Командир дивизии заверяет сертификаты каждому командиру взвода в его подчинении. Генерал армии подписывает сертификаты своим дивизионным командирам. И так далее, до главнокомандующего.
Теперь у Алисы есть целая цепь сертификатов: от главнокомандующего – к генералам армий, от них – к дивизионным командирам, от них – к командирам взводов, и наконец, от командира ее взвода – к ней самой. Она хранит их все и представляет их Бобу. Если она и Боб числятся в одном взводе, у Боба также есть сертификат, выданный командиром взвода. Он знает, как должен выглядеть действительный сертификат, так что может непосредственно проверить и подтвердить ценность Алисиного сертификата. Если они в одной дивизии, но в разных взводах, они оба обладают одинаковыми сертификатами от дивизионного командира. Боб может использовать для подтверждения сертификат Алисиного командира взвода и затем сертификат Алисы. Поскольку Алиса и Боб числятся в одних войсках, каждый из них включен в свою цепь командования. Возможно, потребуется даже сертификат от главнокомандующего, который в данном случае и есть Бог.
Эта система замечательно работает у военных, но гораздо хуже в гражданском обществе. В Интернете сертификаты используются для поддержки множества протоколов: IPsec (Internet Protocol security, интернет-протокол безопасности) и различные системы VPN (Virtual Private Network, виртуальная частная сеть), SSL (Security Socket Layer, протокол безопасности сокета), несколько протоколов электронной коммерции, некоторые протоколы проверки входа в систему. Соответствующие сертификаты выдаются пользователям некоторой инстанцией, называемой бюро сертификации (certificateauthority, СА). СА может быть корпоративной организацией. Правительство также способно выступать в этом качестве. Оно может быть частной компанией, которая сделала своим бизнесом изготовление сертификатов для пользователей Интернета.
Центры сертификации также нуждаются в сертификатах. (Вспомним об иерархии.) Сертификаты выдаются СА другими сертифицирующими органами (возможно, VerySign). В конечном счете мы получаем Бога в этой системе, точнее, целый пантеон Богов. Сертифицирующие органы на самом верхнем уровне имеют корневые сертификаты: они не подписаны кем-либо еще. Такие сертификаты включены в программное обеспечение, которое вы покупаете: ваш браузер, обеспечение частной виртуальной сети и т. д. Это все называется инфраструктурой открытых ключей (public-key infrastructure, PKI). Она работает, но только частично.
Вторая проблема: имя Алисы.
В стародавние времена (примерно в середине 80-х) каждый мечтал о мире, в котором каждая персона, каждый процесс, каждый компьютер, каждый механизм связи – все, что связано с цифровыми коммуникациями, – имели бы уникальное имя. Эти имена хранились бы в широко распространенной базе данных, доступной множеству людей в различных регионах. Этот проект был назван Х.500.
Вообще говоря, сертификаты связывают открытый ключ с уникальным именем (называемым отличительным именем в терминологии Х.500), но, возможно, стоит обсудить, насколько полезна такая связь. Представьте себе, что вы получили сертификат, принадлежащий Джоан Робинсон. Вы, возможно, знаете лично только одну Джоан Робинсон, но сколько людей с таким именем известны центру сертификации? Как вы удостоверитесь, что конкретный сертификат Джоан Робинсон, полученный вами, принадлежит вашей подруге? Вы можете получить ее открытый ключ лично от нее, или она лично подтвердит передачу, но более вероятно, что вы примете сертификат по электронной почте и должны просто поверить, что это «правильная» Джоан Робинсон. Обобщенное имя на сертификате, вероятно, будет дополнено некоторой другой информацией, благодаря которой станет уникальным среди имен, получивших сертификат от одного СА.
Вы знаете эту дополнительную информацию о своей подруге? Знаете ли вы, какой СА выдал ей сертификат?
Вспомним аналогию с телефонным справочником. Если вы захотели найти открытый ключ Джоан Робинсон, вы просмотрели каталог, разыскали ее открытый ключ и послали сообщение, предназначенное только для ее глаз, используя этот открытый ключ. Это могло работать в случае с телефонным каталогом Стэнфордского отделения информационного обеспечения в 1976 году, но сколько Джоан Робинсон присутствуют в телефонном справочнике Нью-Йорка, и насколько это число меньше предполагаемого числа Джоан Робинсон в гипотетическом телефонном справочнике Интернета?
Мы вырастаем в маленьких семьях, где имена служат идентификаторами. К тому времени как нам исполняется пять лет от роду, мы усваиваем этот урок. Имена работают. Это неверно для большого мира, но вещи, впитанные в младенческом возрасте, мы не забываем никогда. В данном случае мы должны внимательно продумать все относительно имен, а не полагаться слепо на опыт пятилетнего ребенка, отложившийся в нашем сознании.
Идея также предполагает, что Алиса и Боб находятся в каких-то взаимоотношениях в физическом мире и хотят перенести эти отношения в киберпространство. Помните времена, когда «киберпространство» было термином из научной фантастики, а все взаимоотношения, о которых мы говорили, – деловые, социальные, банковские, коммерческие – формировались исключительно в мире из плоти и крови? Теперь люди встречаются в Сети и формируют там свои взаимоотношения все время. Иногда им удается свидеться лично через много лет после того, как они уже стали друзьями; в некоторых случаях они так и не входят в личный контакт. В этом прекрасном новом мире система, сконструированная только для того, чтобы проецировать взаимоотношения реального мира в киберпространство, выглядит ограниченной.
Инфраструктуры открытых ключей и центры сертификации несут в себе массу других проблем. Например, что может значить, когда бюро сертификации объявляет кого-либо заслуживающим доверия? Согласно литературе по криптографии, это означает лишь, что этот некто правильно обращается со своим собственным закрытым ключом. Это не говорит, что вы можете всегда доверять сертификату, полученному от СА для какой-то определенной цели: оплатить небольшую сумму или подписать заказ на миллион долларов.
Кто дает СА полномочия проводить подобные авторизации? Кто делает их доверенными лицами? Многие сертифицирующие органы обходят вопрос о том, что им никто не давал власти проводить авторизацию путем выпуска идентификационных сертификатов. Каждый может назначать имена. Мы делаем это все время. Инстанция, подтверждающая сертификаты, идет на риск, если она использует идентификационные сертификаты таким образом, что они подразумевают некий вид авторизации. В основном сертификаты только защищают вас от тех, с кем продавцы PKI не захотели даже иметь дела.
И слово «полномочия» («authority») имеет несколько значений. СА могут обладать авторитетом для выпуска сертификатов, но обладают ли они властью в отношении их содержимого? Например, сертификат сервера SSL содержит два массива данных, представляющих потенциальный интерес для целей безопасности: имя держателя ключа (keyholder) (обычно имя корпорации) и имя сервера в системе DNS (Domain Name System, система доменных имен). Существуют органы, обладающие властью назначать имя в системе DNS, но ни один из сертифицирующих органов SSL, представленных в списках, которые можно видеть в популярных браузерах, таковым не является. Это означает, что имя DNS в сертификате не является авторитетно установленным. Есть органы, назначающие корпоративные имена. Такое имя должно регистрироваться, когда некто хочет получить лицензию на какой-либо бизнес. Однако ни один из СА SSL, опубликованных в популярных браузерах, не обладает полномочиями делать это. В добавление ко всему, если сервер получает сертификат SSL-сервера, он имеет разрешение работать по протоколу SSL. Кто дал полномочия сертификационному органу SSL контролировать подобные разрешения? И является ли контроль за этими разрешениями необходимым? Какой вред будет причинен, если несертифицированный сервер будет использовать кодирование? Никакого.
Некоторые центры сертификации, учитывая тот факт, что они не властны Над содержимым сертификата, выделили структуру, называемую бюро регистрации (Registration Authority, RA), которая должна отвечать за содержание. Идея состоит в том, что RA ответственен за проверку информации, находящейся в сертификатах, а СА отвечает за их выдачу.
Модель RA+CA, безусловно, менее безопасна, чем система, при которой СА находится в составе полномочного органа (то есть RA). Модель RA+CA позволяет некоторому объекту (СА), который не является полномочным относительно содержания, подделать сертификат с соответствующим содержанием. Конечно, сертифицирующий орган подписывает контракт, в котором обещает так не делать, но это не исключает подобную возможность. Между тем, поскольку безопасность всей модели зависит от безопасности обеих ее частей и взаимодействия между ними (они должны каким-либо способом взаимод