Поддержка токенов PKCS#11 с ГОСТ-криптографией в Python. Часть III — Обёртка PyKCS11

от автора

image Подошло время рассказать как была добавлена поддержка поддержка российской криптографии в проект PyKCS11. Всё началось с того, что мне на глаза попалась переписка разработчика проекта PyKCS11 с потенциальными потребителями по поводу возможной поддержки алгоритмов ГОСТ Р 34.10-2012 в нём. В этой переписке автор PkCS11 сказал, что не собирается включать поддержку российских криптоалгоритмов до тех пор, пока они не будут стандартизованы.
Ту же самую мысль он выразил и мне, когда я предложил ему это сделать. И не просто сделать, а выслал соответствующий программный код:

image

После этого я посчитал возможным форкнуть код в свой репозиторий и внести в него соответствующие правки. Проект 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 можно здесь.

После запуска утилиты необходимо зайти на вкладку «Создать токены»:

image

На вкладке можно найти инструкции для получения и установки токенов.

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 токенов с российской криптографией заканчивается.

ссылка на оригинал статьи https://habr.com/ru/post/549198/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *