Использование механизмов криптографических токенов PKCS#11 в скриптовых языках

В своих комментариях к статье «Англоязычная кроссплатформенная утилита для просмотра российских квалифицированных сертификатов x509» пользователь Pas очень правильно заметил про токены PKCS#11, что они «сами все умеют считать». Да, токены фактически являются криптографическими компьютерами. И естественным является желанием использовать эти компьютеры в скриптовых языках будь то Python, Perl или Ruby. Мы уже так или иначе рассматривали использование токенов PKCS#11 с поддержкой российской криптографии в Python для подписания и шифрования документов, для создания запроса на сертификат:



Здесь же мы продолжим разговор о языке Tcl. В предыдущей статье, когда мы рассматривали просмотр и валидацию сертификатов, хранящихся на токенах/смарткартах PKCS#11, мы использовали для доступа к ним (сертификатам) пакет TclPKCS11 версии 0.9.9. Как уже отмечалось, к сожалению, пакет разрабатывался под криптографию RSA и с учетом стандарта PKCS#11 v.2.20. Сегодня уже используется стандарт PKCS#11 v.2.40 и именно на него ориентируется технический комитет по криптографии ТК-26, выпуская рекомендации для отечественных производителей токенов/смарткарт, поддерживающих российскую криптографию. И вот с учетом всего сказанного появилась новый пакет TclPKCS11 версии 1.0.1 . Сразу огововоримся, все криптографические интерфейсы для RSA в новой версии пакета TclPKCS11 v.10.1 сохранены. Библиотека пакета написана на языке Си.

Итак, что нового появилось в пакете? Прежде всего добавлена команда, позволяющая получить список поддерживаемых подключенным токеном криптографических механизмов:

::pki::pkcs11::listmechs <handl> <slotid>

Как получить список слотов с подключенными токенами показано здесь (процедура — proc ::slots_with_token):

proc ::slots_with_token {handle} {
    set slots [pki::pkcs11::listslots $handle]
#    puts "Slots: $slots"
    array set listtok []
    foreach slotinfo $slots {
	set slotid [lindex $slotinfo 0]
	set slotlabel [lindex $slotinfo 1]
	set slotflags [lindex $slotinfo 2]
	if {[lsearch -exact $slotflags TOKEN_PRESENT] != -1} {
	    set listtok($slotid) $slotlabel
	}
    }
#Список найденных токенов в слотах
    parray listtok
    return [array get listtok]
}

Возьмем простой скрипт:

#!/usr/bin/tclsh
lappend auto_path .
package require pki::pkcs11
#Библиотека для доступа к токенам семейства RuToken
set lib "/usr/local/lib64/librtpkcs11ecp_2.0.so"
<source lang="bash">set handle [pki::pkcs11::loadmodule $lib]
#Не забудьте вставить токен
#Получаем список слотов с метками подключенных токенов
set labslot [::slots_with_token $handle]
if {[llength $labslot] == 0} {
    puts "Вы не подключили ни одного токена"
    exit
}
set slotid 0
set lmech [pki::pkcs11::listmechs $handle $slotid]
set i 0
foreach mm $lmech {
#Ищем механизмы ГОСТ
    if {[string first "GOSTR3410" $mm] != -1} { 
	puts -nonewline "[lindex $mm 0] "
	if {$i == 2} {puts "";set i  0}  else { incr i}
    }
}
puts "\n"
exit

Этот скрипт позволяет получить список механизмов для криптографии GOSTR3410, поддерживаемых на токенах семейства RuToken. Для начала возьмем, как писал в статье Pas, «любимый всякими ЭДО Рутокен Лайт»:

$ tclsh TEST_for_HABR.tcl  
listtok(0) = ruToken Lite                     
0 {ruToken Lite                    } 
$

И естественно окажется, что он не поддерживает ни одного мезанизма ГОСТ, что и требовалось доказать. Берем другой токен Рутокен ЭЦП:

$ tclsh TEST_for_HABR.tcl  
listtok(0) = ruToken ECP }                     
0 {ruToken ECP                     } 
CKM_GOSTR3410_KEY_PAIR_GEN CKM_GOSTR3410 CKM_GOSTR3410_DERIVE  
CKM_GOSTR3410_WITH_GOSTR3411  
$

Да, этот токен поддерживает российскую криптографию, но только подпись ГОСТ Р 34.10-2001, которая практически вышла из употребления. Но если взять токен Рутокен ЭЦП-2.0, то все будет хорошо, он поддерживает ГОСТ Р 34.10-2012 с ключами длиной 256 и 512 бит:

$ tclsh TEST_for_HABR.tcl  
listtok(0) = RuTokenECP20                     
0 {RuTokenECP20                    } 
CKM_GOSTR3410_KEY_PAIR_GEN CKM_GOSTR3410 CKM_GOSTR3410_DERIVE  
CKM_GOSTR3410_512_KEY_PAIR_GEN CKM_GOSTR3410_512 CKM_GOSTR3410_12_DERIVE
CKM_GOSTR3410_WITH_GOSTR3411 CKM_GOSTR3410_WITH_GOSTR3411_12_256 CKM_GOS
TR3410_WITH_GOSTR3411_12_512  
$

Если мы заговорили о поддержке российской криптографии, включая алгоритмы шифрования кузнечик и магму, теми или иными токенами, то наиболее полно ее поддерживают программные и облачные токены и это естественно:

$ tclsh TEST_for_HABR.tcl  
listtok(0) = LS11SW2016_LIN_64                
0 {LS11SW2016_LIN_64               } 

$

Переходим в следующей новой функции, добавленной в пакет:

set listcertsder [pki::pkcs11::listcertsder $handle $slotid]

Эта функция возвращает список сертификатов, хранящихся ни токене. Естественно возникает вопрос, а чем она отличается от уже имеющейся функции pki::pkcs11::listcerts?

Прежде всего новая функция не задействует пакет ::pki. Одним из возвращаемых элементов является элемент cert_der, содержащий полный сертификат. Это удобно, например, при экспорте сертификата, или получения его отпечатка (fingetprint). Ранее приходилось собирать полный сертификат из tbs-сертификата и его подписи. Полный перечень возвращаемых элементов для каждого сертификата наглядно видно при распечатке содержимого одного сертификата:

. . . 
array set derc [[pki::pkcs11::listcertsder $handle $slotid] 0]
parray derc
derc(cert_der)      = 3082064a …
derc(pkcs11_handle) = pkcsmod0 
derc(pkcs11_id)     = 5882d64386211cf3a8367d2f87659f9330e5605d 
derc(pkcs11_label)  = Thenderbird-60 от УЦ
derc(pkcs11_slotid) = 0 
derc(type)          = pkcs11
. . .

Элемент pkcs11_id хранит атрибут CKA_ID значение хэш SHA-1 от открытого ключа. Элемент cert_der это CKA_VALUE сертификата, pkcs11_label это CKA_LABEL.

Элемент pkcs11_id (CKA_ID в терминологии стандарта PKCS#11) является наравне с pkcs11_handle библиотеки и идентификатор слота с токеном pkcs11_slotid ключевым элементом для доступа к ключам и сертификатам, хранящимся на токенах.

Так, если мы хотим сменить метку (pkcs11_label) у сертификата или ключей, мы выполняем команду вида:

pki::pkcs11::rеname <cert|key|all>   <список ключевых элементов>

Для удаления с токена сертификата или ключей выполняется команда вида:

pki::pkcs11::delete  <cert|key|all>   <список ключевых элементов>

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

set listparam {}
lappend listparam pkcs11_handle
lappend listparam  $handle
lappend listparam pkcs11_slotid
lappend listparam $pkcs11_slotid
lappend listparam pkcs11_id
lappend listparam $pkcs11_id

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

pki::pkcs11::delete all $listparam

Читатель уже, наверное, догадался, что этот список можно оформить как словарь dict:

set listparam [dict create pkcs11_handle $pkcs11_handle]
dict set listparam pkcs11_slotid $pkcs11_slotid)
dict set listparam pkcs11_id $pkcs11_id

Есть и другие способы, например, через массив (array).

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

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

set pkcs11_id_cert [::pki::pkcs11::importcert  <cert_der_hex>  <список ключевых параметров> 

Функция возвращает значение CKA_ID в шестнадцатеричном виде. Список ключевых параметров определяет токен, на котором будет находится сертификат:

{pkcs11_handle  <handle>  pkcs11_slotid  <slotid>}

На очереди у нас вычисление хэша. В российской криптографии сегодня используется три вида хэш функции:
— ГОСТ Р 34.11-94
— ГОСТ Р 34 .11-2012 с длиной хэш значения 256 бит (stribog256)
— ГОСТ Р 34 .11-2012 с длиной хэш значения 512 бит (stribog512)
Для определения какой хэш поддерживает токен у нас есть функция pki::pkcs11::listmechs.

Функция вычисления хэша имеет следующий вид:

set <результат> [pki::pkcs11::digest <gostr3411|stribog256|stribog512|sha1>  <данные для хеширования> <список ключевых элементов>]

Отметим, что результат вычисления вычисления представляется в шестнадцатеричном виде:

. . . 
set listparam [dict create pkcs11_handle $pkcs11_handle]
dict set listparam pkcs11_slotid $pkcs11_slotid
set res_hex [pki::pkcs11::digest stribog256 0123456789 $listparam]
puts $res_hex
086f2776f33aae96b9a616416b9d1fe9a049951d766709dbe00888852c9cc021

Для проверки возьмем openssl с поддержкой российской криптографии:

$ echo -n "0123456789"|/usr/local/lirssl_csp_64/bin/lirssl_s
tatic  dgst -md_gost12_256 
(stdin)= 086f2776f33aae96b9a616416b9d1fe9a0499 51d766709dbe00888852c9
cc021 
$

Как видим, результат получен идентичный.

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

set result [pki::pkcs11::verify <хэш документа> <подпись документа> <список ключевых элементов>]] 

Если подпись прошла проверку, то возвращается 1, в противном случае – 0. Для проверки электронной подписи требуется сама подпись документа, хэш документа, определяемый типом подписи, и открытый ключ, которым была создана подпись, со всеми параметрами (значение, тип и параметры). Вся информация о ключе в виде asn1-структуры publickeyinfo должна быть включена в список ключевых элементов:

lpkar(pkcs11_handle) = pkcsmod0
lpkar(pkcs11_slotid) = 0
lpkar(pubkeyinfo) = 301f06082a85030701010101301306072a85030202240
006082a8503070101020203430004407d9306687af5a8e63af4b09443ed2e03794be
10eba6627bf5fb3da1bb474a3507d2ce2cd24b63c727a02521897d1dd6edbdc7084d
8886a39289c3f81bdf2e179

ASN1-структура публичного ключа берется из сертификата подписанта:

proc ::pki::x509::parse_cert_pubkeyinfo {cert_hex} {
	array set ret [list]
	set wholething [binary format H* $cert_hex]
	::asn::asnGetSequence wholething cert
	::asn::asnPeekByte cert peek_tag
	if {$peek_tag != 0x02} {
		# Version number is optional, if missing assumed to be value of 0
		::asn::asnGetContext cert - asn_version
		::asn::asnGetInteger asn_version ret(version)
	}
	::asn::asnGetBigInteger cert ret(serial_number)
	::asn::asnGetSequence cert data_signature_algo_seq
		::asn::asnGetObjectIdentifier data_signature_algo_seq ret(data_signature_algo)
	::asn::asnGetSequence cert issuer
	::asn::asnGetSequence cert validity
		::asn::asnGetUTCTime validity ret(notBefore)
		::asn::asnGetUTCTime validity ret(notAfter)
	::asn::asnGetSequence cert subject
	::asn::asnGetSequence cert pubkeyinfo
	binary scan $pubkeyinfo H* ret(pubkeyinfo)
	return $ret(pubkeyinfo)
}

Текст скрипта для проверки электронной подписи сертификатов из файла находится
Сохраните скрипт в файле и попробуйте его выполнить:

$./verify_cert_with_pkcs11.tcl                                 
Copyright(C) Orlov Vladimir (http://museum.lissi-crypto.ru/) 
Usage: verify_cert_with_pkcs11 <file with certificate> <file with CA certificate> 
$

Можно удивиться, а как же сертификаты на токене? Первое, мы решали задачу использования криптографических машин PKCS#11. Мы их задействовали. А чтобы проветить сертификат с токена есть функция пакета pki::pkcs11::listcertsder, которая позволяет выбрать нужный сертификат и проверить его. Это можно рассматривать в качестве домашнего задания.

Появление новой вервии пакета TclPKCS11v.1.0.1 позволило доработать утилиту просмотра сертификатов, добавив в нее функции импорта сертификата на токен, удаление сертификатов и сопутствующих ключей с токена, смена меток сертификатов и ключей и т.д.:



Самая важная добавленная функция это проверка цифровой подписи сертификата:



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

array set  genkey [pki::pkcs11::keypair <тип ключа> <параметр> <список ключевых элементов>]

Как используются функции из пакета TclPKCS11, естественно, можно найти в исходном коде утилиты.

Подробно функция генерации ключевой пары будет рассмотрена в следующей статье, когда будет представлена утилита создания запроса на квалифицированный сертификат с генерацией ключевой пары на токене PKCS#11, механизм получения сертификата в удостоверяющем центре (УЦ) и импорта его на токен:



В этой же статье будет рассмотрена и функция подписания документа. Это будет последняя статья из этой серии. Дальше планируется ряд статей о поддержки российской криптографии в модном сегодня скриптовом языке Ruby. До встречи!