ASN.1 DER: как читать байты криптографических контейнеров¶
Типы, длины, вложенные структуры и правила поиска источника ошибок в сертификатах и CMS.
Документация ПО — НАЙС.ОС CLOUD. Это самостоятельная учебно-справочная статья. Команды приведены для изучения и диагностики; операции с ключами, дисками и действующими сервисами выполняют только после резервного копирования и проверки назначения.
Почему одинаковый OID ещё не означает одинаковый файл¶
DER — каноническая бинарная кодировка ASN.1, используемая в сертификатах и многих криптографических объектах. PEM — текстовая упаковка Base64 с заголовками, а не отдельный алгоритм. В CMS один объект ContentInfo может содержать подписанные или зашифрованные данные; внутри — вложенные структуры с ключами, алгоритмами, сертификатами, подписантами и наборами атрибутов.
Четыре базовых типа¶
| Тип | Что содержит | Характерная особенность |
|---|---|---|
SEQUENCE |
Упорядоченный набор полей | Тег 0x30 |
SET |
Множество элементов | В DER важен канонический порядок кодирования |
OBJECT IDENTIFIER |
Идентификатор типа или алгоритма | Тег 0x06 |
OCTET STRING |
Последовательность октетов | Не обязательно текст |
Тег и длина показывают, как найти следующее поле. Но контекст ASN.1-схемы определяет смысл байтов. Нельзя автоматически заключать, что OCTET STRING является ключом: это может быть подпись, хэш, IV, содержимое сертификата или зашифрованный блок.
Безопасная инспекция неизвестного DER¶
file message.der
openssl asn1parse -inform DER -in message.der -i | head -90
openssl cms -cmsout -print -inform DER -in message.der | head -100
Команда asn1parse не подтверждает корректность подписи. Она лишь отображает структуру. cms -cmsout -print корректно разбирает известные CMS-типы, но для неизвестного алгоритма возможно ограничение криптобиблиотеки. Для сертификатов лучше использовать openssl x509, для запроса — openssl req.
Отдельно об алгоритмических параметрах¶
Структура AlgorithmIdentifier содержит идентификатор алгоритма и необязательные параметры. Некоторые ГОСТ-идентификаторы требуют отсутствие параметров, другие — ASN.1-структуру с OID кривой. Например, для OID хэш-функций по RFC 9215 поле параметров должно отсутствовать. Не нужно механически добавлять NULL, когда спецификация требует отсутствие поля.
Диагностика из трёх последовательных шагов¶
- Определите внешний тип и кодировку: PEM, DER, PFX, CMS SignedData, CMS EnvelopedData или отдельный X.509.
- Найдите
AlgorithmIdentifierи запишите его числовой OID и параметры; сопоставьте с официальной спецификацией. - Только после этого проверяйте поддержку конкретного алгоритма в OpenSSL, GPGSM или другом приложении.
Если подпись не проверяется, причиной может быть не неправильная математика, а другой порядок байтов, неподписанный набор атрибутов, несовпадение связанного содержимого или неправильная цепочка сертификатов.
Что не публиковать в диагностике¶
Не помещайте в обращения поддержки содержимое закрытых ключей, пароли PFX, PIN токенов, секреты симметричных ключей и полные необезличенные корпоративные сертификаты. Для обмена снимками достаточно структуры, OID, версий библиотек и заранее изготовленных публичных фикстур.