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

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

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

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

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

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

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

Disclaimer

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

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

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

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

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

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

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

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: главное о новом стандарте электронной подписи

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

Все известные мне УЦ выдают ключи с сертификатами на подобных токенах. На токен записан контейнер КриптоПро с приватным ключом и сертификатом. При экспорте ключа через 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» и при обработке уже второго ключа будут проблемы.

Для удобства работы ключ из 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) может включаться дополнительная информация о сертификатах. В данное поле может быть включена информация о сертификатах подписывающих сторон.