Использование механизмов криптографических токенов 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 }
Список механизмовCKM_GOSTR3410_KEY_PAIR_GEN
CKM_GOSTR3410_512_KEY_PAIR_GEN
CKM_GOSTR3410
CKM_GOSTR3410_512
CKM_GOSTR3410_WITH_GOSTR3411
CKM_GOSTR3410_WITH_GOSTR3411_12_256
CKM_GOSTR3410_WITH_GOSTR3411_12_512
CKM_GOSTR3410_DERIVE
CKM_GOSTR3410_12_DERIVE
CKM_GOSR3410_2012_VKO_256
CKM_GOSR3410_2012_VKO_512
CKM_KDF_4357
CKM_KDF_GOSTR3411_2012_256
CKM_KDF_TREE_GOSTR3411_2012_256
CKM_GOSTR3410_KEY_WRAP
CKM_GOSTR3410_PUBLIC_KEY_DERIVE
CKM_LISSI_GOSTR3410_PUBLIC_KEY_DERIVE
CKM_GOST_GENERIC_SECRET_KEY_GEN
CKM_GOST_CIPHER_KEY_GEN
CKM_GOST_CIPHER_ECB
CKM_GOST_CIPHER_CBC
CKM_GOST_CIPHER_CTR
CKM_GOST_CIPHER_OFB
CKM_GOST_CIPHER_CFB
CKM_GOST_CIPHER_OMAC
CKM_GOST_CIPHER_KEY_WRAP
CKM_GOST_CIPHER_ACPKM_CTR
CKM_GOST_CIPHER_ACPKM_OMAC
CKM_GOST28147_KEY_GEN
CKM_GOST28147
CKM_GOST28147_KEY_WRAP
CKM_GOST28147_PKCS8_KEY_WRAP
CKM_GOST_CIPHER_PKCS8_KEY_WRAP
CKM_GOST28147_ECB
CKM_GOST28147_CNT
CKM_GOST28147_MAC
CKM_KUZNYECHIK_KEY_GEN
CKM_KUZNYECHIK_ECB
CKM_KUZNYECHIK_CBC
CKM_KUZNYECHIK_CTR
CKM_KUZNYECHIK_OFB
CKM_KUZNYECHIK_CFB
CKM_KUZNYECHIK_OMAC
CKM_KUZNYECHIK_KEY_WRAP
CKM_KUZNYECHIK_ACPKM_CTR
CKM_KUZNYECHIK_ACPKM_OMAC
CKM_MAGMA_KEY_GEN
CKM_MAGMA_ECB
CKM_MAGMA_CBC
CKM_MAGMA_CTR
CKM_MAGMA_OFB
CKM_MAGMA_CFB
CKM_MAGMA_OMAC
CKM_MAGMA_KEY_WRAP
CKM_MAGMA_ACPKM_CTR
CKM_MAGMA_ACPKM_OMAC
CKM_GOSTR3411
CKM_GOSTR3411_12_256
CKM_GOSTR3411_12_512
CKM_GOSTR3411_HMAC
CKM_GOSTR3411_12_256_HMAC
CKM_GOSTR3411_12_512_HMAC
CKM_PKCS5_PBKD2
CKM_PBA_GOSTR3411_WITH_GOSTR3411_HMAC
CKM_TLS_GOST_KEY_AND_MAC_DERIVE
CKM_TLS_GOST_PRE_MASTER_KEY_GEN
CKM_TLS_GOST_MASTER_KEY_DERIVE
CKM_TLS_GOST_PRF
CKM_TLS_GOST_PRF_2012_256
CKM_TLS_GOST_PRF_2012_512
CKM_TLS12_MASTER_KEY_DERIVE
CKM_TLS12_KEY_AND_MAC_DERIVE
CKM_TLS_MAC
CKM_TLS_KDF
CKM_TLS_TREE_GOSTR3411_2012_256
CKM_EXTRACT_KEY_FROM_KEY
CKM_SHA_1
CKM_MD5

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

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
8886a39289c3f81bdf2e179ASN1-структура публичного ключа берется из сертификата подписанта:

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)
}
Текст скрипта для проверки электронной подписи сертификатов из файла находится здесь#! /usr/bin/env tclsh
package require pki
lappend auto_path .
package require pki::pkcs11
#Задайте путь к вашей библиотеке PKCS#11
#set pkcs11_module «/usr/local/lib/libcackey.so»
#set pkcs11_module «/usr/local/lib64/librtpkcs11ecp_2.0.so»
set pkcs11_module «/usr/local/lib64/libls11sw2016.so»
puts «Connect the Token and press Enter»
gets stdin yes
set handle [pki::pkcs11::loadmodule $pkcs11_module]
set slots [pki::pkcs11::listslots $handle]
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 token_slotlabel $slotlabel
set token_slotid $slotid
#Найден слот с токеном
break
}
}
#Из PEM в DER
proc ::cert_to_der {data} {
if {[string first «——BEGIN CERTIFICATE——» $data] != -1} {
set data [string map {«rn» «n»} $data]
}
array set parsed_cert [::pki::_parse_pem $data «——BEGIN CERTIFICATE——» «——END CERTIFICATE——«]
if {[string range $parsed_cert(data) 0 0 ] == «0» } {
#Очень похоже на DER-кодировка «0» == 0x30
set asnblock $parsed_cert(data)
} else {
set asnblock «»
}
return $asnblock
}
proc usage {use error} {
puts «Copyright(C) Orlov Vladimir (http://soft.lissi.ru) 2019»
if {$use == 1} {
puts $error
puts «Usage:nverify_cert_with_pkcs11 <file with certificate> [<file with CA certificate>]n»
}
}
set countcert [llength $argv]
if { $countcert < 1 || $countcert > 2 } {
usage 1 «Bad usage!»
exit
}
set file [lindex $argv 0]
if {![file exists $file]} {
usage 1 «File $file not exist»
exit
}
#Проверяемый сертификат cert_user
puts «Loading user certificate: $file»
set fd [open $file]
chan configure $fd -translation binary
set cert_user [read $fd]
close $fd
if {$cert_user == «» } {
usage 1 «Bad file with certificate user: $file»
exit
}
set cert_user [cert_to_der $cert_user]
if {$cert_user == «»} {
puts «User certificate bad»
exit
}
catch {array set cert_parse [::pki::x509::parse_cert $cert_user]}
if {![info exists cert_parse]} {
puts «User certificate bad»
exit
}
#parray cert_parse
if {$countcert == 1} {
if {$cert_parse(issuer) != $cert_parse(subject)} {
puts «Bad usage: not self signed certificate»
} else {
set cert_CA $cert_user
}
} else {
set fileca [lindex $argv 1]
if {![file exists $fileca]} {
usage 1 «File $fileca not exist»
exit
}
#Сертификат издателя cert_CA
puts «Loading CA certificate: $fileca»
set fd [open $fileca]
chan configure $fd -translation binary
set cert_CA [read $fd]
close $fd
if {$cert_CA == «» } {
usage 1 «Bad file with certificate CA=$fileca»
exit
}
set cert_CA [cert_to_der $cert_CA]
if {$cert_CA == «»} {
puts «CA certificate bad»
exit
}
}
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 token_slotlabel $slotlabel
set token_slotid $slotid
}
}
#Ключ от корневого сертификата
#array set cert_parse_CA [::pki::x509::parse_cert $cert_CA]
catch {array set cert_parse_CA [::pki::x509::parse_cert $cert_CA]}
#array set cert_parse_CA [::pki::x509::parse_cert $cert_CA_256]
#array set cert_parse_CA [::pki::x509::parse_cert $CA_12_512]
if {![info exists cert_parse_CA]} {
puts «CA certificate bad»
exit
}
###############################
set aa [dict create pkcs11_handle $handle pkcs11_slotid $token_slotid]
set tbs_cert [binary format H* $cert_parse(cert)]
#puts «SIGN_ALGO1=$cert_parse(signature_algo)»
catch {set signature_algo_number [::pki::_oid_name_to_number $cert_parse(signature_algo)]}
if {![info exists signature_algo_number]} {
set signature_algo_number $cert_parse(signature_algo)
}
#puts «SIGN_ALGO=$signature_algo_number»
switch — $signature_algo_number {
«1.2.643.2.2.3» — «1 2 643 2 2 3» {
# «GOST R 34.10-2001 with GOST R 34.11-94»
set digest_algo «gostr3411»
}
«1.2.643.7.1.1.3.2» — «1 2 643 7 1 1 3 2» {
# «GOST R 34.10-2012-256 with GOSTR 34.11-2012-256»
set digest_algo «stribog256»
}
«1.2.643.7.1.1.3.3» — «1 2 643 7 1 1 3 3» {
# «GOST R 34.10-2012-512 with GOSTR 34.11-2012-512»
set digest_algo «stribog512»
}
default {
puts «Неизвестная алгоритм подписи:$signature_algo_number»
exit
}
}
#Посчитать хэш от tbs-сертификата!!!!
set digest_hex [pki::pkcs11::digest $digest_algo $tbs_cert $aa]
puts «digest_hex=$digest_hex»
puts [string length $digest_hex]
#Получаем asn-структуру публичного ключа
#Создаем список ключевых элементов
binary scan $cert_CA H* cert_CA_hex
array set infopk [pki::pkcs11::pubkeyinfo $cert_CA_hex [list pkcs11_handle $handle pkcs11_slotid $token_slotid]]
parray infopk
set lpk [dict create pkcs11_handle $handle pkcs11_slotid $token_slotid]
#Добавляем pybkeyinfo в список ключевых элементов
lappend lpk «pubkeyinfo»
#lappend lpk $pubinfo
lappend lpk $infopk(pubkeyinfo)
array set lpkar $lpk
parray lpkar
puts «Enter PIN user for you token «$token_slotlabel»:»
#set password «01234567»
gets stdin password
if { [pki::pkcs11::login $handle $token_slotid $password] == 0 } {
puts «Bad password»
exit
}
if {[catch {set verify [pki::pkcs11::verify $digest_hex $cert_parse(signature) $lpk]} res] } {
puts $res
exit
}
if {$verify != 1} {
puts «BAD SIGNATURE=$verify»
} else {
puts «SIGNATURE OK=$verify»
}
puts «Конец!»
exit

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

$./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. До встречи!

Оставить комментарий