Создание запроса на сертификат, хранимый в мобильном приложении | КриптоПро DSS

Внимание!

Символ “.” в конце получившегося значения является обязательным.

Генерация запроса на сертификат на iis 8 | настройка серверов windows и linux

Зачем нам нужны сертификаты

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

Все используемые иконки созданы Vitaly Gorbachev на сайте Flaticon

К сожалению, поскольку канал является открытым, любой при желании может прослушивать и даже изменять сообщения, которыми обмениваются Алиса и Боб:

Эта ситуация называется атакой “Человек посередине” (Man in the Middle).

Как Алисе и Бобу защититься от этой опасности? На помощь приходит шифрование. Наиболее древними и распространёнными системами шифрования являются системы с симметричным ключом. В этом случае Алиса и Боб должны оба обладать абсолютно одинаковым (поэтому он и называется симметричным) ключом, который неизвестен никому более.

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

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

Что же делать? На помощь приходит асимметричное шифрование или шифрование с открытым ключом. Суть его состоит в следующем. Пусть Алиса хочет передать сообщение Бобу. Боб теперь генерирует не один, а два ключа – открытый и закрытый.

Открытый ключ не представляет секрета. Его Боб свободно раздаёт всем желающим общаться с ним. А вот закрытый ключ Боб хранит в тайне и не показывает никому, даже Алисе. Хитрость заключается в том, что если зашифровать сообщение с помощью открытого ключа, то расшифровать его можно только с помощью закрытого ключа. И наоборот, сообщение, зашифрованное закрытым ключом, расшифровывается открытым ключом.

Теперь ясно, как Алиса и Боб должны действовать. Каждый из них генерирует свои открытый и закрытый ключи. Затем они обмениваются открытыми ключами через их канал связи. Поскольку открытые ключи не представляют собой секрета, их можно передавать через открытые каналы.

Закрытые ключи они хранят у себя в тайне. Пусть теперь Боб хочет послать сообщение Алисе. Он шифрует его открытым ключом Алисы и посылает сообщение по каналу. Расшифровать сообщение может только обладатель закрытого ключа, т. е. только Алиса. Хакер этого сделать не может.

На самом деле всё чуть сложнее. Дело в том, что шифрование с открытым ключом работает намного медленнее симметричного шифрования. Шифровать таким способом большие объёмы данных представляется неудобным. Поэтому, когда Боб хочет общаться с Алисой, он поступает следующим образом.

Он генерирует новый ключ для системы симметричного шифрования (его обычно называют сеансовым ключом). Потом он шифрует этот сеансовый ключ открытым ключом Алисы и посылает его ей. Теперь у Алисы и Боба есть ключ симметричного шифрования, который неизвестен больше никому. С этого момента они свободно могут пользоваться быстрыми алгоритмами симметричного шифрования.

Казалось бы, проблема решена. Но всё не так просто. Хакеру, контролирующему канал связи, есть что нам сказать. Проблема снова кроется в механизме распространения ключей, но теперь уже открытых ключей. Давайте посмотрим, что может произойти.

Пусть Алиса сгенерировала пару из открытого и закрытого ключа. Теперь она хочет передать свой открытый ключ Бобу. Она посылает этот ключ по каналу передачи данных. В этот момент хакер перехватывает этот ключ, не давая ему достичь Боба. Вместо этого хакер генерирует свою пару из открытого и закрытого ключа.

Да, теперь у нас фигурирует масса различных ключей. Давайте разберёмся, как всё это работает. Пусть Боб хочет послать сообщение Алисе. Он шифрует его открытым ключом, который, как он думает, принадлежит Алисе. Но на самом деле ключ этот принадлежит хакеру.

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

Что же можно сделать, чтобы избежать подобного развития ситуации? И здесь мы подбираемся вплотную к сертификатам. Представьте себе, что Алиса распространяет по открытому каналу не просто свой открытый ключ, а ключ с прикреплённой к нему биркой, на которой написано, что этот ключ принадлежит Алисе. На бирке так же содержится подпись некоего уважаемого лица, которому доверяют как Алиса, так и Боб:

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

Можно считать, что ключ с такой биркой и представляют собой сертификат. Но как на самом деле он устроен в цифровом мире?

В цифровом мире всё, что угодно, можно представить в виде последовательности бит (нулей и единиц). Это относится и к нашим ключам. Что же нужно сделать, чтобы создать цифровую подпись для такой последовательности бит? Такая подпись должна обладать следующими свойствами:

Как же создать такую подпись? Можно поступить так. Сначала для нашей последовательности бит считается так называемый хеш. Вы передаёте вашу последовательность бит на вход некоторой функции (называемой функцией хеширования), и она возвращает вам другую последовательность бит, но уже очень короткую. Эта выходная последовательность и называется хешем. Все современные функции хеширования обладают следующими свойствами:

• Для входной последовательности любой длины они всегда генерируют хеш одной и той же длины. Обычно эта длина не превышает нескольких десятков байт. Помните, что наша подпись должна быть короткой. Именно это свойство хеша и делает его удобным для использования в подписи.

• Зная только хеш, вы не можете сказать, из какой последовательности бит он был получен. Т. е. восстановление этой последовательности из хеша невозможно.

• Если у вас есть значение хеша некоторой последовательности бит, то вам очень трудно указать другую последовательность бит, дающую такой же хеш. Действительно, различных файлов длиной в 1 ГБайт очень много. Но для каждого из них можно посчитать хеш длиной, скажем, всего в 32 байта. Различных последовательностей бит длиной в 32 байта намного меньше, чем различных файлов длиной в 1 ГБайт. Это значит, что обязательно будут существовать два различных файла длиной в 1 ГБайт, дающие один и тот же хеш. И тем не менее, зная один такой файл и его хеш, очень сложно узнать другой файл, дающий такой же хеш.

С хешами разобрались. Но, к сожалению, сам по себе хеш не подходит на роль подписи. Да, он короткий, но его может посчитать любой. Хакер может сам вычислить хеш для своего открытого ключа, ничто не препятствует ему сделать это. Как же нам сделать хеш устойчивым к подделке? Здесь на помощь нам снова приходит шифрование с открытым ключом.

Помните, я говорил, что и Алиса, и Боб должны доверять подписи, которая стоит на бирке ключа. Пусть Алиса и Боб доверяют подписи Очень Важного Человека. Как же Очень Важный Человек может подписать ключ? Он генерирует свою пару из открытого и закрытого ключа.

Открытый ключ он передаёт Алисе и Бобу, а закрытый хранит у себя. Когда ему нужно подписать открытый ключ Алисы, он поступает так. Сначала он считает хеш ключа Алисы, а затем шифрует этот хеш своим закрытым ключом. Именно хеш, зашифрованный закрытым ключом Очень Важного Человека (его обычно называют certificate authority) и является подписью. Поскольку никто не знает закрытого ключа Очень Важного Человека, то никто и не может подделать его подпись.

С созданием подписи мы разобрались. Осталось понять, как проверить её подлинность, как проверить то, что подпись не была подделана. Итак, Боб получил некоторый ключ, на бирке которого написано, что это открытый ключ Алисы. А также там присутствует подпись вроде бы Очень Важного Человека.

Как это проверить? Во-первых, Боб вычисляет хеш полученного открытого ключа. Помните, что это может сделать любой. Затем Боб расшифровывает подпись с помощью открытого ключа Очень Важного Человека. Мы помним, что подпись представляет собой тот же зашифрованный хеш.

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

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

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

Однако в нашей строгой схеме всё ещё существует одна брешь. Надеюсь, вы уже поняли к чему я веду. А каким образом Алиса и Боб получают открытый ключ Очень Важного Человека? Ведь если хакер сможет подсунуть им вместо настоящего ключа свой ключ, то всё пропало.

Ну конечно же открытый ключ Очень Важного Человека распространяется так же с помощью сертификата, но теперь уже подписанного Очень-Очень Важным Человеком. Хм… А как же распространяется открытый ключ Очень-Очень Важного Человека? Ну конечно же тоже сертификатом. Ну вы поняли… там сертификаты до самого дна.

Но шутки в сторону. Действительно, сертификат Алисы может быть подписан сертификатом Очень Важного Человека, а тот – сертификатом Очень-Очень Важного Человека. Это называется цепочкой доверия. Но эта цепочка не бесконечна. Обычно она заканчивается корневым сертификатом.

Этот сертификат никем не подписан, а точнее, он подписан сам собой (self-signed certificate). Обычно корневые сертификаты принадлежат очень надёжным компаниям, которые, собственно, и занимаются тем, что подписывают другие сертификаты с помощью своих корневых сертификатов.

Раньше эти компании брали деньги за подписывание сертификатов. Теперь появились сервисы типа Let’s Encrypt, которые делают это бесплатно. Я думаю, что многие большие компании осознали, что лучше предоставлять сертификаты бесплатно и тем самым сделать Интернет более защищённым пространством, нежели иметь массу слабо защищённых сайтов, которые могут быть взломаны и использованы как площадки для атаки на эти же большие компании.

Но вернёмся к сертификатам. Осталось рассмотреть последний вопрос. Почему же мы доверяем корневым сертификатам? Что мешает хакеру подменить их? А всё дело в способе их доставки на компьютеры Боба и Алисы. Дело в том, что основные корневые сертификаты не распространяются по открытому каналу, а устанавливаются вместе с операционной системой. Недавно некоторые браузеры так же стали устанавливаться со своим набором доверенных сертификатов.

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

Как использовать сертификаты в .net коде

Итак, у нас есть Web-сервер, написанный на ASP.NET Core. И мы хотим защитить его созданным нами сертификатом. Сперва этот сертификат нужно получить в коде нашего сервера. Здесь есть два варианта.

Первый вариант – получение сертификата из PFX-файла. Этот вариант применяется, если у вас есть файл сертификата, который вы устанавливали в хранилище доверенных сертификатов. Тогда получить сертификат можно так:

var certificate = new X509Certificate2(
    "certificateForServerAuthorization.pfx",
    "p@ssw0rd"
);

Здесь certificateForServerAuthorization.pfx – имя файла сертификата, а p@ssw0rd – пароль, который вы использовали для его защиты.

Но не всегда файл сертификата доступен вам. В таком случае сертификат можно взять напрямую из хранилища:

Настройка сервиса подписи

Для поддержки сертификатов и ключей, хранимых в мобильном приложении, в Веб-интерфейсе DSS необходимо:

• Добавить криптопровайдер типа Lite

 Add-DssCryptoProvider  -ProviderName "Crypto-Pro GOST R 34.10-2021 Cryptographic Service Provider" -ProviderType 80 -TypeId Lite

• Задать режим подписи Сервиса Подписи: подпись хэш-значения, подпись документа.

Set-DssProperties -ClientSignFullDocRequired $true

• Дополнительно можно настроить отправку Callback о событии подписи запроса на сертификат в МП.

Данная возможность может быть полезна для автоматизации процесса выпуска сертификата.
Прикладная система через callback может быть оповещена о том, что пользователь подписал запрос на сертификат,
и запрос на сертификат может быть передан в УЦ для обработки.

Регистрация callback приведена в статье Оповещения о событиях инициализации мобильного приложения.

Приложение

В своей работе я использовал следующие материалы:

Исходный код для статьи можно найти на GitHub.

Примеры запросов

Пример запроса с указанием различительного имени в строковом представлении:

Примечание

Параметр ClientSignFullDocRequired определяет тип данных, которые будут
передаваться в МП для подписи.

Если ClientSignFullDocRequired = $false, в МП передаётся только хэш-значение документа.
В данном режиме поддерживаются все форматы подписи.

Если ClientSignFullDocRequired = $true, в МП передаётся документ.
В данном режиме поддерживаются следующие форматы подписи: CMS (CAdES-BES, CAdES-T, CAdES-XLT1), XMLDSig, Необработанная подпись.

Создание запроса на сертификат

Параметры выпуска запроса на сертификат можно получить из политики Сервиса Подписи (метод /policy).
Политика Сервиса Подписи содержит:

• список параметров Удостоверяющих Центров, подключенных к DSS;
• список криптопровайдеров, подключенных к DSS.

Каждый элемент списка параметров УЦ содержит:

• Идентификатор УЦ
• Тип УЦ
• Шаблон различительного имени (Distinguished Name)
• Список шаблонов сертификатов
• Отображаемое имя

В интерфейсе интегрируемой системы должна быть возможность выбора Удостоверяющего Центра, для которого будет создан запрос на сертификат.
Для каждого Удостоверяющего Центра Сервис Подписи передаёт отображаемое имя (DSSCAPolicy -> Name), которое может быть показано пользователю.

Для выбранного пользователем Удостоверяющего Центра в интерфейсе интегрируемой системы должна отображаться форма для заполнения идентифицирующих данных.
Форма составляется в соответстии с шаблоном имени (DSSCAPolicy -> NamePolicy). У каждого компонента имени в шаблоне есть отображаемое имя (Name), строковый идентификатор (StringIdentifier)
и требование к заполнению (IsRequired).

Также на форме создания запроса должен быть отображен спискок шаблонов сертификатов (EkuTemplates). Каждый шаблон сертификата имеет отображаемое имя.

Если политика Сервиса Подписи содержит более одного криптопровайдера, необходимо предоставить пользователю возможность выбора.

Данные с формы передаются в метод /requests для создания запроса на сертификат:

• Идентификатор Удостоверяющего Центра
• Различительное имя
• Шаблон сертификата
• ПИН-код на закрытый ключ (опционально)
• Идентификатор криптопровайдера (опционально)

Данные передаются в структуре CertificateRequest.

Идентификатор Удостоверяющего Центра (AuthorityId) является константой. Он может быть получен от Администратора DSS и зафиксирован в настройках интегрируемой системы.

Различительное имя может быть передано в двух форматах:

• Список пар oid:value (DistinguishedName)
• Строковое представление (RawDistinguishedName)

Объектные идентификаторы (OID) компонентов имени указаны в шаблоне имени.

Шаблон сертификата представляет собой набор объектных идентификаторов, которые попадут в расширение Enhanced Key Usage (EKU) запроса на сертификат, или
идентификатор шаблона сертификата КриптоПро УЦ 2.0, который попадёт в расширение Certificate Template (1.3.6.1.4.1.311.21.7).

Шаблон передаётся через разные поля запроса на сертификат в зависимости от типа:

• Enhanced key usage – передаётся в дополнительных параметрах запроса Parameters в ключе EkuString в формате oid1,oid2,…,oidN.

• Certificate Template – передаётся в параметре Template запроса на сертификат.

Идентификатор криптопровайдера должен быть задан, если в Политике Сервиса Подписи доступно более одного криптопровайдера.
Идентификатор криптопровайдера (DSSCSPPolicy -> GroupId) передаётся в дополнительных параметрах запроса в ключе GroupId

Создание запроса на сертификат с подтверждением при помощи вторичной аутентификации

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

При этом в массиве параметров транзакции метода /transactions
должны быть отображены следующие поля запроса на сертификат:

Управление сертификатами пользователя

С точки зрения API DSS управление сертификатами и запросами на сертификат не меняется.
Получение списка сертификатов и запросов, удаление сертификатов и запросов, аннулирование сертификатов, загрузка содержимого сертификата
и запроса на сертификат осуществляется через действующие конечные точки – /certificates, /request.

Заключение

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