В данной статье мы рассмотрим, что такое Инфраструктура открытых ключей (PKI), как она устроена на логическом уровне, для чего используется, а также попытаемся выявить её плюсы и минусы. Никакой математики - только логика работы. При подготовке материала использовались лекции Антона Карпова о PKI, которые можно найти на YouTube.
ПИК Безопасности имеет богатый опыт практического внедрения, применения и сопровождения технологий, описанных в данной статье. Продукты таких вендоров, как InfoTeCS, Код безопасности, Крипто-Про представляют собой комплексные, легко масштабируемые решения, позволяющие шифровать информацию при передаче по открытым каналам связи, разворачивать инфраструктуру PKI и систему обнаружения вторжений (IDS). Полную информацию вы всегда сможете получить у наших специалистов.
Часть 1. Криптография.
Для начала разберемся для каких целей в наши дни применяется криптография:
- Конфиденциальность – невозможность прочтения информации посторонним;
- Целостность данных – невозможность незаметного изменения информации;
- Аутентификация – проверка подлинности авторства или иных свойств объекта;
- Апеллируемость – невозможность отказа от авторства.
Интересно, что конфиденциальность сообщений интересовала людей еще в Древнем мире. Наверное, образно можно говорить о том, что шифрование появилось с того момента, когда люди научились писать. Некоторые из ранних упоминаний о шифровании сообщений датируются пятым веком до н.э. Если читателя интересует история шифрования, рекомендуем к прочтению книгу Саймона Сингха "Книга шифров. Тайная история шифров и их расшифровки". В данном труде автору удается изложить историю шифрования, начиная с древних времен и первого исторического произведения Геродота о греко-персидских войнах, до наших дней и появления квантовой криптографии – в достаточно увлекательной и захватывающей манере. В общем – категорически рекомендуем!
Ну а мы рассмотрим два принципиальных вида алгоритмов шифрования: симметричные алгоритмы шифрования и асимметричные алгоритмы шифрования.
В симметричных алгоритмах шифрования используется один и тот же ключ как для шифрования, так и для дешифрования сообщения. Таким образом, если в обмене сообщениями участвуют два субъекта, у обоих будет одинаковый ключ шифрования/дешифрования. Преимуществом данных алгоритмов шифрования является скорость работы и простота реализации. Основной же проблемой этого вида шифрования является общий ключ шифрования/дешифрования. Безопасная передача этого ключа является очень большой проблемой, ведь злоумышленник, перехватив ключ, сможет читать все сообщения. Поэтому в 70-х годах 20-го столетия появилась криптография с открытым ключом. Определяющими факторами для появления ассиметричного вида шифрования явились:
- Появление алгоритма Диффи-Хеллмана в 1976 году. Визуальный принцип его работы для "не-математиков" очень доступно изложен в данном видео.
- Появление алгоритма шифрования и электронной подписи RSA в 1977 году.
На алгоритмах RSA и Диффи-Хеллмана мы останавливаться не будем, а перейдем к сути криптографии с открытым ключом:
В ассиметричных алгоритмах шифрования для шифрования и дешифрования используются разные ключи, математически связанные между собой. Такие ключи называются ключевой парой. Один из них - закрытый (private key), другой является открытым (public key). Сообщение, которое было зашифровано на открытом ключе, может быть дешифровано только с помощью соответствующего закрытого ключа, и наоборот. Логика следующая:
- Субъект формирует ключевую пару - закрытый ключ он хранит в секрете, а копию открытого ключа он может передавать кому угодно.
- Субъект передает второй стороне свой открытый ключ.
- Вторая сторона шифрует сообщение на открытом ключе субъекта и отправляет по открытому каналу.
- Субъект расшифровывает сообщение своим закрытым ключом.
Стоит заметить, что в современных реализациях VPN (в качестве примера можно привести технологию ViPNet), используется комбинация симметричных и асимметричных алгоритмов шифрования. Например, сначала используются асимметричные алгоритмы для получения сессионного симметричного ключа шифрования (алгоритм Диффи-Хеллмана), а уже потом данные шифруются с помощью быстрого симметричного алгоритма с использованием ключа, который был выработан на первом шаге.
В нашем примере всего два субъекта и понятно, что в реальности, субъектов, обменивающихся информацией, будет гораздо больше. При этом открытый ключ не представляет из себя секрета, поэтому мы смело передаем его по открытым каналам. Таким образом, принципиальная проблема симметричных алгоритмов шифрования решена! Больше нет необходимости передавать секрет по открытым каналам связи. Но возникает другая – подтверждение подлинности открытого ключа. К примеру, субъект направляет нам свой открытый ключ и просит зашифровать на нем и отправить ему конфиденциальную информацию. При этом, мы не можем знать, действительно ли субъект является тем, за кого себя выдает, т.е. принадлежит ли открытый ключ нужному адресату. Возможно, что злоумышленник подменил открытый ключ и направил нам. Получив от нас сообщение, он сможет спокойно его расшифровать. Для решения этой проблемы и была придумана Инфраструктура открытых ключей (Public Key Infrastructure).
Перед тем, как мы перейдем к рассмотрению PKI, нужно немного сказать о технологии электронной подписи (ЭП). Существуют схемы ЭП, основанные на симметричных и асимметричных алгоритмах шифрования. Первый вариант мы рассматривать не станем ввиду малой распространенности. На асимметричных алгоритмах ЭП остановимся подробней.
В 1994 году Главным управлением безопасности связи ФАПСИ был разработан первый российский стандарт ЭЦП — ГОСТ Р 34.10-94 "Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма".
В 2002 году для обеспечения большей криптостойкости алгоритма взамен ГОСТ Р 34.10-94 был введён одноимённый стандарт ГОСТ Р 34.10-2001, основанный на вычислениях в группе точек эллиптической кривой. В соответствии с этим стандартом, термины "электронная цифровая подпись" и "цифровая подпись" являются синонимами.
1 января 2013 года ГОСТ Р 34.10-2001 заменён на ГОСТ Р 34.10-2012 "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи." Применение нового ГОСТ Р 34.10-2012 обязательно с января 2019 года – об этом мы уже писали. Если вы используете электронную подпись, нужно убедиться, что ваши средства ЭП поддерживают данный стандарт.
Асимметричные технологии электронной подписи отличаются от логики работы асимметричных алгоритмов шифрования. В отличие от асимметричных алгоритмов шифрования, где сообщение шифруется на открытом ключе получателя, а дешифрование происходит с помощью закрытого ключа, в алгоритмах электронной подписи сообщение подписывается с применением закрытого ключа, а при проверке подписи используется открытая часть. Логика следующая:
- Субъект формирует ключевую пару - закрытый ключ он хранит в секрете, а копию открытого ключа он может передавать кому угодно.
- Субъект передает второй стороне свой открытый ключ.
- Субъект вычисляет контрольную сумму сообщения с помощью применения хеш-функции.
- Сообщение, вместе с контрольной суммой шифруется на закрытом ключе субъекта. Результат этого преобразования - электронная подпись, вместе с сообщением отправляется Второй стороне.
- Вторая сторона получает сообщение и электронную подпись. С помощью открытого ключа субъекта вторая сторона расшифровывает электронную подпись, а также сама вычисляет контрольную сумму сообщения.
- Вторая сторона сравнивает контрольные суммы и, если они совпадают, происходит подтверждение целостности и авторства документа, так как зашифровать контрольную сумму мог только отправитель (открытый и закрытый ключи имеют однозначное соответствие).
Часть 2. PKI.
Парадигма PKI предполагает существование Корневого удостоверяющего центра (Certificate Authority), которому все участники взаимодействия безоговорочно доверяют. Создается иерархическая система доверия, т.е. Корневой УЦ может делегировать полномочия по подтверждению подлинности ключей пользователей другим УЦ. Система доверия выглядит как древовидная цепочка сертификатов УЦ, вплоть до конечного пользователя. Для подтверждения подлинности ключей пользователя, УЦ и выдает пользователям цифровые сертификаты.
Цифровой сертификат – это открытый ключ субъекта, подписанный закрытым ключом УЦ, содержащий в своем составе информацию о субъекте. Сертификаты создаются в соответствии со стандартом X.509, и могут использоваться для подписи, шифрования и аутентификации. Стандарт X.509 мы рассмотрим чуть дальше.
Таким образом, в состав компонентов PKI структуры входят:
- Корневой УЦ (Root CA)
- Подчиненные УЦ (Subordinate CA (IntermediateCA))
- Набор политик и регламентов
- Каталог выданных сертификатов
- Каталог отозванных сертификатов
Теперь процесс формирования ключей и обмена сообщениями, описанный ранее, в PKI выглядит следующим образом:
- Субъект формирует закрытый ключ
- Субъект формирует запрос на сертификат (CSR – Certificate Signing Request)
- Субъект отправляет запрос в УЦ
- УЦ удостоверяет личность владельца запроса и подписывает запрос своим закрытым ключом, выпуская сертификат
- Вторая сторона получает сертификат субъекта
- Вторая сторона проверяет действительность сертификата субъекта, используя цепочку вплоть до корневого сертификата УЦ, и шифрует сообщения на нем
Многие УЦ генерируют и выдают субъекту ключевую пару, т.е. открытый и закрытый ключ. Таким образом пользователь сам ничего не создает. При такой схеме возможна компрометация закрытого ключа при выдаче оператором УЦ. С другой стороны, ведь УЦ мы безоговорочно доверяем?
Еще раз остановимся на основном, фундаментальном для PKI требовании – должна быть сущность, которой все доверяют. Этой сущностью является Корневой УЦ. Если в ОС Windows открыть список доверенных корневых сертификатов (certmgr.msc -> Доверенные корневые центры сертификации), можно увидеть более 70 сертификатов УЦ, которым система доверяет по умолчанию.
Как правило, все УЦ, перечисленные в этом разделе, выдают сертификаты не пользователям, а подчиненным УЦ, которые в свою очередь работают с пользователями. Таким образом, можно приблизительно представить масштаб распространенности PKI и количество УЦ на сегодняшний день. Также нужно учитывать, что мы фактически безоговорочно доверяем создателю операционной системы, который поместил данные сертификаты в список доверенных. Конечно, для того, чтобы УЦ попал в список доверенных, он должен выполнять ряд требований, как технических, так и организационных.
Например, у Microsoft существует документ "Программа доверенных корневых сертификатов Майкрософт. Требования аудита для центров сертификации", где описаны общие требования для УЦ.
Кроме того существует программа сертификации WebTrust – это мировой стандарт, определяющий набор правил и критериев для УЦ. Критерии стандарта WebTrust были определены The American Institute of Certified Public Accountants (AICPA) и Canadian Institute of Chartered Accountants (CICA) в 1995 году. Любой крупный УЦ регулярно должен проходить аудит WebTrust.
Сертификаты PKI, выдаваемые согласно стандарту WebTrust, имеют статус проверенных и надёжных на мировом уровне, а также попадают в список доверенных в операционных системах (Windows, MAC OS X и др.) и веб-браузерах.
В Российской Федерации, согласно Федеральному закону от 06.04.2011 N 63-ФЗ "Об электронной подписи", аналогично с проведением международного аудита по требованиям безопасности, УЦ могут пройти процедуру аккредитации. Требования для аккредитованных УЦ устанавливает Федеральный закон и подзаконные правовые акты Минкомсвязи. Прохождение процедуры аккредитации дает право УЦ выпускать квалифицированные сертификаты электронной подписи. Такие сертификаты имеют юридическую значимость на территории РФ.
Говоря о PKI, мы по сути говорим о стандарте X.509. Стандарт X.509 предусматривает стандартную структуру сертификата (наборы полей), механизмы проверки действительности сертификата, а также стандартные механизмы получения и отзыва сертификатов:
Структура сертификата:
- Сертификат
- Версия
- Серийный номер
- Идентификатор алгоритма подписи
- Имя издателя
- Период действия:
- Не ранее
- Не позднее
- Имя субъекта
- Информация об открытом ключе субъекта:
- Алгоритм открытого ключа
- Открытый ключ субъекта
- Уникальный идентификатор издателя (обязательно только для v2 и v3)
- Уникальный идентификатор субъекта (обязательно только для v2 и v3)
- Дополнения (для v2 и v3)
- ...возможные дополнительные детали
- Алгоритм подписи сертификата (обязательно только для v3)
- Подпись сертификата (обязательно для всех версий)
Основные форматы файла сертификата:
Согласно RFC 2459:
- .CER — сертификат, или набор сертификатов, закодированных по стандарту CER.
- .DER — сертификат, закодированный по стандарту DER.
- .PEM — PEM-сертификат, закодированный по стандарту DER и использующий Base64 и помещенный между "----- BEGIN CERTIFICATE -----" и "----- END CERTIFICATE -----".
- .P7B, .P7C — PKCS #7 содержит несколько сертификатов или CRL.
Механизмы проверки действительности сертификата:
Любой сертификат в структуре PKI может быть скомпрометирован, поэтому стандарт X.509 предполагает механизмы их проверки. Проверка происходит с использованием "чёрных списков". Проверка происходит по серийному номеру сертификата. Существуют два основных формата:
- CRL (Certificate Revocation List) – Список отозванных сертификатов. Публикуется УЦ на регулярной основе в публичных источниках. Имеет время жизни, которое зависит от политик и регламента УЦ. В своем составе CRL содержит серийный номер сертификата, дату и причину отзыва. CRL может содержать один из статусов: отозван (revoked) или приостановлен (hold), хотя приостановление сертификатов на практике практически не используется. Важно понимать, что CRL является оффлайн инструментом и не позволяет проверять статус сертификата в реальном времени.
- OCSP (Online Certificate Status Protocol) – сетевой протокол, который позволяет проверить статус сертификата в реальном времени. Адрес OCSP-сервера указывается в специальном поле сертификата – CDP (CRL Distribution Point). Важно обеспечить постоянную доступность OCSP-сервера.
C 31 декабря 2017 года начинает действовать редакция Федерального закона N 63-ФЗ "Об электронной подписи", согласно которой аккредитованный УЦ будет обязан иметь в своем составе OSCP-сервер.
Проблемы стандарта X.509:
- Нет возможности ограничить подчиненные УЦ в выдаче сертификатов, т.е. если Корневой УЦ выдал сертификат подчиненному УЦ, тот может выпускать какие угодно сертификаты и у корневого УЦ нет механизмов, позволяющих это хоть как-то контролировать. Сама технология этого не предусматривает. Отсюда вытекает следующий момент: вопрос доверия огромному на сегодняшний день количеству корневых УЦ. Разве можно гарантировать, что все они прошли аудит и соблюдают правила выдачи сертификатов и аутентификации клиента перед выдачей? Если вдобавок посмотреть на политическую ситуацию в мире, то становится понятно, что использование поддельных сертификатов может быть крайне эффективным оружием в информационной войне между государствами. В этом смысле, видя решительные попытки перехода на отечественное программное обеспечение, остается только гадать, почему сертификаты для сайтов коммерческих банков, государственных органов, выданы зарубежными УЦ, ведь в процессе обеспечения информационной безопасности, одним из самых важных принципов является комплексность.
- Остается открытым вопрос: что делать, если недоступны CRL и OCSP? На текущий момент решение одно – УЦ нужно обеспечивать доступность этих компонентов.
- Что делать в случае компрометации Корневого УЦ? Ответ один: нужно отзывать корневой сертификат. При этом станут недействительны все сертификаты, выданные этим УЦ. Если взять в качестве примера Головной УЦ Минкомсвязи, который является корневым для всех сертификатов, аккредитованных УЦ в России, компрометация Головного УЦ приведет к катастрофическим последствиям в любых отношениях, использующих юридически значимую электронную подпись на территории России. На сегодняшний день насчитывается более пятидесяти сфер использования квалифицированных ЭП в нашей стране – это внешний и внутренний ЭДО, электронные торги, взаимодействие с государственными информационными системами и др.
Как видите, PKI не является идеальной инфраструктурой, и некоторые принципиальные моменты требуют решений. Тем более что сфер применения PKI становится всё больше и больше, и в глобальном значении этих областей сомневаться не приходится.
Часть 3. Заключение.
В качестве постскриптума, хочется кратко поговорить о существующих альтернативах и расширениях PKI:
Сеть доверия PGP (Pretty Good Privacy). Подробнее про PGP можно почитать в Интернете. Остановиться хочется именно на идее проверки принадлежности ключа конкретному пользователю. Как и в PKI, при использовании PGP, субъекты должны каким-нибудь способом проверить, что открытый ключ в сертификате действительно принадлежит отправителю. Если в PKI эту задачу решает существование доверенного УЦ, то в PGP используется схема проверки Web of Trust (Сеть доверия). Web of Trust основан на подписи ключей. Вы можете обозначить свое доверие ключу субъекта, которого знаете, подписав его своим ключом. Этот подписанный ключ вы можете отправить на key-server PGP (key-server выступает в роли публичного хранилища открытых ключей пользователя). Затем третье лицо, зная вас и вам доверяя, может обозначить свое доверие и тому лицу, чей ключ вы подписали. Таким образом, собирается сеть доверия. Существуют специальные мероприятия, которые называются PGP Key-signing party, где люди, показывая друг другу свои документы, удостоверяющие личность и открытый ключ (это не шутка), а затем, подписывая проверенные таким образом ключи друг друга, расширяют сеть доверия. Широкого распространения эта технология не получила и используется в довольно узких сферах (команды разработчиков, единомышленников). При этом key-server не играет ключевой роли, ключи могут быть опубликованы где угодно. Но сама идея с подписанными ключами и децентрализованной сетью доверия кажется очень интересной.
Расширение PKI – OCSP stapling. В целях снятия больших нагрузок в инфраструктуре PKI на сервер OCSP придуман механизм OCSP stapling. Он предполагает, что сайт, которому выдан сертификат, в определенные промежутки времени делает запрос в УЦ о статусе своего сертификата. УЦ отвечает метками действительности с проставлением штампа времени. При этом клиент, который заходит на сайт, видит метку УЦ на сертификате сайта, доверяет ему и не обращается к OCSP-серверу.
Расширение PKI – Certificate pinning. В общем случае клиент, который заходит на сервер, получает сертификат сервера, подписанный УЦ. Этот сертификат может быть подменен на сертификат от другого доверенного УЦ, который вдруг был взломан. Данное расширение предполагает, что на клиенте, как правило, в браузерах и мобильных приложениях, прописано соответствие серверов и сертификатов, т.е. прописан список разрешенных для домена сертификатов или УЦ, который хранится в исходных текстах браузера. Этот метод позволяет избежать подмены сертификата за счет сравнения с эталонными в защищенном хранилище браузера. Но этот метод не защищает нас от взлома УЦ, которые есть в списке соответствия данному домену.
Convergence. Так же как и в предыдущем пункте, данный метод призван защитить нас от атаки Man in the middle (MITM) или человек посередине, когда злоумышленник прослушивает канал и перенаправляет нас на свой сервер, передающий сертификат, подписанный УЦ, который находится в доверенных списках клиента. При этом мы предполагаем, что УЦ взломан. Распределенная система доверия предполагает, что в сети находятся специальные узлы, которые называются "нотариусами" (их может быть большое количество, расположены они могут быть в разных странах). Сертификаты нотариусов предварительно "зашиты" на клиенте. В момент получения сертификата с сервера, клиент, перед тем как доверять этому сертификату, обращается к "нотариусам" и просит их проверить со своей стороны, какой сертификат отдает целевой сервер при обращении к нему. Каждый нотариус идет на сервер и сравнивает сертификат сервера, который он получает с сертификатом в запросе клиента. При совпадении информации клиент доверяет сертификату сервера. Конечно, данный метод не защищает нас от взлома самого сервера.
Расширение для TLS протокола – TACK. В процессе установления соединения с сервером, клиент заявляет о поддержке расширения TACK и запрашивает TACK-ключ (эту ключевую пару генерирует администратор сервера, у данного ключа настраиваемое время жизни и порядок смены). В ответ сервер передает открытую часть TACK-ключа, сгенерированную администратором сервера. Передача происходит в рамках TLS handshake. Далее сервер передает клиенту сертификат, выданный УЦ, который подписан закрытым TACK-ключом, а клиент проверяет подпись с помощью открытой части TACK-ключа, переданной ранее. Таким образом, ответственность смещается на сторону сервера. Применение этой технологии не защищает от MITM при первоначальном подключении.
Google Key Pinning. Очень сильно похож на TACK. Отличия следующие: TACK – расширение для TLS, GKP – расширение HTTP. Ключи передаются не в рамках TLS handshake, а в заголовках сервера. У ключей GKP нет времени жизни. В целом технологии очень похожи. Стандарт предполагает генерацию резервных ключей совместно с основным ключом. В случае компрометации ключа используются резервные ключи. При этом также остается проблема MITM при первоначальном подключении.
Certificate Transparency. Технология разработана специалистами Google и призвана решить проблему поддельных сертификатов для доменов и их позднего обнаружения. Идея заключается в том, чтобы сделать невозможным создание сертификата для какого-либо домена незаметно для владельца этого домена. Технология предполагает существование трех объектов:
- Public Logs of Certificates – Постоянно расширяемый, открытый для общего доступа журнал, в который заносятся все выданные сертификаты. Предполагается, что такие журналы будут вести УЦ, записывая в них выданные сертификаты.
- Public Log Monitoring – Мониторы являются публично запускаемыми серверами, которые периодически связывают все серверы, где ведутся журналы сертификатов и следят за подозрительными сертификатами. Например, мониторы могут определить, был ли выпущен незаконный или несанкционированный сертификат для домена, а также они могут наблюдать за сертификатами, которые имеют необычные расширения, странные разрешения или, например, содержат слабые ключи. Предполагается, что Мониторы развернуты владельцами критических, с точки зрения безопасности передаваемых данных, сайтов, что позволяет отслеживать выдачу сертификатов для своих доменов или просто "неравнодушными" к проблемам безопасного интернета людей.
- Public Certificate Auditing – Аудиторы – это клиентские программные компоненты, которые выполняют две функции. Во-первых, они могут проверить, что журналы ведут себя корректно и согласовано. Во-вторых, они могут проверить, что конкретный сертификат появляется в журнале. Это особенно важная функция аудита, поскольку для платформы Transparency требуется, чтобы все сертификаты SSL регистрировались в журнале. Если сертификат не был зарегистрирован в журнале, это знак того, что сертификат является подозрительным, и клиенты TLS могут отказаться от подключения к сайтам с такими сертификатами.
На этом мы остановимся и заметим, что представленные расширения в основном направлены на решение проблемы компрометации УЦ и предлагают делегирование ответственности на других участников взаимодействия. Но, к сожалению, полностью фундаментальные проблемы это не решает и о полноценной альтернативе PKI не может идти и речи.
Также как и любое правило, которое всегда содержит исключения, любая, даже по-настоящему отличная идея, всегда будет содержать в себе недостатки. PKI решает огромную массу задач и, несмотря на имеющиеся в технологии изъяны, является одним из самых значимых применений криптографии в сфере информационных технологий на сегодняшний день. К тому же, давайте говорить прямо, это очень неплохой бизнес для сотен УЦ. Поэтому можно с уверенностью говорить, что PKI будет только расширять свое присутствие в самых различных сферах применения.