TSP, OSCP и CSC для высокоточного сверления

TSP, OSCP и CSC для высокоточного сверления Электронная цифровая подпись

База знаний: КриптоПро CSP для Windows

КриптоПро CSP и Windows 11Опубликовано Наталья Мовчан on 2021-10-07 13:21

На текущий момент рекомендуется использовать для работы на Windows 11 КриптоПро CSP 5. 0 R2 и выше. Для работы с сайтами по TLS с ГОСТ в браузере Microsoft Edge воспользуйтесь инструкцией. Возможная проблема установки КриптоПро CSP описана тут. (50 плюсик(ов)) Класс! Не очень 🙁

Обновления Windows от мая 2022 г. могут сломать КриптоПро. NET.

Для Windows Server 2019:

  • 2022-05 Накопительное обновление .NET Framework 3.5, 4.7.2 и 4.8 для Windows Server 2019 для x64 систем (KB5013868);
  • May 10, 2022-KB5013626 Cumulative Update for .NET Framework 3.5 and 4.8 for Windows 10, version 1809 and Windows Server, version 2019.

Для других ОС номер KB может быть другим, но в названии должно быть что-то про «2022-05» и «. NET Framework».

Как следствие не работает ГОСТ-криптография, в т. могут не работать компоненты DSS (Сервис подписи, Сервис Аналитики и др.

Одна из ошибок (или Warning) в журнале Приложений:

The certificate key algorithm is not supported.

Необходимо обновить КриптоПро. NET до последней сборки:

КриптоПро. NET 1. 8174. 2 от 19. 2022

В связи с переходом на Linux возникла необходимость переноса одной из наших серверных систем написанной на C# в Mono. Система работает с усиленными ЭЦП, поэтому одной из поставленных перед нами задач была проверка работоспособности ГОСТовых сертификатов от КриптоПро в mono. Сам КриптоПро уже довольно давно реализовал CSP под Linux, но первая же попытка использования показала, что нативные классы криптографии Mono (аналогичные тем, что есть в базовом. Net — X509Store, X509Certificate2 и проч. ) не только не работают с ГОСТовыми ключами, они даже не видят их в своих хранилищах. В силу этого работу с криптографией пришлось подключать напрямую через библиотеки КриптоПро.

Андрей *
Оставлено
:
4 октября 2021 г. 17:08:52(UTC)

Здравствуйте. Установите КриптоПро. NET SDK – там есть примеры. Program Files (x86)Crypto Pro. NET SDKExamplesпример:simple. zipCMScsSingleSigner

Dmitriy PRO
Оставлено
:
5 октября 2021 г. 23:58:43(UTC)

Спасибо, все получилось!В итоге сам КриптоПро. NET не понадобился

Приглашаем всех 6 сентября 2022 года в 11:00 (МСК) принять участие в вебинаре “Особенности реализации требований приказа ФАПСИ №152 по учёту СКЗИ”, который совместно проведут компании КриптоПро и Spacebit.

В ходе мероприятия эксперты рассмотрят вопросы нормативного регулирования учета СКЗИ и выполнения соответствующих требований. Отдельное внимание будет уделено возможностям СКЗИ и особенностям их практического применения.

  • Разбор основных требований приказа ФАПСИ №152 по учету СКЗИ;
  • Демонстрация возможностей системы X-Control по реализации требований приказа ФАПСИ №152;
  • Обзор возможностей СКЗИ КриптоПро CSP 5.0;
  • Текущий статус по сертификации различных версий КриптоПро CSP и КриптоПро УЦ.

Участие в мероприятии бесплатное, необходима регистрация.

Подключение в коде

Анализ методов библиотек криптографии оказался удачным, т. КриптоПро реализовало библиотеку «libcapi20. so» которая полностью мимикрирует под стандартные библиотеки Windows шифрования — «crypt32. dll» и «advapi32. dll». Возможно, конечно, не целиком, но все необходимые методы для работы с криптографии там в наличии, и почти все работают.

Поэтому формируем два статических класса «WCryptoAPI» и «LCryptoAPI» каждый из которых будет импортировать необходимый набор методов следующим образом:

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

А затем формируем статический класс «UCryptoAPI» который в зависимости от системы будет вызывать метод одного из двух классов:

Таким образом используя методы класса UCryptoAPI можно реализовывать почти единый код под обе системы.

Поиск сертификата

Работа с криптографией обычно начинается с поиска сертификата, для этого в crypt32. dll имеется два метода CertOpenStore (открывает указанное хранилище сертификатов) и простой CertOpenSystemStore (открывает личные сертификаты пользователя). В силу того, что работа с сертификатами не ограничивается только личными сертификатами пользователя подключаем первый:

Поиск происходит в несколько этапов:

  • открытие хранилища;
  • формирование структуры данных по которым ищем;
  • поиск сертификата;
  • если требуется, то проверка сертификата (описана в отдельном разделе);

В ходе поиска сертификатов есть несколько тонких моментов.

КриптоПро в Linux работает с ANSI строками, а в Windows с UTF8, поэтому:

  • передавая строку для поиска (например, по имени Subject) ее необходимо преобразовывать в набор байт различными кодировками;
  • для всех констант криптования, у которых есть вариация по типу строки (например, CERT_FIND_SUBJECT_STR_A и CERT_FIND_SUBJECT_STR_W) в Windows необходимо выбирать *_W, а в Linux *_A;

Метод MapX509StoreFlags можно взять напрямую из исходников Microsoft без изменений, он просто формирует итоговую маску исходя из. Net флагов.

Значение по которому происходит поиск зависит от типа поиска (сверяйтесь с MSDN для CertFindCertificateInStore), в примере приведены два самых часто используемых варианта — для строкового формата (имена Subject, Issuer и проч) и бинарного (отпечаток, серийный номер).

Процесс создания сертификата из IntPtr в Windows и в Linux сильно отличается. Windows создаст сертификат простым способом:

в Linux же приходиться создавать сертификат в два этапа:

В дальнейшем нам для работы потребуется доступ к hCert, и его надо бы сохранить в объекте сертификата. В Windows его позже можно достать из свойства Handle, однако Linux преобразует структуру CERT_CONTEXT, лежащую по ссылке hCert, в ссылку на структуру x509_st (OpenSSL) и именно ее прописывает в Handle. Поэтому стоит создать наследника от X509Certificate2 (ISDP_X509Cert в примере), который сохранит у себя в отдельном поле hCert в обеих системах.

Не стоит забывать, что это ссылка на область неуправляемой памяти и ее надо освобождать после окончания работы. Net 4. 5 X509Certificate2 не Disposable — очистку методом CertFreeCertificateContext, надо проводить в деструкторе.

Формирование подписи

При работе с ГОСТовыми сертификатами почти всегда используются отцепленные подписи с одним подписантом. Для того чтобы создать такую подпись требуется довольно простой блок кода:

Читайте также:  как поставить ключ в криптопро

В ходе работы метода формируется структура с параметрами и вызывается метод подписания. Структура параметров может позволять сохранить в подписи сертификаты для формирования полной цепочки (поля cMsgCert и rgpMsgCert, первый хранит количество сертификатов, второй список ссылок на структуры этих сертификатов).

Метод подписания может получать один или несколько документов для одновременного подписания одной подписью. Это, кстати, не противоречит 63 ФЗ и бывает очень удобно, т. пользователь вряд ли обрадуется необходимости несколько раз нажимать на кнопку «подписать».

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

Единственной серьезной проблемой является поиск OID алгоритма хэширования (Digest) используемый при подписании — в явном виде его нет в сертификате (там есть только алгоритм самой подписи). И если в Windows его можно указать пустой строкой — он подцепится автоматически, но Linux откажется подписывать если алгоритм не тот.

Но тут есть хитрость — в информации об алгоритме подписи (структура CRYPT_OID_INFO) в pszOID храниться OID подписи, а в Algid — храниться идентификатор алгоритма хэширования. А преобразовать Algid в OID уже дело техники:

Получение OID алгоритма хэширования

Внимательно прочитав код можно удивится, что идентификатор алгоритма получается простым способом (CertOIDToAlgId) а Oid по нему — сложным (CryptFindOIDInfo). Логично было бы предположить использование либо оба сложных, либо оба простых способа, и в Linux оба варианта успешно работают. Однако в Windows сложный вариант получения идентификатора и простой получения OID работает нестабильно, поэтому стабильным решением будет вот такой странный гибрид.

Проверка подписи

Проверка подписи происходит в два этапа, в начале проверяется сама подпись, а затем проверяется сертификат, которым она была сформирована (цепочка, дата подписания и проч). Так же как и при подписании необходимо указать набор подписываемых данных, параметры подписи и саму подпись:

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

После извлечения сертификата подписанта преобразуем его в наш класс и проверяем (если это указано в параметрах метода). Для проверки используется дата подписания первого подписанта (см. раздел извлечение информации из подписи, и раздел проверка сертификата).

Done.

Гайд написан с исследовательской целью – проверить возможность подписания документов УКЭП с помощью самописного сервиса на. NET Core 3. 1 с формированием штампов подлинности и времени подписания документов.

Безусловно это решение не стоит брать в работу “как есть” и нужны некоторые доработки, но в целом оно работает и подписывает документы подписью УКЭП.

Установка сертификата

Перед тем как реализовывать код, необходимо установить сертификат и убедится что он нормально работает.

Компонент КриптоПро CSP версии 3. 9 был установлен в Centos 7 в папку /opt/cprocsp. Для того, чтобы не было конфликтов между утилитами mono и КриптоПро, имеющих одинаковые названия (например, certmgr), в переменные окружения не стали вносить путь до папки и все утилиты вызывались по полному пути.

Если среди списка нет считывателя с папки на диске (HDIMAGE) ставим его:
/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -add HDIMAGE store

Установленный сертификат можно увидеть с помощью следующей команды:
/opt/cprocsp/bin/amd64/certmgr -list mMy

Если с сертификатом все нормально, то можно переходить к подключению в коде.

Извлечение информация из подписи

Часто в системах работающих с криптографией требуется печатное представление подписи. В каждом случае оно разное, поэтому лучше сформировать класс информации о подписи, который будет содержать информацию в удобном для использования виде и уже с его помощью обеспечивать печатное представление. Net такой класс есть — SignedCms, однако его аналог в mono c подписями КритоПро, во первых отказывается работать, во вторых содержит модификатор sealed и в третьих почти все свойства у него закрыты на запись, поэтому придется формировать свой аналог.

Сама по себе подпись содержит два основных элемента — список сертификатов и список подписантов. Список сертификатов может быть пустой, а может содержать в себе все сертификаты для проверки, включая полные цепочки. Список же подписантов указывает на кол-во реальных подписей. Связь между ними осуществляется по серийному номеру и издателю (Issuer). Теоретически в одной подписи может быть два сертификата от разных издателей с одним серийным номером, но на практике этим можно пренебречь и искать только по серийному номеру.

Чтение подписи происходит следующим образом:

Разбор подписи происходит в несколько этапов, вначале формируется структура сообщения (CryptMsgOpenToDecode), затем в нее вносятся реальные данные подписи (CryptMsgUpdate). Остается проверить что это реально подпись и получить сначала список сертификатов, а потом список подписантов. Список сертификатов извлекается последовательно :

Получение списка сертификатов

Сначала определятся количество сертификатов из параметра CMSG_CERT_COUNT_PARAM, а затем последовательно извлекается информация о каждом сертификате. Завершает процесс создания формирование контекста сертификата и на его основе самого сертификата.

Извлечение данных подписанта сложнее. В них содержится указание на сертификат и список параметров подписи (например, дата подписания). Процесс извлечения данных выглядит следующим образом:

Извлечение информации о подписанте

В ходе него сначала определяется размер структуры подписанта, а затем извлекается и сама структура CMSG_SIGNER_INFO. В ней легко найти серийный номер сертификата и по нему найти нужный сертификат в ранее извлеченном списке. Обратите внимание, что серийный номер содержится в обратном порядке.

После извлечения сертификата необходимо определить параметры подписи, самая важная из которых — дата подписания (даже если это не верифицированная сервером штампа даты времени, для отображения она очень важна).

Список атрибутов подписи

Атрибуты представляют из себя вложенный справочник вида Oid – список значений (по сути это разобранная структура ASN. Пройдя по первому уровню формируем вложенный список:

Разобрать атрибут подписи

Ключевой особенностью данного процесса является правильный подбор наследника Pkcs9AttributeObject. Проблема в том, что стандартный способ создания в mono не работает и приходится формировать выбор класса прямо в коде. К тому же из основных типов Mono на данный момент позволяет формировать только дату.

Обернув представленные выше методы в два класса — информация о подписи и информация о подписанте — получаем аналог SignedCms, из которой при формировании печатного вида извлекаем данные.

Читайте также:  Версия сервиса электронной подписи устарела - как исправить ошибку - ЭЦП Эксперт

Шифрование

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

Процесс шифрования происходит в три этапа — заполнение параметров, определение длины и наконец шифрование. Зашифрованные данные могут быть большие, вероятно, поэтому метод поддерживает режим двух вызовов.

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

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

Получение алгоритма шифрования

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

В случае если таких алгоритмов больше чем один можно так же фильтровать по размеру (опираясь на размер алгоритма хэширования).

Дешифрование

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

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

Проверка сертификата

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

  • целостность цепочки (сертификат издателя, сертификат издателя сертификата издателя, и т. п.);
  • сертификат корневого издателя — должен быть в хранилище доверенных корневых центров;
  • период действия всех сертификатов — момент использования сертификата должен быть в границах этого периода;
  • каждый из сертификатов в цепочке, кроме корневого, должен отсутствовать в списке отозванных у своего издателя (CRL);

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

Как уже понятно из введения, проверка сертификата на валидность, одна из самых сложных задач. Именно поэтому в библиотеке масса методов для реализации каждого из пунктов в отдельности. Поэтому, для упрощения обратимся к исходникам. Net для метода X509Certificate2. Verify() и возьмем их за основу.

Проверка состоит из двух этапов:

  • сформировать цепочку сертификатов вплоть до корневого;
  • проверить каждый из сертификатов в ней (на отзыв, время и проч.);

Такая проверка должна осуществляться перед подписанием и шифрованием на текущую дату, и в момент проверки подписи на дату подписания. Сам метод проверки небольшой:

Сначала формируется цепочка методом BuildChain, а затем она проверяется. В ходе формирования цепочки формируется структура параметров, дата проверки и флаги проверки:

Формирование цепочки сертификата

Это сильно упрощенный вариант формирования цепочки по сравнению с тем, как ее формирует Microsoft. Структуры hCertPolicy и hAppPolicy можно наполнить OID-ами, отображающими права на действия, которые необходимы в проверяемом сертификате. Но в примере, будем считать, что их мы не проверяем.

Так же можно в параметры построения цепочки добавить дополнительное хранилище сертификатов (например, извлеченное из подписи).

Метод MapRevocationFlags — можно взять напрямую из исходников. Net без изменений —он просто формирует uint по набору передаваемых флагов.

Заключение

Набор реализованных методов работы с криптографией был подвергнут нагрузочному тестированию по схеме цикла полной работы:

  • ожидание 10 мс;
  • извлечение сертификата;
  • проверка полученной подписи;
  • извлечение параметров подписи;
  • дешифрование полученных данных;

Данный цикл был запущен в Windows и в Linux в 1-ом, 10-и и 50-и потоках, чтобы проверить работу в Linux сразу в нескольких потоках. Приложение в Linux работало стабильно в течении какого-то времени во много-поточном режиме (и чем больше потоков, тем меньше по времени), а затем «вставало» наглухо. Что свидетельствует о наличии взаимной блокировки (deadlock-е) в библиотеке (при нарушении работы с потоками связанных с разделяемым доступом обычно происходит падение с «Access Violation»).

По этой причине для обеспечения стабильности работы все методы класса UCryptoAPI стоит обрамить критической секцией. Для этого добавляем поле fpCPSection типа object после чего в каждый вызов добавляем следующую конструкцию:

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

Нагрузочное тестирование так же показало утечки памяти в mono при обращении к полям Issuer и Subject сертификата. Утечка, вероятно, происходит при попытке mono сформировать классы X500DistinguishedName для подписанта и издателя. К счастью, mono посчитали этот процесс достаточно ресурсоемким (или же они знают об утечке), поэтому предусмотрели кэширование результата данного формирования во внутренние поля сертификата (impl. issuerName и impl. subjectName). Поэтому данная утечка лечится прямой записью через отражение (Reflection) в эти поля экземпляров класса X500DistinguishedName, сформированных на базе значений из структуры CERT_CONTEXT сертификата.

Немного покодим

Потребуется 2 COM библиотеки: “CAPICOM v2. 1 Type Library” и “Crypto-Pro CAdES 1. 0 Type Library”. Они содержат необходимые объекты для создания УКЭП.

В этом примере будет подписываться BASE64 строка, содержащая в себе PDF-файл. Немного доработав код можно будет подписать hash-значение этого фала.

Основной код для подписания был взят со страниц Подпись PDF с помощью УЭЦП- Page 2 (cryptopro. ru) и Подпись НЕОПРЕДЕЛЕНА при создании УЭЦП для PDF на c# (cryptopro. ru), но он использовался для штампа подписи на PDF документ. Код из этого гайда переделан под сохранение файла подписи в отдельный файл.

Условно процесс можно поделить на 4 этапа:

  • Поиск сертификата в хранилище – я использовал поиск по отпечатку в хранилище пользователя;
  • Чтение байтов подписанного файла;
  • Сохранение файла подписи рядом с файлом.
Читайте также:  Списки с поддержкой CSP подписаны SIG

Пробный запуск

Для подписания возьмем PDF-документ, который содержит надпись “Тестовое заявление

TSP, OSCP и CSC для высокоточного сверления

Больше для теста нам ничего не надо

Далее запустим программу и дождемся подписания файла:

TSP, OSCP и CSC для высокоточного сверления

Готово. Теперь можно приступать к проверкам.

Проверка в КриптоАРМ

Время создания ЭП заполнено:

TSP, OSCP и CSC для высокоточного сверления

Штамп времени на подпись есть:

TSP, OSCP и CSC для высокоточного сверления

Доказательства подлинности также заполнены:

TSP, OSCP и CSC для высокоточного сверления

В протоколе проверки есть блоки “Доказательства подлинности”, “Штамп времени на подпись” и “Время подписания”:

TSP, OSCP и CSC для высокоточного сверления

TSP, OSCP и CSC для высокоточного сверления

TSP, OSCP и CSC для высокоточного сверления

Проверка на Госуслугах

TSP, OSCP и CSC для высокоточного сверления

Проверка в Контур. Крипто

TSP, OSCP и CSC для высокоточного сверления

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

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

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

и положим туда все необходимое.

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

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

  • Установите КриптоПро 5.0 и убедитесь, что у вас есть действующая лицензия. – для меня подошла втроенная в ЭП;
  • Установите core 3.1 sdk и runtime и распространяемый пакет Visual C++ для Visual Studio 2015 обычно ставится вместе со студией; прим.: на II этапе мне пришлось через установщик студии поставить дополнительное ПО для разработки на C++ – сборщик требует предустановленный DIA SDK.
  • Задайте переменной среды DOTNET_MULTILEVEL_LOOKUP значение 0 – не могу сказать для чего это нужно, но в оригинальной инструкции это есть;
  • package_windows_debug.zip распакуйте в .packagesruntime-debug-windows.zip распакуйте в .
    untime
  • package_windows_debug.zip распакуйте в .packages
  • runtime-debug-windows.zip распакуйте в .
    untime
  • Добавьте источник пакетов NuGet в файле %appdata%NuGetNuGet.Config – источник должен ссылаться на путь .packages в созданной вами папке. Пример по добавлению источника есть в основной инструкеии. Для меня это не сработало, поэтому я добавил источник через VS Community;
  • Склонируйте репизиторий DotnetCoreSampleProject в .
  • Измените файл .DotnetSampleProjectDotnetSampleProject.csproj – для сборок System.Security.Cryptography.Pkcs.dll и System.Security.Cryptography.Xml.dll укажите полные пути к .
    untime;
  • Перейдите в папку проекта и попробуйте собрать решение. Я собирал через Visual Studio после открытия проекта.

II – Сборка проекта со сборкой corefx для Windows

  • Выполните 1-3 и 6-й шаги из I этапа;
  • Склонируйте репозиторий corefx в .
  • Выполните сборку запустив .corefxuild.cmd – на этом этапе потребуется предустановленный DIA SDK
  • Выполните шаги 5, 7-9 из I этапа. Вместо условного пути .packages укажите .corefxartifactspackagesDebugNonShipping, а вместо .
    untime укажите .corefxartifactsin
    untime
    etcoreapp-Windows_NT-Debug-x64

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

Что имеем на входе?

  • КриптоПро CSP версии 5.0 – для поддержки Российских криптографических алгоритмов (подписи, которые выпустили в аккредитованном УЦ в РФ)
  • КриптоПро TSP Client 2.0 – нужен для штампа времени
  • КриптоПро OCSP Client 2.0 – проверит не отозван ли сертификат на момент подписания
  • КриптоПро .NET Client – таков путь
  • Любой сервис по проверке ЭП – я использовал Контур.Крипто как основной сервис для проверки ЭП и КриптоАРМ как локальный. А еще можно проверить ЭП на сайте Госуслуг
  • КЭП по ГОСТ Р 34.11-2012/34.10-2012 256 bit, которую выпустил любой удостоверяющий центр
  • КриптоПро CSP версии 5.0 – у меня установлена версия 5.0.11944 КС1, лицензия встроена в ЭП.
  • КриптоПро TSP Client 2.0 и КриптоПро OCSP Client 2.0 – лицензии покупается отдельно, а для гайда мне хватило демонстрационного срока.
  • КриптоПро .NET Client версии 1.0.7132.2 – в рамках этого гайда я использовал демонстрационную версию клиентской части и все действия выполнялись локально. Лицензию на сервер нужно покупать отдельно.
  • Контур.Крипто бесплатен, но требует регистрации. В нем также можно подписать документы КЭП, УКЭП и проверить созданную подпись загрузив ее файлы.

Так, а что надо на выходе?

А на выходе надо получить готовое решение, которое сделает отсоединенную ЭП в формате. sig со штампом времени на подпись и доказательством подлинности. Для этого зададим следующие критерии:

  • ЭП проходит проверку на портале Госуслуг, через сервис для подтверждения подлинности ЭП формата PKCS#7 в электронных документах;
  • КриптоАРМ после проверки подписиЗаполнит поле “Время создания ЭП” – в конце проверки появится окно, где можно выбрать ЭП и кратко посмотреть ее свойстваСтобец “Время создация ЭП”В информации о подписи и сертификате (двойной клик по записе в таблице) на вкладке “Штампы времени” в выпадающем списке есть оба значения и по ним заполнена информация:В протоколе проверки подписи есть блоки “Доказательства подлинности”, “Штамп времени на подпись” и “Время подписания”. Для сравнения: если документ подписан просто КЭП, то отчет по проверке будет достаточно коротким в сравнении с УКЭП.
  • Заполнит поле “Время создания ЭП” – в конце проверки появится окно, где можно выбрать ЭП и кратко посмотреть ее свойстваСтобец “Время создация ЭП”
  • В информации о подписи и сертификате (двойной клик по записе в таблице) на вкладке “Штампы времени” в выпадающем списке есть оба значения и по ним заполнена информация:
  • В протоколе проверки подписи есть блоки “Доказательства подлинности”, “Штамп времени на подпись” и “Время подписания”. Для сравнения: если документ подписан просто КЭП, то отчет по проверке будет достаточно коротким в сравнении с УКЭП.
  • Контур.Крипто при проверке подписи выдаст сообщение, что совершенствованная подпись подтверждена, сертификат на момент подписания действовал и указано время создания подпись:Усовершенствованная подпись подтверждена

UPD1: Поменял в коде переменную, куда записываются байты файла подписи.

Также я забыл написать немного про подпись штампа времени – он подписывается сертификатом владельца TSP-сервиса. По гайду это ООО “КРИПТО-ПРО”:

TSP, OSCP и CSC для высокоточного сверления

UPD2: Про библиотеки CAdESCOM и CAPICOM

Если создать пустой проект на. NET Core 3. 1, подключив непропатченные библиотеки, то при обращении к закрытому ключу выпадет исключение “System. NotSupportedException” c сообщением “The certificate key algorithm is not supported

TSP, OSCP и CSC для высокоточного сверления

NET Core 3. 1 – Исключение без пропатченных библиотек

Но при использовании пропатченных библиотек это исключение не выпадает и с приватным ключем можно взаимодействовать:

TSP, OSCP и CSC для высокоточного сверления

Также код из гайда работает с. NET Framework 4. 8 без использования пропатченных библиотек, но вместо обращения к пространству имен “System. Security. Cryptography”, которое подменяется пропатченными библиотеками для. NET Core, CSP Gost3410_2012_256CryptoServiceProvider будет использован из пространства имен “CryptoPro. Sharpei”:

TSP, OSCP и CSC для высокоточного сверления

Ссылки

  • документация КриптоПро CAPILite
  • ресурс c объявлением стандартных экспортируемых функций в С#
  • исходники .Net:
    класс CAPIBaseкласс X509Certificate2класс SignedCMSкласс SignerInfo
  • класс CAPIBase
  • класс X509Certificate2
  • класс SignedCMS
  • класс SignerInfo
  • исходники mono:
    класс X509Certificate2класс X509CertificateImplBtls
  • класс X509CertificateImplBtls
Оцените статью
ЭЦП Эксперт
Добавить комментарий

Adblock
detector