Цифровая подпись
С точки зрения задачи цифровой подписи — аутентификации сообщения — гораздо привлекательнее выглядят асимметричные схемы: в таких схемах любой может проверить аутентичность сообщения.
В частности, цифровая подпись по асимметричной схеме используется для:
- установления зашифрованного соединения с HTTP-сервером (подтверждая, что ответивший на запрос сервер действительно соответствует доменному имени, введённому пользователем в адресную строку браузера)
- электронных писем (подтверждая, что отправитель — это именно тот, чей адрес указан в качестве обратного)
Зашифрованное соединение обычно использует симметричную схему шифрования. А асимметричная схема используется для передачи ключа симметричной схемы. Подписывается при этом публичный ключ этой асимметричной схемы.
Подробнее:
- владелец сервера, привязанного к доменному имени
foo.bar, хочет получить возможность устанавливать зашифрованные соединения с клиентами - он генерирует пару ключей (публичный и приватный), которые затем будет использовать для получения от клиентов ключа симметричной схемы
- также он обращается к сертифицирующей организации с запросом на получение сертификата
- сертифицирующая организация проверяет, что доменное имя действительно соответствует тому серверу, с которого происходит запрос, после чего выдаёт сертификат — публичный ключ владельца сервера вместе с некоторой вспомогательной информацией (в том числе — о самой организации)
- сертификат подписывается приватным ключом сертифицирующей организации
Теперь каждый, кто доверяет сертифицирующей организации, доверяет и владельцу сертификата.
Цепочки сертификатов
В реальности тех организаций, которым доверяют, например, ОС и браузеры, не так много: несколько сотен.
Сертифицирующих организаций гораздо больше. Для обеспечения возможности их работы используется очень простая схема: конечный пользователь (владелец сервера) предоставляет клиенту не один (свой) сертификат, а цепочку сертификатов: сертификаты всех промежуточных организаций между ним и «корневой».
В общих чертах цепочка выглядит так (опуская дополнительную информацию):
- «конечный сертификат»: имя сервера, ключ сервера (К0), имя издателя (И1), подпись (ключом К1), метка о конечности сертификата (чтобы не было возможности продолжить цепочку)
- следующий сертификат: имя субъекта (И1), ключ субъекта (К1), имя издателя (И2), подпись (ключом К2)
- следующий сертификат: имя субъекта (И2), ключ субъекта (К2), имя издателя (И3), подпись (ключом К3)
и так далее до
- «корневой сертификат»: имя субъекта (Иn), ключ субъекта (Кn), имя издателя (Иn), подпись (ключом Kn)