Что такое 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 типов данных. Приведем таблицу кодирования для этих типов:

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

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

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

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

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

Источник

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

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

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

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

Источник

Противодействие коррупции

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

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

Ключ подписи и его сертификат могут распространяться в двух формах:

Файл-контейнер

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

Внешние программы, например Microsoft Outlook, Microsoft Word/Excel или любая программа создания и проверки электроной подписи, при вызове функций подписания или проверки обращаются к части операционной системы, отвечающей за криптографию (Microsoft Crypto API), которая в зависимости от задействованных криптографических алгоритмов вызывает соответствующий криптопровайдер. В нашем случае используется отечественная криптография. Поскольку Microsoft Windows не имеет встроенной поддержки российских алгоритмов электронной подписи, следует установить криптопровайдер отечественной криптографии.
Если сертификат подписи был заранее установлен в систему (в Хранилище сертификатов), то криптопровайдер знает, в каком контейнере от какого сертификата лежит закрытый ключ, и требует от пользователя ввода пароля от этого контейнера. Если закрытый ключ расположен на электронном ключе, криптопровайдер запрашивает пин-код. При успешном вводе пароля контейнер открывается, осуществляются операции с использованием закрытого ключа, после чего контейнер закрывается.

Про использование криптопровайдера и Microsoft Outlook/Office рассказывается в статье Использование электронного ключа доступа к порталу госуслуг для осуществления электронной подписи. Если требуется создать электронную подпись произвольного документа, например, XML-формы запроса «Единого реестра доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено» с сайта http://zapret-info.gov.ru, необходимо программное обеспечение с соответствующим функционалом (создание электронной подписи в формате PKCS#7).

При использовании программного криптопровайдера создание подписи с использованием квалифицированного сертификата, содержащегося в файле-контейнере и на электронном ключе ничем не отличается.

При использовании ключей подписи, содержащихся на электронных ключах, есть три варианта: использовать программный криптопровайдер (рассмотрено выше), использовать общедоступное программное обеспечение, реализующее стандартный интерфейс работы с электронными ключами PKCS#11, или создавать самописное ПО, использующее API разработчика электронного ключа. Последние два варианта используют встроенный в электронный ключ криптопровайдер.

Рассмотрим частный случай второго варианта.

OpenSUSE Linux + OpenSSL + OpenSC + Rutoken ECP

Здесь будет целесообразнее изложить материал в виде пошагового HOWTO.

1. OpenSUSE 12.2, доустанавливаем недостающее ПО

Включаем автостарт демона смарт-карт:

2. Обеспечиваем поддержку в OpenSSL электронного ключа Aktiv Rutoken ECP

Скачиваем с сайта производителя драйвера и настройки (всегда полезно поискать свежую версию):

Добавляем в исходный файл /etc/ssl/openssl.cnf секции:

Раскладываем библиотеки из архива по соответствующим каталогам, файл libp11.so.2 кладём в каталог /usr/lib/

Проверяем работоспособность электронного ключа:

Будет запрошен пин-код электронного ключа и выдан список объектов на ключе.

3. Считываем с электронного ключа сертификат подписи

Среди объектов, хранящихся на электронном ключе нас интересуют сертификат и закрытый ключ (поле ID уникально для каждой тройки объектов: открытый ключ, закрытый ключ, сертификат):

Извлекаем сертификат, который будет использоваться для подписи, в файл signer_cert.crt:

4. Создаём электронную подпись

Имеется некий файл document.txt, для которого мы хотим создать электронную подпись.

Поле -inkey e59e26a30000000020ffbbd2567ccd01 определяет ID закрытого ключа, использующегося при создании подписи.

На выходе получаем файлы: document.txt.detached.p7s, который содержит электронную подпись файла document.txt, и document.txt.attached.p7s, который содержит текст документа + его электронную подпись.

5. Проверяем электронные подписи

Примечание

17 декабря 2012 г., Лабазников Н.В., Начальник отдела сетевых технологий и информационной безопасности ООО»УЦИ»

Все права на статью принадлежат ООО «УЦИ». Разрешается копирование статьи без уведомления правообладателя. При копировании необходимо указывать ссылку на источник.

В отношении персональных данных ООО «УЦИ» придерживается политики

Источник

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

Введение

Внедрение электронной подписи (без разделения на используемые криптоалгоритмы и критерий «квалифицированности», см. закон 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 – веб-приложения и веб-сервисы.

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

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

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

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

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

Заключение

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

Источник

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

Статья посвящена обзору стандартов С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-токена.

Источник