4.4Сертификация

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

Это делается так: открытый ключ и информация о том, кому он принадлежит, подписываются стороной, которой доверяет получатель. Результат такой подписи, т.е. сертификат, получатель может всегда проверить. Для этого он расшифровывает открытым ключом центра сертификации присланный сертификат и сравнивает вычисленный таким образом открытый ключ отправителя, информацию об отправителе с теми данными, которые передал отправитель.

А кто подтвердит подлинность сертификата, то есть открытого ключа центра сертификации? Доверять подписывающей стороне получатель может на основании того, что ее ключ был подписан третьей стороной. То есть у центра сертификации должен быть сертификат. Таким образом возникает иерархия доверия. Очевидно, что некоторый ключ должен быть корнем иерархии (то есть ему мы доверяем не потому, что он кем-то подписан, а потому, что мы верим a-priori, что ему можно доверять). В централизованной инфраструктуре ключей имеется очень небольшое количество корневых ключей сети (например, облеченные полномочиями государственные агенства; их также называют сертификационными агенствами - certification authorities). В распределенной инфраструктуре нет необходимости иметь универсальные для всех корневые ключи, и каждая из сторон может доверять своему набору корневых ключей (скажем, своему собственному ключу и ключам, ею подписанным). Эта концепция носит название сети доверия (web of trust) и реализована, например, в PGP (система шифрования, используемая для почтовых сообщений).

Полный вариант цифровой подписи документа выглядит так: из документа генерируется так называемый дайджест (message digest) (обычно для этого используется хэш) и к нему добавляется информация о том, кто подписывает документ, штамп времени и прочее. Получившаяся строка далее зашифровывается секретным ключом подписывающего с использованием того или иного алгоритма. Получившийся зашифрованный набор битов и представляет собой подпись. К подписи обычно прикладывается открытый ключ подписывающего лица и сертификат, удостоверяющий подлинность открытого ключа.

Получатель сначала решает для себя доверяет ли он тому факту, что открытый ключ принадлежит именно тому, кому должен принадлежать (с помощью сети доверия или априорного знания), т.е. использует сертификат. А затем дешифрует подпись с помощью открытого ключа. Если подпись нормально дешифровалась, и ее содержимое соответствует документу (дайджест и др.), то сообщение считается подтвержденным.

Опишем схему сертификации. Пусть Ц – центр сертификации, которому доверяют А и Б. Ц распространяет свой открытый ключ (при помощи защищенного канала или не электронным путем).

А желает получить сертификат. Для этого он отправляет информацию о себе в Ц. Ц часто не просто подтверждает ключи, а генерирует их, то есть формирует пару «открытый – закрытый ключ» для А, проверяет надежность А. Отправляет А сформированную пару, а также открытый сертификат – открытый ключ А и данные об А, зашифрованные закрытым ключом Ц.

Заметим, что в данной схеме мы не рассматриваем вопрос о том, каким образом передаются данные от А к Ц и наоборот. Очевидно, что они не могут передаваться в открытом виде. Но мы уже знаем, по крайней мере, один алгоритм выработки секретного ключа - алгоритм Диффи-Хэлмана, при помощи которого А и Ц могут договориться о секретном ключе и в дальнейшем шифровать свою переписку, пользуясь любым симметричным алгоритмом.

Возможный вариант предложенной схемы: А сам формирует пару «открытый – закрытый ключ» и отправляет Ц данные о себе и свой открытый ключ.

Далее А при отправке сообщения Б добавляет к сообщению помимо всего прочего сертификат. Теперь Б может, расшифровав сертификат, сравнить подтвержденную Ц информацию с той, которую сообщает А, и убедиться в подлинности А.