При осуществлении электронного документооборота требуется создание электронной подписи документа для придания ему юридической значимости.

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

В Российской Федерации приняты: стандарт ЭП первого уровня - ГОСТ 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 г., Лабазников Н.В., Начальник отдела сетевых технологий и информационной безопасности ООО"УЦИ"

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