Подошло время рассказать как была добавлена поддержка российской криптографии в проект PyKCS11. Всё началось с того, что мне на глаза попалась переписка разработчика проекта PyKCS11 с потенциальными потребителями по поводу возможной поддержки алгоритмов ГОСТ Р 34.10-2012 в нём. В этой переписке автор PkCS11 сказал, что не собирается включать поддержку российских криптоалгоритмов до тех пор, пока они не будут стандартизованы.Ту же самую мысль он выразил и мне, когда я предложил ему это сделать. И не просто сделать, а выслал соответствующий программный код:
После этого я посчитал возможным форкнуть код в свой репозиторий и внести в него соответствующие правки. Проект PyKCS11 с поддержкой российской криптографии находится здесь.
I. Добавляем поддержку российских криптоалгоритмов
Итак, что же было сделано. Я фактически последовал одному из советов автора проекта PyKCS11:
What I can propose you is to create a PyKCS11_GOST.py file with the constant names and functions you want in order to extend PyKCS11 with GOST support.
(Я могу предложить вам создать файл PyKCS11_GOST.py с именами констант и функциями, которыми вы хотите расширить PyKCS11 для поддержки ГОСТ.)
Все константы, утвержденные ТК-26 для PKCS#11, были сведены в один файл pkcs11t_gost.h, помещенный в папку src:
//ТК-26
#define NSSCK_VENDOR_PKCS11_RU_TEAM 0xd4321000
#define NSSCK_VENDOR_PKSC11_RU_TEAM NSSCK_VENDOR_PKCS11_RU_TEAM
#define CK_VENDOR_PKCS11_RU_TEAM_TC26 NSSCK_VENDOR_PKCS11_RU_TEAM
#define CKK_GOSTR3410_512 0xd4321003UL
#define CKK_KUZNYECHIK 0xd4321004UL
#define CKK_MAGMA 0xd4321005UL
#define CKK_GOSTR3410_256 0xd4321006UL
#define CKP_PKCS5_PBKD2_HMAC_GOSTR3411_TC26_V1 0xd4321801UL
#define CKP_PKCS5_PBKD2_HMAC_GOSTR3411_2012_256 0xd4321002UL
#define CKP_PKCS5_PBKD2_HMAC_GOSTR3411_2012_512 0xd4321003UL
#define CKM_GOSTR3410_512_KEY_PAIR_GEN 0xd4321005UL
#define CKM_GOSTR3410_512 0xd4321006UL
#define CKM_GOSTR3410_WITH_GOSTR3411 0x00001202
#define CKM_GOSTR3410_WITH_GOSTR3411_12_256 0xd4321008UL
#define CKM_GOSTR3410_WITH_GOSTR3411_12_512 0xd4321009UL
#define CKM_GOSTR3410_12_DERIVE 0xd4321007UL
#define CKM_GOSR3410_2012_VKO_256 0xd4321045UL
#define CKM_GOSR3410_2012_VKO_512 0xd4321046UL
#define CKM_KDF_4357 0xd4321025UL
#define CKM_KDF_GOSTR3411_2012_256 0xd4321026UL
#define CKM_KDF_TREE_GOSTR3411_2012_256 0xd4321044UL
#define CKM_GOSTR3410_PUBLIC_KEY_DERIVE 0xd432100AUL
#define CKM_LISSI_GOSTR3410_PUBLIC_KEY_DERIVE 0xd4321037UL
#define CKM_GOST_GENERIC_SECRET_KEY_GEN 0xd4321049UL
#define CKM_GOST_CIPHER_KEY_GEN 0xd4321048UL
#define CKM_GOST_CIPHER_ECB 0xd4321050UL
#define CKM_GOST_CIPHER_CBC 0xd4321051UL
#define CKM_GOST_CIPHER_CTR 0xd4321052UL
#define CKM_GOST_CIPHER_OFB 0xd4321053UL
#define CKM_GOST_CIPHER_CFB 0xd4321054UL
#define CKM_GOST_CIPHER_OMAC 0xd4321055UL
#define CKM_GOST_CIPHER_KEY_WRAP 0xd4321059UL
#define CKM_GOST_CIPHER_ACPKM_CTR 0xd4321057UL
#define CKM_GOST_CIPHER_ACPKM_OMAC 0xd4321058UL
#define CKM_GOST28147_PKCS8_KEY_WRAP 0xd4321036UL
#define CKM_GOST_CIPHER_PKCS8_KEY_WRAP 0xd432105AUL
#define CKM_GOST28147_CNT 0xd4321825UL
#define CKM_KUZNYECHIK_KEY_GEN 0xd4321019UL
#define CKM_KUZNYECHIK_ECB 0xd432101AUL
#define CKM_KUZNYECHIK_CBC 0xd432101EUL
#define CKM_KUZNYECHIK_CTR 0xd432101BUL
#define CKM_KUZNYECHIK_OFB 0xd432101DUL
#define CKM_KUZNYECHIK_CFB 0xd432101CUL
#define CKM_KUZNYECHIK_OMAC 0xd432101FUL
#define CKM_KUZNYECHIK_KEY_WRAP 0xd4321028UL
#define CKM_KUZNYECHIK_ACPKM_CTR 0xd4321042UL
#define CKM_KUZNYECHIK_ACPKM_OMAC 0xd4321043UL
#define CKM_MAGMA_KEY_GEN 0xd432102AUL
#define CKM_MAGMA_ECB 0xd4321018UL
#define CKM_MAGMA_CBC 0xd4321023UL
#define CKM_MAGMA_CTR 0xd4321020UL
#define CKM_MAGMA_OFB 0xd4321022UL
#define CKM_MAGMA_CFB 0xd4321021UL
#define CKM_MAGMA_OMAC 0xd4321024UL
#define CKM_MAGMA_KEY_WRAP 0xd4321029UL
#define CKM_MAGMA_ACPKM_CTR 0xd4321040UL
#define CKM_MAGMA_ACPKM_OMAC 0xd4321041UL
#define CKM_GOSTR3411_12_256 0xd4321012UL
#define CKM_GOSTR3411_12_512 0xd4321013UL
#define CKM_GOSTR3411_12_256_HMAC 0xd4321014UL
#define CKM_GOSTR3411_12_512_HMAC 0xd4321015UL
#define CKM_PBA_GOSTR3411_WITH_GOSTR3411_HMAC 0xd4321035UL
#define CKM_TLS_GOST_KEY_AND_MAC_DERIVE 0xd4321033UL
#define CKM_TLS_GOST_PRE_MASTER_KEY_GEN 0xd4321031UL
#define CKM_TLS_GOST_MASTER_KEY_DERIVE 0xd4321032UL
#define CKM_TLS_GOST_PRF 0xd4321030UL
#define CKM_TLS_GOST_PRF_2012_256 0xd4321016UL
#define CKM_TLS_GOST_PRF_2012_512 0xd4321017UL
#define CKM_TLS_TREE_GOSTR3411_2012_256 0xd4321047ULВ этот перечень вошли механизмы как необходимые для формирования и проверки подписи по (ГОСТ Р 34.10-2012) ГОСТ Р 34.10-2012, так и шифрования (ГОСТ Р 34.12-2015 и ГОСТ Р 34.13-2015 — алгоритмы шифрования Кузнечик и Магма). Естественно, здесь же присутствуют и алгоритмы хэширования ГОСТ Р 34.11-2012.
Для того, чтобы ГОСТ-овые константы попали в процесс сборки модуля, необходимо добавить в файл pkcs11.i (файл для SWIG) оператор включения файла pkcs11t_gost.h
%include "pkcs11t_gost.h"перед оператором
%include "pkcs11lib.h"Но это еще не всё. В методе getMechanismList (script PKCS11/__init__.py) заблокирован вывод механизмов, чей код больше CKM_VENDOR_DEFINED (именно об этом и пишет автор проекта PyKCS11) (0x80000000L). Заметим, что ГОСТ-овые константы для новых алгоритмов попадают под это ограничение. Необходимо его снять хотя бы для ГОСТ-ов, поэтому заменим код метода getMechanismList на новый:
def getMechanismList(self, slot):
"""
C_GetMechanismList
:param slot: slot number returned by :func:`getSlotList`
:type slot: integer
:return: the list of available mechanisms for a slot
:rtype: list
"""
mechanismList = PyKCS11.LowLevel.ckintlist()
rv = self.lib.C_GetMechanismList(slot, mechanismList)
if rv != CKR_OK:
raise PyKCS11Error(rv)
m = []
#Правки для ГОСТ
#define NSSCK_VENDOR_PKCS11_RU_TEAM 0xd4321000
for x in range(len(mechanismList)):
mechanism = mechanismList[x]
if mechanism >= CKM_VENDOR_DEFINED:
if mechanism >= CKM_VENDOR_DEFINED and mechanism < 0xd4321000:
k = 'CKM_VENDOR_DEFINED_0x%X' % (mechanism - CKM_VENDOR_DEFINED)
CKM[k] = mechanism
CKM[mechanism] = k
m.append(CKM[mechanism])
return m
#ORIGINAL
# for x in range(len(mechanismList)):
# mechanism = mechanismList[x]
# if mechanism >= CKM_VENDOR_DEFINED:
# k = 'CKM_VENDOR_DEFINED_0x%X' % (mechanism - CKM_VENDOR_DEFINED)
# CKM[k] = mechanism
# CKM[mechanism] = k
# m.append(CKM[mechanism])
# return mОтметим также, что несмотря на то, что в модуль включены все механизмы, которые определены во включаемых файлах pkcs11t.h и pkcs11t_gost.h для pkcs11 v.2.40, не все эти механизмы могут быть выполнены. Проблема состоит в том, что для некоторых из них требуется определенная структура параметров. Это, в частности, относится к механизму CKM_RSA_PKCS_OAEP, которому требуются параметры в виде структуры CK_RSA_PKCS_OAEP_PARAMS, и механизму CKM_PKCS5_PBKD2, который ждет параметров в виде структуры CK_PKCS5_PBKD2_PARAMS. Есть и другие механизмы. Но поскольку автор реализовал отдельные структуры для отдельных механизмов (для того же CKM_RSA_PKCS_OAEP), то не составит труда реализовать поддержку структур параметров и для других механизмов. Так, если кому потребуется работа с контейнером PKCS#12, то придется реализовать поддержку структуры CK_PKCS5_PBKD2_PARAMS.
Всё это относится к довольно сложным криптографическим механизмам.
А вот всё то, что касается хэширования, формирования проверки электронной подписи, наконец, шифрования, то всё работает замечательно. Но для начала надо собрать проект.
II. Сборка обертки PyKCS11 с поддержкой ГОСТ-ов
Она ничем не отличается от сборки родной обёртки PkCS11 за исключением того, что исходный код необходимо получить здесь.
Далее следуем инструкции по сборке и установке пакета PyKCS11.
Для тестирования потребуется токен с поддержкой российской криптографии. Здесь мы имеем в виду ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. Это может быть как аппаратный токен, например RuTokenECP-2.0, так и программные или облачные токены.
Установить программный токен или получить доступ к облачному токену можно, воспользовавшись утилитой cryptoarmpkcs.
После запуска утилиты необходимо зайти на вкладку «Создать токены»:
На вкладке можно найти инструкции для получения и установки токенов.
III. Тестирование российских алгоритмов
Для тестирования можно использовать скрипты, которые лежат в папке testGost:
- ckm_kuznyechik_cbc.py
- ckm_gostr3411_12_256.py
- ckm_gostr3410_with_gostr3411_12_256.py
- ckm_gostr3410_512.py
Для тестирования исходные данные брались как из соответствующих ГОСТ-ов, так и из рекомендаций ТК-26.
В данных скриптах тестируются следующие механизмы:
1. Генерация ключевых пар:
- CKM_GOSTR3410_512_KEY_PAIR_GEN (ГОСТ Р 34.10-2012 с длиной ключа 1024 бита)
- CKM_GOSTR3410_KEY_PAIR_GEN (ГОСТ Р 34.10-2012 с длиной ключа 512 бит)
2. Формирование и проверка электронной подписи:
- CKM_GOSTR3410
- CKM_GOSTR3410_512
- CKM_GOSTR3410_WITH_GOSTR3411_12_256
3. Хэширования:
- CKM_GOSTR3411_12_256
4. Шифрование/расшифрование
- CKM_KUZNYECHIK_CBC
Генерация ключевых пар позволяет владельцу токена получить закрытый ключ, которым он может подписать, например, запрос на сертификат. Запрос на сертификат может быть отправлен в удостоверяющий центр и там по нему могут выдать сертификат. Владелец сертификата может импортировать его на токен, где хранится закрытый ключ. Теперь у владельца токена есть личный сертификат с закрытым ключом, который он может использовать для подписи документов.
Ну а если ему требуется особый режим секретности, то он может зашифровать документ по одному из алгоритмов, а именно по Магме или Кузнечику. Всё это конечно в том случае, если сам токен поддерживает эти механизмы, пакет PyKCS11 является всего лишь посредником.
На этом наше повествование, связанное с поддержкой в Python токенов с российской криптографией, заканчивается.