Public key infrastructure

Что такое PKI

Публикация: 07 Июль 2005 — 15:41, редакция: 21.07.2011 13:36

PKI

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

Используя криптопровайдер КриптоПро CSP пользователи ОС MS Windows могут воспользоваться стандартными программными средствами фирмы Microsoft для реализации и использования решений, основанных на Инфраструктуре Открытых Ключей. К этим средствам относятся:

• Инструментарий разработчика CryptoAPI
• Инструментарий разработчика CAPICOM 1.0

• Центр Сертификации (MS Certification Authority)
• Certificate Enrollment Control (xenroll)
• Microsoft Outlook
• Microsoft Outlook Express
• Microsoft Authenticode

Обучение

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

• Использование ЭЦП и PKI.
• Теория и Практика применения PKI.

Использование ЭЦП и PKI. Юридические, теоретические и практические основы использования электронной цифровой подписи и инфраструктуры открытых ключей в прикладных системах организации.

Теория и Практика применения PKI. Теоретические основы, стандарты и варианты практических подходов к построению инфраструктуры открытых ключей.

Построение PKI на основе продуктов Microsoft с использованием сертифицированного криптопровайдера КриптоПро CSP.

Академия АйТи предлагает следующие курсы, связанные с PKI:

Применение инфраструктуры открытых ключей и ЭЦП

Программа учебного курса Применение инфраструктуры открытых ключей и ЭЦПориентирована на администраторов безопасности, эксплуатирующих программные продукты средство криптографической защиты информации «КриптоПро CSP» и приложение «КриптоАРМ».

Рассматриваются вопросы внутренней структуры продуктов, процессы их инсталляции, эксплуатации и администрирования. Анализируются Российское законодательство, относящееся к использованию PKI, процедуры подготовки операционной системы (ОС) для установки и эксплуатации решений.

Uses

PKIs of one type or another, and from any of several vendors, have many uses, including providing public keys and bindings to user identities which are used for:

• Encryption and/or sender authentication of e-mail messages (e.g., using OpenPGP or S/MIME);
• Encryption and/or authentication of documents (e.g., the XML Signature or XML Encryption standards if documents are encoded as XML);
• Authentication of users to applications (e.g., smart card logon, client authentication with SSL). There’s experimental usage for digitally signed HTTP authentication in the Enigform and mod_openpgp projects;
• Bootstrapping secure communication protocols, such as Internet key exchange (IKE) and SSL. In both of these, initial set-up of a secure channel (a «security association») uses asymmetric key—i.e., public key—methods, whereas actual communication uses faster symmetric key—i.e., secret key—methods;
• Mobile signatures are electronic signatures that are created using a mobile device and rely on signature or certification services in a location independent telecommunication environment;
• Internet of things requires secure communication between mutually trusted devices. A public key infrastructure enables devices to obtain and renew X509 certificates which are used to establish trust between devices and encrypt communications using TLS.

Recovery Agent

Now I would like to spend some time about Recovery Agent. This feature is very important if you encrypt corporate data. Depending on your country and your law, security officers must be able to unencrypt information for a while even if the employee has left. To be able to unencrypt all data even if the private key of the user has been lost, you should use recovery agent.

The principle is simple: all private keys generated by client are copied in a key archival. Then the recovery agent certificate is able to open this key archival. To recover data, just extract the related private key from key archival and use it to unencrypt data.

To implement Key Archival, I will create a certificate for Romain Serre using Key Recovery Agent certificate template:

In security tab, I add my account with Read and Enroll permissions.

Next I configure my CA to issue the certificate template:

Now I open a mmc with certificates snap-ins which manage my user account:

Right click on Personal and select All tasks, Request New Certificate.

When you are asked for a certificate template, select Key Recovery Agent and click on Enroll. At the end of this process, the enrollment is pending and wait for your approval.

To approve the certificate request, open the certification authority console and click on Pending Requests. Right click on your certificate and select All Tasks and Issue.

Now open issued certificates and double click on the previously issued certificate. Navigate to the Details tab and export the certificate by clicking on Copy to file. Follow the process and export your certificate to .cer file.

Once your certificate is exported, go back to your mmc and right click on Personal. Select All Tasks and import as below.

Follow the import process and select the .cer file that you have just exported. Now you should have the certificate in your personal store.

To configure the Key Archival, open the certification authority, right click on the CA name and select properties. Navigate to Recovery Agents tab. Select Archive the key, click on Add and select the certificate:

Before restarting Certificate Services, the status of the key recovery agent certificates is not loaded. When you click on apply, the service restarts and the status should be valid.

Now to archive the private key in the Key Archival, edit the template that you want and navigate to the Request Handling tab. Tick the Archive subject’s encryption private key checkbox. Select the Key archival and click ok:

Now, private keys will be archived to the Key Archival. To understand the user key recovery, I recommend you this topic.

Перевыпуск ключей ЭЦП

Для того чтобы подать заявку на выпуск новых регистрационных свидетельств, пройдите по вкладке «Мои ключи ЭЦП» — «Перевыпуск ключей ЭЦП».

Примечание: при подаче заявки с личного кабинета, Первый руководитель подписывает данную заявку своими действующими ключами ЭЦП. Подтверждать заявку в Центре регистрации, нет необходимости. Количество подаваемых заявок из личного кабинета ограничено (50 заявок в течение 30 дней).

Перед подтверждением заявки Вам необходимо настроить ключ, для этого выберите «Хранилище ключей»: Персональный компьютер, eToken PRO (Java, 72K), JaCarta, Kaztoken, AKey. В поле «Путь к хранилищу ключей» укажите папку, в которой находится Ваше регистрационное свидетельство для подписания GOSTNCA и нажмите кнопку «Сохранить».

Далее ознакомьтесь с пользовательским соглашением, и подтвердите ваше согласие.

Ваши данные (ФИО, БИН, ИИН, наименование организации) заполнятся автоматически. Заполните поле «Населенный пункт» и в случае необходимости получения уведомлений от НУЦ РК, укажите адрес электронной почты.

В поле «Хранилище ключей» укажите тип хранилища: Персональный компьютер, eToken 72K, JaCarta, Kaztoken, AKey.

В случае выбора «Хранилище ключей»: Персональный компьютер, в поле «Путь к хранилищу ключей» необходимо указать папку, в которой будет создан контейнер для хранения Вашего закрытого ключа. После подтверждения заявки оператором ЦР в неё будут установлены регистрационные свидетельства.

Внимание! Хранилище «Персональный компьютер» является небезопасным. Рекомендуем использовать защищенный носитель ключевой информации для снижения риска компрометации ключей ЭЦП

Для этого нажмите кнопку «Обзор» и выберите папку либо устройство для хранения Ваших ключей ЭЦП.

После выбора места хранения нажмите кнопку «Открыть». Далее нажмите кнопку «Подать заявку». В новом окне «Редактирования заявки», выберите статус «Заявка подписана пользователем».

Далее Вам необходимо подтвердить корректность данных указанных в заявке, поставив галочку.

На следующей странице Вам представится информация о статусе Вашей заявки. «Выпущены регистрационные свидетельства (сертификаты) по заявке», программа автоматически укажет ранее выбранное Вами место хранения закрытых ключей. Далее установите сертификаты.

Перевыпуск ключей ЭЦП успешно завершен.

Design

Public key cryptography is a cryptographic technique that enables entities to securely communicate on an insecure public network, and reliably verify the identity of an entity via digital signatures.

A public key infrastructure (PKI) is a system for the creation, storage, and distribution of digital certificates which are used to verify that a particular public key belongs to a certain entity. The PKI creates digital certificates which map public keys to entities, securely stores these certificates in a central repository and revokes them if needed.

A PKI consists of:

• A certificate authority (CA) that stores, issues and signs the digital certificates;
• A registration authority (RA) which verifies the identity of entities requesting their digital certificates to be stored at the CA;
• A central directory—i.e., a secure location in which keys are stored and indexed;
• A certificate management system managing things like the access to stored certificates or the delivery of the certificates to be issued;
• A certificate policy stating the PKI’s requirements concerning its procedures. Its purpose is to allow outsiders to analyze the PKI’s trustworthiness.

Digital Certificate

For analogy, a certificate can be considered as the ID card issued to the person. People use ID cards such as a driver’s license, passport to prove their identity. A digital certificate does the same basic thing in the electronic world, but with one difference.

Digital Certificates are not only issued to people but they can be issued to computers, software packages or anything else that need to prove the identity in the electronic world.

• Digital certificates are based on the ITU standard X.509 which defines a standard certificate format for public key certificates and certification validation. Hence digital certificates are sometimes also referred to as X.509 certificates.

  Public key pertaining to the user client is stored in digital certificates by The Certification Authority (CA) along with other relevant information such as client information, expiration date, usage, issuer etc.

• CA digitally signs this entire information and includes digital signature in the certificate.

• Anyone who needs the assurance about the public key and associated information of client, he carries out the signature validation process using CA’s public key. Successful validation assures that the public key given in the certificate belongs to the person whose details are given in the certificate.

The process of obtaining Digital Certificate by a person/entity is depicted in the following illustration.

As shown in the illustration, the CA accepts the application from a client to certify his public key. The CA, after duly verifying identity of client, issues a digital certificate to that client.

Criticism

Some argue that purchasing certificates for securing websites by SSL and securing software by code signing is a costly venture for small businesses. However, the emergence of free alternatives such as Let’s Encrypt, has changed this. HTTP/2, the latest version of HTTP protocol allows unsecured connections in theory, in practice major browser companies have made it clear that they would support this protocol only over a PKI secured TLS connection. Web browser implementation of HTTP/2 including Edge from Microsoft, Chrome from Google, Firefox from Mozilla, and Opera supports HTTP/2 only over TLS by using ALPN extension of TLS protocol. This would mean that to get the speed benefits of HTTP/2, website owners would be forced to purchase SSL certificates controlled by corporations.

Current web browsers carry pre-installed intermediary certificates issued and signed by a Certificate Authority. This means browsers need to carry a large number of different certificate providers, increasing the risk of a key compromise[citation needed].

When a key is known to be compromised it could be fixed by revoking the certificate, but such a compromise is not easily detectable and can be a huge security breach. Browsers have to issue a security patch to revoke intermediary certificates issued by a compromised root certificate authority. Some practical security vulnerabilities of X.509 certificates and known cases where keys were stolen from a major Certificate Authority are listed below.

• See
• See
• See

Components of PKI

A Public Key Infrastructure implementation typically consists of following 4 elements:

• A Certificate Authority (CA), which acts as “the root of trust”. The CA issues digital certificates representing the ownership of a public key.
• A Registration Authority (RA), also known sometimes as a subordinate CA, which validates the registration of a digital certificate with a public key. Every time when a request for verification of any digital certificate is made, it goes to RA. The RA then decides whether to authenticate the request or not. RA can also issue certificates for specific use cases depending on the permissions granted to it by CA.
• A certificate database, which issues and revokes certificates.
• And finally, a certificate store where issued certificates are stored with their private keys.

Blending in PKI infrastructure

• Self-signed: the default option, PKI uses a self-signed CA certificate
• External CA: when --external-ca option is used, ipa-server-install produces a certificate certificate request for it’s CA certificate so that it can be properly chained in existing PKI infrastructure.
• CA-less: FreeIPA with CA-less configuration does not set up PKI server at all and only accepts signed certificates for the Web Server and Directory Server components.

Chaining with Windows Server 2012

This can be worked around by signing the certificate via command line utility certreq.exe using following command:

certreq.exe -submit -attrib "CertificateTemplate:SubCA" ipa.csr mkad2012-ipa-ca

Requesting a new certificate

Certificate can be requested either manually by a privileged user who is then able to request it for any chosen hostname (cn) or by the host itself, which can request a certificate for it’s own hostname, ideally via Certmonger.

Manual certificate requests

On a FreeIPA client, run the following commands to request a new certificate which can then be used by a mod_nss Apache module to secure a HTTPS traffic with a certificate published by FreeIPA CA:

1. Create a Kerberos principal for the service that will use/own the certificate:

   # ipa service-add HTTP/`hostname`

2. Create NSS certificate database which will hold the certificate

   # mkdir -p /etc/httpd/nssdb; cd /etc/httpd/nssdb

   # certutil -N -d .

3. Set correct directory ownership and SELinux context (on platforms running on SELinux):

   # chown :apache *.db && chmod g+rw *.db

   
   # semanage fcontext -a -t cert_t "/etc/httpd/nssdb(/.*)?"
   # restorecon -FvvR /etc/httpd/nssdb/

4. Add FreeIPA CA certificate

   # certutil -A -d . -n 'EXAMPLE.COM IPA CA' -t CT,, -a < /etc/ipa/ca.crt

5. Request a signed certificate for the service

   # certutil -R -d . -a -g 2048 -s CN=`hostname`,O=EXAMPLE.COM > web.csr

   
   # ipa cert-request --principal=HTTP/`hostname` web.csr
   # ipa cert-show $SERIAL_NUMBER --out=web.crt
   # certutil -A -d . -n Server-Cert -t u,u,u -i web.crt

6. Optionally show and validate the certificate

   # certutil -L -d . -n Server-Cert

   # certutil -V -u V -d . -n Server-Cert

Obviously, this procedure has a disadvantage of the certificate not being tracked by the Certmonger and thus not being automatically renewed before it’s validity ends.

Automated certificate requests with Certmonger

To request a new (HTTP) certificate for a FreeIPA client, the procedure is slightly easier. The biggest benefit is that the certificate is automatically renewed before the validation ends:

1. Create a Kerberos principal for the service that will use/own the certificate:

   # ipa service-add HTTP/`hostname`

2. Create NSS certificate database which will hold the certificate

   # mkdir -p /etc/httpd/nssdb; cd /etc/httpd/nssdb

   # certutil -N -d .

3. In case you created the database with a PIN (asked interactively in the previous step), remember it or store it to text file:

   # echo $PIN > pwdfile.txt

   # chmod o-rwx pwdfile.txt

4. Set correct directory ownership and SELinux context (on platforms running on SELinux):

   # chown :apache *.db && chmod g+rw *.db

   
   # semanage fcontext -a -t cert_t "/etc/httpd/nssdb(/.*)?"
   # restorecon -FvvR /etc/httpd/nssdb/

5. Add FreeIPA CA certificate

   # certutil -A -d . -n 'EXAMPLE.COM IPA CA' -t CT,, -a < /etc/ipa/ca.crt

6. Request a signed certificate for the service and see the entry in Certmonger. In case you created a NSS database with a PIN (see the step 3.), use -P $PIN or -p /etc/httpd/nssdb/pwdfile.txt option to tell certmonger about it:

   # ipa-getcert request -d /etc/httpd/nssdb -n Server-Cert -K HTTP/`hostname` -N CN=`hostname`,O=EXAMPLE.COM -g 2048 -p /etc/httpd/nssdb/pwdfile.txt

   SAN names: in FreeIPA 4.0 and later, you can add optional SAN DNS names to your request with -D. Note that you need to first create respective host or service objects and configure that given host can manage them with service-add-host or host-add-managedby command. These objects are being verified when FreeIPA cert-req command authorizes the SAN names.

7. Check the status of the requested certificate. If request succeeded, it will be in a MONITORING state:

   # ipa-getcert list -d /etc/httpd/nssdb/ -n Server-Cert

8. Optionally show and validate the certificate

   # certutil -L -d . -n Server-Cert

   # certutil -V -u V -d . -n Server-Cert

Cистемные требования

Системные требования исходят из среды выполнения для Java 8. Более подробные описания указаны по ссылкам:

• Системные требования к Java 8
• Oracle JDK 8 and JRE 8 Certified System Configurations
  Contents

Для ОС Windows и Mac OS X не требуется устанавливать Java, так как среда выполнения поставляется вместе с NCALayer.

Linux

Oracle Java SE Runtime Environment 8 или OpenJDK 8 + OpenJFX 8 (например, для семейства Debian — пакет openjfx).

В случае отсутствия необходимой версии JRE в официальном репозитории ОС, рекомендуется скачать и установить Liberica JRE 8. При этом необходимо указать переменную JAVA_HOME среды окружения. Например:

Пространство на диске: не менее 200 МБ

Браузеры

Все популярные браузеры с поддержкой протокола WebSocket — Firefox, Safari, IE 11, основанные на Chromium (Chrome, Opera, Yandex, Vivaldi и т.д.)

Public Key Cryptographic Standards

Public Key Cryptographic Standards (PKCS) are a set a “standards” to describe some cryptographic process. I have written the word standard between quote because it is not really standards. PKCS specifications are published by RSA Security (belong to EMC since 2006) company and only a few of them are taken up by the normalization agency.

PKCS specifications are numbered after a hash. For example the DH key exchange is called PKCS#3. In this part I will not present you all PKCS specification. Only the most important to understand PKI are described. For more information, you can visit http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-rsa-cryptography-standard.htm.

PKCS#7 (RFC 2315)

PKCS#7 is standardized by the IETF as RFC 2315. This standard defines syntax for cryptographic message either to sign or encrypt data. This standard also describes how to respond to a PKCS#10 message.

PKCS#7 certificate is based on PKCS#7 specification and it is a X.509 certificate as described previously. PKCS#7 certificates can have these file extensions: .p7b, .p7c, .der, .cer, .crt or .pem. On Microsoft environment, .cer and .der are mainly used.

PKCS#10 (RFC 2986)

PKCS#10 is standardized by the IETF as RFC 2986. This standard describes the certificate request process. Usually this request is sent to a certificate authority. The CA can sign the request and so issue a PKCS#7 certificate. On Microsoft environment, the certificate request file has .req, .csr or .txt extension. On other environment, this file can be found with .p10 extension.

The certificate request contains the identity of the issuer and his public key. The certificate request is signed by the private key of the issuer.

PKCS#11

PKCS11 is an API for security token such as HSM (Hardware Security Module) or Smartcard. When you plug a smartcard on your Windows, the communication is done across PKCS11 API. Usually this API is added to system when you install the smartcard drivers.

PKCS#12

PKCS#12 specification describes how to store and transport safety private keys, certificates or other sensitive information. PKCS#12 file act as a container usually protected by password. Because PKCS#12 can store certificates, the chain of trust can be included in the file. On Microsoft environment, the PKCS#12 file extension is .pfx. On other environment it can be found as .p12 file.

Выводы

Системы управления ключевыми носителями и цифровыми сертификатами — это решения для централизованного учета, управления и аудита ключевых носителей и цифровых сертификатов, которые позволяют автоматизировать большинство перечисленных операций и значительно снизить нагрузку на администраторов информационных систем, операторов удостоверяющих центров и других сотрудников компании (например, сотрудников Help Desk). Широкое применение методов аутентификации на основе PKI, а также использование защищенных носителей ключевой информации способствуют появлению в инфраструктуре компаний таких решений, как системы управления ключевыми носителями и цифровыми сертификатами.

Из зарубежных производителей систем управления ключевыми носителями и цифровыми сертификатами на российском рынке активно присутствуют Gemalto (SafeNet) и HID Global. В рамках импортозамещения наблюдается рост популярности продуктов российских разработчиков — таких, как «Аванпост», «Аладдин Р.Д.», Indeed ID и «Актив»:

1. Avanpost PKI — предназначен для централизованного управления всеми элементами PKI из единого интерфейса. Сюда входит управление электронными сертификатами, ключевыми носителями, ведение поэкземплярного учета СКЗИ, автоматизация процесса выпуска сертификатов, реализация полного цикла workflow, ведение журналов событий.
2. JaCarta Management System (JMS) — система управления, полноценно поддерживающая новую линейку средств аутентификации и электронной подписи JaCarta, а также смарт-карты и токены SafeNet eToken (в т. ч. модели ГОСТ). Система автоматизирует типовые операции при работе с токенами, позволяет централизованно управлять доступом к корпоративным системам и получать информацию обо всех действиях в отношении средств аутентификации и ЭП. JMS дополнительно обеспечивает соблюдение требований российского законодательства в части учета СКЗИ.
3. Indeed Card Management — система, позволяющая выполнять учет и управление ключевыми носителями, сертификатами и СКЗИ, резервное копирование ключевой информации. Она автоматизирует работу с несколькими УЦ и предоставляет сервис самообслуживания пользователей и возможность использования виртуальной смарт-карты.
4. Рутокен KeyBox — средство администрирования и управления жизненным циклом ключевых носителей (USB-токенов, смарт-карт и других устройств), ориентированное на использование в корпоративных сетях, построенных на технологиях Microsoft Windows. Рутокен KeyBox является системой, обеспечивающей связь между учетными записями пользователей, средствами аутентификации, приложениями и регламентами ИБ (корпоративной политикой безопасности).

Компании Gemalto (SafeNet), HID Global, «Аладдин Р.Д.» и «Актив», помимо систем управления ключевыми носителями и цифровыми сертификатами, также занимаются производством ключевых носителей (USB-токены и смарт-карты). Компании «Аванпост» и Indeed ID самостоятельно не производят ключевые носители, однако поддерживают распространенных в России моделей ключевых носителей токенов, смарт-карт и биометрических считывателей.