Выработка двойственного ключа по алгоритму KEG

Добрый день.

Прошу помочь со следующим вопросом.
В документации к стандарту PKCS11 на сайте приведен "Пример выработки двойственного ключа по алгоритму KEG" (https://dev.rutoken.ru/pages/viewpage.a … d=13795364). В качестве используемого механизма выработки предлагается использовать механизм CKM_VENDOR_GOST_KEG. Если я правильно понял приведенный на сайте пример, то далее по исходного коду буфер gostKegDerifivationMech, для которого определяется данный механизм, не используется. В функцию C_DeriveKey передается буфер gostR3410_12DerivationMech (который, судя по наименованию, предназначался для механизма CKM_GOSTR3410_12_DERIVE).
Поэтому было выдвинуто предположение, что имеется некая неопределенность в примере и было опробовано несколько разных вариантов кода для генерации ключа. Проблема заключается в том, что сгенерировать двойственный ключ типа CKK_KUZNECHIK_TWIN_KEY пока не удается ни с использованием механизма CKM_VENDOR_GOST_KEG (возвращается CKR_MECHANISM_INVALID), ни с использованием механизма CKM_GOSTR3410_12_DERIVE (возвращается CKR_MECHANISM_PARAM_INVALID).
Прошу подсказать в чем может быть проблема.

Спасибо.

Re: Выработка двойственного ключа по алгоритму KEG

Добрый день!

Уточните пожалуйста модель токена, которую Вы используете, версию SDK и драйверов

(2021-10-05 10:19:26 отредактировано BeanSoup)

Re: Выработка двойственного ключа по алгоритму KEG

Спасибо за быстрый ответ.
Версия драйверов Рутокен: 4.8.8.0, токен: "Рутокен ЭЦП 2.0", SDK (сведения из README.txt): "Комплект разработчика Рутокен SDK (с) Rutoken, 2021".
Если я правильно помню, то драйвера и SDK скачивал отсюда: https://www.rutoken.ru/support/download/windows/, https://www.rutoken.ru/developers/sdk/.

Re: Выработка двойственного ключа по алгоритму KEG

BeanSoup, добрый день!

Механизмы Кузнечик и Магма доступны только в Рутокен ЭЦП 3.0 NFC.

В следующей версии библиотеки PKCS#11 механизм CKM_VENDOR_GOST_KEG будет заменен на реализацию ТК26 (практически идентичную) - CKM_GOST_KEG.

(2021-10-05 12:44:46 отредактировано BeanSoup)

Re: Выработка двойственного ключа по алгоритму KEG

Спасибо за ответ.
Т.е. правильно ли я понял, что пример выработки двойственного ключа по алгоритму KEG (https://dev.rutoken.ru/pages/viewpage.action?pageId=13795364, раздел 6.6) для текущей версии библиотеки PKCS11 не применим/актуален для токенов "Рутокен ЭЦП 2.0"?

Re: Выработка двойственного ключа по алгоритму KEG

BeanSoup, верно, для устройств ЭЦП 2.0 доступны механизмы VKO GOST R  34.10-2012 и KDF_TREE_GOSTR3411_2012_256 (с ключами ГОСТ-89).

(2021-10-05 13:08:39 отредактировано BeanSoup)

Re: Выработка двойственного ключа по алгоритму KEG

Благодарю всех за развернутые ответы!

(2021-10-13 16:01:35 отредактировано BeanSoup)

Re: Выработка двойственного ключа по алгоритму KEG

Добрый день.

Прошу помочь разобраться в следующей ситуации.
Я продолжаю попытки реализовать алгоритм KEG с использованием устройств рутокен. При реализации стремлюсь опираться на документ ТК26 "Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)".  Если я правильно понял представленное в нем описание, то:
- в качестве KEG для 512 бит можно использовать алгоритм VKO512;
- в качестве KEG для 256 бит можно использовать связку алгоритмов VKO256 + KDF_TREE;
- результатом работы KEG является последовательность длиной 64 байта.
Полноценного примера для использования механизма KDF_TREE_GOSTR3411_2012_256 на сайте или в SDK я не смог найти, однако заполнить структуру CK_KDF_TREE_GOST_PARAMS в соответствии с требованиями документа ТК26 и довести до рабочего состояния функцию C_DeriveKey (возвращает значение CKR_OK) удалось.
В итоге с вариантом KEG для 256 бит возникли следующие вопросы:
- при использовании механизма VKO_GOSTR3410_2012 в качестве параметра kdf следует передавать значение "CKM_KDF_GOSTR3411_2012_256" или значение "CKD_NULL"?
- почему при использовании механизма KDF_TREE_GOSTR3411_2012_256 при передаче параметру ulL (в качестве байтовой длины вырабатываемого ключевого материала) значения 64 байта функция C_DeriveKey вырабатывает последовательность длиной 32 байта?

Спасибо.

Re: Выработка двойственного ключа по алгоритму KEG

Добрый день.
Можете показать значения параметров, которые вы передаете в структуру CK_KDF_TREE_GOST_PARAMS

(2021-10-13 16:58:52 отредактировано BeanSoup)

Re: Выработка двойственного ключа по алгоритму KEG

Благодарю за быстрый ответ.
В настоящий момент используются следующие параметры

CK_KDF_TREE_GOST_PARAMS x;
CK_MECHANISM y = { (CK_MECHANISM_TYPE)KDF_TREE_GOSTR3411_2012_256, NULL_PTR, 0 };
CK_UTF8CHAR z[] = { "kdf tree" };
BYTE k[8] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };

x.pLabel = (CK_BYTE_PTR)z;
x.ulLabelLength = 8;
x.pSeed = k;
x.ulSeedLength = 8;
x.ulR = 1;
x.ulL = 64;
x.ulOffset = 0;
x.pParameter = &y;
x.ulParameterLen = sizeof(y);


В качестве типа вырабатываемого ключа используется значение CKK_GOST28147.

Re: Выработка двойственного ключа по алгоритму KEG

Результатом работы функции C_DeriveKey является ключ стандарта ГОСТ 28147-89 размером 32 байта.
ulL - размер вырабатываемого ключевого материала, из которого по смещению ulOffset берется 32 байта для выходного результата.

BeanSoup пишет:

- при использовании механизма VKO_GOSTR3410_2012 в качестве параметра kdf следует передавать значение "CKM_KDF_GOSTR3411_2012_256" или значение "CKD_NULL"?

В наших примерах передается CKM_KDF_GOSTR3411_2012_256

(2021-10-14 14:07:33 отредактировано BeanSoup)

Re: Выработка двойственного ключа по алгоритму KEG

Я попробую переформулировать вопрос.
В разделе 6.4.5.1 документа ТК26 "Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)" регламентируется порядок получения ключа по алгоритму KEG. Результатом работы данного алгоритма является последовательность длиной 64 байта (этот результат затем предполагается передавать на вход алгоритма Kexp15). Итоговым выходом алгоритма KEG (256 бит) является результат работы механизма KDF_TREE_GOSTR3411_2012_256. Для определения длины вырабатываемой последовательности механизма KDF_TREE_GOSTR3411_2012_256 в соответствии с документацией рутокен используется переменная ulL, но при этом можно считать только 32 байта.
Пожалуйста поясните, можно ли каким-либо образом считать 64 байта выхода работы механизма KDF_TREE_GOSTR3411_2012_256?

Re: Выработка двойственного ключа по алгоритму KEG

Данный документ описывает использование ключей стандарта Магма или Кузнечик в TLS 1.2.
Для использования этих ключей необходим Рутокен ЭЦП 3.0.

Возвращаясь к этим вопросам, наши разработчики ответили следующее:

BeanSoup пишет:

- при использовании механизма VKO_GOSTR3410_2012 в качестве параметра kdf следует передавать значение "CKM_KDF_GOSTR3411_2012_256" или значение "CKD_NULL"?

CKD_NULL, так как требуется в результате получить результат выполнения VKO-256 для последующего применения функции диверсификации. Интерфейс механизма VKO_GOSTR3410_2012 не подразумевает комбинированное использование с диверсификацией по kdf_tree в общем случае. для комбинированного использования был введен механизм KEG.

BeanSoup пишет:

- почему при использовании механизма KDF_TREE_GOSTR3411_2012_256 при передаче параметру ulL (в качестве байтовой длины вырабатываемого ключевого материала) значения 64 байта функция C_DeriveKey вырабатывает последовательность длиной 32 байта?

ulL задает параметр согласно рекомендациям по стандартизации, то есть, общий размер вырабатываемого ключевого материала. Он может быть использован не полностью, за используемый "фрагмент" ключевого материала отвечает параметр ulOffset диверсификации, а также тип результирующего ключа. Таким образом, для получение 64 байтов ключевого материала требуется выставить в качестве CKA_KEY_TYPE результирующего ключа двойной ключ Магма (CKK_MAGMA_TWIN_KEY) или двойной ключ Кузнечик (CKK_KUZNECHIK_TWIN_KEY).

Но это все справедливо для токенов и смарт-карт с поддержкой Магмы и Кузнечика.

Re: Выработка двойственного ключа по алгоритму KEG

Аверченко Кирилл пишет:

Данный документ описывает использование ключей стандарта Магма или Кузнечик в TLS 1.2.
CKD_NULL, так как требуется в результате получить результат выполнения VKO-256 для последующего применения функции диверсификации. Интерфейс механизма VKO_GOSTR3410_2012 не подразумевает комбинированное использование с диверсификацией по kdf_tree в общем случае. для комбинированного использования был введен механизм KEG.

Спасибо за подтверждение, именно так я и предполагал.

Аверченко Кирилл пишет:

Данный документ описывает использование ключей стандарта Магма или Кузнечик в TLS 1.2.
ulL задает параметр согласно рекомендациям по стандартизации, то есть, общий размер вырабатываемого ключевого материала. Он может быть использован не полностью, за используемый "фрагмент" ключевого материала отвечает параметр ulOffset диверсификации, а также тип результирующего ключа. Таким образом, для получение 64 байтов ключевого материала требуется выставить в качестве CKA_KEY_TYPE результирующего ключа двойной ключ Магма (CKK_MAGMA_TWIN_KEY) или двойной ключ Кузнечик (CKK_KUZNECHIK_TWIN_KEY).
Но это все справедливо для токенов и смарт-карт с поддержкой Магмы и Кузнечика.

Понятно. Да, я пытался передавать ключи CKK_MAGMA_TWIN_KEY и CKK_KUZNECHIK_TWIN_KEY в шаблон и получал соответствующую ошибку от C_Derivekey. Без ошибки отрабатывало только для CKK_GOST28147.

Теперь в целом все понятно, спасибо. Хотелось бы только уточнить есть ли какие-либо токены/смарткарты ЭЦП 3.0, поддерживающие описанный функционал, кроме этих https://www.rutoken.ru/products/catalogue/id_114.html?

Re: Выработка двойственного ключа по алгоритму KEG

BeanSoup, приветствую. Сейчас только смарт-карта. В ноябре ожидается устройство Рутокен ЭЦП 3.0 NFC в форм-факторе USB-токена.