Введение

Каждый разработчик в России рано или поздно проходит через то, что к нему приходит менеджер и говорит, что нужно что-то как-то подписывать через КриптоПро. Разработчик начинает искать информацию в интернете и получает в выдаче кучу терминов вроде СКЗИ, ГОСТ Р 34.10, Стрибог, Кузнечик, PKCS#7, PKCS#11, CAdES-BES, X.509, отсоединенная подпись и др. Попытки во всём этом разобраться приводят его либо на строгие академические статьи с тоннами высшей математики, либо на форумы КриптоПро, где суровые системные администраторы общаются на своём эльфийском.

Дальше будет попытка разобраться во всём этом на человеческом языке.

1. Три кита криптографии: Хэш, Подпись и Шифр

Самая частая ошибка новичков (и авторов плохих ТЗ) - свалить все криптографические термины в одну кучу. В любой современной защищённой системе (будь то ГОСТ или западный стек) работают три абсолютно разных «кита». У каждого из них своя математика и своя строгая роль. Давайте разберём их обязанности.

Кит первый: Хэширование

Например, ГОСТ Р 34.11-2012 (он же «Стрибог»)

Представьте, что у вас есть огромный договор на 50 мегабайт. Гонять такой объем данных через сложные математические формулы подписи — долго и вычислительно дорого. Поэтому документ сначала нужно «сжать» без потери уникальности.

Функция хэширования берет файл любого размера и превращает его в короткую строку фиксированной длины (например, в 64 символа).

• Главное свойство: Из хэша невозможно восстановить исходный текст.

• Главный эффект: Если вы измените в договоре на 50 МБ хотя бы одну запятую, итоговый хэш изменится до неузнаваемости.

Кит второй: Асимметричная электронная подпись

Например, ГОСТ Р 34.10-2012

Электронная подпись отвечает на два главных вопроса: «Кто это подписал?» и «Не изменился ли документ по дороге?». Она работает на базе асимметричной криптографии, где у вас всегда есть пара ключей:

1. Закрытый ключ: Лежит у вас на защищенном токене или флешке под пин-кодом. Знаете его только вы. Им вы генерируете подпись.

2. Открытый ключ: Доступен всему миру внутри вашего сертификата. С его помощью любой проверяющий (или сервер ФНС) может убедиться, что подпись сделана именно вашим закрытым ключом.

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

Кит третий: Симметричное блочное шифрование

Например, ГОСТ Р 34.12-2015 (шифры «Магма» и «Кузнечик»)

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

2. Три поколения отечественной криптографии (История ГОСТ)

Криптография не стоит на месте: компьютеры становятся мощнее, математики находят новые уязвимости, а суперкомпьютеры учатся быстрее перебирать ключи. Поэтому регуляторы примерно раз в 10–15 лет проводят масштабную ревизию стандартов и принудительно переводят всю страну на новые алгоритмы.

3. А что у них? Западные аналоги

Российские ГОСТы не уникальны по своей логике — они решают те же самые задачи, что и международные алгоритмы. Чтобы вам было проще ориентироваться, давайте сопоставим наши алгоритмы с тем западным стеком (RSA, AES, SHA), с которым вы наверняка сталкивались при настройке обычного веб-сервера Nginx или работы с JWT-токенами.

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

4. Разбираемся с семейством стандартов PKCS и X.509

В предыдущих главах мы разобрались с математикой: у нас есть хэш «Стрибог», подпись ГОСТ 34.10 и шифр «Магма». Но как операционная система или ваш код на Python узнают, что конкретный набор байт — это именно открытый ключ ГОСТ, а не кусок видеофайла?

Математика без стандартов упаковки бесполезна. Чтобы софт разных разработчиков понимал друг друга, компания RSA Security создала семейство стандартов PKCS (Public-Key Cryptography Standards), а комитет ITU-T — стандарт X.509.

Как достучаться до железа: PKCS #11 и PKCS #1

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

• PKCS #11 — это стандарт единого интерфейса (драйвера) для работы с аппаратными устройствами [OASIS PKCS11 TC]. Программа (например, КриптоПро) отправляет хэш внутрь токена по правилам PKCS#11, токен сам внутри себя подписывает его ГОСТом и отдает обратно только сырые байты подписи.

• Связь с Западом: Для алгоритма RSA существует свой базовый стандарт PKCS #1, который описывает самую элементарную математику западной подписи [RFC 8017]. Для ГОСТа аналогом PKCS#1 являются сами российские стандарты.

Как хранить и запрашивать ключи: PKCS #12 и PKCS #10

Если ваш ключ хранится не на токене, а в виде файла на диске, или если вы только собираетесь получить подпись в Удостоверяющем центре (УЦ), в силу вступают другие стандарты:

• PKCS #10 (Файлы .csr) — это стандарт запроса на выпуск сертификата [RFC 2986]. Вы генерируете пару ключей на компьютере, упаковываете свой открытый ключ и анкетные данные (ФИО, ИНН) по правилам PKCS#10 и отправляете этот файл в УЦ. В ответ вам будет выслан файл .cer - ваш сертификат.

• PKCS #12 (Файлы .pfx или .p12) — это стандарт защищенного контейнера [RFC 7292]. Если приватный и публичный ключ генерирует УЦ, тогда он может выдать вам один файл, в котором под надежным паролем (зашифрованный «Магмой» или AES) лежат вместе и ваш закрытый ключ, и ваш открытый сертификат.

Цифровой паспорт: X.509 (Файлы .cer или .crt)

Когда УЦ проверил ваши документы, он выпускает ваш главный цифровой паспорт — сертификат соответствия стандарта X.509 [RFC 5280].

• Обоснование: Этот стандарт строго определяет, в каких именно метаполях будут записаны ваш ИНН, СНИЛС, ОГРН, имя компании, срок действия подписи и, самое главное, сам ваш открытый ключ ГОСТ вместе с идентификаторами алгоритмов (OIDs) [RFC 5280]. Благодаря X.509 любая программа в мире знает, как прочитать ваши данные.

5. Форматы готовых подписей: PKCS #7, CAdES, XAdES и PAdES

Теперь мы подошли к финальной точке. Ваш код на Python взял хэш файла (Кит 1), через КриптоПро попросил токен (по протоколу PKCS#11) подписать его закрытым ключом (Кит 2). На выходе вы получили «сырые» байты подписи — просто набор случайных символов.

Если вы отправите эти сырые байты проверяющей стороне (например, в Честный Знак), их система выдаст ошибку. Почему? Потому что проверяющий софт не знает, чей это открытый ключ, в какое время была сделана подпись и какой именно ГОСТ использовался. Сырую подпись нужно упаковать в «коробку».

Базовая коробка: PKCS #7 / CMS

PKCS #7 (в современных стандартах называется CMS — Cryptographic Message Syntax) — это общепринятый стандарт упаковки криптографических сообщений [RFC 2315].

• Что внутри: Метод signedData в вашем коде берет сырые байты подписи и упаковывает их в структурированный контейнер ASN.1. Туда же он дописывает идентификаторы алгоритмов ГОСТ и встраивает ваш сертификат X.509, чтобы проверяющий сразу видел, кто подписал документ.

Усовершенствованные коробки под разные задачи

Обычный PKCS#7 имеет огромный минус: в нем нет доверенного штампа времени. Вы можете перевести часы на компьютере назад и подписать документ «прошедшим числом». Чтобы решить эту проблему и адаптировать подпись под разные типы файлов, криптографы создали три усовершенствованных формата.

• CAdES (CMS Advanced Electronic Signatures):

  Обоснование: Это расширение PKCS#7 [CAdES от КриптоПро]. Именно его вы используете в коде, указывая флаг CADESCOM_CADES_BES. Формат CAdES позволяет добавлять в подпись подписанные атрибуты времени (signingTime) и внешние штампы времени от штамп-серверов (TSA) [Жизненного цикла ЭП]. Идеален для отсоединенных подписей (когда подпись лежит в отдельном файле .sig рядом с исходным документом).

• XAdES (XML Advanced Electronic Signatures):

  Обоснование: Если вы подписываете строго структурированный XML-документ (например, счет-фактуру для налоговой), создавать отдельный .sig файл неудобно. Стандарт XAdES описывает, как упаковать подпись ГОСТ в виде валидных XML-тегов прямо внутрь самого документа [ETSI EN 319 132].

• PAdES (PDF Advanced Electronic Signatures):

  Обоснование: Создан специально для документов PDF. Подпись ГОСТ зашивается в специальный бинарный сектор внутри PDF-файла [ETSI EN 319 142]. Когда пользователь открывает такой файл в Adobe Reader, программа видит эту структуру, проверяет её по цепочке сертификатов и отображает красивый интерактивный штамп: «Документ подписан цифровой подписью».

Заключение

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

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