101 прием работы с OpenSSL

Anton Karpov

Хакер, номер #074, стр. 074-100-3

- Получать и хранить все (N-1) ключей, персонально запрашивая каждый у его владельца - весьма затруднительно. Да еще если учесть, что люди могут терять/раскрывать свои ключи и генерировать новые. Как я узнаю, что один из моих респондентов сгенерировал новый ключ, и старый уже не действителен?

- Как удостовериться, что публичный ключ собеседника принадлежит ему? Что его web-страничка с ключом не была взломана, а ключ - заменен?

Для решения этих проблем было решено ввести новый доверенный орган, который назвали Ceritifcate Authority, CA (русский официальный перевод - "удостоверяющий центр"), и теперь все участники, сгенерировав себе пару ключей (public-private), не ломают голову, а отправляют свой публичный ключ этому CA. Причем не в "голом виде", а оформив его в запрос на сертификат - по сути, тот же ключ, с прописанными персонализирующими владельца ключа полями (имя, фамилия, город, адрес).

X509 - это стандарт на сертификаты. CA получает запрос и выдает автору ключа уже полноценный сертификат, одновременно удостоверяя авторство ключа, подписывая его своим private key и размещая сертификат клиента для публичного доступа. Таким образом, сертификат - тот же public key, только оформленный в специальном виде. Наконец, если кто-то теряет или раскрывает свой закрытый ключ, он создает CA запрос на отзыв сертификата (ceritificate revokation). CA помечает сертификат как отозванный, помещая информацию о нем в специальный список, CRL (ceritificate revokation list). Теперь, чтобы проверить, действителен ли ключ, нужно всего лишь скачать с сайта CA свежий CRL и проверить наличие в нем сертификата респондента.

Эта красивая схема содержит одно слабое звено - все участники обязаны безоговорочно доверять CA, ведь к нему они обращаются за ключами других людей, за CRL, да и сам CA непосредственно отвечает за то, что конкретный человек имеет данный ключ. Вот почему во всех странах функционирование официальных CA подведено под мощную юридическую базу, выпущены соответствующие законы. В России существует закон "Об Электронной Цифровой Подписи", согласно которому юридическую силу имеют те CA, которые используют отечественные криптоалгоритмы (ГОСТ) для подписи и шифрования. "Имеют юридическую силу" - значит, подпись клиентом такого CA электронного документа (файла) на уровне закона приравнена к личной ручной подписи на бумаге. Впрочем, нам сгодится и RSA, мы же не ведем переписку государственной важности ;).

Для разворачивания полноценных CA существуют удобные фронтэнды, например, TinyCA. Нас, как всегда, интересует консольная подноготная всего процесса. Поэтому сейчас мы запустим свой маленький CA и выдадим на нем сертификат нашему веб-серверу. Генерируем rsa-ключ для CA:

# openssl genrsa -des3 -out myca.key 2048