Подошло время рассказать как была добавлена поддержка поддержка российской криптографии в проект PyKCS11. Всё началось с того, что мне на глаза попалась переписка разработчика проекта PyKCS11 с потенциальными потребителями по поводу возможной поддержки алгоритмов ГОСТ Р 34.10-2012 в нём. В этой переписке автор PkCS11 сказал, что не собирается включать поддержку российских криптоалгоритмов до тех пор, пока они не будут стандартизованы.
Ту же самую мысль он выразил и мне, когда я предложил ему это сделать. И не просто сделать, а выслал соответствующий программный код:
После этого я посчитал возможным форкнуть код в свой репозиторий и внести в него соответствующие правки. Проект PyKCS11 с поддержкой российской криптографии находится здесь.
Итак, что же было сделано. Я фактически последовал одному из советов автора проекта PyKCS11:
Все константы, утвержденные ТК-26 для PKCS#11, были сведены в один файл pkcs11t_gost.h, помещенный в папку src:
В этот перечень вошли механизмы как необходимые для формирования и проверки подписи по (ГОСТ Р 34.10-2012) ГОСТ Р 34.10-2012, так и шифрования (ГОСТ Р 34.12-2015 и ГОСТ Р 34.13-2015 — алгоритмы шифрования Кузнечик и Магма). Естественно, здесь же присутствуют и алгоритмы хэширования ГОСТ Р 34.11-2012.
Для того, чтобы ГОСТ-овые константы попали в процесс сборки модуля, необходимо добавить в файл pkcs11.i (файл для SWIG) оператор включения файла pkcs11t_gost.h
перед оператором
Но это еще не всё. В методе getMechanismList (script PKCS11/__init__.py) заблокирован вывод механизмов чей код больше CKM_VENDOR_DEFINED (именно об этом и пишет автор проекта PyKCS11) (0x80000000L). Заметим, что ГОСТ-овые константы для новых алгоритмов попадают под это ограничение. Необходимо его снять хотя бы для ГОСТ-ов, заменим код метода getMechanismList на новый:
Отметим также, что несмотря на то, что в модуль включены все механизмы, которые определены во включаемых файлах 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.
Всё это относится к довольно сложным криптографическим механизмам.
А вот всё то, что касается хэширования, формирования проверки электронной подписи, наконец, шифрования, то всё работает замечательно. Но для начала надо собрать проект
Она ничем не отличается от сборки родной обёртки PkCS11 за исключением того, что исходный код необходимо получить здесь.
Далее следуем инструкции по сборке и установке пакета PyKCS11.
Для тестирования потребуется токен с поддержкой российской криптографии. Здесь мы имеем в виду ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. Это может быть как аппаратный токен, например RuTokenECP-2.0, так и программные или облачные токены.
Установить программный токен или получить доступ к облачному токену можно, воспользовавшись утилитой cryptoarmpkcs.
Скачать утилиту cryptoarmpkcs можно здесь.
После запуска утилиты необходимо зайти на вкладку «Создать токены»:
На вкладке можно найти инструкции для получения и установки токенов.
II. Тестирование российских алгоритмов
Для тестирования можно использовать скрипты, которые лежат в папке testGost:
Для тестирования исходные данные брались как из соответствующих ГОСТ-ов, так и из рекомендаций ТК-26.
В данных скриптах тестируются следующие механизмы:
1. Генерация ключевых пар:
2. Формирование и проверка электронной подписи:
3. Хэширования:
4. Шифрование/расшифровка
Генерация ключевых пар позволяет владельцу токена получить закрытый ключ, которым он может подписать, например, запрос на сертификат. Запрос на сертификат может быть отправлен в удостоверяющий центр и там по нему могут выдать сертификат. Владелец сертификата может импортировать его на токен, где хранится закрытый ключ. Теперь у владельца токена есть личный сертификат с закрытым ключом, который он может использовать для подписи документы.
Ну а если ему требуется особый режим секретности, то он может зашифровать документ по одному из алгоритмов, а именно Магме или Кузнечику. Всё это конечно в том случае, если сам токен поддерживает эти механизмы, пакет PyKCS11 является всего лишь посредником.
На этом наше повествование, связанное с поддержкой в Python токенов с российской криптографией заканчивается.
Ту же самую мысль он выразил и мне, когда я предложил ему это сделать. И не просто сделать, а выслал соответствующий программный код:
После этого я посчитал возможным форкнуть код в свой репозиторий и внести в него соответствующие правки. Проект 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.
Скачать утилиту cryptoarmpkcs можно здесь.
Скачать утилиту cryptoarmpkcs можно здесь.
- Linux32
- Linux64
- OS X
- WIN32
- WIN64
После запуска утилиты необходимо зайти на вкладку «Создать токены»:
На вкладке можно найти инструкции для получения и установки токенов.
II. Тестирование российских алгоритмов
Для тестирования можно использовать скрипты, которые лежат в папке 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 токенов с российской криптографией заканчивается.