Побег из Крипто Про. ГОСТ 34.10-2012 edition / Хабр

Побег из Крипто Про. ГОСТ 34.10-2012 edition / Хабр Электронная цифровая подпись

Что произойдет с подписями по гост 2001

Удостоверяющие центры уже перестали выдавать сертификаты ЭП по ГОСТ 2001 — с 2021 года они формируют сертификаты только по новому стандарту. А с 2020 года сертификаты по старому ГОСТу не будут поддерживать информационные системы и средства электронной подписи.

Поэтому с 1 января 2020 года сертификаты ЭП по ГОСТ 2001 фактически перестанут действовать — их нельзя будет использовать для формирования электронной подписи, подписания документов и работы в сервисах и информационных системах.

Почему изменился гост электронной подписи

Сертификаты ключей проверки электронной подписи (сертификаты ЭП или ЭЦП) формируются по определенному стандарту шифрования. Раньше этим стандартом был ГОСТ 2001. Чтобы повысить надежность электронной подписи, ФСБ и Минкомсвязи решили ввести новый стандарт — ГОСТ 2021. Об этом сообщили в соответствующем уведомлении.

Новый ГОСТ стали вводить в 2021 году. С 2020 года он станет обязательным, а все сертификаты на ГОСТ 2001 будут недействительны.

Disclaimer

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

А зачем это вообще надо? Хорошо написанно оригинальной статье. Повторяться не буду.

Как избавиться от ошибок

Вы все сделали правильно, установили корневой сертификат по инструкции, проверили свойства носителя, конвертировали файлы, но что-то пошло не так, и все еще не работает ЭЦП ГОСТ 2021. Возможно, не обновили КриптоПро — минимальная версия программы 4.0.

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

Ошибка ЭЦП ГОСТРешение
Корневой сертификат установлен некорректноЗапустить казначейскую программу установки
Стоит блокировка использования ключа ЭЦПВключить утилиту с правами администратора, снять блокировку и перезагрузить ПК
Невозможно создание объекта сервером программирования объектовЗарегистрировать библиотеку capicom.dll на рабочем столе и проверить установку КриптоПро ЭЦП Browser plug-in 2.0
Неизвестный криптографический алгоритмУдаляем ветки в реестре ПК через «Редактор реестра». Потребуется удалить:
  • [HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptDllFindOIDInfo1.2.643.2.1.3.2.1!1];
  • [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftCryptographyOIDEncodingType 0CryptDllFindOIDInfo1.2.643.2.1.3.2.1!1]
Недоступен сервис подачи документов для получения сертификата через официальный сайт ФКОтключить на время подачи запроса антивирус
Не подписываются документы в Электронном бюджете (не отображается сертификат)Конвертировать файлы и изменить формат контейнера в закрытом ключе

Как конвертировать файлы

Вы установили новый ключ, но он почему-то не работает? Первое, что надлежит сделать, — узнать, соответствует ли ЭЦП обновленным стандартам. Вот как проверить ГОСТ ЭЦП:

  1. Открыть установленный файл.
  2. Отобразить его свойства.
  3. Посмотреть ГОСТ сертификата.

Если в свойствах стоит верное значение (ГОСТ 2021), но не удается подписать документ в ГИИС «Электронный бюджет», возможно, проблема в названии организации. Если наименование заказчика превышает 127 символов, возникают ошибки с отображением при подписании файлов в ГИИС.

Чтобы это сделать:

Как обновить сертификат до нового госта

Все сертификаты, выпущенные по ГОСТ 2001, перестанут действовать 1 января 2020 года. Чтобы продолжить использовать электронную подпись в 2020 году, владельцам сертификатов по ГОСТ 2001 нужно в ближайшее время получить сертификат по ГОСТ 2021. Вы можете оставить заявку на выпуск нового сертификата на нашем сайте или в вашем сервисном центре.

Как проверить гост

Чтобы узнать, на каком ГОСТе выпущен ваш сертификат, откройте файл сертификата и перейдите на вкладку «Состав». В полях «Алгоритм подписи» и «Хэш-алгоритм подписи» будет указан ГОСТ, который использует ваш сертификат: ГОСТ Р 34.10-2001 (старый стандарт) или ГОСТ Р 34.11-2021 (новый).

Пример сертификата на новом ГОСТе:

Как проверить сертификат

Если вы недавно меняли ЭЦП (в течение 2021 года), не торопитесь получать новую подпись. Для начала проверьте стандарт действующего ключа. Вот как узнать ГОСТ ЭЦП:

  1. Найдите и войдите в файл сертификата на своем ПК.
  2. В контекстном меню выберите блок «Свойства».
  3. Проверьте алгоритм действующей подписи.

Если у вашей подписи актуальный госстандарт, спокойно работайте дальше. Менять сертификат нет необходимости.

Как создать новый носитель по госстандарту р 34.11-2021/34.10-2021

Вы скачали и установили программу Converter.exe? Отлично! Теперь приступайте к созданию носителя по обновленным стандартам. Вот как формировать файл через конвертер ЭЦП по ГОСТу 2021:

1. Запускаем программу.

2. Вставляем носитель с закрытым ключом. Обновляем список носителей.

3. Выбираем действие «Конвертировать». Вставляем новый чистый носитель (объем не имеет значения). Обновляем список.

4. Придумываем пароль и сохраняем.

5. Автоматически откроется окно для ввода пароля от сертификата ключа ЭЦП, сгенерированного в казначейском УЦ.

6. Конвертация завершена. Система уведомит вас об успешном окончании процедуры. На носителе установлены два файла.

7. Теперь переходим к генерации ключей. Входим в программу генерации и запускаем импорт.

8. Откроется окно для импорта. В верхнем поле выбираем сертификат, выданный УЦ, а в нижнем — конвертированный файл. Затем вставляем носитель и выбираем его значение.

9. Вводим пароль нового носителя и завершаем импорт. Сертификат готов к работе.

Как установить новый сертификат

Срок действия старых сертификатов заканчивается, и до начала нового года рекомендуется получить новый экземпляр. Отправьте запрос на получение сертификата по госстандарту Р 34.11-2021/34.10-2021.

Для формирования и отправки заявки используйте портал заявителя информационной системы «Удостоверяющий центр Федерального казначейства». Новые стандарты ЭЦП не влияют на алгоритм получения самого ключа.

Вот инструкция по скачиванию и установке сертификатов от удостоверяющего центра ФК РФ:

Шаг 1. Переходим на официальный сайт Федерального казначейства РФ.

Шаг 2. Выбираем раздел «Удостоверяющий центр», затем «Корневые сертификаты».

Шаг 3. Активировать ссылку на скачивание корневого сертификата УЦ — на сайте действует специальная настройка ЭЦП ГОСТ 2021.

Шаг 4. Сохранить файл в выбранную локальную директорию автоматизированного рабочего места (АРМ) пользователя.

Читайте также:  Инструкция по подключению и настройке работы компьютера с ППО "СУФД-онлайн"

Шаг 5. В контекстном меню сохраненного файла выбрать действие «Установить».

Шаг 6. Выбрать хранилище «Локальный компьютер» в Мастере импорта сертификатов.

Шаг 7. Вручную выбрать хранилище: нажать «Обзор», найти «Промежуточные центры сертификации».

Шаг 8. Проверить сведения в окне завершения. Нажать «Готово».

Шаг 9. Если все действия выполнены правильно, то появится сообщение об успешном импорте.

Переход на гост-2021: главное о новом стандарте электронной подписи

04 декабря 2021

Переход на ГОСТ-2021: главное о новом стандарте электронной подписи

До конца 2021 года все аккредитованные удостоверяющие центры России должны были перейти на формирование и проверку сертификатов квалифицированной электронной подписи в соответствии со стандартом ГОСТ Р 34.10-2021.

Эксперты «Инфотекс Интернет Траст» рассказывают о процессе перехода на новый криптографический стандарт.

ГОСТ Р 34.10-2021 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи» — российский криптографический стандарт, описывающий алгоритмы формирования и проверки электронной подписи, принятый и введённый в действие вместо ГОСТ Р 34.10-2001 Приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2021 года №215-ст.

Введение нового стандарта

В начале 2021 года ФСБ России известила разработчиков средств криптографической защиты информации о начале перехода на использование нового национального стандарта ГОСТ Р 34.10-2021 в средствах электронной подписи для информации, не содержащей сведений, составляющих государственную тайну.

Документ ФСБ России №149/7/1/3-58 от 31.01.2021 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования», выписка из которого была опубликована на сайте ТК26, устанавливал следующие требования:

  • после 31 декабря 2021 года прекратить сертификацию средств электронной подписи на соответствие требованиям к средствам электронной подписи, утверждённым приказом ФСБ России от 27.12.2021 г. №796, если в этих средствах не предусматривается реализация функций в соответствии с ГОСТ Р 34.10-2021;
  • после 31 декабря 2021 года запретить использование ГОСТ Р 34.10-2001 для формирования электронной подписи.

В октябре 2021 года Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации опубликовало на портале Федерального ситуационного центра электронного правительства Разъяснение по переходу на ГОСТ Р 34.10-2021, в котором подтверждалось, что использование схемы ГОСТ Р 34.10-2001 для формирования электронной подписи после 31 декабря 2021 года не допускается, в том числе и для формирования списка отзыва сертификатов, а после 31 декабря 2021 года формирование электронной подписи должно производиться по алгоритму ГОСТ Р 34.10-2021.

Также в разъяснении Минкомсвязи сообщалось о том, что выпуск сертификатов для подчиненных аккредитованных удостоверяющих центров с использованием схемы подписи, установленной стандартом ГОСТ Р 34.10-2021, планируется начать не позднее середины июля 2021 года.

Кроме того, в документе говорилось о том, что квалифицированный сертификат пользователя и квалифицированный сертификат аккредитованного удостоверяющего центра, выдавшего его пользователю, должны соответствовать одному стандарту: либо ГОСТ-2021, либо ГОСТ-2001. Если сертификаты будут сформированы в соответствии с разными стандартами, то есть будут иметь различную схему подписи, они не смогут пройти проверку на Едином портале государственных и муниципальных услуг.

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

16 июля 2021 года Минкомсвязь опубликовала Уведомление о начале выпуска сертификатов ключей проверки электронных подписей подчинённых удостоверяющих центров на Головном удостоверяющем центре в соответствии с ГОСТ Р 34.10-2021, после чего аккредитованные удостоверяющие центры, запросившие в Головном удостоверяющем центре сертификат подчинённого удостоверяющего центра, сформированный по ГОСТ-2021, получили возможность выпускать сертификаты пользователей в соответствии с новым стандартом.

Чем вызвана необходимость перехода на новый ГОСТ?

В 2021 году было выпущено два новых стандарта — ГОСТ Р 34.10-2021 по формированию и проверке электронной подписи и ГОСТ Р 34.11-2021 по функции хэширования. Новые стандарты заменили ГОСТ по электронной подписи 2001 года и ГОСТ по функции хэширования 1994 года. В алгоритме формирования и проверки электронной подписи нового стандарта изменений не произошло, а вот функция хеширования существенно изменилась. Новая российская функция хеширования Стрибог с криптографической точки зрения существенно превосходит ту, что использовалась ранее и была описана в стандарте 1994 года.

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

Проблемы перехода на ГОСТ-2021

В октябре 2021 года, после того как Минкомсвязь объявила о том, что выпуск сертификатов для подчиненных удостоверяющих центров по схеме ГОСТ Р 34.10-2021 планируется начать не ранее июля 2021 года, стало ясно, что к установленному ФСБ России контрольному сроку, после которого запрещается использование ГОСТ-2001, — 31 декабря 2021 года, затруднительно обеспечить безболезненный перевод всех владельцев сертификатов ГОСТ-2001 на сертификаты ГОСТ-2021 без существенных дополнительных расходов со стороны удостоверяющих центров.

В связи с этим весной 2021 года Минкомсвязь инициировала ряд совещаний с представителями аккредитованных удостоверяющих центров по вопросу организации перехода на схему формирования электронной подписи по ГОСТ-2021. В ходе совещаний обсуждались проблемы удостоверяющих центров, связанные с жестким требованием обеспечить всех пользователей сертификатами ГОСТ-2021 до конца 2021 года, поскольку с начала 2021 года использование сертификатов ГОСТ-2001 запрещалось утвержденным ФСБ России порядком перехода на новый стандарт.

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

С какими сложностями сопряжён переход на новый ГОСТ?

Читайте также:  Перенос сертификатов КриптоПРО на другой компьютер, за минуту | IT блоги - Windows, *nix, vmWare, Hyper-V, NetApp, SEO, HTML, видеонаблюдение

Процесс перехода на новый ГОСТ достаточно длительный. Средства электронной подписи, в обязательном порядке поддерживающие новые ГОСТы, разрабатываются с конца 2021 года — с этого момента не принимаются технические задания на разработку средств электронной подписи без поддержки  ГОСТ Р 34.10/11-2021. Соответственно, поскольку срок действия сертификата на средства электронной подписи и средства удостоверяющего центра обычно составляет 3 года, все такие сертифицированные средства уже давно поддерживают новые алгоритмы.

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

Еще одно препятствие на пути к применению новых сертификатов — неготовность информационных систем к приёму и проверке электронной подписи, сформированной по новому ГОСТу.

Соответственно, для того чтобы переход на новый ГОСТ Р 34.10-2021 завершился, необходима совокупность факторов: удостоверяющие центры должны иметь возможность выпускать сертификаты по новому стандарту, а информационные системы — поддерживать работу с этими сертификатами.

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

Продление срока действия ГОСТ Р 34.10-2001

Учитывая вышеуказанные обстоятельства, ФСБ продлила срок действия стандарта ГОСТ Р 34.10-2001 до 31 декабря 2021 года письмом от 07.09.2021 №149/7/6-363 после консультаций с исполнительными органами власти, представителями удостоверяющих центров, разработчиками СКЗИ, операторами ИС и порталов.

В связи с этим 12 сентября 2021 года Минкомсвязь опубликовала новое Уведомление об организации перехода на использование схемы электронной подписи по ГОСТ Р 34.10-2021 с подробным планом мероприятий по реализации перехода на новый стандарт, сроками перехода и рекомендациями производителям средств электронной подписи и удостоверяющих центров, аккредитованным удостоверяющим центрам, владельцам квалифицированных сертификатов и операторам информационных систем, в которых используется электронная подпись.

Основные положения уведомления Минкомсвязи, непосредственно касающиеся аккредитованных удостоверяющих центров:

  • срок действия стандарта ГОСТ Р 34.10-2001 продлевается до 31 декабря 2021 года;
  • до конца 2021 года производители средств электронной подписи должны продлить сроки действия сертификатов соответствия ФСБ России на средства электронной подписи, поддерживающие ГОСТ-2001, иначе электронные подписи, формируемые в 2021 году по ГОСТ-2001 с помощью средства ЭП со сроком действия сертификата ФСБ России до 31 декабря 2021 года, не будут считаться квалифицированными;
  • после 31 декабря 2021 года аккредитованные удостоверяющие центры должны прекратить выпуск квалифицированных сертификатов по схеме ГОСТ-2001;
  • владельцы квалифицированных сертификатов должны быть оповещены о том, что создание квалифицированной ЭП по схеме ГОСТ-2001 после 31 декабря 2021 года будет невозможным в связи с тем, что сертификаты соответствия ФСБ России на средства ЭП, поддерживающие ГОСТ-2001, прекратят свое действие 1 января 2020 года;
  • при выдаче квалифицированных сертификатов для ключей ГОСТ-2001 после 30 сентября 2021 года аккредитованные удостоверяющие центры должны ограничивать период их действия датой не позднее 31 декабря 2021 года (например, ограничением периода действия сертификата или включением в состав сертификата расширения Private Key Usage Period со значением, не превосходящим 31 декабря 2021 года);
  • мероприятия по встраиванию ГОСТ-2021 в информационные системы, использующие электронную подпись, и ввод их в эксплуатацию должны быть завершены до 31 декабря 2021 года;
  • информация о готовности ИС к работе с электронной подписью по ГОСТ-2021 будет публиковаться на портале Федерального ситуационного центра электронного правительства.

Переход к использованию сертификатов по ГОСТ-2021: что важно знать абонентам

На основании письма ФСБ РФ от 07.09.2021 №149/7/6-363 и Уведомления Минкомсвязи об организации перехода на использование схемы электронной подписи по ГОСТ Р 34.10-2021, использование стандарта ГОСТ Р 34.10-2001 для формирования электронной подписи продлевается до 31 декабря 2021 года. Начиная с 1 января 2020 года формировать электронную подпись можно будет только в соответствии с ГОСТ Р 34.10-2021.

Абоненты аккредитованных удостоверяющих центров могут использовать сертификаты электронной подписи, сформированные в соответствии с ГОСТ-2001, до конца периода их действия, но не позднее чем до 31 декабря 2021 года. При этом на протяжении всего 2021 года для подписания документов квалифицированной электронной подписью допускается использование как старых действующих сертификатов, сформированных по ГОСТ-2001, так и новых, созданных по стандарту ГОСТ-2021.


*на правах рекламы.

Получение ключа с токена

image

Все известные мне УЦ выдают ключи с сертификатами на подобных токенах. На токен записан контейнер КриптоПро с приватным ключом и сертификатом. При экспорте ключа через CryptoPro CSP он экспортируется в особый «КриптоПро pfx» не совместимый ни с чем.

Просьбы выдать ключ в стандартном pfx или любом другом типовом контейнере УЦ игнорируют.Если кто знает УЦ выдающие подписи в стандартных контейнерах поделитесь координатами в комментариях. Хороших людей не стыдно попиарить.

Для преобразования контейнера КриптоПро в стандартный pfx мы как и в оригинальной статье будем использовать P12FromGostCSP. Старые взломанные версии не работают с ключами по 2021 Госту. Идем на сайт авторов и покупаем новую.

Итак мы получили стандартный pfx с ключом и сертификатом.

Обновление Bouncy Castle

Обновляем Bouncy Castle до 1.60 Старые версии могут не поддерживать алгоритмы ГОСТ 2021.

Инициализация Bouncy Castle

    static {
        BouncyCastleProvider bcProvider = new BouncyCastleProvider();
        String name = bcProvider.getName();
        Security.removeProvider(name); // remove old instance
        Security.addProvider(bcProvider);
    }

Разбор pfx

               
KeyStore keyStore = KeyStore.getInstance("PKCS12", "BC");
ByteArrayInputStream baos = new ByteArrayInputStream(pfxFileContent);
keyStore.load(baos, password.toCharArray());

Enumeration<String> aliases = keyStore.aliases();

while (aliases.hasMoreElements()) {
    String alias = aliases.nextElement();
    if (keyStore.isKeyEntry(alias )) {
        Key key = keyStore.getKey(alias , keyPassword.toCharArray());
        java.security.cert.Certificate certificate = keyStore.getCertificate(alias );
        addKeyAndCertificateToStore((PrivateKey)key, (X509Certificate)certificate);
    }
}


Алиасы обязательно изменяем. Утилита P12FromGostCSP задает всегда один и тот же алиас «csp_exported» и при обработке уже второго ключа будут проблемы.

Читайте также:  Сбербанк-АСТ - электронная торговая площадка [#F1]

Для удобства работы ключ из pfx необходимо загрузить в стандартный Java KeyStore и дальше работать только с ним.

Загрузка KeyStore

FileInputStream is = new FileInputStream(keystorePath);
keystore = KeyStore.getInstance(KeyStore.getDefaultType());
char[] passwd = keystorePassword.toCharArray();
keystore.load(is, passwd);

Сохранение ключа с сертификатом в KeyStore


public void addKeyAndCertificateToStore(PrivateKey key, X509Certificate certificate) {
    synchronized (this) {
        keystore.setKeyEntry(alias.toLowerCase(), key, keyPassword.toCharArray(), new X509Certificate[] {certificate});

        FileOutputStream out = new FileOutputStream(keystorePath);
        keystore.store(out, keystorePassword.toCharArray());
        out.close();
   }
}

Загрузка ключей и сертификатов из KeyStore


Enumeration<String> aliases = keystore.aliases();

while (aliases.hasMoreElements()) {
    String alias = aliases.nextElement();

    if (keystore.isKeyEntry(alias)) {
        Key key = keystore.getKey(alias, keyPassword.toCharArray());
        keys.put(alias.toLowerCase(), key); //any key,value collection

        Certificate certificate = keystore.getCertificate(alias);
        if (certificate instanceof X509Certificate)
            certificates.put(alias.toLowerCase(), (X509Certificate) certificate); //any key,value collection
    }
}

Подпись файла


CMSProcessableByteArray msg = new CMSProcessableByteArray(dataToSign);
 
List certList = new ArrayList();
certList.add(cert);

Store certs = new JcaCertStore(certList);
CMSSignedDataGenerator gen = new CMSSignedDataGenerator();
ContentSigner signer = new org.bouncycastle.operator.jcajce.JcaContentSignerBuilder("GOST3411WITHECGOST3410-2021-256").setProvider("BC").build(privateKey);

gen.addSignerInfoGenerator(new JcaSignerInfoGeneratorBuilder(new JcaDigestCalculatorProviderBuilder().setProvider("BC").build()).build(signer, certificate));
gen.addCertificates(certs);
CMSSignedData sigData = gen.generate(msg, false);
byte[] sign = sigData.getEncoded(); //result here

Есть вариант JcaContentSignerBuilder(«GOST3411WITHECGOST3410-2021-512») для 512 битовых ключей. Мои УЦ выдают 256 битные ничего не спрашивая и игнорируют уточняющие вопросы.

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


byte[] data = ...; //signed file data
byte[] signature = ...;//signature
boolean checkResult = false;

CMSProcessable signedContent = new CMSProcessableByteArray(data);
CMSSignedData signedData;
try {
    signedData = new CMSSignedData(signedContent, signature);
} catch (CMSException e) {
    return SIGNATURE_STATUS.ERROR;
}

SignerInformation signer;
try {
    Store<X509CertificateHolder> certStoreInSing = signedData.getCertificates();
    signer = signedData.getSignerInfos().getSigners().iterator().next();

    Collection certCollection = certStoreInSing.getMatches(signer.getSID());
    Iterator certIt = certCollection.iterator();

    X509CertificateHolder certHolder = (X509CertificateHolder) certIt.next();
    X509Certificate certificate = new JcaX509CertificateConverter().getCertificate(certHolder);

    checkResult = signer.verify(new JcaSimpleSignerInfoVerifierBuilder().build(certificate));

} catch (Exception ex) {
    return SIGNATURE_STATUS.ERROR;
}

Проверка подписи полностью аналогична проверке по Госту 2001 года. Можно ничего не менять.

Резюме

В результате всех вышеописанных действий мы получили относительно легкий способ избавиться от тяжкой ноши Крипто Про в 2021 году.

Форматэлектронной подписи, обязательный для реализации всеми средствами электронной подписи

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

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

2. В соответствии с настоящим Форматом средства ЭП должны обеспечивать возможность создания нескольких ЭП в одном документе с сохранением данных, описывающих контекст, содержание, структуру документов, а также обеспечивающих управление документами в используемых информационных системах, – метаданных и сертификатов, на которых основаны эти ЭП, в электронном сообщении.

3. При включении в состав ЭП дополнительной информации, отличной от указанной в пунктах 5, 6 и 7 настоящего Формата, требования к ее назначению и расположению в структуре ЭП определяются заказчиком в техническом задании на разработку (модернизацию)

средств ЭП и удостоверяющего центра (далее – УЦ), в соответствии с приказом ФСБ России от 9 февраля 2005 г. N 66 “Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (Положение ПКЗ-2005)” (зарегистрирован Минюстом России 3 марта 2005 г., регистрационный N 6382), с изменениями, внесенными приказом ФСБ России от 12 апреля 2021 г.

4. Формат определяется в соответствии с основами аутентификации в открытых системах1, синтаксисом криптографических сообщений, описанием дополнительных атрибутов криптографических сообщений, спецификацией абстрактной синтаксической нотации версии один2.

——————————

1 Основы аутентификации в открытых системах определены в ГОСТ Р ИСО/МЭК 9594-8-98 “Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации” (принят и введен в действие постановлением Госстандарта России от 19 мая 1998 г. N 215, опубликован в августе 1998 г. ИПК “Издательство стандартов”, ИУС 9-98).

2 Спецификация абстрактной синтаксической нотации версии один определена в ГОСТ Р ИСО/МЭК 8824-1-2001 “Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации” (принят и введен в действие постановлением Госстандарта России от 6 сентября 2001 г. N 375-ст, опубликован в ноябре 2001 г. ИПК “Издательство стандартов”, ИУС 11-2001).

——————————

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

 SignedData ::= SEQUENCE {

     version                         CMSVersion,

     digestAlgorithms                DigestAlgorithmIdentifiers,

     encapContentInfo                EncapsulatedContentInfo,

     certificates               [0]  IMPLICIT CertificateSet OPTIONAL,

     crls                       [1]  IMPLICIT RevocationInfoChoices

                                     OPTIONAL,

     signerInfos                     SignerInfos }

5.1. Поле version (типа CMSVersion) определяет версию синтаксиса ЭП, которая зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах:

 CMSVersion ::= INTEGER

                      { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

5.2. Поле digestAlgorithms (тип DigestAlgorithmldentifiers) включает в себя идентификаторы используемых алгоритмов хэширования и связанные с ними параметры и определяется следующим образом:

 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

 DigestAlgorithmIdentifier ::= AlgorithmIdentifier

В качестве идентификатора алгоритма хэширования указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.11-2021 “Информационная технология. Криптографическая защита информации. Функция хэширования”3(далее – ГОСТ Р 34.11-2021).

——————————

3 ГОСТ Р 34.11-2021 “Информационная технология. Криптографическая защита информации. Функция хэширования” (утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2021 г. N 216-ст, опубликован в апреле 2021 г. ФГУП “СТАНДАРТИНФОРМ”, ИУС 3-2021, поправка ИУС 6-2021).

——————————

для алгоритма с длиной выхода 256 бит:

     id-tc26-gost3411-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643)

 rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-256(2) }

для алгоритма с длиной выхода 512 бит:

     id-tc26-gost3411-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643)

 rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-512(3) }

5.3. Поле encapContentlnfo (тип EncapsulatedContentlnfo) содержит подписываемые данные (eContent) вместе с их типом (eContentType) и определяется следующим образом:

 EncapsulatedContentInfo ::= SEQUENCE {

     eContentType                       ContentType,

     eContent                     [0]   EXPLICIT OCTET STRING OPTIONAL }

     ContentType ::= OBJECT IDENTIFIER

В случае если поле eContent присутствует, то в нем содержится подписываемый электронный документ. Если поле eContent отсутствует, электронный документ хранится в отдельном файле.

5.4. В поле certificates (тип CertificateSet) может включаться дополнительная информация о сертификатах. В данное поле может быть включена информация о сертификатах подписывающих сторон.

Оцените статью
ЭЦП Эксперт
Добавить комментарий

Adblock
detector