ИНТЕГРАЦИЯ С ЕСИА ПРОБЛЕМА СЛОЖНЕЕ ЧЕМ КАЖЕТСЯ

Криптопровайдеры

Де-факто стандартом отрасли является класс криптосредств, известных как криптопровайдеры. Криптопровайдер — это предоставляющая специальный API и специальным образом зарегистрированная в ОС библиотека, которая позволяет расширить список поддерживаемых в ОС криптоалгоритмов.

Следует отметить, что несовершенство предлагаемых MS Windows механизмов расширения вынуждает разработчиков криптопровайдеров дополнительно модифицировать высокоуровневые криптобиблиотеки и приложения MS Windows в процессе их выполнения для того, чтобы «научить» их использовать российские криптоалгоритмы.

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

Высокоуровневые функции обработки сообщений

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

В основе работы данных функций лежит стандарт PKCS #7 (RFC 2315). Более подробно об этом стандарте будет рассказано несколько позднее, а здесь будет сказано лишь о его основных особенностях.

Основу стандарта PKCS #7 составляют способы кодирования и описания различных данных, используемых в криптографических приложениях. Так, предоставляются стандарты по кодированию шифрованных и подписанных сообщений, стандарт кодирования сессионного ключа, стандарт кодирования информации о сертификате и многое другое. Работа со стандартом PKCS #7 реализована на многих платформах, отличных от MS Windows, что позволяет создавать кроссплатформенные приложения. Высокоуровневые функции скрывают многие не очень существенные моменты использования стандарта PKCS #7, благодаря чему упрощается работа с криптографическими данными.

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

Шифрование

Для шифрования используется функция CryptEncryptMessage. Данная функция имеет следующее описание:

В качестве первого параметра данной функции передается указатель на структуру CRYPT_ENCRYPT_MESSAGE_PARA. В полях данной структуры передается информация об используемом для шифрования криптопровайдере, используемом алгоритме и вспомогательная информация, нужная для правильной работы выбранного алгоритма. Параметр cRecipientCert передает количество используемых сертификатов получателей. Сам массив используемых сертификатов получателей передается в параметре rgpRecipientCert.

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

Параметры pbToBeEncrypted и cbToBeEncrypted идентифицируют область обрабатываемых данных. Зашифрованный контент и его размер возвращается через параметры pbEncryptedBlob и pcbEncryptedBlob соответственно.

Пример использования данной функции приведен ниже:

Расшифровывание

Для расшифровывания зашифрованного контента применяется функция CryptDecryptMessage, имеющая следующее описание:

BOOL CryptDecryptMessage(PCRYPT_DECRYPT_MESSAGE_PARA pDecryptPara,
BYTE* pbEncryptedBlob,
DWORD cbEncryptedBlob,
BYTE* pbDecrypted,
DWORD* pcbDecrypted,
PCCERT_CONTEXT* ppXchgCert);

В качестве первого параметра данной функции передается указатель на структуру типа CRYPT_DECRYPT_MESSAGE_PARA. В полях данной структуры передается список хранилищ сертификатов, в которых будет производиться поиск сертификата для импорта сессионного ключа (сертификата обмена). В параметрах pbEncryptedBlob и cbEncryptedBlob передается информация о блоке входных данных, подлежащих расшифровке. В параметрах pbDecrypted и pcbDecrypted передаются принимающий буфер и его размер соответственно. В этот буфер будут помещены расшифровываемые данные. В параметре ppXchgCert возвращается ссылка на контекст сертификата, который был использован для обмена (если эта информация не нужна, то данный параметр должен быть установлен в NULL).

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

Пример использования этой функции приведен ниже:

Цифровая подпись

В отличие от простейшего случая формирования цифровой подписи базовыми функциями в стандарте PKCS предусмотрено существование двух видов цифровой подписи: подпись, совмещенная с подписываемыми данными (attached signature) и подпись, отдельная от данных (detached signature). Функция CryptSignMessage, формирующая оба эти вида подписей, имеет следующее описание:

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

Если флаг fDetachedSignature установлен в false, параметр cToBeSigned всегда должен быть равен 1. Это связано с особенностями реализации низкоуровневых функций работы с криптографическими сообщениями, особенности которых будут рассмотрены позднее.

Параметр rgpbToBeSigned представляет собой массив данных, передаваемых для формирования цифровой подписи. Параметр rgcbToBeSigned представляет собой массив размеров элементов переданного массива данных. Выходное значение функции (цифровая подпись) формируется в параметрах pbSignedBlob и pcbSignedBlob.

Проверка цифровой подписи

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

BOOL CryptVerifyMessageSignature(PCRYPT_VERIFY_MESSAGE_PARA pVerifyPara,
DWORD dwSignerIndex,
BYTE* pbSignedBlob,
DWORD cbSignedBlob,
BYTE* pbDecoded,
DWORD* pcbDecoded,
PCCERT_CONTEXT* ppSignerCert);

В качестве первого параметра данной функции передается указатель на структуру типа CRYPT_VERIFY_MESSAGE_PARA. В полях данной структуры передается информация о контексте криптопровайдера, применяемом для проверки подписи, и ссылке на функцию, с помощью которой находится сертификат подписчика в локальных хранилищах данных. В случае, когда ссылка на данную функцию равна NULL, функция CryptVerifyMessageSignature ищет данный сертификат внутри самой цифровой подписи. Параметр dwSignerIndex задает номер подписчика, для которого необходимо проверить подпись (в одном файле подписи потенциально может быть несколько цифровых подписей от различных подписчиков). Для первого подписчика параметр dwSignerIndex должен быть равным 0. В параметрах pbSignedBlob и cbSignedBlob передается информация о входном блоке данных, подлежащем проверке. В параметрах pbDecoded и pcbDecoded может быть передана информация о блоке памяти, в который помещается раскодированное проверяемое сообщение (для которого, собственно, и была сформирована цифровая подпись). В случае, когда данная информация не нужна, параметры pbDecoded и pcbDecoded должны быть установлены в NULL. В параметре ppSignerCert возвращается двойной указатель на контекст сертификата подписчика.

Пример использования этой функции примерно соответствует примеру для функции CryptVerifyDetachedMessageSignature, приведенному ниже.

Функция, проверяющая отсоединенную от данных цифровую подпись, имеет следующее описание:

Параметры pVerifyPara и dwSignerIndex имеют точно такой же смысл, что и соответствующие параметры функции CryptVerifyMessageSignature. Параметры pbDetachedSignedBlob и cbDetachedSignedBlob описывают область памяти, которая хранит собственно проверяемые данные. Параметр cToBeSigned описывает количество элементов в массивах, передаваемых в параметрах rgpbToBeSigned и rgcbToBeSigned. Параметр rgpbToBeSigned представляет собой массив областей памяти, содержащий в себе данные, для которых проверяется цифровая подпись. Параметр rgcbToBeSigned содержит массив размеров блоков памяти, указанных в параметре rgpbToBeSigned. В параметре ppSignerCert возвращается двойной указатель на контекст сертификата подписчика. Результат проверки (правильна или неправильна цифровая подпись) возвращается как результат выполнения функции CryptVerifyDetachedMessageSignature.

Совмещение цифровой подписи и шифрованных данных

Кроме применения формирования отдельно шифрованного и отдельно подписанного контентов в стандарте PKCS #7 предусмотрено получение контента, который представляет собой цифровую подпись, совмещенную с зашифрованными данными (сначала формируется цифровая подпись открытых данных, затем данные шифруются). Таким образом, собственно проверка данных может быть осуществлена получателем шифрованных данных, для которого они предназначались. Такой способ передачи данных хорош, прежде всего, отсутствием передачи проверяемых данных в открытом виде.

Функция CryptSignAndEncryptMessage, осуществляющая подобную работу в Crypto API, имеет следующее описание:

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

Расшифровывание и проверка совмещенной цифровой подписи и шифрованных данных

Для расшифровывания и проверки совмещенных цифровой подписи и шифрованных данных применяют специальную функцию CryptDecryptAndVerifyMesageSignature, имеющую следующее описание:

BOOL CryptDecryptAndVerifyMesageSignature(PCRYPT_DECRYPT_MESSAGE_PARA pDecryptPara,
PCRYPT_VERIFY_MESSAGE_PARA pVerifyPara,
DWORD dwSignerIndex,
BYTE* pbEncryptedBlob,
DWORD cbEncryptedBlob,
BYTE* pbDecrypted
DWORD* pcbDecrypted,
PCCERT_CONTEXT* ppXchgCert,
PCCERT_CONTEXT* ppSignerCert);

Значения параметров данной функции полностью аналогичны значениям параметров функций CryptDecryptMessage и CryptVerifyMessageSignature. Результат проверки (правильна или неправильна цифровая подпись) получается как результат функции CryptDecryptAndVerifyMessageSignature.

Работа с форматом Base64 (PEM)

Кроме стандарта PKCS #7 достаточно часто можно встретить употребление другого стандарта – PEM (Privacy-Exchanged Mail). Фактически же в данном стандарте применяются два последовательных кодирования: первичное в PKCS #7 и вторичное в Base64. То есть если мы после завершения шифрования высокоуровневой функцией CryptEncryptMessage закодируем полученный результат в кодировке Base64, то полученный результат можно принять за образец применения стандарта PEM.

Работа с Base64 крайне проста и реализована во многих библиотеках. В частности, я бы хотел порекомендовать читателям средства, предоставляемые функциями Base64Encode и Base64Decode. Данные функции объявлены в заголовочном файле библиотеки ATL “atlenc.h”. Работа с данными функциями достаточно проста. Ниже приведен пример использования данных функций.

Всё необходимое

Наш инвентарь для путешествия:

Немного о КриптоПРО CSP +. Net Core 5+

Вот тут и начинаются первые проблемы. На момент написания статьи у КриптоПРО . Net нет поддержки . Net Core 5 и выше. Есть сборка под . Net Core 3.1 но и она выглядит сомнительно. Поэтому было решено поднять сервис для . Net Framework 4.8 который будет использовать средства КриптоПРО CSP для подписания с использованием ЭЦП, а так же проверки ответов от ЕСИА.

Немного о контейнере закрытого ключа и сертификата

Когда мы начинали делать эту задачу у нас была КЭП на токене, но как оказалось на нём был неэкспортируемый контейнер. Скажу сразу, что экспортировать контейнер с такого токена запрещено ФНС. Поэтому необходимо заранее получить токен на имя сотрудника с экспортируемым контейнером. Так как его необходимо будет скопировать на сервер.

Привязка закрытого ключа к сертификату

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

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

Пример кода для привязки закрытого ключа к сертификату:

Успехов в разработке крипто-провайдера!

Локальные прокси

Основным принципом действия локального прокси является прием незащищенного соединения от приложения, установка TLS-туннеля с удаленным сервером и передача «прикладного уровня» между приложением и удаленным сервером по этому туннелю.

Некоторые локальные прокси кроме того дополнены механизмом ЭЦП специальным образом промаркированных WEB-форм (Inter-PRO, МагПро КриптоТуннель). Существуют локальные прокси, которые предоставляют для браузера WEB API ЭЦП (систему HTTP-запросов и ответов, аналогичных программному API криптобиблиотеки).

Предисловие

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

Эта статья скорее больше актуализация и дополнение информации из этой статьи.

Соберем проект с поддержкой ГОСТ Р 34. 11-2012 256 bit

Гайд разделен на несколько этапов. Основная инструкция по сборке опубликована вместе с репозиторием DotnetCoreSampleProject — периодически я буду на нее ссылаться.

Первым делом создадим новую папку

Инструкция делится на 2 этапа — мне пришлось выполнить оба, чтобы решение заработало. В папку добавьте подпапки .
untime и .packages

I — Сборка проекта без сборки corefx для Windows

На этом месте у вас должно получиться решение, которое поддерживает ГОСТ Р 34.11-2012 256 bit.

Криптографические решения. От криптопровайдеров до браузерных плагинов

Время на прочтение

Производители средств криптографической защиты информации (СКЗИ) предлагают различные механизмы для интеграции криптосредств в информационные системы. Существуют решения, ориентированные на поддержку систем с Web-интерфейсом, мобильных и десктопных приложений, серверных компонентов. С КЗИ интегрируются в приложения Microsoft и в продукты Open Source, обеспечивают поддержку различных прикладных протоколов и форматов электронной подписи.

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

В данном материале сделана попытка классифицировать средства криптографической защиты информации.

Классификация построена на основе:

Кроме того, показаны способы интеграции СКЗИ с Web-приложениями и возможность его использования на мобильных платформах

Общая схема классификации приведена в таблице:

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

Дополнительная информация

Эта статья опубликована в журнале
RSDN Magazine

#3-2006. Информацию о журнале можно найти здесь

Функция I_CryptGetDefaultCryptProvider из crypt32. dll

По непонятной для меня причине Windows часто не пытается искать нужный крипто-провайдер по идентификатору алгоритма, с которым требуется работать. В таких случаях она просто вызывает недокументированную функцию I_CryptGetDefaultCryptProvider, и если тот провайдер, который вернула эта функция, не умеет работать с данным алгоритмом, то процесс завершается с ошибкой. Так происходит, например, при разборе в Internet Explorer ответа PKCS#7 в сценарии с запросом сертификата на тестовом УЦ.

HCRYPTPROV WINAPI I_CryptGetDefaultCryptProv(ALG_ID algid);

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

Довольно спорное предложение – заниматься изменением системных библиотек Windows. – прим.ред.

Обсуждение способов замены функций в системной dll выходит далеко за рамки данной статьи. Могу лишь, как один из способов решения, предложить библиотеку Microsoft Detours:

Создание криптографического провайдера для Windows

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

Только после выполнения этих действий провайдер нормально интегрируется в систему, и вы сможете, например, при помощи вашего провайдера генерировать сертификаты с помощью стандартного компонента ОС Windows – Сertification services.

Рассмотрим подробнее каждый из упомянутых выше шагов, предполагая при этом, что библиотека с CSP уже имеется, и что все функции провайдера работают корректно.

Это вообще законно?

С удовольствием узнаю ваше мнение в комментариях.