Алгоритм ЭЦП ГОСТ в сертификатах: 34.10-2012 и OID

Алгоритм электронной подписи ГОСТ в российских сертификатах — это связка двух стандартов: ГОСТ Р 34.10-2012 формирует и проверяет саму подпись на эллиптических кривых, ГОСТ Р 34.11-2012 (Стрибог) считает хеш документа. В сертификате они видны как пара OID: алгоритм открытого ключа 1.2.643.7.1.1.1.1 и алгоритм подписи 1.2.643.7.1.1.3.2. Старые ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94 для формирования новых подписей не применяются с 1 января 2019 года. Главное различие внутри действующего стандарта — длина ключа: вариант 256 бит дает подпись 64 байта и OID подписи 1.2.643.7.1.1.3.2, вариант 512 бит — подпись 128 байт и OID 1.2.643.7.1.1.3.3.

Разберем, какие поля сертификата читать, чем 256-битный вариант отличается от 512-битного и почему набор параметров кривой ломает интеграцию чаще, чем сам алгоритм. Покажем, где OID алгоритма лежит внутри контейнера CMS и почему расширение файла подписи о нем ничего не говорит. Таблица OID, сценарная таблица по носителям и криптопровайдерам, тарифы на подключение КЭДО с электронными подписями и ответы на частые вопросы — во второй половине статьи.

Загрузите документ и файл подписи: сервис покажет алгоритм открытого ключа, хеш-алгоритм, издателя сертификата и срок его действия.

Проверка электронной подписи

Покажем, кто и когда подписал документ и действует ли сертификат. Без регистрации.

1 Выберите вид подписи:

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

Открепленная подписьДва файла: сам документ и отдельный файл подписи (.sig).

2 Загрузите документ и файл подписи:

Документ

Перетащите или выберите файл Максимальный размер файла 100 МБ

Файл подписи (.sig)

Перетащите или выберите файл Максимальный размер файла 100 МБ

Нажимая кнопку «Проверить подпись», я даю свое согласие на обработку моих персональных данных, в соответствии с Федеральным законом от 27.07.2006 года №152-ФЗ «О персональных данных», на условиях и для целей, определенных в Согласии на обработку персональных данных.

Сбросить Проверить подпись

Нужно подписать документ?

Подпишите прямо в браузере через КриптоПро. На PDF можно поставить штамп в нужном месте.

Подписать документ

Какой алгоритм ГОСТ используется в сертификатах: 34.10-2012 плюс 34.11-2012

Одного алгоритма в сертификате не бывает. Российская электронная подпись всегда собрана из двух стандартов, и в структуре сертификата X.509 они лежат в разных полях. ГОСТ Р 34.10-2012 описывает процессы формирования и проверки подписи через операции в группе точек эллиптической кривой над конечным простым полем. ГОСТ Р 34.11-2012 описывает функцию хеширования, которой документ сжимается перед подписанием. Оба стандарта утверждены приказом Росстандарта от 7 августа 2012 года и разработаны Центром защиты информации и специальной связи ФСБ России совместно с ОАО «ИнфоТеКС».

Пожалуйста, подпишитесь на нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

В поле Signature Algorithm сертификата стоит составной идентификатор: он сразу называет и схему подписи, и хеш-функцию. Поле Public Key Algorithm называет только схему подписи для ключа владельца. Отдельно от них лежат параметры открытого ключа — идентификатор набора параметров эллиптической кривой. Три разных места, три разных OID, и путаница между ними дает большую часть вопросов вида «почему у контрагента подпись не проверяется».

Ниже — идентификаторы, которые реально встречаются в российских квалифицированных сертификатах.

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

Как определить алгоритм ГОСТ в своем сертификате: пошаговая инструкция

1. Шаг 1. Откройте сертификат и перейдите на вкладку «Состав». Найдите строки «Алгоритм подписи» и «Хеш-алгоритм подписи» — это алгоритм, которым удостоверяющий центр подписал сам сертификат.
2. Шаг 2. В той же вкладке откройте поля «Открытый ключ» и «Параметры открытого ключа». Первое дает схему подписи владельца, второе — идентификатор набора параметров эллиптической кривой.
3. Шаг 3. Сверьте оба значения с таблицей OID. Если в поле подписи стоит 1.2.643.7.1.1.3.2, а в ключе 1.2.643.7.1.1.1.1, перед вами стандартный 256-битный вариант.
4. Шаг 4. Проверьте цепочку сертификации. Алгоритм подписи корневого и промежуточного сертификатов задает удостоверяющий центр, и он может отличаться от алгоритма ключа владельца.
5. Шаг 5. Проверьте алгоритм на готовом подписанном файле, а не только на сертификате. В протоколе проверки видно, какой хеш реально применялся при подписании конкретного документа.

Мария Ж, специалист по цифровой подписи и КЭДО: «Сертификат показывает, каким алгоритмом можно подписывать, а протокол проверки — каким подписали на самом деле. Это разные вещи, и при разборе спорного документа смотреть нужно именно на протокол: там видны и алгоритмы, и время подписания, и цепочка сертификации. Сохраняйте протокол вместе с файлом подписи, а не восстанавливайте его задним числом.»

256 или 512 бит: чем отличаются варианты и где это заметно

ГОСТ Р 34.10-2012 отличается от предшественника прежде всего наличием второго набора параметров — для секретного ключа порядка 512 бит. Схема формирования подписи в обоих вариантах одна, меняются длина ключа, длина хеша и размер результата. Подпись по 256-битному варианту занимает 64 байта, по 512-битному — 128 байт. Хеш-функция ГОСТ Р 34.11-2012 тоже двухвариантная: 256 и 512 бит, и она обязана соответствовать длине ключа.

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

Отдельная история — набор параметров кривой. Алгоритм может совпадать, а paramSet различаться, и тогда подпись формально валидна, но конкретная система ее не принимает. При интеграции сверять нужно три значения: OID алгоритма подписи, OID алгоритма открытого ключа и OID параметров кривой. Список допустимых наборов принимающая система обычно фиксирует в настройках проверки формата сертификатов, и этот список стоит запросить до начала работ, а не после первой ошибки.

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

Старые ГОСТ Р 34.10-2001 и 34.11-94: что с ними стало

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

Отсюда практическое правило для архивного хранения: одного файла подписи мало. Нужны сертификат подписанта, сертификаты цепочки, список отзыва на дату подписания и, желательно, штамп времени. Форматы CAdES-T и CAdES-A для этого и придуманы: штамп времени фиксирует момент подписания независимо от того, истек ли потом сертификат.

Пожалуйста, подпишитесь на нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

Во что обходится неверно выбранный алгоритм

Цена ошибки здесь не равна стоимости перевыпуска сертификата. Если сертификат выпущен с параметрами, которых не принимает информационная система контрагента, все документы, подписанные за период до обнаружения проблемы, придется переподписывать заново — с актом о невозможности переподписания там, где вторая сторона уже недоступна. В кадровом документообороте последствия жестче: документ, подписанный подписью, которую нельзя проверить, при проверке ГИТ трактуется как неоформленный, а это штраф на юридическое лицо от 30 000 до 50 000 рублей по части 1 статьи 5.27 КоАП РФ.

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

Где алгоритм записан в файле подписи: sig, p7s и CAdES

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

Идентификаторы алгоритмов лежат в двух местах контейнера: digestAlgorithm описывает хеш-функцию, signatureAlgorithm — схему подписи. Значения там те же самые, что и в сертификате. Если в контейнере алгоритм один, а в сертификате подписанта другой, проверка падает на несоответствии, и переустановка провайдера это не лечит.

Чем открыть p7s и почему расширение ничего не говорит об алгоритме

Расширение файла подписи задается настройкой приложения, а не стандартом. В Инструментах КриптоПро расширение подписанного файла выбирается из списка p7s, sig, sgn, в КриптоАРМ ГОСТ к ним добавляются sign и bin. Содержимое при этом одинаковое: тот же CMS с теми же OID. Файл с расширением p7s от контрагента открывается любым средством, которое умеет CMS и понимает ГОСТ-идентификаторы.

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

Важный нюанс из практики: формат подписи и профиль усовершенствования тоже настраиваются приложением. В параметрах подписания выбирается CAdES-BES или вариант со штампом времени, и по умолчанию там стоит BES — без штампа. Для документов, которые переживут срок действия сертификата, этот выбор нужно менять руками.

Мария Ж, судебный эксперт по трудовому праву: «Когда электронный документ попадает в спор, вопрос почти никогда не стоит про стойкость ГОСТа. Вопрос стоит про то, можно ли сегодня подтвердить, что подпись была действительна в момент подписания. Поэтому мы советуем хранить не только подписанный файл, но и протокол проверки со штампом времени и цепочкой сертификации.»

Формы для учета сертификатов и разбора ошибок проверки

Комплект для администратора, который выдает токены и разбирает жалобы «подпись не проходит»: начните с чек-листа диагностики, остальное подключайте по мере надобности.

Носители и криптопровайдеры: где ГОСТ считается на самом деле

Стандарт описывает математику, но считает ее конкретное средство. Ключи делятся на две группы. Программные генерируются криптопровайдером, и токен работает как защищенное пин-кодом хранилище: при подписании закрытый ключ ненадолго попадает в оперативную память компьютера. Такие ключи называют извлекаемыми, а носители — пассивными. Аппаратные ключи генерируются внутри криптоядра микроконтроллера токена, наружу не выходят и скопировать их нельзя — это неизвлекаемые ключи, а носители называют активными.

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

Мария Ж, соучредитель сервиса КЭДО Добыто: «Перед выбором формата ключа мы всегда спрашиваем, на скольких рабочих местах он будет жить. Если человек носит токен между машинами, часть из которых работает на КриптоПро CSP 4.0, ему нужен пассивный извлекаемый контейнер: неизвлекаемые ключи поддерживаются начиная с пятой версии провайдера. Уточните версии провайдера на всех рабочих местах до выпуска сертификата, а не после.»

Из носителей с аппаратным ГОСТом на рынке представлены Рутокен ЭЦП 3.0 и ESMART Token ГОСТ. У ESMART Token ГОСТ на отечественном чипе MIK51 аппаратно реализованы ГОСТ 28147-89, ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012, сертификат ФСБ России выдан по классам КС1, КС2 и КС3. Носитель поддерживается основными российскими криптопровайдерами, включая КриптоПро CSP, и совместим с Astra Linux, ALT Linux и РЕД ОС.

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

Логика тут одна: длина ключа почти никогда не решающий параметр, а версия провайдера и режим генерации контейнера — почти всегда.

ГОСТ вне подписи: шифрование, TLS и защита писем

Подпись — только часть российской криптографии в сертификате. За симметричное шифрование отвечают алгоритмы ГОСТ Р 34.12-2015: Кузнечик с блоком 128 бит и Магма с блоком 64 бита. В КриптоПро CSP они поддерживаются начиная с версии 5.0 R2. Банк России ведет работы по переходу на эти алгоритмы и рекомендует их банкам при взаимодействии с регулятором, поэтому для финансового сектора обновление провайдера минимум до 5.0 R2 — вопрос совместимости, а не вкуса.

Для веб-ресурсов действует отдельная ветка — TLS с российской криптографией. В КриптоПро CSP 5.0 R3 добавлена поддержка TLS 1.3 с российскими алгоритмами по классу КС1, встроен браузерный плагин и появился SDK для встраивания усовершенствованных подписей и обращения к службам штампов времени и статусов сертификатов. Серверные ГОСТ-сертификаты для сайтов выпускает Национальный удостоверяющий центр, там же выдаются и RSA-сертификаты, а корневые сертификаты Минцифры устанавливаются через портал государственных услуг.

Электронное письмо защищается тем же набором стандартов через S/MIME: подпись считается по ГОСТ 2012, шифрование — по ГОСТ 2015. Почтовый клиент КриптоАРМ ГОСТ 3 подключается к серверам по IMAP, SMTP и POP3, для соединения требуется защищенный канал по ГОСТ, а зашифрованные письма в списке помечаются замком. Для организаций, которым запрещено использовать иностранное ПО, это рабочий способ пересылать по почте персональные данные, машиночитаемые доверенности и коммерческую тайну.

ГОСТ в кадровом документообороте: виды ЭЦП и данные МЧД

В КЭДО ГОСТ работает не везде. Простая электронная подпись криптографии не содержит вовсе: это логин, пароль, код из СМС и запись в журнале системы, а ее юридическая сила держится на соглашении сторон и локальном нормативном акте. Усиленная неквалифицированная и усиленная квалифицированная подписи строятся на ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012, и различаются они не алгоритмом, а тем, аккредитован ли выпустивший сертификат удостоверяющий центр и соответствует ли средство подписи требованиям ФСБ России.

Виды подписи для кадровых документов закреплены статьей 22.3 ТК РФ, введенной 377-ФЗ, а общие правила — статьями 5 и 14 63-ФЗ от 6 апреля 2011 года. Требования к форме квалифицированного сертификата утверждены приказом ФСБ России от 27 декабря 2011 года № 795; в редакции приказа ФСБ России от 2 февраля 2024 года № 50 они действуют до 1 сентября 2027 года. Требования к средствам электронной подписи и средствам удостоверяющего центра установлены приказом ФСБ России от 27 декабря 2011 года № 796.

Важный нюанс из практики: в тарифах Добыто ПЭП и УНЭП для сотрудников выпускаются бесплатно на всех тарифах, а УКЭП оформляется через партнеров-удостоверяющих центров. При планировании перехода на КЭДО это меняет не стоимость, а сроки: собственная выдача идет минутами, внешний выпуск квалифицированного сертификата — по регламенту удостоверяющего центра.

Машиночитаемая доверенность живет по тем же правилам. Данные МЧД — это XML-файл с реквизитами доверителя, представителя, сроком и кодами полномочий из классификатора Единой системы нормативной справочной информации. Подписывается МЧД квалифицированной подписью руководителя, обычно открепленной подписью отдельным файлом, и передается вместе с документом. Алгоритмы там те же, что и в любом другом ГОСТ-сертификате, отдельной криптографии для МЧД не существует.

Мария Ж, юрист со стажем более 20 лет: «Коды полномочий в машиночитаемой доверенности нужны не человеку, а алгоритму: система автоматически сверяет, есть ли у подписанта право подписывать именно этот документ. Пока классификатор наполняется, часть полномочий вписывается текстом, и как раз здесь чаще всего расходятся ожидания сторон. Согласуйте формулировку полномочия с принимающей стороной до выпуска доверенности.»

Для филиала отдельного субъекта права не возникает: доверенность выдает юридическое лицо, а руководитель филиала действует по доверенности от организации. Если полномочия нужно передать дальше по цепочке, передоверие оформляется у нотариуса: он проверяет паспортные данные нового представителя и актуальную выписку из ЕГРЮЛ, подписывает новую доверенность своей квалифицированной подписью и выгружает ее в информационную систему. Проверить готовую пару из сертификата представителя и доверенности можно в сервисе проверки на портале государственных услуг, где отдельно загружаются сертификат, XML доверенности и файл открепленной подписи.

Когда разбираться в алгоритме ГОСТ не нужно

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

В практике Добыто мы закладываем пилотную группу до раскатки КЭДО на всю компанию именно поэтому: на пилоте выясняется, какая часть сотрудников реально столкнется с токенами и провайдером, а какая обойдется подписью, выпущенной внутри сервиса.

Стоимость подключения КЭДО и электронных подписей

Стоимость зависит от численности сотрудников, набора видов подписи и потребности в интеграции с учетной системой.

Итоговая сумма складывается из численности, выбранного набора видов подписи и необходимости выделенного сервера с SLA. Разбивка по функциям и условия перехода между планами собраны на странице тарифов ДОБЫТО КЭДО: при повышении тарифа разница пересчитывается пропорционально оставшемуся периоду.

Выводы

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

Мы в Добыто занимаемся кадровым электронным документооборотом и подписью в нем: выпускаем ПЭП и УНЭП сотрудникам внутри сервиса, разбираем ошибки проверки чужих файлов и настраиваем маршруты подписания под структуру компании. Если разбор алгоритмов нужен ради того, чтобы кадровые документы стабильно проходили проверку, эту часть закрывают настройки сервиса, а не ручное чтение OID.

Частые вопросы

Почему OpenSSL не проверяет ГОСТ-подпись и как это чинить

Без подключенного ГОСТ-движка OpenSSL не знает идентификаторов вида 1.2.643.7.1.1.3.2 и возвращает ошибку неизвестного алгоритма подписи, а не сообщение о неверной подписи. Лечится подключением ГОСТ-движка к сборке OpenSSL либо проверкой через криптопровайдер с поддержкой российских алгоритмов. Диагностический признак простой: если инструмент ругается на алгоритм, проблема в окружении; если на значение хеша — в файле.

Сколько байт занимает подпись по ГОСТ и почему файл sig весит килобайты

Само значение подписи занимает 64 байта для 256-битного варианта и 128 байт для 512-битного. Остальной объем файла — это контейнер CMS: сертификат подписанта, цепочка сертификации, при наличии список отзыва, штамп времени TSP и служебные поля. Поэтому открепленная подпись обычно весит несколько килобайт, а при усовершенствованном формате — заметно больше.

Можно ли подписать документ ГОСТом для иностранного контрагента

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

Что делать, если забыт пароль от контейнера или пин-код токена

Закрытый ключ по паролю не восстанавливается: при исчерпании попыток ввода пин-кода носитель блокируется, а для неизвлекаемых ключей копии не существует в принципе. Единственный путь — обращение в удостоверяющий центр за перевыпуском сертификата и генерацией нового ключа. Ранее подписанные документы при этом остаются действительными, переподписывать их не требуется.

Чем ГОСТ 34.10-2018 отличается от ГОСТ Р 34.10-2012

ГОСТ 34.10-2018 — межгосударственный стандарт, разработанный на основе национального ГОСТ Р 34.10-2012 и введенный в действие с 1 июня 2019 года. Схема формирования подписи та же самая, включая вариант параметров для секретного ключа порядка 512 бит. В российских квалифицированных сертификатах в полях алгоритмов указывается национальный стандарт.

Можно ли хранить несколько сертификатов с разными алгоритмами на одном токене

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

Кто отвечает за выбор алгоритма при выпуске сертификата

Набор алгоритмов и параметров определяет удостоверяющий центр по своему регламенту и по требованиям информационной системы, для которой выпускается сертификат. Запросить конкретный вариант можно, но право выбора остается за центром: он обязан выпускать сертификаты по форме, утвержденной приказом ФСБ России № 795, и в рамках сертифицированных средств удостоверяющего центра.