Технология pki что это

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

PKI (Public Key Infrastructure)

Содержание

Описание

Инфраструктура открытых ключей – это система цифровых сертификатов, центров сертификации и центров регистрации, которые проверяют и подтверждают подлинность каждого объекта, участвующего в электронной транзакции с использованием криптографии с открытыми ключами. Инфраструктура открытых ключей использует технологию открытых ключей для:

Основные определения

Цифровая подпись- метод использования шифрования с открытым ключом для обеспечения целостности данных и невозможности отказа от посылки. Зашифрованный блок информации после расшифровки получателем, идентифицирует отправителя и подтверждает сохранность данных. Например: документ «сжат», HASH зашифрован с помощью частного ключа отправителя и приложен к документу (по сути, это означает приложить «отпечаток пальца» этого документа). Получатель использует открытый ключ для расшифровки полученного сообщения до состояния «выжимки», которая затем сравнивается с «выжимкой» полученной после «сжатия» присланного документа. Если обе «выжимки» не совпали, то это означает, что документ был изменен или поврежден в процессе пересылки.

Компоненты PKI

Основная идея

Задачей PKI является определение политики выпуска цифровых сертификатов, выдача их и аннулирование, хранение информации, необходимой для последующей проверки правильности сертификатов. В число приложений, поддерживающих PKI, входят: защищенная электронная почта, протоколы платежей, электронные чеки, электронный обмен информацией, защита данных в сетях с протоколом IP, электронные формы и документы с электронной цифровой подписью (ЭЦП).

Удостоверяющий центр также публикует и списки отозванных сертификатов (Certificate Revocation List/CRL), которые могут использовать клиенты инфраструктуры открытого ключа, когда решают вопрос о доверии сертификату пользователя и/или компьютера.

Создаётся пара ключей либо центром выдачи сертификатов (удостоверяющим центром), по запросу пользователя, или же самим пользователем с помощью специального программного обеспечения. Пользователь делает запрос на сертификат, после чего, после процедуры идентификации пользователя, центр выдаёт ему сертификат со своей подписью. Эта подпись свидетельствует о том, что данный сертификат выдан именно этим центром выдачи сертификатов и никем другим.

Секретный ключ используется для подписи данных, открытый ключ в свою очередь используется для шифрования данных. Открытый ключ известен всем, а секретный ключ хранится в тайне. Владелец секретного ключа всегда хранит его в защищённом хранилище и ни при каких обстоятельствах не должен допустить того, чтобы этот ключ стал известным злоумышленникам или другим пользователям. Если же секретный ключ всё таки станет известен злоумышленникам, то он считается скомпрометированным и должен быть отозван и заменен. Только владелец секретного ключа может подписать данные, а также расшифровать данные, которые были зашифрованы открытым ключом, соответствующим секретному ключу владельца. Подпись на данных или письме гарантирует авторство полученной информации и то, что информация в процессе передачи не подверглась изменениям. Подпись двоичного кода гарантирует, что данное программное обеспечение действительно произведено указанной компанией и не содержит вредоносного кода, если компания это декларирует.

Архитектуры PKI В основном выделяют 5 видов архитектур PKI:

В основном PKI делятся на разные архитектуры по следующим признакам:

Примеры использования PKI

Шифрование сообщений

Сторона Б зашифровывает документ открытым ключом стороны А. Чтобы убедиться, что открытый ключ действительно принадлежит стороне А, сторона Б запрашивает сертификат открытого ключа у удостоверяющего центра. Если это так, то только сторона А может расшифровать сообщение, так как владеет соответствующим закрытым ключом.

Электронный отпечаток

Электронно-цифровая подпись (ЭЦП)

Сторона А формирует ЭЦП документа и отправляет документ стороне Б. Сторона Б запрашивает сертификат открытого ключа стороны А у удостоверяющего центра, а также информацию о действительности сертификата. Если сертификат стороны А действителен и проверка ЭЦП прошла успешно, значит документ был подписан стороной А, а не кем-то другим.

Источник

Про 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» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами:

Источник

Журнал ВРМ World

PKI: Как это работает

Сегодняшний бизнес все в большей степени начинает использовать VPN, обеспечивающие выгодные с точки зрения стоимости услуги в области коммуникации, обладающие высоким уровнем безопасности и способствующие созданию более тесных отношений с партнерами, поставщиками и даже потребителями такими способами, о которых всего несколько лет назад никто даже и не мечтал. Более того, перспектива замены дорогостоящих арендуемых и коммутируемых линий на эффективные IP-соединения с целью подсоединения удаленных сотрудников и филиалов к корпоративной сети является крайне заманчивым предложением для многих организаций.

Используя комбинацию туннелирования, шифрования, аутентификации и контроля доступа, VPN предоставляет пользователям защищенный способ доступа через Интернет или другие общие или частные IP-сети. Реализация VPN включает в себя два основных технологических решения: протокол туннелирования и метод аутентификации пользователей туннеля.

IPSec, протокол туннелирования Уровня 3 (сетевого уровня), сегодня обычно используется для шифрования и выделения данных для защищенной передачи по VPN корпоративных сетей. Ряд методов аутентификации, служащих для проверки идентичности допущенных пользователей, может реализовываться через IPSec, включая пароли, известные серверу и клиенту, доступ с передачей маркера и цифровые сертификаты. Для широкой реализации в экстранет самым простым методом является Инфраструктура Открытых Ключей (Public Key Infrastructure, PKI), использующая технологию цифровых сертификатов. Эта статья расскажет о том, как PKI работает в среде VPN.

Определение PKI

Технология PKI заключается в использовании двух математически-связанных цифровых ключей, имеющих следующие свойства:

Обслуживание недействительных сертификатов

Даже если срок действия сертификата еще не истек, он может рассматриваться как недействительный или непригодным по ряду причин: владелец может больше в нем не нуждаться, сертификат может быть дискредитирован или украден, владелец мог уже выпустить новый сертификат, имеющий преимущество относительно существующего.

В этом случае CA-оператор может пойти двумя путями. Сертификат может быть внесен в Certificate Revocation List (CRL-X.509v2) и выпущен на определенный срок. CRL остается в v2, так как было оговорено, что при переходе других компонентов на v3 в него не было внесено никаких изменений. Либо аннулирование сертификата осуществляется с помощью Online Certificate Status Protocol (OCSP) на онлайновом сервере, представляющим собой, например, сервер базы данных X.509 v3, обеспечивающий сервис такого рода.

Каждый раз, как конечная точка IPSec проверяет допустимость сертификата, предоставленного для аутентификации, она проверяет последний кэшированный CRL или использует OCSP для определения, включен ли данный сертификат в соответствующий список. Если он в списке, это означает, что сертификат больше не действителен и конечная точка IPSec его отклонит.

Как работает сложная PKI

Сложная PKI может использовать множество различных CA с Root CA (корневыми CA). Root CA хранит «собственноручно» подписанный сертификат и выпускает сертификаты для подчиненных CA (т.е. относящихся к более низкому уровню), которые, в свою очередь, могут выпускать сертификаты для различных RA (Registration Authorities) или LRA (Local Registry Authorities). В процессе работы RA или LRA получает исходный запрос на сертификат от запрашивающей стороны и передает аутентифицированный запрос своему CA, выпускающему этот сертификат. Иерархия различных CA напоминает дерево, именно поэтому исходный CA назван Root CA (см. Рис. 1).

В случае конечной точки IPSec CP определяет, какая информация должна быть предъявлена CA для аутентификации до выпуска сертификата для этой конечной точки. Он также определяет, какую информацию будет содержать индивидуальный сертификат и как он будет выглядеть. CP определяет обновление CRL или требования размещения уведомления об аннулированном сертификате на сервере OCSP. Кроме того, CP может также определять требования физической безопасности, которым должен соответствовать CA.

Присвоение и регистрация Объектного Идентификатора (Object Identifier)

Когда CP уже сформулирована, ее следует разместить на сайте компании. Компания, составляющая CP, должна быть зарегистрирована через IANA (Internet Assigned Numbers Association), чтобы ее CP был присвоен Объектный идентификатор (Object Identifier, OID). OID представляет собой представление компании в численной форме. Этот OID следует поместить в сертификат, чтобы RP (лицо, получающее данный сертификат) могло найти и ознакомиться с CP сертификата на сайте идентифицируемой компании. Прочитав CP, RP самостоятельно решает, заслуживает ли данный сертификат доверия.

Написание Положения об использовании сертификата (Certificate Practice Statement)

Для успешной реализации CA, в зависимости от уровня необходимой авторизации, оператор CA должен либо написать специальное Положение об использовании сертификата (Certificate Practice Statement, CPS) либо составить общее CPS. CPS представляет собой документ, описывающий подробности реализации CP и объясняющий порядок соотнесения CA с требованиями CP. По правилам American Bar Association, идентификатор CPS (OID) также должен включаться в сертификат. Эта информация в дальнейшем позволит RP проверять квалификацию Certificate Authority.

Создание собственного CA

Хотя разработка CP и CPS может показаться ненужной, так как компания, использующая CA, полностью контролирует их реализацию, тем не менее, это необходимо по двум причинам. Во-первых, это гарантирует оптимальный уровень безопасности, поскольку компания создает документы и по эксплуатационным вопросам, и по проверке безопасности. Во-вторых, это необходимо в случае, когда компания планирует провести взаимную сертификацию с другой PKI.

Взаимная сертификация означает, что сертификат, выпущенный одной PKI, становится применим в другой PKI. И CP и CPS каждой из PKI будет проверен другой PKI с целью убедиться, что их сертификаты можно рассматривать как равнозначные относительно важных для них аспектов (не совсем верно было бы называть их полностью «равнозначными», так как юридически это означало бы и словесное совпадение). Взаимная сертификация представляет собой простое физическое действие: каждый CA выпускает для другого сертификат, содержащий Policy Mappings Extension (Расширенное отображение политики), закрепляющий вышеуказанное соглашение. Сложность состоит в согласовании соглашений CP и CPS между двумя PKI.

Взаимная сертификация может быть обременительна, когда существует множество PKI, так как в этом случае число взаимных сертификатов растет в геометрической прогрессии. Если имеются две PKI, будет два сертификата, но если PKI будет четыре, им придется обменяться уже двенадцатью сертификатами. В какой-то момент индивидуальный EE утратит способность проходить эту цепь для выяснения допустимости возможно легитимного предъявленного ему сертификата, т.е. реализация этого EE не имеет вычислительных возможностей для прохождения цепи такой протяженности. В данном случае решением будет Bridged PKI (шунтированная PKI).

Источник

Инфраструктура открытых ключей

В этом упрощенном примере выделяется по крайней мере одна очевидная проблема: у Боба должен быть открытый ключ, который он использовал для шифрования сообщения. То есть он не знает, что ключ, который он использовал для шифрования, на самом деле принадлежит Алисе. Возможно, что другая сторона, отслеживающая коммуникационный канал между Бобом и Алисой, заменяла другой ключ.

Концепция инфраструктуры открытого ключа изменилась для помощи в устранении этой проблемы и других. Инфраструктура открытых ключей (PKI) состоит из программных и аппаратных элементов, которые доверенная третья сторона может использовать для установления целостности и принадлежности открытого ключа. Доверенная сторона, называемая центром сертификации (CA), обычно выполняет эту задачу, выдавая подписанные (зашифрованные) двоичные сертификаты, подтверждающие подлинность субъекта сертификата, и привязывает удостоверение к открытому ключу, содержащемуся в сертификате. ЦС подписывает сертификат с помощью его закрытого ключа. Он выдает соответствующий открытый ключ всем заинтересованным сторонам в самозаверяющего сертификата ЦС. При использовании ЦС предыдущий пример можно изменить следующим образом:

В целом процесс подписи сертификата позволяет Бобу проверить, что открытый ключ не был изменен или поврежден во время передачи. Перед выдачей сертификата центр сертификации хэширует содержимое, подписывает (шифрует) хэш с помощью собственного закрытого ключа и включает зашифрованный хэш в выданный сертификат. Боб проверяет содержимое сертификата, расшифровывать хэш с помощью открытого ключа ЦС, выполняя отдельный хэш содержимого сертификата и сравнивая два хэша. Если они совпадают, Боб может быть уверенным в том, что сертификат и открытый ключ, которые он содержит, не были изменены.

Типичная PKI состоит из следующих элементов.

API регистрации сертификатов позволяет отправлять запросы на архивацию сертификатов и ключей в центры сертификации и регистрации и устанавливать выданный сертификат на локальный компьютер. Он не позволяет напрямую управлять базой данных сертификатов или хранилищем сертификатов.

В следующих разделах инфраструктура открытых ключей Майкрософт обсуждается более подробно:

Источник

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.

Источник