Защита секретов с помощью PKI и сертификатов

В статье «Сейф для секретов», опубликованной в Windows IT Pro/RE № 7 за 2005 год, было рассказано о принципах использования общего ключа и шифрования с открытым/секретным ключом. В ней отмечалось, что метод с общим ключом удобен при шифровании больших массивов данных, а шифрование с открытым/секретным ключом больше подходит для обмена информацией между сторонами, но достоинства обоих методов можно соединить. В статье также были рассмотрены способы объединения алгоритмов с открытым/секретным ключом и хеширования, что позволяет получить цифровые сигнатуры, удостоверяющие как личность отправителя сообщения, так и неизменность данных с момента их подписания. Шифрование с открытым/секретным ключом — гибкий и эффективный способ удостоверить личность и обмениваться секретной информацией между сторонами, которые не знают друг друга. Однако у этого метода есть серьезный недостаток: пользователи должны каким-то образом обменяться открытыми ключами и точно знать, что данный открытый ключ действительно принадлежит законному корреспонденту, а не мошеннику. Чтобы гарантировать личность корреспондента, необходима инфраструктура для обмена открытыми ключами. И такая технология существует. Она называется PKI (public key infrastructure, «инфраструктура открытых ключей»).

Источники сертификатов

В PKI используются сертификаты, генерируемые серверами, называемыми центрами сертификации, Certification Authority (CA). Они удостоверяют личность пользователя и его открытый ключ. С помощью PKI две стороны, незнакомые друг с другом, могут проверить личность друг друга и безопасно обмениваться информацией, доверяя CA. CA располагает собственной парой открытого и частного ключей: это краеугольный камень безопасности PKI.

Экран 1. Образец сертификата от VeriSign

Рассмотрим пример. Чтобы Боб мог использовать PKI, он должен получить из CA сертификат, аналогичный показанному на экране 1. Компьютер Боба генерирует пару из открытого и частного ключей, а затем устанавливает соединение с CA. Процесс авторизации описан во врезке «Аутентификация запроса нового сертификата». Например, он выдает идентификационную информацию, в частности об имени, адресе электронной почты, компании и подразделении. Боб передает открытый ключ в CA, но никогда не раскрывает свой секретный ключ, если только CA не предоставляет услуги доверительного хранения/резервного копирования. В результате даже CA не может похитить информацию, защищенную секретным паролем Боба. Затем CA вставляет идентифицирующую информацию и открытый ключ Боба в сертификат, обычно в соответствии со стандартом Public-Key Cryptography Standards (PKCS), созданным лабораторией RSA Laboratories. Более подробную информацию можно найти по адресу http://www.rsasecurity.com/rsalabs/node.asp?id=2124. И наконец, CA дополняет сертификат цифровой сигнатурой, хешируя сертификат, а затем шифрует хеш с использованием собственного частного ключа. В полях сертификата Thumbprint и Thumbprint algorithm (экран 2) можно увидеть зашифрованный хеш сертификата и использованный CA алгоритм хеширования (sha1). Боб может сообщить полученный сертификат другим лицам или опубликовать в таких службах каталога, как Active Directory (AD).

Экран 2. Образец хеша зашифрованного сообщения сертификата

PKI в действии

Теперь рассмотрим, каким образом Боб может использовать свой сертификат при работе с таким широко распространенным приложением, как электронная почта. Предположим, Боб хочет послать Алисе сообщение по электронной почте и убедить Алису в том, что сообщение отправлено Бобом и не было изменено при пересылке. Алиса — доверенное лицо Боба, а посылаемое сообщение представляет собой заказ на покупку акций. Secure MIME (S/MIME) — общепризнанный протокол безопасности для электронной почты, поэтому как Боб, так и Алиса должны располагать S/MIME-совместимым почтовым клиентом, таким как Microsoft Outlook. При желании Боб может подписать сообщение с применением частного ключа, соответствующего его сертификату. Эта сигнатура представляет собой хеш сообщения, зашифрованного секретным ключом Боба. Почтовый клиент Боба посылает сообщение, сигнатуру и сертификат Алисе. Почтовый клиент Алисы обнаруживает, что сообщение представлено в формате S/MIME, и приступает к проверке сигнатуры. С помощью того же алгоритма, который был использован генерирующим CA, ее клиент вычисляет собственный хеш сообщения, расшифровывает хеш открытым ключом в сертификате Боба, а затем сравнивает два хеша. Если они совпадают, то клиенту Алисы становится известно, что сообщение подписано секретным ключом, соответствующим открытому ключу сертификата.

Каким же образом Алиса и ее почтовый клиент убеждаются, что открытый ключ действительно принадлежит Бобу? Ведь открытый ключ в сертификате мог быть подменен злоумышленником в процессе передачи или сообщение вместе с сертификатом могли быть фальшивыми. Прежде чем доверять сообщению, подписанному сертификатом, почтовый клиент Алисы должен проверить сертификат. Ранее отмечалось, что для работы PKI все пользователи системы должны доверять CA. Чтобы установить доверие, CA уже передал Алисе свой открытый ключ. Например, Windows 2000 и более поздние операционные системы располагают сертификатами с подписями всех крупных CA в Internet и автоматически получают сертификаты корпоративных центров сертификации CA, которые пользователи организуют в своей среде AD. С помощью Group Policy можно указать дополнительные доверенные CA или удалить стандартные CA. Поэтому почтовый клиент Алисы может проверить сертификат Боба. Ее клиент вычисляет собственный хеш сертификата Боба и использует открытый ключ CA для дешифрации хеша цифровой сигнатуры сертификата. Если хеши совпадают, то клиенту известно, что CA подписал сертификат своим секретным ключом. На основе этих данных почтовый клиент Алисы убеждается, что информация в сертификате — имя, почтовый адрес и открытый ключ — действительно принадлежит Бобу, так как CA аутентифицировал Боба, прежде чем удовлетворить его запрос сертификата. Таким образом, Алиса уверена в подлинности заказа на покупку акций.

Конечно, Алиса может быть уверена в подлинности сообщения только в той степени, в которой она доверяет CA. Если CA не защитит секретный ключ или неверно аутентифицирует того, кто запрашивает сертификат, система безопасности PKI развалится. Независимые центры сертификации CA, такие как компании VeriSign, генерируют сертификаты различных уровней в соответствии со степенью строгости проверки запросов сертификатов. Интересный документ об этих процедурах опубликован по адресу https://www.VeriSign.com/repository/rpa.html.

Безопасность частного ключа зависит от секретности частного ключа, соответствующего сертификату. Если секретный ключ Боба украден, то вор сможет действовать от его лица. В одной из следующих статей будет рассмотрено применение списка отозванных сертификатов CRL (certificate revocation list) и стандартов PKI в данной ситуации и других случаях, возникающих при работе с сертификатами и секретными ключами.

Рэнди Франклин Смит - Редактор Windows IT Pro, консультант по информационной безопасности и главный управляющий компании Monterey Technology Group. Преподает на курсах Ultimate Windows Security course series и имеет сертификаты SSCP, CISA и Security MVP. rsmith@ultimatewindowssecurity.com

Аутентификация запроса нового сертификата

Процедура аутентификации запроса в разных CA различна. В некоторых CA администратор должен просмотреть и одобрить запрос, для чего может потребоваться проверка подлинности пользователя в его присутствии. Компания VeriSign, известный центр сертификации CA в Internet, использует электронную почту для аутентификации сертификатов уровня Class 1 (нижний уровень безопасности); запрашивающий должен успешно получить сообщение электронной почты от VeriSign, зарегистрироваться на Web-узле компании и ввести код, указанный в сообщении. Windows PKI использует учетную запись AD для автоматической интегрированной аутентификации сертификатов, запрашиваемых из Windows Enterprise CA. Windows CA могут работать в двух режимах: Enterprise (корпоративный) или Standalone (автономный). Помимо прочего, центры сертификатов уровня Enterprise интегрируются с AD для аутентификации, публикации сертификатов и ведения списка отозванных сертификатов (CRL), а также других задач управления сертификатами.