Сертификаты

Одна важная часть процесса цифровой подписи была выше объяснена так: предположим, что Alice передала Bob свой открытый ключ. Но это накладывает довольно сильное ограничение: Bob может проверять подписи только тех сторон, с которыми он уже заранее контактировал. Было бы лучше, если бы Bob мог получить открытый ключ Alice именно тогда, когда возникает необходимость проверить ее подпись, без предварительной подготовки.

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

Один выход из ситуации ”chicken-and egg” появляется, если открытый ключ Alice подписан кем-то, чьи подписи Bob может проверить, например некоторым удостоверяющим центром. Такая информация, подписанная цифровой подписью, называется сертификатом (certificate). Обратите внимание, что удостоверяющий центр только подтверждает открытый ключ Alice; он не обязан высказываться о сообщениях, которые отправляет Alice.

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

Все браузеры предоставляют информацию о сертификате. В нашем примере ее можно найти, как показано ниже.

Подписан отпечаток (fingerprint) информации в сертификате. Удостоверяющий центр, подписавший сертификат, — ”DigiCert SHA2 Extended Validation Server CA”.

Инфраструктура открытых ключей

Наше решение проблемы ”chicken-and-egg” не сняло все ограничения. Мы все еще предполагали, что

• Удостоверяющий центр A каким-то образом проверил личность Alice и, следовательно, подписал открытый ключ Alice;
• Bob каким-то образом получил открытый ключ того же удостоверяющего центра A.

Такая сторона A называется удостоверяющим центром (Certificate Authority, CA). Но Alice и Bob должны иметь возможность взаимодействовать с разными удостоверяющими центрами. Иначе CA легко становится узким местом системы.

Типичное решение этой проблемы — организовать иерархию удостоверяющих центров. Например, у Bob может быть открытый ключ корневого CA, например встроенный в его браузер. Затем этот корневой CA предоставляет сертификаты для других CA, которые находятся на один уровень ниже в иерархии. Эти CA могут предоставлять сертификаты для открытых ключей региональных CA, а Alice может взаимодействовать с одним таким региональным CA.

Bob должен проверить все сертификаты в цепочке сертификатов (certificate chain). После проверки всех сертификатов Bob наконец может проверить подпись Alice.

Все CA вместе с некоторыми другими сторонами, которые нужны, например, для управления отозванными сертификатами, образуют инфраструктуру открытых ключей (public-key infrastructure, PKI).

В нашем HTTPS-примере цепочка сертификатов имеет длину два. ”DigiCert SHA2 Extended Validation Server CA” выдала сертификат для сайта F-Secure, а ”DigiCert High Assurance EV Root CA” выдала сертификат для ”DigiCert SHA2 Extended Validation Server CA”. Открытый ключ корневого CA должен быть встроен в браузер для успешной аутентификации сайта.

Фактическое значение подписи сертификата показано ниже.

Не забудьте проверить свои баллы в индикаторе в правом нижнем углу материала!