Мы должны быть в состоянии защитить базы данных открытых ключей, но пригодна ли сама идея обеспечить свободный и широкий доступ к открытым ключам? Надо признать, что это не работает.
Сертификаты являются решением обозначенной проблемы. Сертификат представляет собой связь между открытым ключом и подтверждением подлинности. Пользующийся всеобщим доверием объект – назовем его Богом – берет имя Алисы и ее открытый ключ, связывает их и затем подписывает все это. Теперь Боб может не беспокоиться. Он получил Алисин сертификат открытого ключа – его не очень заботит, откуда – и проверил подпись Бога на нем. Боб доверяет Богу, так что, если он удостоверился в подлинности подписи, он знает, что открытый ключ принадлежит Алисе, а не какому-то обманщику. Проблема решена; мир теперь безопасен для электронной коммерции.
Однако не совсем. Заметим, что в действительности мы не решили проблему. Все, что мы сделали, возвращает нас к первоначальному вопросу: «Как Боб узнает, что открытый ключ Алисы действительно принадлежит ей?» Или изменим формулировку: «Как Боб узнает, что открытый ключ Бога действительно его ключ?». Боб проверил подлинность подписи Бога на сертификате, прежде чем начал использовать Алисин ключ, так что ему необходим был открытый ключ Бога. И где он его мог получить?
Но мы все же решили кое-что. Вероятно, Боб хочет взаимодействовать со множеством людей, не только с Алисой. И если Бог подписал каждый сертификат, мы свели проблему Боба к меньшей проблеме: теперь вместо подтверждения открытого ключа каждого нужно подтвердить лишь один ключ – Божий. Но эту проблему мы обсудим позже.
Настоящий сертификат представляет собой нечто немного более сложное. Он содержит информацию о персоне (имя, возможно, место работы, возможно, электронный адрес и другие сведения), информацию о сертификате (кем он выпущен, каков его срок годности), информацию об изготовителе сертификата или о том, кто его подписал (кто он, какой алгоритм он использовал для подписания сертификата и информацию относительно открытого ключа (какой алгоритм))… и собственно открытый ключ.
Основная идея состоит в том, что Алиса некоторым образом получает подписанный Богом сертификат открытого ключа. Либо она создает пару открытый ключ/закрытый ключ и отправляет открытый ключ Богу, который возвращает ей сертификат открытого ключа, либо Бог сотворит пару открытый ключ/закрытый ключ для Алисы и пошлет ей закрытый ключ и сертификат открытого ключа. (Здесь мы сталкиваемся с проблемой безопасности этого обмена, но пока что не берем ее в голову.)
Это все работает великолепно до тех пор, пока Алиса не потеряет свой закрытый ключ. Может быть, кто-то украдет его. Может быть, она забудет его. (Или, что более правдоподобно, ее компьютер «полетит» и не останется резервной копии.) Боб собирается попытаться послать ей сообщение, зашифрованное этим потерянным ключом. Или, хуже того, Боб попытается проверить подлинность подписей, созданных после того, как некто украл ключ. Что мы будем делать тогда?
Мы обратимся к Богу, и он аннулирует Алисин сертификат. Он объявит старый сертификат недействительным, неправильным и непригодным. Как он это сделает? Бог не может обшарить каждый уголок в Сети и уничтожить каждую копию сертификата. (Конечно, может быть, Господь Бог и всемогущ, но это только аналогия.) Возможно, он даже не знает, что у Боба есть такая копия.
Так что Бог включает Алисин сертификат в список аннулированных сертификатов, или 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), но, возможно, стоит обсудить, насколько полезна такая связь. Представьте себе, что вы получили сертификат, принадлежащий Джоан Робинсон. Вы, возможно, знаете лично только одну Джоан Робинсон, но сколько людей с таким именем известны центру сертификации? Как вы удостоверитесь, что конкретный сертификат Джоан Робинсон, полученный вами, принадлежит вашей подруге? Вы можете получить ее открытый ключ лично от нее, или она лично подтвердит передачу, но более вероятно, что вы примете сертификат по электронной почте и должны просто поверить, что это «правильная» Джоан Робинсон. Обобщенное имя на сертификате, вероятно, будет дополнено некоторой другой информацией, благодаря которой станет уникальным среди имен, получивших сертификат от одного СА.