Секреты и ложь. Безопасность данных в цифровом мире

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

Однако не совсем. Заметим, что в действительности мы не решили проблему. Все, что мы сделали, возвращает нас к первоначальному вопросу: «Как Боб узнает, что открытый ключ Алисы действительно принадлежит ей?» Или изменим формулировку: «Как Боб узнает, что открытый ключ Бога действительно его ключ?». Боб проверил подлинность подписи Бога на сертификате, прежде чем начал использовать Алисин ключ, так что ему необходим был открытый ключ Бога. И где он его мог получить?

Но мы все же решили кое-что. Вероятно, Боб хочет взаимодействовать со множеством людей, не только с Алисой. И если Бог подписал каждый сертификат, мы свели проблему Боба к меньшей проблеме: теперь вместо подтверждения открытого ключа каждого нужно подтвердить лишь один ключ – Божий. Но эту проблему мы обсудим позже.

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

Основная идея состоит в том, что Алиса некоторым образом получает подписанный Богом сертификат открытого ключа. Либо она создает пару открытый ключ/закрытый ключ и отправляет открытый ключ Богу, который возвращает ей сертификат открытого ключа, либо Бог сотворит пару открытый ключ/закрытый ключ для Алисы и пошлет ей закрытый ключ и сертификат открытого ключа. (Здесь мы сталкиваемся с проблемой безопасности этого обмена, но пока что не берем ее в голову.)

Это все работает великолепно до тех пор, пока Алиса не потеряет свой закрытый ключ. Может быть, кто-то украдет его. Может быть, она забудет его. (Или, что более правдоподобно, ее компьютер «полетит» и не останется резервной копии.) Боб собирается попытаться послать ей сообщение, зашифрованное этим потерянным ключом. Или, хуже того, Боб попытается проверить подлинность подписей, созданных после того, как некто украл ключ. Что мы будем делать тогда?

Мы обратимся к Богу, и он аннулирует Алисин сертификат. Он объявит старый сертификат недействительным, неправильным и непригодным. Как он это сделает? Бог не может обшарить каждый уголок в Сети и уничтожить каждую копию сертификата. (Конечно, может быть, Господь Бог и всемогущ, но это только аналогия.) Возможно, он даже не знает, что у Боба есть такая копия.

Так что Бог включает Алисин сертификат в список аннулированных сертификатов, или CRL (certificaterevocationlist). (Вспомним, как 20 лет назад торговцы публиковали списки номеров недействительных кредитных карт. Это CRL.) Бог выпускает CRL регулярно (компании кредитных карт делают это раз в неделю), и это уж дело Боба – удостовериться, что Алисин сертификат не находится в последнем списке, прежде чем он использует его. Он должен также убедиться, что сертификат не просрочен и что он в действительности принадлежит Алисе.

Каким образом Боб может осуществить последнее? Он сравнит имя Алисы с указанным на сертификате. Если они совпадают, сертификат принадлежит ей. Это звучит просто, однако ж не работает.

Это отдельная проблема. Во-первых, никто не может выступать в роли Бога. Или, более точно, не существует организации или объекта, с которым может договориться каждый и чье правосудие не подлежит сомнению. Во-вторых, Алиса может не иметь уникального имени, относительно которого все согласились.

Разберемся со всем по порядку. Сначала первая проблема. Вспомним, чтобы система в целом работала, Алиса должна получить свой сертификат от кого-либо, кому и она, и Боб доверяют. В действительности существует иерархия доверенных лиц, определяющая ценность выданного сертификата. Военная организация, возможно, лучший пример такого рода системы. Командир взвода подписывает сертификат каждому бойцу в своем взводе. Командир дивизии заверяет сертификаты каждому командиру взвода в его подчинении. Генерал армии подписывает сертификаты своим дивизионным командирам. И так далее, до главнокомандующего.