Глава 21
Практические аспекты PKI
Если вам нужна инфраструктура открытого ключа, ее можно купить или
разработать самому. В первом случае вам, вероятно, не понадобилась бы на-
ша помощь.
Практическая криптография
— это книга по инженерии, а не
справочник покупателя. Поэтому мы полагаем, что вы решили развернуть
собственную инфраструктуру. В этой главе приводится несколько практиче-
ских соображений, которые могут пригодиться при разработке инфраструк-
туры открытого ключа.
21.1
Формат сертификата
Что бы вы ни делали, держитесь подальше от сертификатов X.509. Поче-
му? Ответ на этот вопрос вы найдете в [39]. Определить формат сертификата
самому и то легче. В действительности сертификат — это всего лишь тип дан-
ных с обязательными и необязательными полями. Поскольку эта проблема из
области программной инженерии, вдаваться в ее детали мы не будем. Однако
обратите внимание: кодирование конкретной структуры данных должно быть
уникальным, поскольку в криптографии структура данных часто подверга-
ется хэшированию, чтобы подписать ее или сравнить с другой структурой
данных. Работая с форматом наподобие XML, допускающим несколько пред-
ставлений одной и той же структуры данных, необходимо тщательно следить
за тем, чтобы цифровые подписи и хэш-коды всегда функционировали так,
как положено.
21.1.1
Язык разрешений
В любой инфраструктуре открытого ключа (кроме, пожалуй, самых про-
стых) вам придется ограничить полномочия сертификатов, которые может
362
21.1. Формат сертификата
363
выдавать подчиненный центр сертификации. Для этого необходимое огра-
ничение нужно закодировать в сертификате подчиненного ЦС, что, в свою
очередь, требует наличия языка, с помощью которого можно было бы описы-
вать разрешения, предоставленные ключу. Это, вероятно, наиболее сложный
момент разработки инфраструктуры открытого ключа, и здесь мы ничем не
можем вам помочь. Ограничения, которые следует наложить на подчинен-
ный ЦС, зависят от специфики конкретного приложения. Если вы не мо-
жете придумать подходящих ограничений, пересмотрите свое решение на-
счет использования PKI. При отсутствии ограничений в сертификате каж-
дый подчиненный ЦС, по сути, получает в свое распоряжение главный ключ
с неограниченными полномочиями, а это очень плохо для безопасности си-
стемы. Разумеется, вы можете ограничиться использованием единственного
ЦС, но это лишит вас многих преимуществ инфраструктуры открытого клю-
ча перед сервером ключей.
21.1.2
Ключ корневого ЦС
Чтобы центр сертификации мог выполнять какие-либо действия, ему нуж-
на пара “открытый ключ-закрытый ключ”. Генерация пары ключей — зада-
ние довольно простое. Открытый ключ ЦС вместе с некоторыми дополни-
тельными данными (например, сроком действия) должен быть распростра-
нен между всеми участниками общения. Для упрощения системы это обычно
выполняется с помощью сертификата, подписанного самим ЦС. Вообще-то
это довольно странная конструкция: ЦС подписывает сертификат своего же
открытого ключа. Хотя данный процесс иногда называют
самосертификаци-
ей (self-certification)
, на деле он не имеет с ней ничего общего. Это название —
всего лишь историческая ошибка, которой мы почему-то придерживаемся до
сих пор. Данный сертификат вообще не сертифицирует ключ и никоим обра-
зом не доказывает его безопасность. Каждый может создать открытый ключ
и лично сертифицировать его. Все, что делает подобный сертификат, — это
привязывает к ключу дополнительные данные. Сюда относятся список раз-
решений, срок действия, контактные данные соответствующего сотрудника
и т.п. Сертификат, подписанный самим ЦС, использует тот же формат дан-
ных, что и другие сертификаты системы. Все остальные участники могут
воспользоваться существующим кодом, чтобы проверить эти дополнитель-
ные данные. Сертификат, подписанный корневым ЦС, называется
корневым
сертификатом (root certificate)
инфраструктуры открытого ключа.
Следующий шаг — безопасным образом распространить корневой серти-
фикат между всеми участниками системы. Каждый должен знать ключ кор-
невого ЦС, и каждый должен иметь правильный корневой сертификат.
364
Достарыңызбен бөлісу: |