Написал на hotline@rutoken.ru

Уже разбираемся.
Возможно ли предоставить минимальный пример, где вы наблюдаете ошибку?

Спасибо, что указали нам на ошибку с public полями. В ближайшей версии библиотеки исправим эту проблему.

Подскажите, пожалуйста, как выработать двойственный ключ по алгоритму KEG на java под android?
При выполнении функции C_DeriveKey получаю ошибку 0x00000071(недопустимый параметр механизма).

Все шаги повторяю из примера https://dev.rutoken.ru/pages/viewpage.a … M_GOST_KEG с адаптиацией под android.

Шаги:
1. Сгенерировал ключевую пару по алгоритму ГОСТ Р34.10 2012-256
2. Сгенерировал UKM(синхропосылку) длиной 24 байта для данной ключа
3. Создал шаблон идентичный примеру (из сайта)
4. Создал класс CK_ECDH1_DERIVE_PARAMS с параметрами ukm и publicKey, kdf = 1.
   - CK_ECDH1_DERIVE_PARAMS не удалось использовать из пакета ru.rutoken.pkcs11jna, так как свойства класса не указаны как public, из-за чего получал ошибки. Пришлось продублировать этот класс в проекте.
5. Генерирую CK_MECHANISM с типом CKM_GOST_KEG и параметром CK_ECDH1_DERIVE_PARAMS.

Использую SDK от 2022 04 21. (106f9f507f7ece07c7e3a5bbd0c8f721594b9b1c). Тесты провожу на Рутокен ЭЦП 3.0 NFC.

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

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

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

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

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

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

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

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

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

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.

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

Спасибо.