Криптография ГОСТ простыми словами: хэши, подписи, шифрование и сертификаты
Рано или поздно российскому разработчику приходится работать с электронной подписью, сертификатами или программами класса "КриптоПро". После первых поисков легко столкнуться с длинным списком терминов: СКЗИ, ГОСТ Р 34.10, "Стрибог", "Кузнечик", PKCS#7, PKCS#11, CAdES-BES, X.509, отсоединённая подпись и другие.
Проблема в том, что эти понятия относятся к разным уровням одной системы. Одни алгоритмы вычисляют отпечаток файла, другие подтверждают авторство, третьи скрывают содержимое, а стандарты PKCS и X.509 описывают способы хранения ключей, сертификатов и готовых подписей.
Три главные задачи криптографии
Практически любую защищённую систему удобно рассматривать через три базовых механизма: хэширование, электронную подпись и шифрование. У каждого из них собственное назначение.
Хэширование: цифровой отпечаток документа
Хэш-функция принимает данные любого размера и преобразует их в короткую последовательность фиксированной длины. Например, большой договор, архив или файл размером 50 МБ превращается в значение длиной 256 или 512 бит.
Хэш нельзя использовать для восстановления исходного документа. Это не архив и не способ сжатия в обычном смысле, а односторонний цифровой отпечаток.
Главное свойство хэша - чувствительность к изменениям. Если в документе заменить один символ или добавить всего одну запятую, результат вычисления изменится полностью. Поэтому получатель может сравнить хэш исходного и полученного файла и понять, не было ли содержимое изменено.
В российском наборе стандартов для этой задачи применяется ГОСТ Р 34.11-2012, известный как "Стрибог". Он предусматривает варианты с длиной результата 256 и 512 бит.
Электронная подпись: кто подписал и что именно подписали
Электронная подпись отвечает на два вопроса: кто создал подпись и сохранился ли документ в первоначальном виде.
В основе используется асимметричная криптография с парой ключей:
- закрытый ключ хранится у владельца и применяется для создания подписи;
- открытый ключ распространяется вместе с сертификатом и используется для проверки.
Закрытый ключ обычно находится на защищённом токене, смарт-карте или другом устройстве, доступ к которому защищён PIN-кодом. Открытый ключ сам по себе не является секретом: его должны получить все участники, которым необходимо проверять подпись.
На практике подписывается не весь большой файл напрямую, а его хэш. Алгоритм электронной подписи преобразует этот отпечаток с помощью закрытого ключа в цифровую последовательность. Проверяющая сторона заново вычисляет хэш документа и сопоставляет его с данными подписи.
В российской криптографии для электронной подписи используется ГОСТ Р 34.10-2012. Стандарт основан на криптографии эллиптических кривых и предусматривает ключи длиной 256 или 512 бит.
Шифрование: защита содержимого
Подпись подтверждает подлинность документа, но не скрывает его текст. Если необходимо сделать данные недоступными для посторонних, применяется шифрование.
Симметричный алгоритм использует один секретный ключ: им данные зашифровываются и им же расшифровываются. Главная сложность такой схемы - безопасно передать ключ второй стороне.
К российским симметричным алгоритмам относятся ГОСТ 34.12-2015 "Магма" и "Кузнечик". "Магма" связана с развитием ГОСТ 28147-89, а "Кузнечик" представляет собой более новую конструкцию.
Важно не путать подпись и шифрование. Подписанный файл может оставаться полностью читаемым, а зашифрованный документ не обязательно подтверждает личность отправителя.
Как развивались отечественные стандарты
Криптографические алгоритмы периодически пересматриваются: растёт вычислительная мощность компьютеров, обнаруживаются слабые места, совершенствуются методы атак. Поэтому старые стандарты постепенно выводятся из эксплуатации.
Первое поколение
В 1990-е годы применялись:
- ГОСТ Р 34.10-94 для электронной подписи;
- ГОСТ Р 34.11-94 для хэширования;
- ГОСТ 28147-89 для симметричного шифрования.
Сегодня этот набор считается устаревшим.
Второе поколение
В 2000-е появился ГОСТ Р 34.10-2001, построенный на эллиптических кривых. Для хэширования при этом продолжал использоваться ГОСТ Р 34.11-94.
Выпуск сертификатов на базе ГОСТ Р 34.10-2001 официально прекратили в 2019 году, поэтому в новых системах ориентироваться на него не следует.
Современный набор
Актуальное поколение включает:
- ГОСТ Р 34.10-2012 - электронная подпись;
- ГОСТ Р 34.11-2012 - хэширование, "Стрибог";
- ГОСТ Р 34.12-2015 - симметричное шифрование "Магма" и "Кузнечик".
Именно эти названия чаще всего встречаются в современных сертификатах, криптопровайдерах и технических требованиях.
Чем ГОСТ отличается от зарубежных алгоритмов
Логика российской криптографии не уникальна. Западные системы решают те же задачи с помощью других стандартов:
- SHA-256 и SHA-512 выполняют роль хэш-функций;
- RSA и ECDSA применяются для электронной подписи;
- AES используется для симметричного шифрования;
- TLS защищает сетевое соединение;
- сертификаты описываются стандартом X.509.
Различие заключается не в самих задачах, а в конкретных математических алгоритмах, форматах данных, правилах сертификации и требованиях регуляторов.
Что такое PKCS и X.509
PKCS - семейство стандартов, описывающих форматы криптографических объектов. Они помогают разным программам одинаково понимать ключи, сертификаты и подписи.
PKCS#11: доступ к токену
PKCS#11 - программный интерфейс для работы с криптографическим оборудованием. Через него приложение может обращаться к токену, находить сертификаты, использовать закрытый ключ и создавать подпись, не извлекая секретный ключ наружу.
Это особенно важно с точки зрения безопасности: закрытый ключ может навсегда оставаться внутри защищённого устройства.
PKCS#12: контейнер с ключом и сертификатом
PKCS#12 используется для хранения закрытого ключа, сертификата и связанных данных в одном контейнере. Файлы такого типа часто имеют расширение `.pfx` или `.p12` и защищаются паролем.
Такой контейнер нужно считать секретным: он может содержать закрытый ключ. Передача его по незащищённым каналам или хранение без пароля создаёт серьёзный риск.
PKCS#10: запрос на сертификат
PKCS#10 описывает запрос на выпуск сертификата. В нём указывается открытый ключ и сведения о владельце, а сам запрос подписывается соответствующим закрытым ключом.
Центр сертификации проверяет заявку и после необходимых процедур выпускает сертификат.
X.509: цифровой паспорт открытого ключа
Сертификат X.509 связывает открытый ключ с его владельцем. В нём содержатся имя субъекта, открытый ключ, срок действия, данные центра сертификации, идентификаторы алгоритмов и электронная подпись самого удостоверяющего центра.
Файлы сертификатов часто имеют расширения `.cer` или `.crt`. Однако расширение не гарантирует конкретный формат хранения: сертификат может быть представлен в бинарном виде DER или в текстовом формате PEM.
Проверять нужно не только срок действия сертификата, но и цепочку доверия, назначение ключа, соответствие алгоритма и наличие отзыва.
Форматы готовых подписей
После создания подписи нужно определить, как упаковать её вместе с документом.
PKCS#7 и CMS
PKCS#7, а в более современном варианте CMS, служит универсальным контейнером для подписей и сертификатов. Он может содержать сам документ или только подпись, связанную с внешним файлом.
Если контейнер включает исходные данные, подпись называют присоединённой. Если файл хранится отдельно, используется отсоединённая подпись. В последнем случае для проверки обязательно нужны и исходный документ, и файл подписи.
CAdES
CAdES развивает CMS и добавляет профили, необходимые для долговременного использования электронной подписи. Например, можно включить сведения о времени подписания, сертификатах, ответах служб проверки статуса и доказательствах, позволяющих проверять подпись спустя годы.
Обозначение CAdES-BES обычно означает базовую подпись с минимальным набором дополнительных данных. Более сложные профили предназначены для долгосрочного хранения и усиленной проверки.
XAdES и PAdES
XAdES применяется для подписания XML-документов. Такой формат удобен в интеграциях между информационными системами, где данные уже представлены в XML.
PAdES предназначен для PDF. Подпись может быть встроена внутрь самого PDF-файла, а отображение информации о подписанте - добавлено на страницу документа.
Выбор формата зависит не от личных предпочтений разработчика, а от требований информационной системы, формата исходного файла и нормативных правил.
Что учитывать при проектировании
Перед реализацией подписи нужно определить несколько вещей:
1. Какой алгоритм требуется: ГОСТ 2012, старый стандарт или другой профиль.
2. Где будет храниться закрытый ключ: токен, файловый контейнер, HSM или иной носитель.
3. Нужна ли отсоединённая подпись.
4. Должен ли подписанный контейнер включать сертификат.
5. Требуется ли долгосрочная проверка подписи.
6. Кто и как будет проверять цепочку доверия.
7. Нужно ли шифровать данные помимо их подписания.
8. Как будет обрабатываться отзыв сертификата и окончание его срока действия.
Отдельное внимание следует уделить кодировкам, каноникализации XML, формату бинарных данных и обработке ошибок. Даже корректный криптографический алгоритм не спасёт систему, если разные участники по-разному сериализуют один и тот же документ.
Итоговая схема
Упрощённый процесс выглядит так:
1. Система получает исходный документ.
2. Вычисляет его хэш с помощью подходящей функции.
3. Создаёт подпись закрытым ключом.
4. Формирует контейнер PKCS#7/CMS, CAdES, XAdES или PAdES.
5. При необходимости добавляет сертификат и данные проверки.
6. Передаёт результат получателю.
7. Получатель проверяет сертификат, подпись и соответствие документа исходному хэшу.
Главное правило - не смешивать уровни. "Стрибог" не подписывает документы, ГОСТ Р 34.10-2012 не шифрует файлы, сертификат X.509 не заменяет закрытый ключ, а PKCS#7 не является самостоятельным алгоритмом. Когда роли каждого элемента разделены, работа с российской криптографией перестаёт выглядеть набором загадочных аббревиатур и превращается в понятную инженерную задачу.