Работа с электронной подписью по ГОСТ (ограничения)

jsrsasign изначально ориентирована на реализацию криптографических операций в среде JavaScript без необходимости нативных расширений. Основной акцент сделан на алгоритмах RSA, ECDSA, SHA-1, SHA-2 и форматах X.509, PKCS#1, PKCS#8, PKCS#7 (CMS).

Поддержка ГОСТ-алгоритмов (ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ 28147-89) в данной библиотеке отсутствует в базовой поставке. Это формирует ключевое ограничение при попытке использования библиотеки в инфраструктурах, где требуется соответствие российским криптографическим стандартам.

Архитектурное ограничение криптографического ядра

Внутреннее криптографическое ядро реализовано на JavaScript и не использует нативные провайдеры ОС. Это приводит к нескольким системным ограничениям:

• отсутствие интеграции с CryptoAPI (Windows) и OpenSSL-провайдерами
• невозможность использования сертифицированных криптопровайдеров
• фиксированный набор алгоритмов, заложенный в библиотеку
• отсутствие поддержки нестандартных эллиптических кривых ГОСТ

ГОСТ-алгоритмы требуют специфических параметров кривых, форматов подписи и хеширования, которые не совпадают с реализациями ECDSA и SHA, используемыми в jsrsasign.

Почему ГОСТ сложно реализовать в JavaScript-криптографии

ГОСТ-стандарты отличаются не только алгоритмически, но и инфраструктурно:

1. Отличия в математической модели

ГОСТ Р 34.10-2012 использует эллиптические кривые с параметрами, отличными от secp256r1/secp256k1. Это требует:

• поддержки кривых вида id-tc26-gost-3410-12-256-paramSetA/B
• иной структуры точки и операций умножения
• специфического детерминированного генератора подписи

В jsrsasign реализация ECC ограничена стандартными кривыми NIST.

2. Отличия в хешировании

ГОСТ Р 34.11-2012 (Стрибог) не входит в стандартный набор SHA-функций:

• SHA-256 / SHA-512 используются в jsrsasign
• Стрибог требует отдельной реализации S-box и линейного преобразования
• отсутствие встроенного digest приводит к невозможности формирования корректной подписи ГОСТ

3. ASN.1 и форматы сертификатов

ГОСТ-сертификаты часто используют расширенные OID и нестандартные параметры:

• отличающиеся OID алгоритмов подписи
• специфические параметры ключей в X.509
• обязательные расширения, используемые в инфраструктуре КриптоПро

jsrsasign поддерживает ASN.1, но не реализует полный набор ГОСТ-расширений.

Ограничения WebCrypto API и влияние на ГОСТ

Современные браузеры предоставляют WebCrypto API, но его возможности ограничены:

• отсутствует поддержка ГОСТ-алгоритмов в стандартной спецификации W3C
• доступен только набор: RSA-OAEP, RSASSA-PKCS1-v1_5, ECDSA, AES-GCM
• расширения зависят от браузера и ОС (и практически не стандартизированы)

jsrsasign может работать поверх WebCrypto, но это не решает проблему ГОСТ, так как API не предоставляет соответствующих примитивов.

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

В стандартной модели jsrsasign процесс подписи выглядит следующим образом:

• загрузка приватного ключа (PEM/PKCS#8)
• формирование хеша (SHA-256/SHA-1)
• вычисление подписи через RSA/ECDSA
• упаковка результата в base64 или CMS/PKCS#7

Пример RSA-подписи:

const sig = new KJUR.crypto.Signature({ "alg": "SHA256withRSA" });
sig.init(privateKeyPem);
sig.updateString("data");
const signature = sig.sign();

В контексте ГОСТ аналогичный процесс невозможен из-за отсутствия алгоритмов подписи и хеширования.

Обходные архитектурные решения для ГОСТ

В системах, где требуется ГОСТ-подпись, jsrsasign используется только как вспомогательный слой. Основные подходы:

1. Вынесение криптографии в внешние модули

Подпись выполняется вне JavaScript-среды:

• native CryptoPro CSP (Windows/Linux)
• Node.js bindings к OpenSSL с ГОСТ-патчами
• внешние REST API криптопровайдеров

JavaScript в этом случае:

• формирует данные для подписи
• отправляет их в внешний сервис
• получает готовую подпись

2. Использование плагинной архитектуры

Возможна интеграция через:

• WebAssembly-модули с реализацией ГОСТ
• нативные браузерные расширения
• локальные агенты подписи

jsrsasign используется только для:

• работы с ASN.1
• обработки сертификатов X.509
• проверки CMS-структур (если формат совместим)

3. Гибридная схема CMS/PKCS#7

В некоторых системах используется подход:

• ГОСТ-подпись формируется внешним провайдером
• jsrsasign разбирает PKCS#7 контейнер
• выполняется проверка структуры без криптографической валидации

Работа с сертификатами ГОСТ

Сертификаты ГОСТ в X.509 отличаются следующими особенностями:

• алгоритмы подписи: id-GostR3410-2012-256/512
• хеш-функции: id-GostR3411-2012-256/512
• специфические расширения Key Usage
• обязательные OID в Subject Public Key Info

jsrsasign может:

• парсить ASN.1 структуру сертификата
• извлекать поля Subject, Issuer, Validity
• декодировать base64/DER представление

но не способен:

• валидировать криптографическую подпись ГОСТ
• вычислять fingerprint по Стрибогу
• проверять цепочку доверия в ГОСТ PKI без внешнего провайдера

Пример парсинга сертификата:

const cert = new X509();
cert.readCertPEM(certPem);

const subject = cert.getSubjectString();
const issuer = cert.getIssuerString();
const serial = cert.getSerialNumberHex();

Проблемы совместимости форматов

1. DER/PEM различия

ГОСТ-инфраструктуры часто используют DER-контейнеры с расширенными OID. jsrsasign работает с ними, но:

• возможны ошибки декодирования расширенных полей
• нестандартные структуры могут игнорироваться

2. CMS/PKCS#7 контейнеры

Поддержка CMS в jsrsasign ограничена:

• RSA/DSA/ECDSA подписи обрабатываются корректно
• ГОСТ-алгоритмы не интерпретируются
• SignedData может быть прочитан, но не проверен

3. Кодировки и ASN.1 нюансы

ГОСТ-сертификаты часто содержат:

• OCTET STRING нестандартной длины
• вложенные структуры параметров кривых
• специфические BIT STRING представления ключей

jsrsasign ASN.1 parser работает корректно только в рамках стандартных схем.

Ограничения валидации цепочек доверия

Проверка цепочки сертификатов в jsrsasign основана на:

• встроенных trust anchors (ограниченно)
• RSA/ECDSA проверке подписи
• стандартных алгоритмах хеширования

ГОСТ PKI требует:

• проверки через национальные удостоверяющие центры
• использования сертифицированных криптопровайдеров
• учета политик криптографической защиты

Эти механизмы отсутствуют в библиотеке.

Типичные сценарии ошибок при попытке использования ГОСТ

Ошибка алгоритма подписи

При загрузке сертификата:

• неизвестный OID алгоритма
• невозможность сопоставления с SHA/ECDSA

Ошибка проверки подписи

• digest mismatch
• отсутствие поддерживаемого hash algorithm
• невозможность вычисления контрольного значения

Ошибка ключевой структуры

• неподдерживаемая ECC-кривая
• некорректный SubjectPublicKeyInfo parsing
• отсутствие параметров domain parameters

Интеграционная модель в реальных системах

В промышленной архитектуре jsrsasign чаще всего выполняет вспомогательную роль:

• разбор сертификатов и метаданных
• визуализация цепочек доверия
• подготовка данных для подписи
• проверка не криптографических частей CMS

Криптографическая часть ГОСТ делегируется:

• системам электронного документооборота
• криптопровайдерам уровня ОС
• специализированным SDK

Ограничения безопасности JavaScript-среды

Дополнительное ограничение связано с самой средой выполнения:

• отсутствие сертификации FIPS/ГОСТ в браузере
• невозможность защищенного хранения ключей
• риск утечки приватных данных через память JS runtime
• отсутствие защищенных аппаратных модулей (HSM)

ГОСТ-инфраструктуры обычно требуют:

• аппаратной защиты ключей
• сертифицированных криптомодулей
• изолированной среды выполнения

Эти требования противоречат модели jsrsasign.

Практическая модель использования в ГОСТ-системах

Типичная архитектура выглядит следующим образом:

• JavaScript слой (jsrsasign):

  • парсинг X.509
  • подготовка подписываемых данных
  • обработка CMS контейнеров

• внешний криптопровайдер:

  • генерация подписи ГОСТ
  • проверка цепочек доверия
  • работа с ключами

Разделение ответственности позволяет использовать jsrsasign без нарушения криптографических требований.

Итоговые ограничения применения

Использование jsrsasign в контексте ГОСТ ограничивается следующими факторами:

• отсутствие нативной поддержки ГОСТ алгоритмов
• несовместимость с криптопровайдерами РФ
• ограниченная работа с расширенными ASN.1 структурами
• отсутствие доверенной среды выполнения
• невозможность полноценной проверки подписи ГОСТ

Библиотека остается применимой только в слоях обработки данных и PKI-структур, не затрагивающих криптографические вычисления ГОСТ.