Создание и проверка электронной подписи в формате PKCS#7 с использованием квалифицированного сертификата
Стандарты на ЭП являются двухуровневыми. Первый уровень представляет собой непосредственно ЭП документа (подпись с помощью закрытого ключа). Вторым уровнем называют совокупность ЭП и всех документов, необходимых для обеспечения юридической значимости ЭП: сертификат ключа, с помощью которого осуществлялось подписание, или цепочку сертификатов, время создания подписи и т.д.
В Российской Федерации приняты: стандарт ЭП первого уровня - ГОСТ 34-10.2001, второго уровня - PKCS#7 с возможностью добавления временных меток.
Это обязывает владельца квалифицированного сертификата, например, при подаче заявления в государственный орган создать электронную подпись документа в формате PKCS#7 и подать её вместе с заявлением. Обратившееся лицо будет однозначно идентифицировано, осуществится проверка целостности и неизменности заявления с момента создания и проверка электронной подписи заявителя, которая при успешности всех предыдущих проверок будет приравнена к собственноручной подписи заявителя.
Создание подписи с использованием программного криптопровайдера
Ключ подписи и его сертификат могут распространяться в двух формах:
- Файл-контейнер;
- Электронный ключ (например, Rutoken или eToken).
Файл-контейнер
Если нет желания тратиться на электронный ключ, можно получить в удостоверяющем центре ключ подписи и сертификат в виде файла-контейнера, который представляет собой программный аналог электронного ключа. Доступ к ключу подписи, содержащемуся в файле-контейнере осуществляется при помощи программного криптопровайдера с использованием пароля (доступ к ключу подписи, содержащемуся в электронном ключе осуществляется при помощи встроенного в ключ криптопровайдера с использованием пин-кода).
Внешние программы, например 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, доустанавливаем недостающее ПО
zypper install openssl engine_pkcs11 pcsc-ccid libpcsclite1 libtool opensc
Включаем автостарт демона смарт-карт:
chkconfig pcscd on
2. Обеспечиваем поддержку в OpenSSL электронного ключа Aktiv Rutoken ECP
Скачиваем с сайта производителя драйвера и настройки (всегда полезно поискать свежую версию):
wget http://www.rutoken.ru/download/software/forum/pkcs11-gost-linux-2-x86.zip
Внутри архива - 4 файла:
libp11.so.2 libpkcs11_gost.so librtpkcs11ecp.so openssl.cnf
Добавляем в исходный файл /etc/ssl/openssl.cnf секции:
[openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [gost_section] default_algorithms = ALL [pkcs11_section] engine_id = pkcs11_gost dynamic_path = /usr/lib/pkcs11-gost/libpkcs11_gost.so MODULE_PATH = /usr/lib/pkcs11-gost/librtpkcs11ecp.so init = 0
, а в самое начало файла - строку "openssl_conf = openssl_def"
Раскладываем библиотеки из архива по соответствующим каталогам, файл libp11.so.2 кладём в каталог /usr/lib/
Проверяем работоспособность электронного ключа:
pkcs11-tool --module /usr/lib/pkcs11-gost/librtpkcs11ecp.so -Ol
Будет запрошен пин-код электронного ключа и выдан список объектов на ключе.
3. Считываем с электронного ключа сертификат подписи
Среди объектов, хранящихся на электронном ключе нас интересуют сертификат и закрытый ключ (поле ID уникально для каждой тройки объектов: открытый ключ, закрытый ключ, сертификат):
Certificate Object, type = X.509 cert label: ViPNet Certificate ID: e59e26a30000000020ffbbd2567ccd01 Private Key Object; GOSTR3410 PARAMS OID: 06072a850302022400 label: ViPNet PrivateKey ID: e59e26a30000000020ffbbd2567ccd01 Usage: decrypt, sign
Извлекаем сертификат, который будет использоваться для подписи, в файл signer_cert.crt:
pkcs11-tool --module /usr/lib/pkcs11-gost/librtpkcs11ecp.so -l -r \ -y cert -d e59e26a30000000020ffbbd2567ccd01 -o signer_cert.crt
В этой команде -d e59e26a30000000020ffbbd2567ccd01 - ID сертификата.
4. Создаём электронную подпись
Имеется некий файл document.txt, для которого мы хотим создать электронную подпись.
Присоединённую:
openssl smime -engine pkcs11_gost -sign -in document.txt \ -out document.txt.attached.p7s -outform der -noverify -binary \ -signer certpem.crt -inkey e59e26a30000000020ffbbd2567ccd01 \ -keyform engine -nodetach
Отсоединённую:
openssl smime -engine pkcs11_gost -sign -in document.txt \ -out document.txt.detached.p7s -outform der -noverify -binary \ -signer certpem.crt -inkey e59e26a30000000020ffbbd2567ccd01 \ -keyform engine
Поле -inkey e59e26a30000000020ffbbd2567ccd01 определяет ID закрытого ключа, использующегося при создании подписи.
На выходе получаем файлы: document.txt.detached.p7s, который содержит электронную подпись файла document.txt, и document.txt.attached.p7s, который содержит текст документа + его электронную подпись.
5. Проверяем электронные подписи
Присоединённую:
openssl smime -verify -in document.txt.attached.p7s -noverify -inform der
Отсоединённую:
openssl smime -verify -in document.txt.attached.p7s -noverify -inform der -content document.txt
Примечание
Во всех командах openssl используется параметр -noverify - не происходит автоматическая проверка сертификата подписи на валидность.
__________________________________
17 декабря 2012 г., Лабазников Н.В., Начальник отдела сетевых технологий и информационной безопасности ООО"УЦИ"
Все права на статью принадлежат ООО "УЦИ". Разрешается копирование статьи без уведомления правообладателя. При копировании необходимо указывать ссылку на источник.