ГОСТ электронная подпись

ГОСТ Р 34.10-2012

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

Область применения

Цифровая подпись позволяет:

  1. Аутентифицировать лицо, подписавшее сообщение;
  2. Контролировать целостность сообщения;
  3. Защищать сообщение от подделок;
  4. Доказать авторство лица, подписавшего сообщение.

История

Данный алгоритм разработан главным управлением безопасности связи Федерального агентства правительственной связи и информации при Президенте Российской Федерации при участии Всероссийского научно-исследовательского института стандартизации. Разрабатывался взамен ГОСТ Р 34.10-94 для обеспечения большей стойкости алгоритма.

Описание

ГОСТ Р 34.10-2012 и ГОСТ Р 34.10-2001 основаны на эллиптических кривых. Стойкость этих алгоритмов основывается на сложности вычисления дискретного логарифма в группе точек эллиптической кривой, а также на стойкости хэш-функции. Для ГОСТ Р 34.10-2012 используется хэш-функция по ГОСТ Р 34.11-2012. Для ГОСТ Р 34.10-2001 — ГОСТ Р 34.11-94.

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

После подписывания сообщения М к нему дописывается цифровая подпись размером 512 или 1024 бит и текстовое поле. В текстовом поле могут содержаться, например, дата и время отправки или различные данные об отправителе:

Сообщение М

+
Цифровая подпись Текст
Дополнение

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

Алгоритм

Приводится описание варианта схемы ЭЦП с длиной секретного ключа 256 бит. Для секретных ключей длиной 512 бит (второй вариант формирования ЭЦП, описанный в стандарте) все преобразования аналогичны.

Параметры схемы цифровой подписи

J ( E ) = 1728 4 a 3 4 a 3 + 27 b 2 ( mod p ) {\displaystyle J(E)=1728{\frac {4a^{3}}{4a^{3}+27b^{2}}}{\pmod {p}}} , причём 4 a 3 + 27 b 2 ≢ 0 ( mod p ) {\displaystyle 4a^{3}+27b^{2}\not \equiv 0{\pmod {p}}} .

Каждый пользователь цифровой подписи имеет личные ключи:

Дополнительные требования:

Двоичные векторы

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

Блок-схемы:

  • Формирование цифровой подписи

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

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

Криптостойкость

Криптостойкость цифровой подписи опирается на две компоненты — на стойкость хэш-функции и на стойкость самого алгоритма шифрования.

Отличия от ГОСТ 34.10-94 (стандарт 1994—2001 гг)

Использование математического аппарата группы точек эллиптической кривой, позволяет существенно сократить порядок модуля p {\displaystyle p} , без потери криптостойкости.

Также старый стандарт описывает механизмы получения чисел p {\displaystyle p} , q {\displaystyle q} и a {\displaystyle a} .

Возможные применения

Примечания

  1. 1 2 3 4 Игоничкина Е. В. Анализ алгоритмов электронной цифровой подписи. Проверено 16 ноября 2008. Архивировано 22 февраля 2012 года.
  2. Семёнов Г. Цифровая подпись. Эллиптические кривые. «Открытые системы» № 7-8/2002 (8 августа 2002). Проверено 16 ноября 2008. Архивировано 22 февраля 2012 года.
  3. Бондаренко М. Ф., Горбенко И. Д., Качко Е. Г., Свинарев А. В., Григоренко Т. А. Сущность и результаты исследований свойств перспективных стандартов цифровой подписи X9.62-1998 и распределения ключей X9.63-199X на эллиптических кривых. Проверено 16 ноября 2008. Архивировано 22 февраля 2012 года.
  4. RFC 4357, глава 5.2, «VKO GOST R 34.10-2001» — Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms
  5. RFC 4491 — Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure
  6. RFC 4490 — Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)
  7. Leontiev, S., Ed. and G. Chudov, Ed. GOST 28147-89 Cipher Suites for Transport Layer Security (TLS) (англ.) (декабрь 2008). — Internet-Drafts, work in progress. Проверено 12 июня 2009. Архивировано 24 августа 2011 года.
  8. S. Leontiev, P. Smirnov, A. Chelpanov. Using GOST 28147-89, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms for XML Security (англ.) (декабрь 2008). — Internet-Drafts, work in progress. Проверено 12 июня 2009. Архивировано 24 августа 2011 года.
  9. V. Dolmatov, Ed. Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC (англ.) (апрель 2009). — Internet-Drafts, work in progress. Проверено 12 июня 2009. Архивировано 22 февраля 2012 года.

Ссылки

  • ГОСТ Р 34.10-2012. Информационные технологии. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи. (). Проверено 17 июня 2013. Архивировано 17 июня 2013 года.
  • ГОСТ Р 34.10-2001. Информационные технологии. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи. (). Проверено 11 августа 2009. Архивировано 22 февраля 2012 года.

Программные реализации

  • МагПро КриптоПакет. — криптографический проект компании ООО «Криптоком» по добавлению российских криптографических алгоритмов в библиотеку OpenSSL.
    • Проект Эталонная реализация российских алгоритмов шифрования в openssl на сайте GitHub
  • КриптоПро CSP — криптографический проект компании «Крипто-Про».
  • Signal-COM CSP. — криптографический проект компании ЗАО «Сигнал-КОМ».
  • ЛИРССЛ-CSP. — кроссплатформенная криптографическая библиотека компании ООО «ЛИССИ».
  • ViPNet CSP. — программные комплексы, средства криптографической защиты информации компании ОАО «ИнфоТеКС».
  • Проект WebCrypto GOST Javascript библиотека на сайте GitHub
  • Libgcrypt
  • Bouncy Castle

Аппаратные реализации

  • Рутокен ЭЦП 2.0
  • JaCarta-2 ГОСТ
  • ESMART Token ГОСТ.
  • MS_KEY K «Ангара».

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

1. Откройте меню Пуск — Панель управления — КриптоПро CSP.

2. В окне программы КриптоПро CSP перейдите на вкладку Сервис и нажмите кнопку Просмотреть сертификаты в контейнере:

3. В следующем окне нажмите кнопку Обзор, чтобы выбрать контейнер для просмотра (в нашем примере контейнер находится на смарт-карте JaCarta):

4. После выбора контейнера нажмите кнопку Ок, затем Далее.

* Если после нажатия на кнопку Далее Вы видите такое сообщение:

«В контейнере закрытого ключа отсутствует открытый ключ шифрования», следует установить сертификат по рекомендациям, описанным в разделе Вариант 2.

5. В окне Сертификат для просмотра нажмите кнопку Установить:

6. Если откроется сообщение «Этот сертификат уже присутствует в хранилище сертификатов. Заменить существующий сертификат новым, с проставленной ссылкой на закрытый ключ?», нажмите Да:

7. Дождитесь сообщения об успешной установке:

8. Сертификат установлен. Можно закрыть все открытые окна КриптоПро.

Вариант 2. Установка через меню «Установить личный сертификат».

Для установки сертификата этим способом Вам понадобится файл сертификата (файл с расширением.cer). Он может находиться, например, на съемном носителе или на жёстком диске компьютера (если Вы делали копию сертификата или Вам присылали его по электронной почте).

В случае, если файл сертификата отсутствует, напишите письмо с описанием проблемы в техническую поддержку по адресу pu@skbkontur.ru.

1. Откройте меню Пуск — Панель управления — КриптоПро CSP.

2. В окне программы КриптоПро CSP перейдите на вкладку Сервис и нажмите кнопку Установить личный сертификат:

3. В следующем окне нажмите кнопку Обзор, чтобы выбрать файл сертификата:

4. Укажите путь к файлу сертификата и нажмите кнопку Открыть (в нашем примере файл сертификата находится на Рабочем столе):

5. В следующем окне нажмите кнопку Далее; в окне Сертификат для установки нажмите Далее.

6. Поставьте галку в окне Найти контейнер автоматически (в нашем примере контейнер находится на смарт-карте JaCarta) и нажмите Далее:

7. В следующем окне отметьте пункт Установить сертификат (цепочку сертификатов) в контейнер и нажмите Далее:

8. В окне Завершение мастера установки личного сертификата нажмите Готово:

9. Если КриптоПро CSP запрашивает pin-код от контейнера, введите нужный код или попробуйте стандартные pin-коды носителей:

10. Если откроется сообщение «Этот сертификат уже присутствует в хранилище сертификатов. Заменить существующий сертификат новым, с проставленной ссылкой на закрытый ключ?», нажмите Да:

11. Сертификат установлен. Можно закрыть все открытые окна КриптоПро.

Форматы электронной подписи

Статья посвящена обзору стандартов СMS (Cryptographic Message Syntax) для подписанных сообщений.

Для чего нужен CMS

Стандарт CMS описывает структуру криптографических сообщений, включающих в себя защищенные данные вместе со сведениями, необходимыми для их корректного открытия или использования. Например, в сообщении размещаются защищенные данные, информация об алгоритме хеширования и подписи, времени подписи, сертификате открытого ключа, цепочке сертификации и т.д. Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль p, коэффициенты эллиптической кривой a и b и порядок циклической подгруппы точек эллиптической кривой q. И все это нужно каким-то образом передать адресату сообщения.
RSA Laboratories в серии своих стандартов криптографии с открытом ключом (PKCS) предложила решение этой проблемы путем определения синтаксиса для защищенных сообщений в следующих стандартах:

  • PKCS #7 «Cryptographic Message Syntax Standard»,
  • PKCS #10 «Certificate Request Syntax Standard».

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

  • просто данные (data),
  • данные с электронной подписью (signed data),
  • упакованные данные (enveloped data),
  • хешированные данные (digested data),
  • зашифрованные данные (encrypted data),
  • данные с проверкой подлинности (authenticated data).

В рамках статьи мы подробно рассмотрим только данные с электронной подписью (signed data).
Чтобы не путаться в терминологии, далее исходные данные, которые мы хотим передать защищенным способом, будут называться данными, а получившееся защищенное сообщение CMS – просто сообщением.

Стандарт CMS (PKCS #7 и RFC 5652): теория

Чуть истории

Синтаксис криптографических сообщений (CMS) впервые был определен в PKCS #7, который позже был опубликован в качестве рекомендаций RFC 2315 «PKCS #7: Cryptographic Message Syntax Version 1.5». Спустя еще несколько версий RFC в сентябре 2009 года был принят RFC 5652 «Cryptographic Message Syntax (CMS)», который является действующим стандартом на данный момент.
Под спойлером иллюстрируется тяжелая судьба стандарта.
Смотреть
Эволюция PKCS#7/CMS

Подпись в CMS-формате (signed data type)

Подпись, описанная стандартом CMS, характеризуется следующими особенностями:

  1. Данные могут быть подписаны несколькими сторонами (множественная подпись). В таком случае в сообщении будут присутствовать несколько структур SignerInfo с информацией о подписывающих сторонах: значением подписи и необходимой для проверки ее подлинности информацией.
  2. Тип данных никак не регламентируется, лишь уточняется, что в качестве данных может быть сообщение формата CMS, то есть подписанное Алисой сообщение может быть целиком подписано Бобом.
  3. Подписывать можно не только данные, но и некоторые атрибуты сообщения – хеш сообщения (digest message), время подписи (signing time), значение другой подписи (countersignature).
  4. Открытый ключ подписывающей стороны может быть несертифицированным.
  5. Подпись может отсутствовать и вовсе.

Данные с электронной подписью используются не только для подписи содержимого и часто используются для распространения сертификатов и списков отзыва сертификатов (Certification Revocation List, CRL). В таком случае подписываемые данные отсутствуют, а поля Certificates и CRLs, наоборот, присутствуют.
Подписанное Алисой сообщение в формате CMS будет иметь следующий вид (серым отмечены необязательные атрибуты):

  • Версия синтаксиса CMS Version зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах
  • Digest Algorithms включает в себя идентификаторы используемых алгоритмов хеширования и ассоциированные с ними параметры.
  • Encapsulated Content содержит подписываемые данные (Content) вместе с их типом (Content Type). Содержимое может отсутствовать, тип – нет.
  • Certificates предназначен для цепочки сертификатов, отражающих путь сертификации от центра сертификации, выдавшего сертификат, до каждой из подписывающих сторон. Также могут присутствовать сертификаты подписывающих сторон.
  • CRLs (Certificate Revocation List) предоставляет информацию о статусе отзыва сертификатов, достаточную для определения валидности сертификата подписывающей стороны.
  • Информация о каждой подписывающей стороне содержится в структурах типа Signer Info, которых может быть любое количество, в том числе и нулевое (в случае отсутствия подписи).
    • Версия синтаксиса CMS Version определяется значением Signer ID.
    • Signer ID определяет открытый ключ подписывающей стороны (subjectKeyIdentifier) или сертификат его открытого ключа, необходимый для проверки подлинности подписи (issuerAndSerialNumber).
    • Digest Algorithm определяет алгоритм хеширования и все ассоциированные с ним параметры, используемые подписывающей стороной.
    • В Signed Attributes помещаются атрибуты, требующие подписи. Поле может отсутствовать только при подписи простых данных (Content Type = id-data), при подписи других данных (например, Content Type = id-SignedData) должно присутствовать с как минимум двумя обязательными атрибутами – типом (Content Type) и хешем данных (Message Digest).
    • Signature Algorithm содержит идентификатор алгоритма подписи вместе с его параметрами.
    • В Signature Value помещается значение подписанного закрытым ключом хеша от данных (Content) и атрибутов для подписи (Signed Attributes).
    • В Unsigned Attributes помещаются оставшиеся атрибуты, не требующие подписи.

Если Боб решает целиком подписать полученное от Алисы сообщение, то используется механизм инкапсуляции, и сообщение будет выглядеть вот так:
CMS предлагает два интересных атрибута, расширяющих возможности обычной подписи: время подписи (Signing Time) и контрасигнатуру (Countersignature). Первый атрибут определяет предполагаемое время осуществления подписи, а второй предназначен для подписи другой подписи (подписывается хеш от значения подписи). Атрибут Countersignature представляет собой структуру Signer Info с отсутствующим в Signed Attributes атрибутом Content Type и обязательно присутствующим атрибутом Message Digest. Атрибут Countersignature может иметь свой собственный атрибут Countersignature.
Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:

Галопом по Европам оставшимся типам

СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины.
Упакованные данные (enveloped data) представляют собой зашифрованные данные вместе с зашифрованными для одного или более получателей ключами, которыми эти данные были зашифрованы. Комбинация зашифрованного сообщения с одним зашифрованным ключом шифрования для одного получателя называется цифровым конвертом. Данный тип используется в качестве конверта с (подписанными) данными для одного или нескольких получателей.
Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных.
Зашифрованные данные часто используются для шифрования данных для локального хранилища, иногда с выработанным из пароля ключом шифрования.
Данные из аутентифицированного источника (данные с проверкой подлинности) включают в себя данные вместе с их MAC-кодом и зашифрованными ключами аутентификации для одного или нескольких получателей. Используются для защиты целостности сообщений для неограниченного количества получателей.
В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.

CMS в реальной жизни

Стандарт CMS имеет немало воплощений в современном мире IT – на нем основаны:

  • стандарт защищенной электронной почты S/MIME (RFC 3851),
  • расширенные сервисы защиты для S/MIME (RFC 2634, кстати, тут описаны дополнительные атрибуты CMS и технология тройного «обертывания» на основе множественной инкапсуляции: данные подписываются, затем шифруются и снова подписываются),
  • расширенные форматы представления информации об аннулированных сертификатах (RFC 5940) и пр.

Закономерным развитием идей CMS для сообщений с электронной подписью cтал CAdES (CMS Advanced Electronic Signature), расширенный стандарт подписанных сообщений CMS, который также послужит темой для еще одной нашей статьи.

Как реализовать на практике?

Стандарт CMS/PKCS#7 с поддержкой российских криптоалгоритмов реализован в сертифицированных СКЗИ наших партнеров:

  • КриптоПро CSP компании Крипто-Про
  • VipNet CSP компании Инфотекс
  • СигналКом CSP или Message-PRO компании СигналКом и др.

Кроме того, стандарт CMS с российской криптографией реализован в Open Source приложении OpenSSL.
Наша компания поддержала CMS c российской криптографией в продукте Рутокен Плагин. Рутокен Плагин предназначен для использования в браузерах, все криптографические операции производятся аппаратно, «на борту» USB-токена.

Новый ГОСТ-2012 для ЭЦП с 1 января 2020 года

Возможность применения криптографического стандарта выпуска электронной подписи по ГОСТ Р 34.10-2001 прекращается 31 декабря 2019 года, согласно письму ФСБ РФ от 07.09.2018 №149/7/6-363.

В связи с этим, с 1 января 2020 года будут применяться только электронные подписи, выпущенные по ГОСТ Р 34.10-2012. Применение ЭЦП, сформированных на устаревшем ГОСТе, окажется невозможным.

Сертификаты ЭЦП, сформированные в соответствии с ГОСТ-2001, могут использоваться до окончания периода их действия, но лишь до 31 декабря 2019 года. До этого момента допускается использование как действующих сертификатов, сформированных по старому ГОСТ-2001, так и новых, созданных по стандарту ГОСТ-2012.

Как проверить ГОСТ ЭЦП?

1. Перейти по ссылке:
https://www.cryptopro.ru/sites/default/files/products/cades/demopage/cades_bes_sample.html

2. В перечне выбрать сертификат, который нужно проверить:

3. Информация по сертификату, указанному в выделенной строке, будет выведена ниже:

Если в строке “Алгоритм ключа” указан ГОСТ Р 34.10-2001, необходимо осуществить перевыпуск или продление для получения ключа ЭЦП на новом ГОСТе. Для этого обратитесь в организацию, выдавшую вам ЭЦП.

Если алгоритм – ГОСТ Р 34.10-2012, значит, сертификат соответствует требованиям и перевыпуск не требуется.

Как перейти к использованию сертификатов на новом ГОСТ?

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

Чтобы проверить, какая версия КриптоПро установлена на вашем компьютере перейдите в «Пуск» → «Все программы» → «КриптоПро CSP». Поле «Версия продукта» должно содержать значение 4.0.9944.

В случае, если применяемая версия ниже, программу КриптоПро CSP необходимо обновить до версии 4.0 или выше, иначе ЭЦП на новом ГОСТе не будет работать.

Если ваш действующий сертификат имеет встроенную лицензию, то и в новый полученный сертификат также встроена лицензия КриптоПро CSP. В этом случае приобретать лицензию для версии 4.0 не нужно.

Скачать программу КриптоПРО версия 2020 года
https://www.cryptopro.ru/downloads

В иных случаях, для обновления будет необходимо приобретение лицензии.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *