Регистрация

[Информационная безопасность, Криптография, Python, C++, ООП] Поддержка токенов PKCS#11 с ГОСТ-криптографией в Python. Часть II — Обёртка PyKCS11

Ответить на тему
Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
26-Мар-2021 22:30
Цитировать


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

Скачать утилиту cryptoarmpkcs можно здесь.

SPL


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

На вкладке можно найти инструкции для получения и установки токенов.
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 токенов с российской криптографией заканчивается.
 ===========
 Источник:
habr.com
===========
Похожие новости: Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_kriptografija (Криптография), #_python, #_c++, #_oop (ООП), #_python3, #_pkcs#11, #_python_class, #_c++, #_certificate, #_elektronnaja_podpis (электронная подпись), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_kriptografija (
Криптография
), #_python, #_c++, #_oop (
ООП
)
Профиль  ЛС 
Показать сообщения:     
Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 13:23
Часовой пояс: UTC + 5