pkcs 7 что это

Технологии работы с электронной подписью

Введение

Внедрение электронной подписи (без разделения на используемые криптоалгоритмы и критерий «квалифицированности», см. закон 63-ФЗ, ст. 5) в информационную систему обычно вызвано необходимостью контроля целостности и авторства порождаемых в системе информационных потоков и документов.

Под катом описаны интерфейсы для работы с электронной подписью, а также распространенные форматы электронной подписи.

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

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

Отдельное внимание в вопросе работы с электронной подписью следует уделить установлению соответствия между открытым ключом подписи и непосредственно лицом, которому он принадлежит. Для решения данной задачи существует такое понятие, как «Сертификат открытого ключа электронной подписи» (или просто «цифровой сертификат»). Для выдачи, проверки действительности, отзыва и управления сертификатами необходима инфраструктура открытых ключей (Public Key Infrastructure). Вопрос сопоставления открытого ключа и его владельца – один из самых важных и сложных при работе с асимметричной криптографией, так как открытый ключ – это никак не идентифицируемый набор публичной информации, которая служит для проверки электронной подписи. А при отсутствии связки этой информации непосредственно с ее владельцем она всегда может быть изменена злоумышленником, что позволит ему формировать электронную подпись и выдавать ее за электронную подпись другого лица.

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

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

Но реализация криптоалгоритмов с учетом высокого быстродействия, отсутствия ошибок и гарантированного выполнения требований математических преобразований – непростая задача, которой занимаются квалифицированные разработчики.

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

Дополнительно, средства криптографической защиты информации (СКЗИ, этот термин широко используется в РФ) могут иметь самое разное представление: от программных библиотек до высокопроизводительных специализированных железок (Hardware Security Module, HSM).

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

С целью совместимости различных реализаций, а также упрощения их встраивания в прикладное программное обеспечение, были разработаны несколько стандартов, относящиеся к различным аспектам работы с СКЗИ и непосредственно электронной подписью.

Интерфейсы для доступа к СКЗИ

На сегодняшний день широкое распространение получили один промышленный стандарт работы с СКЗИ и один (фактически два) проприетарный интерфейс всеми известной компании Microsoft.

PKCS#11

PKCS#11 (Public-Key Cryptography Standard #11) – платформонезависимый программный интерфейс для работы с аппаратно реализованными СКЗИ: смарт-карты, HSM’ы, криптографические токены. Иногда PKCS#11 используется для доступа к программно реализованным криптографическим библиотекам.

PKCS#11 представляет собой довольно обширный документ, опубликованный RSA Laboratories, который описывает набор функций, механизмов, алгоритмов и их параметров для работы с криптографическими устройствами или библиотеками. В данном документе четко прописаны правила, в соответствии с которым будет работать прикладное программное обеспечение при вызове криптографических функций.

Данный стандарт поддерживается во многих open source-проектах, использующих криптографию. Для примера, Mozilla Firefox позволяет хранить сертификаты и закрытые ключи для аутентификации через SSL/TLS на токенах, работая с ними по PKCS#11.

Если прикладное программное обеспечение «умеет» работать с PKCS#11, то производителю СКЗИ необходимо реализовать программную библиотеку, которая наружу будет выставлять интерфейсы, описанные в стандарте, а внутри реализовывать необходимую СКЗИ логику: работа непосредственно с криптографическим устройством или реализация необходимых криптоалгоритмов программно. В этом случае прикладное программное обеспечение должно «подцепить» необходимую библиотеку и выполнять необходимые действия в соответствии с рекомендациями стандарта. Это обеспечивает заменяемость различных устройств и их библиотек для прикладного программного обеспечения и прозрачное использование СКЗИ в различных системах.

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

Microsoft Crypto API 2.0

Операционная система Microsoft Windows, независимо от версии, довольно сложная система, которая помимо всего прочего занимается вопросами обеспечения безопасности пользовательских и корпоративных данных. В этих задачах традиционно широко используется криптография.

С целью унификации доступа к криптографическим функциям компания Microsoft разработала проприетарный API: Microsoft Crypto API. Широкое распространение приобрела версия Crypto API 2.0. Парадигма Microsoft Crypto API базируется на использовании так называемых криптопровайдеров, или, по-русски, поставщиков криптографии.

Спецификация Crypto API описывает набор функций, которые должна предоставлять библиотека криптопровайдера операционной системе, способы интеграции с ней и спецификации вызовов. Таким образом, производитель СКЗИ, выполняющий правила Crypto API, имеет возможность интеграции своего решения в операционную систему Microsoft Windows, а прикладное программное обеспечение получает доступ криптографическим функциям посредством унифицированного интерфейса.

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

Но расплатой за удобство становится платформозависимость и необходимость тесной интеграции решения в операционную систему.

В Windows Vista Microsoft представила новую версию криптографического программного интерфейса – Microsoft CNG (Cryptography API: Next Generation). Данный интерфейс базируется уже не на поставщиках криптографии, а на поставщиках алгоритмов и поставщиках хранилищ ключевой информации. В силу того, что распространенность Windows XP все еще довольно велика, CNG в прикладных системах используется крайне мало.

Проприетарные интерфейсы

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

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

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

Описанные выше интерфейсы для доступа к криптографическим функциям позволяют обращаться за выполнением математических преобразований к различным, как хорошо было замечено Microsoft, «поставщикам криптографии».

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

PKCS#7

PKCS#7 (Public-Key Cryptography Standard #7), или CMS (Cryptographic Message Syntax) – стандарт, публикуемый и поддерживаемый все той же RSA Laboratories, описываемый синтаксис криптографических сообщений.

PKCS#7 также публикуется в качестве RFC с номером 2315.

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

С этой целью в PKCS#7 размещается информация об исходном сообщении (опционально), алгоритмах хеширования и подписи, параметрах криптоалгоритмов, времени подписи, сертификат ключа электронной подписи, цепочка сертификации и т. д.

Большинство атрибутов PKCS#7 являются опциональными, но их обязательность может определяться прикладной системой.

Отдельно следует отметить, что PKCS#7 позволяет ставить несколько подписей под одним документом, сохраняя всю необходимую информацию в сообщении.

Формирование и проверка PKCS#7 реализованы в криптографических «надстройках» в Microsoft Crypto API, речь о которых шла выше. Но сам формат довольно хорошо специализирован и его поддержка может быть реализована нативно.

XML-DSig

W3C разработала и опубликовала рекомендации по составлению подписанных сообщений в формате XML.

Фактически XML-DSig решает те же вопросы, что и PKCS#7. Основное отличие в том, что в PKCS#7 данные хранятся в структурах, сформированных в соответствии с разметкой ANS.1 (фактически, бинарные данные), а в XML-DSig данные хранятся в текстовом формате в соответствии с правилами документа «XML Signature Syntax and Processing».

Область применения XML-DSig – веб-приложения и веб-сервисы.

Сырая подпись

Описанные выше форматы электронной подписи необходимы при взаимодействии разнородных систем, когда информация об отправителе подписанного сообщения минимальна.

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

В этом случае фактически передается только само значение электронной подписи вместе с документом. Информация для проверки берется получателем из централизованной базы данных.

Это позволяет значительно упростить процедуры выработки и проверки подписи, так как отсутствуют шаги формирования и разбора сообщений в соответствии с каким-либо форматом.

Заключение

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

Читайте также: Что значит релиз трека

Источник

#Основные понятия синтаксиса криптографических сообщений PKCS 7

Функции сообщений CryptoAPI соответствуют стандарту PKCS # 7 Cryptographic Message Syntax (CMS). Разработчики должны быть знакомы с этой спецификацией, чтобы наиболее эффективно использовать низкоуровневые функции сообщений. Некоторые из его определений выделены здесь.

Тип данных, содержащихся в сообщении PKCS # 7, называется его типом содержимого. Существует два класса типов содержимого: базовый и расширенный.

Ниже приведены типы содержимого, определенные в # стандарте PKCS 7.

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

Источник

Структура PKCS7-файла

Довелось мне на днях столкнуться с такой напастью как p7s файл и, как вследствие этого, с Cryptographic Message Syntax (CMS). На хабре нашлась интересная статья описывающая структуру CMS данных, но в ней к сожалению нет примера, позволяющего наглядно продемонстрировать CMS на практике. Я хочу немного дополнить ту статью и разобрать внутренности файла цифровой подписи p7s.

Что же такое Cryptographic Message Syntax? Это стандарт, описывающий структуру сообщений, полученных с использованием криптографии.
В стандарте описывается шесть типов данных: data, signedData, envelopedData, signedAndEnvelopedData, digestedData, and encryptedData. В данном топике я расскажу о типе signedData (данные с электронной подписью).

Прежде всего следует сказать, что стандартный p7s файл имеет ASN.1 структуру.
ASN.1 — формат записи, с помощью которого можно описывать сложные структуры данных, состоящие из различных типов.
Приведу краткую выдержку из своего старого топика про x.509 сертификаты:

ASN.1-кодировка описывается следующим правилом. Сперва записываются байты, характеризующий тип данных, затем последовательность байтов хранящих сведения о длине данных и лишь после этого следуют сами данные.

К примеру, для кодировки целого числа INTEGER 65537 используется следующая форма: 02 03 01 00 01.
Здесь первый байт 02, определяет тип INTEGER (полную таблицу типов вы можете найти например тут), второй байт 03 показывает длину блока. А следующие за этим байты 01 00 01, являются шестнадцатеричной записью нашего числа 65537.

В нашем случае, для описание простейшего самоподписанного сертификата, достаточно 9 типов данных. Приведем таблицу кодирования для этих типов:

Наименование типа	Краткое описание	Представление типа в DER-кодировке
SEQUENCE	Используется для описания структуры данных, состоящей из различных типов.	30
INTEGER	Целое число.	02
OBJECT IDENTIFIER	Последовательность целых чисел.	06
UTCTime	Временной тип, содержит 2 цифры для определения года	17
GeneralizedTime	Расширенный временной тип, содержит 4 цифры для обозначения года.	18
SET	Описывает структуру данных разных типов.	31
UTF8String	Описывает строковые данные.	0C
NULL	Собственно NULL	05
BIT STRING	Тип для хранения последовательности бит.	03

Структура P7S файла

В стандарте CMS приводится описание структуры файла содержащего сведения об ЭЦП.

Используя ASN.1-парсер можно легко разобрать что скрывается за шестнадцатеричным кодом.

Этот пример отличается от предыдущего наличием дополнительного блока:

Именно в нем содержатся SignedAttributes. Помимо двух обязательных атрибутов при подписи был использован атрибут signedTime, который хранит время подписи.

Источник

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

Статья посвящена обзору стандартов СMS (Cryptographic Message Syntax) для подписанных сообщений.

Для чего нужен CMS

Чтобы не путаться в терминологии, далее исходные данные, которые мы хотим передать защищенным способом, будут называться данными, а получившееся защищенное сообщение CMS – просто сообщением.

Стандарт CMS (PKCS #7 и RFC 5652): теория

Чуть истории

Подпись в CMS-формате (signed data type)

Подписанное Алисой сообщение в формате CMS будет иметь следующий вид (серым отмечены необязательные атрибуты):

CMS предлагает два интересных атрибута, расширяющих возможности обычной подписи: время подписи (Signing Time) и контрасигнатуру (Countersignature). Первый атрибут определяет предполагаемое время осуществления подписи, а второй предназначен для подписи другой подписи (подписывается хеш от значения подписи). Атрибут Countersignature представляет собой структуру Signer Info с отсутствующим в Signed Attributes атрибутом Content Type и обязательно присутствующим атрибутом Message Digest. Атрибут Countersignature может иметь свой собственный атрибут Countersignature.

Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:

Галопом по Европам оставшимся типам

СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины.
Упакованные данные (enveloped data) представляют собой зашифрованные данные вместе с зашифрованными для одного или более получателей ключами, которыми эти данные были зашифрованы. Комбинация зашифрованного сообщения с одним зашифрованным ключом шифрования для одного получателя называется цифровым конвертом. Данный тип используется в качестве конверта с (подписанными) данными для одного или нескольких получателей.
Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных.
Зашифрованные данные часто используются для шифрования данных для локального хранилища, иногда с выработанным из пароля ключом шифрования.
Данные из аутентифицированного источника (данные с проверкой подлинности) включают в себя данные вместе с их MAC-кодом и зашифрованными ключами аутентификации для одного или нескольких получателей. Используются для защиты целостности сообщений для неограниченного количества получателей.

В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.

CMS в реальной жизни

Как реализовать на практике?

Наша компания поддержала CMS c российской криптографией в продукте Рутокен Плагин. Рутокен Плагин предназначен для использования в браузерах, все криптографические операции производятся аппаратно, «на борту» USB-токена.

Источник

OpenSSL и Network Security Services (NSS) — две стороны одной медали

О какой медали идет речь в заголовке? Речь идет об инфраструктуре открытых ключей (Public Key Infrastructure — PKI/ИОК) на базе стандартов криптографии с открытым ключом (Public Key Cryptography Standards — PKCS). Инфраструктура открытых ключей включает в себя множество различных объектов и механизмов работы с ними, а также протоколы взаимодействия объектов друг с другом (например, протоколы TLS, OCSP). В число объектов ИОК/PKI входят сертификаты x509 и ключевые пары (приватные и публичные ключи), подписанные и зашифрованные документы (pkcs#7, CMS), защищенные контейнеры для хранения приватных ключей (pkcs#8) и личных сертификатов с ключами (pkcs#12) и т.д. В число механизмов входят не только криптографические функции, которые позволяют шифровать и подписывать документы по различным алгоритмам, но и функции, формирующие конечные объекты ИОК в соответствии со стандартами (сертификаты, запросы, подписанные/зашифрованные документы, пакеты протоколов и т.д. и т.п.). Да, и как не вспомнить центральный объект ИОК/PKI — Удостоверяющий Центр (УЦ).

Любой пользователь Интернет, не подозревая того, использует различные механизмы и объекты ИОК/PKI, например, протокол HTTPS при доступе к различным сайтам, когда подписывает и/или шифрует свои электронные письма или использует электронную подпись в документообороте.
Наиболее продвинутыми средствами для создания инфраструктуры открытых ключей, программных средств, работающих в составе PKI/ИОК, являются OpenSSL и Network Security Services (NSS).
OpenSSL — набор полноценных криптографических библиотек и утилиты с открытым исходным кодом, которые поддерживает почти все низкоуровневые алгоритмы хеширования, шифрования и электронной подписи, а также реализует большинство популярных криптографических стандартов, в том числе: позволяет создавать ключи RSA, DH, DSA, EC, выпускать сертификаты X.509, шифровать и подписывать данные и создавать SSL/TLS соединения.
Следует отметить, что объекты, с которыми работает утилита OpenSSL, хранятся в файлах (сертификаты, ключи).

Таким же набором полноценных криптографических библиотек и утилит с открытым исходным кодом является и Network Security Services (NSS).

Основное отличие OpenSSL от NSS заключается в том, что OpenSSL предполагает, что сертификаты и ключи хранятся в файлах, а NSS для хранения сертификатов и ключей использует базы данных и токены PKCS#11.
Самым существенным является то, что оба проекта (OpenSSL и NSS) строго придерживаются стандартов и поэтому не возникает проблем при их совместном использовании в различных проектах. Таким хорошим примером их содружества может служить, например, применение протокола HTTPS, когда сайты/порталы строятся на базе Apache с mod_ssl на базе OpenSSL, а доступ к ним ведется, например, посредством Firefox, в котором поддержка TLS 1.0/TLS 1.2 и TLS 1.3 осуществляется с помощью библиотек NSS.

Ниже будет показано как утилиты OpenSSL и NSS могут использоваться для решения одних и тех же задач. В дальнейшем каждый может использовать утилиты по своему вкусу.
Познакомиться с библиотечными функциями может каждый, просмотрев исходный код той или иной утилиты.

Просмотр сертификатов и других сущностей, хранящихся в файлах

В пакете OpenSSL присутствует одна утилита — openssl, первым параметром в которой задается собственно команда (Standard commands), которую необходимо выполнить:

Как можно заметить, при выполнении команды openssl help, помимо собственно перечня команд, выводится список поддерживаемых хэш-алгоритмов и алгоритмов шифрования (в их перечень включены и функции сжатия и работы с base64).

Для просмотра сертификата (x509), запроса (req) или списка отозванных сертификатов (crl) достаточно выполнить команду следующего вида:

В пакете NSS аналогичные действия выполняет утилита pp.

Утилита pp — это утилита элегантной печати (Pretty Print) файла, содержащего ASN.1 структуру в DER или PEM-кодировке:

По умолчанию предполагается, что все объекты находятся в DER-кодировке. Если же объекты находятся в PEM-кодировке, то необходимо задать параметр «-a» (аналог параметра «-inform PEM» для утилиты openssl). И еще один параметр «-u» задается, если в объекте содержатся символы в кодировке UTF-8. Напомним, что аналогичный параметр есть и у утилиты openssl — «-nameopt utf8».

В пакете NSS есть и утилита для просмотра ASN.1-структыры объекта, аналог утилиты openssl asn1.parse. Это утилита derdump:

Из самого названия утилиты следует, что она работает с файлами в DER-кодировке. Но это не страшно. В состав пакета входят две утилиты, которые конвертируют файлы из PEM/BASE64-кодировки в DER-кодировку и обратно. Это утилиты atob и btoa.

Например, для конвертации сертификата из PEM-формата в DER-формат в OpenSSL надо выполнить следующую команду:

В NSS это будет выглядеть так:

Параметр «-w» указывает, какой текст включить в начало выходного файла и конец. В данном случае «-w CERTIFICATE» приведет к появлению стандартного для PEM-формата в OpenSSL заголовка и концевика:

И OpenSSL и NSS могут работать с контейнерами pkcs#12. И они оба позволяют не только создавать, но и просмотривать содержимое контейнера pkcs12. Но, при использовании утилиты openssl требуется сначала разобрать контейнер и сохранить сертификаты из контейнера в отдельных файлах. После этого их можно спокойно просмотреть. В NSS просмотр содержимого контейнера можно выполнить за один проход. Для этого используется утилита pk12util следующего вида:

Name: Certificate Key Usage
Usages: Digital Signature
Key Encipherment
Key Agreement

Name: Certificate Type
Data:

Name: Extended Key Usage
TLS Web Client Authentication Certificate
E-Mail Protection Certificate

Name: Certificate Subject Key ID
Data:
26:a1:b3:98:1c:fe:62:ba:23:81:96:37:3f:08:bd:70:
d6:f2:b1:46

Name: Certificate Authority Key Identifier
Key ID:
0a:b6:f6:87:64:1d:8e:b3:63:08:29:9f:21:59:ad:47:
d8:ea:07:f4
Issuer:
Directory Name: «E=ca@test.ru,OGRN=1111111111111,INN=22222222
2222,CN=Удостоверяюший Центр,OU=Отд
ел Удостоверяюший Центр,O=Удост
оверяюший Центр,STREET=»ул. Хавровс
кая, д. 0″,L=Хабраград,ST=Московска
я область,C=RU»
Serial Number:
00:a2:9b:22:32:3e:a7:3d:d8

Name: Certificate Subject Alt Name
RFC822 Name: «test@rsa.ru»

Name: Certificate Issuer Alt Name
Error: Parsing extension: Certificate extension value is invalid.
Data: Sequence <
>

Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Signature:
2f:75:7e:71:9e:15:5c:97:fe:a2:e1:2a:52:39:56:55:
e0:62:60:bc:5f:6d:c2:b6:ec:cd:8b:10:b3:b1:3f:e5:
d6:d1:5f:a5:fa:61:c1:ce:3e:db:6a:2f:b2:13:46:8d:
67:cf:18:09:61:97:01:45:bc:99:bb:0c:d6:0a:a3:03:
87:0a:8e:10:3a:d5:e3:94:6d:4a:24:fa:c3:40:0b:43:
c2:3b:00:56:06:c4:d2:fc:b2:7e:e9:00:e5:2f:4b:e2:
3a:91:49:ce:f8:c3:60:ec:01:74:d8:1a:3b:af:e6:f6:
91:db:c5:f1:d7:de:be:18:38:47:41:8a:e2:ef:80:91:
10:54:41:ae:55:22:6f:d7:8c:fa:46:b6:b6:2a:ee:6a:
0c:c9:03:18:af:4e:93:6c:61:f3:b4:78:0c:61:93:f1:
d8:1b:00:c3:e5:29:9a:08:0a:f8:31:67:88:3d:c3:88:
7a:60:c0:c4:52:94:25:56:e5:a3:df:7d:58:c5:df:9a:
c7:22:7e:2c:f6:fb:2c:bf:b7:7f:c5:ca:2b:0f:8c:20:
77:b9:1f:e0:62:5a:3d:d4:6f:12:ea:c8:51:67:a5:75:
ad:e9:ac:9e:4e:2e:2d:34:80:e7:d8:64:f6:8f:2f:33:
32:1f:8b:bc:9c:e8:77:4a:ee:7b:84:31:ec:28:e9:70
Fingerprint (SHA-256):
96:F4:A5:FA:6D:8A:F8:7E:A6:10:49:BD:43:34:C1:92:C6:7D:FF:63:41:8E:69:C0:AC:34:6B:CB:63:7B:56:31
Fingerprint (SHA1):
B6:91:9B:C6:7A:45:9C:92:FD:E7:C7:33:00:FA:91:DF:7D:5F:00:21

Friendly Name: Тестовый сертификат

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
00:a2:9b:22:32:3e:a7:3d:d8
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: «E=ca@test.ru,OGRN=1111111111111,INN=222222222222,CN=Удос
товеряюший Центр,OU=Отдел Удостоверя
юший Центр,O=Удостоверяюший Центр,STR
EET=»ул. Хавровская, д. 0″,L=Хабраград,ST=М
осковская область,C=RU»
Validity:
Not Before: Tue Jul 07 08:08:11 2020
Not After: Fri Jul 05 08:08:11 2030
Subject: «E=ca@test.ru,OGRN=1111111111111,INN=222222222222,CN=Удос
товеряюший Центр,OU=Отдел Удостоверя
юший Центр,O=Удостоверяюший Центр,STR
EET=»ул. Хавровская, д. 0″,L=Хабраград,ST=М
осковская область,C=RU»
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
e7:08:ed:83:08:10:7b:48:56:37:8b:e2:4a:31:1a:7b:
0d:4e:d2:a2:67:d7:04:60:a0:09:db:06:64:21:01:4e:
0d:41:d8:61:15:c6:58:83:66:7e:6b:65:72:0d:2b:c3:
50:26:11:04:82:4b:1a:12:d0:dc:e1:13:1c:76:69:0f:
c2:59:e2:5d:60:6d:fe:8a:48:fa:8b:1e:05:07:34:6d:
8a:e3:76:23:42:9e:7b:64:0b:6a:fb:36:63:31:96:df:
ed:d3:e8:7c:6e:39:d4:7d:da:b8:f4:ec:53:57:60:f1:
d8:a4:3a:3f:3b:4a:63:6c:2a:55:90:21:15:23:4a:37:
21:31:a0:c4:bb:84:0d:96:18:3c:3b:ba:92:e3:e2:17:
56:e5:d9:8c:58:24:8a:a3:53:b6:4f:02:4d:30:a6:0f:
34:ad:20:cf:6f:03:ca:23:1e:d3:15:bc:80:09:d8:1e:
90:07:da:90:a9:34:9e:6e:ed:6b:10:b7:a1:a4:a9:b4:
04:ac:6a:40:d8:00:52:d6:6a:28:f2:8c:c6:84:81:8a:
cd:63:a6:53:82:d2:4e:11:ec:94:81:d7:9c:79:8a:30:
9c:40:75:4d:d9:88:0b:cc:a4:0c:5d:6d:23:a6:ac:56:
8c:49:d9:1f:2b:63:cb:50:fc:a3:e0:3e:35:4e:f4:03
Exponent: 65537 (0x10001)
Signed Extensions:
Name: Certificate Basic Constraints
Critical: True
Data: Is a CA with no maximum path length.

Name: Certificate Subject Key ID
Data:
0a:b6:f6:87:64:1d:8e:b3:63:08:29:9f:21:59:ad:47:
d8:ea:07:f4

Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Signature:
17:7d:29:dc:4d:6e:4c:99:7a:bc:b2:2a:a5:80:f9:5f:
0c:60:00:2b:f3:f4:ef:19:d7:ed:56:07:5d:24:e1:b3:
f6:43:e2:05:9b:75:ce:cd:cf:27:1e:1c:cd:d8:cc:43:
77:16:04:7e:8a:dd:89:c4:b2:75:ae:f4:84:23:53:18:
fe:be:c5:1d:40:55:aa:91:9f:f5:96:06:5d:07:22:a8:
1c:b9:29:c4:49:2e:75:10:75:22:95:36:16:58:2f:77:
f5:fa:6d:de:c4:67:ca:f3:e1:98:51:b4:ba:b7:2a:7f:
06:db:33:5a:a6:bb:53:57:f4:18:93:16:9c:0e:43:d0:
46:e6:84:55:bb:ff:68:fe:fa:32:d5:23:2a:d5:65:9b:
d9:63:45:6b:53:71:64:dd:da:e1:40:fa:89:30:b1:73:
8b:f8:7c:3c:2f:72:24:ad:e8:5c:07:89:2f:3a:0d:37:
48:29:1f:0d:5f:9e:11:73:56:b8:d9:24:eb:2d:2e:18:
c7:9b:90:62:09:20:61:75:b9:a1:9a:3f:99:34:8e:06:
30:ce:7d:60:42:7d:e0:14:f2:88:f2:41:a0:46:4d:55:
17:d4:c2:15:64:c9:3e:f5:cc:0a:41:f7:c0:d0:94:96:
ea:64:e0:45:3a:e0:a3:d6:22:a9:d1:e3:c4:51:e8:96
Fingerprint (SHA-256):
F5:DF:15:79:5E:1E:41:84:96:8C:8C:CA:37:0C:A6:BB:C3:21:AE:3D:32:42:8C:63:C2:64:BA:0A:74:DC:37:F8
Fingerprint (SHA1):
CF:C6:B9:D4:3C:16:6F:31:91:2A:09:2F:FE:4C:57:89:0F:5A:F1:DB

Friendly Name: Удостоверяюший Центр

Key(shrouded):
Friendly Name: Тестовый сертификат

Encryption algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC
Parameters:
Salt:
c4:fa:4a:6a:4f:54:a1:7a
Iteration Count: 2048 (0x800)
$

При создании контейнера PKCS#12 утилитой openssl мы воспользовались графической оболочной CAFL63:

Теперь самое время поговорить о хранилище NSS.

Хранилище NSS

Хранилищем NSS является каталог, в котором хранятся три базы данных.

В базе данных (БД) cert8.db/cert9.db хранятся сертификаты. В БД key3.db/key4.db хранятся закрытые ключи. И, наконец, в БД secmod.db/pkcs11.txt хранится информация (прежде всего путь к библиотеке), позволяющая работать со сторонними токенами/смарткартами/облаками с интерфейсом PKCS#11.

Для создания хранилища NSS предназначена утилита modutil следующего формата:

Также просто из хранилища сертификатов старого формата (DBM) (cert8.db, key3.db и secmod.db) создается и хранилище в новом формате (SQLite3) (cert9.db, key4.db и pkcs11.txt). Для этого достаточно выполнить утилиту работы с сертификатами certutil в режиме просмотра ключей (-K) или сертификатов (-L) с параметром –X, например:

Отметим, что такие хранилища есть во всех проектах, построенных на NSS, включая Firefox, Thunderbird, Seamonkey, GoogleChrome, LibreOffice.

После создания хранилиша NSS автоматически становится доступным встроенный модуль «NSS Internal PKCS #11 Module» с двумя встроенными токенами:

Токен «NSS Generic Crypto Services» реализует криптографические функции и механизмы, а токен «NSS Certificate DB» предназначен для хранения сертификатов и ключей и другой дополнительной информации (например, о доверии корневым сертификатам). Токен «NSS Certificate DB» (внутренний токен NSS) для хранения сертификатов использует базу данных cert8.db/cert9.db, а закрытые ключи хранит в базе данных key3.db/key4.db.

Получить информацию о встроенных токенах внутреннего модуля «NSS Internal PKCS #11 Module», включая поддерживаемые по умолчанию криптографические механизмы, можно путем выполнения следующей команды:

— Name: NSS Internal PKCS #11 Module
Library file: **Internal ONLY module**
Manufacturer: Mozilla Foundation
Description: NSS Internal Crypto Services
PKCS #11 Version 3.0
Library Version: 3.52
Cipher Enable Flags: None
Default Mechanism Flags: RSA:ECC:DH:RC2:RC4:DES:AES:CAMELLIA:SEED:SHA1:SHA256:SHA512:MD5:MD2:SSL:TLS

Slot: NSS Internal Cryptographic Services
Slot Mechanism Flags: RSA:ECC:DH:RC2:RC4:DES:AES:CAMELLIA:SEED:SHA1:SHA256:SHA512:MD5:MD2:SSL:TLS
Manufacturer: Mozilla Foundation
Type: Software
Version Number: 3.52
Firmware Version: 1.0
Status: Enabled
Token Name: NSS Generic Crypto Services
Token Manufacturer: Mozilla Foundation
Token Model: NSS 3
Token Serial Number: 0000000000000000
Token Version: 4.0
Token Firmware Version: 0.0
Access: Write Protected
Login Type: Public (no login required)
User Pin: NOT Initialized

Подключение дополнительного модуля для работы с внешними устройствами PKCS#11 делается все той же утилитой modutil:

Например, для работы с токенами РУТокен, поддерживающими российскую криптографии, достаточно выполнить следующую команду:

Для получения списка модулей, которые поддерживают то или иное хранилище NSS, с информацией о каждом модуле (библиотека, список поддерживаемых слотов и подключенных к ним токенах) необходимо выполнить следующую команду:

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

Мы ею уже пользовались, когда получали информацию о встроенных (внутренних) токенах NSS.
И, если можно добавить модуль, то можно и удалить модуль из базы данных:

Доступ к внешним токенам, как правило, защищен PIN-кодом. А вот доступ к встроенному токену «NSS Certificate DB» по умолчанию не защищен паролем (PIN-кодом). Но установить его не составляет труда, например:

Аналогичным образом можно поменять PIN-код и у внешнего токена.

Теперь самое время перейти к работе с токенами, их механизмами и объектами.

Доступ к объектам токена PKCS#11

Для доступа к объектам (ключи, сертификаты) токенов PKCS#11 служит утилита certutil. Отметим, что по своей функциональности утилита certutil не уступает утилите openssl. Для просмотра функциональности утилиты certutil достаточно выполнить команду:

Но нас сейчас интересует только доступ к сертификатам и ключам. Напомним, что при хранении на токене PKCS#11 и тем и другим, как правило, приписываются атрибуты CKA_ID и CKA_LABEL. Для просмотра списка сертификатов на том или ином токене необходимо выполнить следующую команду:

В качестве метки токена может быть указана реальная метка токена или одно из ключевых слов — all или internal. В первом случае (метка токена all) перебираются все токены, подключенные к хранилищу NSS, а во втором случае (internal или «NSS Certificate DB») будет просматриваться внутренний токен хранилища «NSS Certificate DB».

Например, для получения списка сертификатов, находящихся на токене с меткой «LS11SW2016», модуль доступа к которому зарегистрирован в хранилище NSS «/home/a513/tmp/TEST_NSS» необходимо выполнить следующую команду:

Список сертификатов, находящихся на токене, выводится в две колонки. В первой колонке дается nicknamе сертификата, а во второй — атрибуты доверия этого сертификата.

Причем, если сертификат имеет закрытый ключ на токене, где он находится, то в этой колонке будет значение «u,u,u».

Если атрибуты не устанавливались, то в колонке будет значение «,,».

Сертификаты с атрибутами доверия «u,u,u» (у них есть закрытый ключ) могут быть использованы для аутентификации или формирования электронной подписи.

Другие значения атрибутов доверия могут быть установлены для сертификатов, находящихся на встроенном токене «NSS Certificate DB». Но об этом позже.

Что же такое nickname сертификата в NSS?

Для внутреннего токена («NSS Certificate DB») метка токена в nickname может отсутствовать.

Если рассматривать механизмы токенов PKCS#11, то мы увидим, что операции генерации ключей, импорта сертификатов и ключей сами по себе не предусматривают установку значений атрибутов CKA_ID и CKA_LABEL. Это все перекладывается на разработчика прикладного ПО. Но, если вы используете утилиты NSS для работы с токенами, то оказывается, что они берут на себя эти хлопоты.

Для просмотра списка закрытых ключей используется следующая команда:

При этом распечатывается тип ключа, CKA_ID и CKA_LABEL ключа.

Но вернемся к сертификатам. Для просмотра сертификата, находящегося на токене, в текстовом виде достаточно выполнить команду:

Name: Certificate Key Usage
Usages: Digital Signature
Key Encipherment
Key Agreement

Name: Certificate Type
Data:

Name: Extended Key Usage
TLS Web Client Authentication Certificate
E-Mail Protection Certificate

Name: Certificate Subject Key ID
Data:
26:a1:b3:98:1c:fe:62:ba:23:81:96:37:3f:08:bd:70:
d6:f2:b1:46

Name: Certificate Subject Alt Name
RFC822 Name: «test@rsa.ru»

Name: Certificate Issuer Alt Name
Error: Parsing extension: Certificate extension value is invalid.
Data: Sequence <
>

Mozilla-CA-Policy: false (attribute missing)
Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
User
$

Если у просматриваемого сертификата на этом же токене имеется закрытый ключ, то флаги доверия сертификата (Certificate Trust Flags) будут иметь значение User:

Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
User

Для экспорта сертификата с токена в стандартный вывод достаточно добавить дополнительный параметр «-a» или «-r». Параметр «-a» предписывает выводить сертификат в формате PEM:

Для вывода в DER-формате используется параметр «-r».

Установить сертификат на токен

Предположим у вас есть контейнер PKCS#12 с личным сертификатом и закрытым ключом, который вы сформировали средствами OpenSSL. Для экспорта личного сертификата в хранилище NSS используется команда pk12util следующего вида:

Если вы хотите импортировать сертификат на конкретный токен, то необходимо задать его метку. Отметим еще одну особенность. Если контейнер содержит в своем составе корневые сертификаты, то они будут сохранены на внутреннем токене «NSS Certificate DB». При этом атрибуты доверия по умолчанию не устанавливаются. Если по каким-либо причинам требуется установка атрибутов доверия к тем или иным сертификатам центров регистрации (корневым сертификатам) или SSL-сертификатам, то используется утилита certutil следующего вида:

Для каждого сертификата есть три доступные категории доверия, выраженные в следующем порядке: SSL, S/MIME, подпись кода для каждого параметра доверия:

Для установки просто сертификата из файла используется утилита certutil следующего вида:

К сожалению, в данном контексте не эквивалентна nickname сертификата, рассмотренному выше. Здесь метка сертификата соответствует просто CKA_LABEL, просто метки без указания метки токена. Какой-то разнобой.

По умолчанию предполагается, что сертификат находится в файле в DER-кодировке. Если сертификат в PEM-кодировке, то необходимо задавать параметр «-a». Если параметр «-i» не задан, то сертификат будет браться из стандартного ввода (stdin). По умолчанию сертификаты устанавливаются в токен «NSS Certificate DB», но можно установить сертификат и на внешний токен (параметр «-h»). При установке сертификата на внешний токен сертификат будет установлен как на внутренний токен («NSS Certificate DB»), так и внешний токен. При этом атрибуты доверия для внешнего токена будут проигнорированы, будет выдано предупреждение: «could not change trust on certificate».

Дубликат сертификата на внутреннем токене при желании можно удалить.

Для удаления сертификата с любого токена используется следующая команда:

Например, для удаления с токена RuTokenECP20 сертификата с меткой (CKA_LABEL) «Пользователь1» достаточно выполнить следующую команду:

При удалении сертификата его закрытый ключ не удаляется (если он есть, конечно). Для удаления закрытого ключа надо выполнить команду вида:

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

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

Для работы с электронной подписью в пакете NSS есть три утилиты.

Для формирования электронной подписи используется утилита p7sign:

К сожалению, утилита формирует подпись без привязки ко времени ее формирования. Но это легко исправляется. Достаточно в функцию SignFile в утилите p7sign.c добавить строку с вызовом функции добавления времени формирования подписи:

Теперь будет формироваться электронная подпись в формате CAdes-BES.

По умолчанию утилита p7sign формирует отсоединенную подпись. Если нужна присоединенная подпись, то необходимо указать параметр «-e». Надо иметь ввиду, что подпись не будет сформирована, если в хранилище NSS, на его внутреннем токене, отсутствует цепочка корневых сертификатов для сертификата подписанта или не выставлены атрибуты доверия для них.

Для проверки электронной подписи используется утилита p7verify:

Интерес представляет параметр «-u». Он предписывает проверить тип сертификата подписанта и если он не соответствует заданному типу, то подпись признать недействительной.

Значение может принимать следующие значения:

0 — certUsageSSLClient
1 — certUsageSSLServer
2 — certUsageSSLServerWithStepUp
3 — certUsageSSLCA
4 — certUsageEmailSigner
5 — certUsageEmailRecipient
6 — certUsageObjectSigner
7 — certUsageUserCertImport
8 — certUsageVerifyCA
9 — certUsageProtectedObjectSigner
10 — certUsageStatusResponder
11 — certUsageAnyCA
12 — certUsageIPsec

По умолчанию используется certUsageEmailSigner (4).
Утилита p7content позволяет получить информацию о времени подписания документа, кем он был подписан и адрес электронной почты подписанта. В случае, если подпись была присоединенной, то извлекается и сам контент, который был подписан.

Утилита p7content имеет следующий формат:

Это только часть утилит, входящих в состав пакета NSS. Естественно, как и в OpenSSL, так и в NSS есть утилиты (или команды), которые позволяют создать запросы на сертификаты и выпускать сертификаты, т.е. можно развернуть полнофункциональный удостоверящий центр, как это делается с использованием openssl. Можно поднять tls-сервер утилитой selfserv(аналог openssl s_server) и воспользоваться tls-клиентом tstclnt (аналог openssl s-client) и многое, многое другое.

Кстати, список шифрсьютов (ciphersuite) в NSS можно получить утилитой listsuites. В OpenSSL для этих целей служит команда openssl ciphers. Соответствие имен набора шифров OpenSSL в имена IANA шифрсьютов можно найти здесь.

Действительно, OpenSSL и NSS — две стороны (два типа интерфейсов для одних и тех же протоколов и стандартов) одной медали — Инфраструктуры Открытых ключей.

При наличии интереса к данной теме повествование будет продолжено.

В завершении хотелось бы еще остановиться на графической оболочке для NSS. Для OpenSSL существуют различные графические оболочки. Отметим только две из них — XCA и CAFL63.

Графическая оболочка guinsspy для пакета NSS

Первый вопрос, на чем разрабатывать? Было решено на Python-е.

Второй вопрос, на чем писать графический интерфейс? Ответ — Tkinter.

Первоначально gui разрабатывалось на PAGE. Но потом от него отошли. Но контекст остался.

В качестве темы оформления виджетов решено было использовать тему Breeze для python3 и тему Arc для python2, поскольку для последнего отсутствует тема Breeze. Для этого надо установить пакет с темами для pythona:

Еще нам потребуется пакет fsb795 для работы с сертификатами:

Утилиты NSS, на базе которых строится графическая оболочка guinsspy, очень часто запрашавают пароли или PIN-оды через консоль. Единственным способом взаимодействия с ними через графический интерфейс является использование пакета pexpect:

В качестве примере использования пакета pexpect приведем код процедуры импорта контейнера PKCS#12:

Бесконечный цикл (while(True):) в процедуре ждет наступления одного из четырех событий:

Первое событие связано с приглашением на ввод пароля или PIN-кода («Enter Password or Pin»).
При его наступлении на экране будет отображаться окно для ввода PIN-кода (левое окно на скриншоте):

Второе событие связано с вводом пароля к контейнеру PKCS#12 («Enter password for PKCS12 file»). При его наступлении на экране будет отображаться окно для ввода пароля к файлу с контейнером PKCS#12 (правое окно на скриншоте).

Третье событие связано с завершением работы утилиты pk12util (pexpect.EOF), а четвертое событие — с завершением работы утилиты по таймауту (pexpect.TIMEOUT).

Исходный код утилиты guinsspy можно найти здесь. Дистрибутив пакета NSS для работы с токенами PKCS#11 с российской криптографией для платформы Linux x86_64 можно найти там же.

Для тестирования токенов с российской криптографией скопируйте папку NSS_GOST_3.52.1_Linux_x86_64 в свой домашний каталог. Создайте скрипт guinsspy_gost.sh:

Теперь запустите этот скрипт и работайте с российскими токенами.
Если у вас нет под рукой токена с российской криптографией, то зайдите на вкладку «Создать SW/Cloud токен», которая вам плдскажет как создать программный токен на вашем компьютере или подключиться к облачному токену:

И напоследок, скриншоты создания запроса на сертификат:

Полученный запрос можно будет передать в УЦ CAFL63, выпустить там сертификат, установить на токен, на котором был создан закрытый ключ. А дальше использовать этот сертификат, например, для подписания документов.

Источник