Public Key Cryptography: осваиваем открытые ключи на практике
Содержание статьи
Картина мира
Перед погружением в код давай разберем немного терминологии. PKI — инфраструктура открытых ключей. Как несложно догадаться, PKI основана на асимметричном шифровании. В симметричных шифрах для шифрования и расшифрования используется один ключ. В асимметричных для шифрования используется один ключ, а для расшифрования — другой. Вместе они образуют ключевую пару.
Информация, необходимая для работы PKI, содержится в сертификате X.509. В PKI участвуют как минимум три стороны: Алиса, Боб и удостоверяющий центр (УЦ). У Алисы и Боба есть сертификаты с закрытым ключом, подписанные так называемым корневым сертификатом УЦ. У Алисы есть сертификат Боба с открытым ключом, а у Боба — сертификат Алисы с открытым ключом. Алиса и Боб доверяют УЦ и благодаря этому могут доверять друг другу.
Упрощенная структура PKI
Xakep #206. Ключ от всех дверей
Сертификаты X.509
Так повелось, что основным «активом» в PKI является сертификат X.509. Сертификат — это что-то вроде паспорта, он содержит информацию, позволяющую идентифицировать субъект, которому выдан сертификат (поле Subject), указывает, кем он был выпущен (поле Issuer), серийный номер сертификата и многое другое. В Windows управлять сертификатами можно с помощью оснастки «Сертификаты» ( run->certmgr.msc ).
Менеджер сертификатов
Сертификаты хранятся в хранилищах («Личное», «Доверенные центры сертификации», «Доверенные лица». ).
При получении сертификата важно установить его в правильное хранилище. Так, сертификаты, которые ты хочешь использовать для электронной подписи, должны быть установлены в хранилище «Личное», а сертификаты получателей, которым нужно будет отправлять зашифрованные сообщения, — в хранилище «Доверенные лица». Сертификаты удостоверяющих центров (УЦ) должны быть установлены в хранилище «Доверенные корневые центры сертификации». При установке сертификата система предлагает два варианта: выбрать хранилище автоматически либо указать вручную. Рекомендую использовать второй вариант, так как автоматика иногда устанавливает сертификат не в то хранилище. Сертификат, которым мы хотим подписывать сообщения, должен иметь закрытый ключ. О наличии закрытого ключа можно узнать, посмотрев на свойства сертификата, где русским по белому будет написано: «есть закрытый ключ для этого сертификата».
Закрытый ключ для сертификата
Самое интересное о сертификате мы можем узнать на вкладке «Состав».
Состав сертификата
Обрати внимание на поля «Алгоритм подписи», «Алгоритм хеширования подписи» и «Открытый ключ». Если хочешь использовать сертификат для осуществления транзакций в России, во всех этих полях ты должен видеть слово «ГОСТ». Также следует обратить внимание на значение поля «Использование ключа» и поля «Действителен с» и «Действителен по»: первое позволит понять, возможно ли использование сертификата для выполнения нужной нам операции (шифрование, подпись), а второе и третье — возможно ли использовать данный сертификат в указанный момент времени. В дополнение к этому следует убедиться, что сертификат действителен. В этом нам поможет вкладка «Путь сертификации». Если с сертификатом все хорошо, мы увидим надпись: «Этот сертификат действителен».
Состояние сертификата
WARNING
Цифровая подпись
Представь, дорогой читатель, что ты занимаешься некой очень ответственной работой. И результаты своей работы отправляешь в виде отчетов, от которых в конечном итоге зависят чьи-то конкретные судьбы и жизни. Получатели твоих отчетов принимают на их основе очень важные решения, и, если ты напортачишь, вполне можешь получить срок. Так вот, в таких ответственных организациях без электронной подписи никуда. Она позволяет тебе подписать тот самый суперважный секретный отчет своим сертификатом с закрытым ключом. Закрытый ключ, в идеале, может храниться на токене — специальном съемном устройстве, похожем на флешку, которое ты в редкие моменты достаешь из сейфа. Подпись гарантирует, что твой отчет отправлен именно тобой, а не уборщицей или сторожем. С другой стороны, ты не сможешь отказаться от авторства (это называется «неотрекаемость») и, если накосячишь в своем суперважном документе, на сторожа свалить вину не получится.
Электронная подпись применяется не только в спецслужбах и органах, но и в бизнесе. Например, для перевода пенсионных накоплений в НПФ: мы генерируем запрос на сертификат, отправляем его в удостоверяющий центр (УЦ). УЦ выпускает сертификат, мы подписываем сертификатом заявление на перевод пенсионных накоплений, отправляем — и вуаля. Подпись также позволяет осуществлять контроль целостности подписываемых данных. Если данные будут изменены, подпись не пройдет проверку.
Перед тем как заюзать наш сертификат, необходимо его проверить. Процедура включает в себя проверку цепочки сертификации, проверку срока действия и проверку, не отозван ли сертификат. Если мы подпишем файл недействительным сертификатом, подпись будет недействительной.
Мы проверили сертификат и убедились, что он в порядке. Переходим непосредственно к подписыванию данных. Подпись бывает двух видов: прикрепленная и открепленная.
Прикрепленная и открепленная подписи
Результатом прикрепленной подписи будет CMS (Cryptography Message Syntax) — сообщение, содержащее как подписываемые данные, так и саму подпись. Открепленная подпись содержит только саму подпись. Рекомендую использовать именно открепленную подпись, потому что с ней намного меньше мороки. В нее проще поставить метку времени, она меньше весит, так как не содержит подписываемые данные. Подписываемые данные легко открыть, посмотреть. В случае прикрепленной подписи для того, чтобы просмотреть подписанные данные, CMS-сообщение необходимо сначала декодировать. В общем, прикрепленной подписи я рекомендую избегать всеми силами. Если потребуется передавать подпись и контент вместе, рассмотри вариант архивирования (вместо использования прикрепленной подписи используй открепленную, просто заархивируй подписываемый файл и открепленную подпись). Посмотрим на код подписи (С#):
На C++ будет что-то вроде:
Вызов кода на C++ из C# будет выглядеть примерно так:
Проверка подписи и декодирование
А теперь, дорогой читатель, представь, что ты большой начальник и должен принять важное стратегическое решение на основе отчета, который тебе прислал сотрудник по электронной почте. Для твоего удобства отчет был подписан открепленной подписью. Открыв почту и скачав отчет, ты, как опытный, знающий жизнь человек, не спешишь принимать на веру содержимое отчета и проверяешь подпись. После проверки выясняешь, что подпись неверна — не сошлась контрольная сумма. В результате оповещаешь службу безопасности, которая проводит расследование и выясняет, что хитрые конкуренты взломали почтовый сервер и отправили тебе фальшивый документ. Тебя наградили за бдительность, конкурентов посадили, а компания наконец-то получила оригинальный отчет с проверенной электронной подписью.
Если пользователь прислал тебе отчет в виде прикрепленной подписи, тебе для чтения придется его декодировать:
А так будет выглядеть код проверки подписи при вызове из C#:
Шифрование
Зачем нужно шифрование, все уже знают. PKI нам дает полезную плюшку: мы можем зашифровать один документ так, что расшифровать его смогут несколько получателей. Это очень удобно. Для этого нам нужно иметь сертификаты получателей.
Расшифрование
При расшифровании необходимо, чтобы сертификат, указанный при шифровании в коллекции получателей, был установлен в хранилище сертификатов. Так как сообщение может быть зашифровано и адресовано нескольким получателям, для расшифрования нам необходимо найти того получателя, сертификат которого установлен в нашем хранилище сертификатов.
Заключение
Как видишь, работа с PKI достаточно сложная и требует серьезной подготовки, выдержки и терпения. Перед тем как бросаться реализовывать классные фичи, крайне важно понимать основные концепции PKI.
За кадром остались поточное шифрование и расшифрование, подпись несколькими сертификатами, генерация запросов на сертификат и многое другое, но основу я тебе показал. Код примеров с тестами можно скачать на GitHub.
Про PKI «на пальцах» за 10 минут
Предложил коллегам провести внутреннюю мини-лекцию по сабжу — идея зашла. Сел писать план лекции и… чот психанул — в итоге очнулся, дописывая небольшой гайд. Подумал, что будет полезно добавить сюда что-то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел.
Пишу на примере наших повседневных задач, которые знакомы многим: беспарольный доступ к серверам OpenVPN и защита доступа к ресурсам с помощью HTTPS.
Без теории не обойтись
PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется. То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной.
Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что-то, или запрещает в противном случае.
OpenVPN: как это бывает
На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто-то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале.
При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно OpenVPN клиента, находятся файлы (на примере сотрудника Иванова А.А.):
В компании Acme все эти файлы генерирует Полуэкт…
А теперь как должно быть
На моем примере, упрощенно:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
(пароль в конце лучше не указывать, а то придется его вводить каждый раз при подключении, а VPN у нас по сертификатам как раз, чтобы этого не было; тем более у нас в Pixonic есть OTP от Google);
Нужна ли вам эта фишка — вопрос для обсуждения. Соответственно, то, как ее внедрить, пока что выходит за рамки этой статьи.
И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 90 дней с момента выпуска сертификата. Чего не случится с SSH-доступом, если коллеги забудут отключить аккаунт во FreeIPA или удалить строчку из authorized_keys руками. C — сесуриту.
Теперь по Борщеву HTTPS
Предположим, вы хотите «включить SSL» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами:
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
OpenVPN и инфраструктура открытых ключей (PKI)
OpenVPN пользуется заслуженной популярностью у системных администраторов, находя широкое применения в самых разнообразных сценариях. Но очень часто внедрение OpenVPN происходит посредством повторения инструкций, без глубокого понимания смысла выполняемых действий. Особенно это касается «генерации ключей», эта простая с виду операция имеет достаточно глубокий скрытый пласт, формируя собственную инфраструктуру открытых ключей. Отсутствие понимания структуры PKI, как показывает отклик наших читателей, способно приводить к различного рода затруднениям и проблемам при использовании OpenVPN.
Всем известно, что для аутентификации пользователей OpenVPN использует вместо паролей сертификаты. Что это дает? Это дает существенное повышение безопасности. Мы сейчас не будем говорить о том, что пароль можно перехватить. Современные системы не передают пароли в открытом виде, используя вместо них достаточно хорошо защищенные сложными криптографическими алгоритмами хеши. Но пароль всегда можно подобрать и это одно из наиболее уязвимых мест.
Сертификат подобрать невозможно, его можно либо иметь, либо не иметь. Но само по себе наличие сертификата еще ничего не дает, он не является секретным и вы вполне можете его получить, но чтобы установить защищенное соединение с сервером вам потребуется закрытый ключ, который хранится в надежном месте и (в идеале) никогда не покидает пределы клиентского ПК.
Но как сервер определит, что именно этот клиент имеет право доступа? Существует ошибочное мнение, что сертификаты выдает именно сервер и поэтому он знает, кто из клиентов имеет право подключаться, а кто нет. Однако это не так и данное заблуждение часто приводит к разного рода затруднениям при работе с OpenVPN.
В нашем случае таким «бюро пропусков» служит Центр сертификации (CA, Certification authority), вокруг которого складывается инфраструктура открытых ключей. Авторитет CA неоспорим и доверие к нему не подвергается сомнению. Именно CA осуществляет всё управление сертификатами, как для клиентов, так и для серверов.
Это абсолютно отдельная сущность, хотя физически она может находиться на одном узле с сервером OpenVPN. Чаще всего в роли центра сертификации используется Easy-RSA, хотя можно использовать любое другое ПО, скажем, в роли CA вполне может выступать Mikrotik. Но общий смысл от этого не меняется, создав центр сертификации мы вместе с ним создаем область доверия, которая называется инфраструктурой открытых ключей.
Давайте рассмотрим следующую схему:
При создании центра сертификации мы генерируем ключевую пару из открытого и закрытого ключей. Открытый ключ, вместе с другой информацией о нашем CA содержится в корневом сертификате ca.crt, который должен иметь самое широкое распространение в нашей инфраструктуре, так как именно он составляет основу доверительных отношений. Имея на руках корневой сертификат, мы можем проверить сертификат любого другого субъекта и убедиться, что он выдан нашим CA и следовательно мы можем ему доверять.
Закрытый ключ центра сертификации представляет самую большую ценность и должен храниться в надежном месте, а также никогда не покидать пределы CA. Компрометация закрытого ключа фактически уничтожает область доверия, так как мы не можем быть уверенны, что предъявленный нам сертификат выпущен именно CA, а не завладевшим ключом злоумышленником.
В теории мы должны на каждом клиенте центра сертификации создать открытый и закрытый ключи, сформировать запрос на сертификат и отправить его CA, который в свою очередь выпустит нужный нам сертификат и подпишет его своим открытым ключом. Таким образом никакая критически важная для безопасности информация (закрытые ключи) по каналам связи не передается.
На практике схема, когда и ключи, и сертификаты формирует CA вполне допустима, так как все это контролируется системным администратором, который может принять разумные меры для недопущения несанкционированного доступа к закрытым ключам.
Таким образом на каждом из узлов нашей OpenVPN-сети должен присутствовать закрытый ключ, сертификат узла и корневой сертификат CA. При этом ни клиенты, ни сервера не знают кому именно выпущены сертификаты и в каком количестве.
Это очень важный момент. OpenVPN-сервер не имеет списка клиентов и готов предоставить доступ любому, кто предоставит валидный сертификат. Почему? Потому что все они входят в область доверия, созданную центром сертификации в рамках инфраструктуры открытых ключей.
Чтобы получить доступ клиент предъявляет серверу собственный сертификат, сервер, при помощи корневого сертификата CA убеждается, что данный сертификат действительно выдан нашим центром сертификации и ему можно доверять, затем проверяется срок его действия и при успешной проверке начинается процесс установления защищенного соединения.
Срок действия является одним из наиболее важных параметров сертификата и его можно успешно использовать в свою пользу. Скажем для сотрудника на испытательном сроке можно выпустить сертификат на 30 дней, а затем просто перевыпустить на больший срок. Это гораздо безопаснее, чем потом забыть отозвать сертификат у непрошедшего испытательного срока работника.
Со своей стороны клиент точно также проверяет действительность сертификата сервера, после чего устанавливает с ним связь. При этом любой клиент с сертификатом текущего CA может без проблем подключиться к любому серверу в рамках инфраструктуры PKI.
Что касается CA, что обычно он размещается на одном из серверов OpenVPN, но в более сложных схемах имеет смысл вынести его на отдельный узел, лучше всего на виртуальную машину, которую даже можно большую часть времени держать выключенной, включая только для того, чтобы выпустить или отозвать очередной сертификат.
Но OpenVPN так не умеет, что влечет за собой некоторые дополнительные действия. Рассмотрим еще одну схему:
После того, как CA обновил список отозванных сертификатов (CRL) его нужно распространить на все сервера OpenVPN в нашей инфраструктуре, после чего они будут понимать, что данный сертификат отозван и отказывать в соединении. Если мы не выполним данное условие, то те сервера, которые не получили обновленный CRL будут по-прежнему разрешать доступ клиенту сертификат которого отозван.
Что касается практики, то правильный сценарий предусматривает в пределах одной организации один центр сертификации, создание для нескольких OpenVPN-серверов нескольких CA является достаточно грубой ошибкой. Единственный CA позволяет иметь одну точку управления доверием для всей вашей сети вне зависимости от количества серверов и клиентов в ней.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
PKI (Public Key Infrastructure)
Содержание
Описание
Инфраструктура открытых ключей – это система цифровых сертификатов, центров сертификации и центров регистрации, которые проверяют и подтверждают подлинность каждого объекта, участвующего в электронной транзакции с использованием криптографии с открытыми ключами. Инфраструктура открытых ключей использует технологию открытых ключей для:
Основные определения
Цифровая подпись- метод использования шифрования с открытым ключом для обеспечения целостности данных и невозможности отказа от посылки. Зашифрованный блок информации после расшифровки получателем, идентифицирует отправителя и подтверждает сохранность данных. Например: документ «сжат», HASH зашифрован с помощью частного ключа отправителя и приложен к документу (по сути, это означает приложить «отпечаток пальца» этого документа). Получатель использует открытый ключ для расшифровки полученного сообщения до состояния «выжимки», которая затем сравнивается с «выжимкой» полученной после «сжатия» присланного документа. Если обе «выжимки» не совпали, то это означает, что документ был изменен или поврежден в процессе пересылки.
Компоненты PKI
Основная идея
Задачей PKI является определение политики выпуска цифровых сертификатов, выдача их и аннулирование, хранение информации, необходимой для последующей проверки правильности сертификатов. В число приложений, поддерживающих PKI, входят: защищенная электронная почта, протоколы платежей, электронные чеки, электронный обмен информацией, защита данных в сетях с протоколом IP, электронные формы и документы с электронной цифровой подписью (ЭЦП).
Удостоверяющий центр также публикует и списки отозванных сертификатов (Certificate Revocation List/CRL), которые могут использовать клиенты инфраструктуры открытого ключа, когда решают вопрос о доверии сертификату пользователя и/или компьютера.
Создаётся пара ключей либо центром выдачи сертификатов (удостоверяющим центром), по запросу пользователя, или же самим пользователем с помощью специального программного обеспечения. Пользователь делает запрос на сертификат, после чего, после процедуры идентификации пользователя, центр выдаёт ему сертификат со своей подписью. Эта подпись свидетельствует о том, что данный сертификат выдан именно этим центром выдачи сертификатов и никем другим.
Секретный ключ используется для подписи данных, открытый ключ в свою очередь используется для шифрования данных. Открытый ключ известен всем, а секретный ключ хранится в тайне. Владелец секретного ключа всегда хранит его в защищённом хранилище и ни при каких обстоятельствах не должен допустить того, чтобы этот ключ стал известным злоумышленникам или другим пользователям. Если же секретный ключ всё таки станет известен злоумышленникам, то он считается скомпрометированным и должен быть отозван и заменен. Только владелец секретного ключа может подписать данные, а также расшифровать данные, которые были зашифрованы открытым ключом, соответствующим секретному ключу владельца. Подпись на данных или письме гарантирует авторство полученной информации и то, что информация в процессе передачи не подверглась изменениям. Подпись двоичного кода гарантирует, что данное программное обеспечение действительно произведено указанной компанией и не содержит вредоносного кода, если компания это декларирует.
Архитектуры PKI В основном выделяют 5 видов архитектур PKI:
В основном PKI делятся на разные архитектуры по следующим признакам:
Примеры использования PKI
Шифрование сообщений
Сторона Б зашифровывает документ открытым ключом стороны А. Чтобы убедиться, что открытый ключ действительно принадлежит стороне А, сторона Б запрашивает сертификат открытого ключа у удостоверяющего центра. Если это так, то только сторона А может расшифровать сообщение, так как владеет соответствующим закрытым ключом.
Электронный отпечаток
Электронно-цифровая подпись (ЭЦП)
Сторона А формирует ЭЦП документа и отправляет документ стороне Б. Сторона Б запрашивает сертификат открытого ключа стороны А у удостоверяющего центра, а также информацию о действительности сертификата. Если сертификат стороны А действителен и проверка ЭЦП прошла успешно, значит документ был подписан стороной А, а не кем-то другим.
