Форум Рутокен — Работа с функциями библиотеки rtPKCS11ECP

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (enzain) — Thu, 09 Aug 2018 13:03:48 +0000

Владимир Салыкин пишет:

Добрый день, enzain.
Враппер для PKCS11 библиотеки на языке C# вы можете скачать через NuGet (ищите RutokenPkcs11Interop). Или можете собрать его самостоятельно.
Ссылка на репозиторий с примерами: https://github.com/AktivCo/RutokenPkcs11Interop.Samples
Ссылка на репозиторий с исходным кодом обертки pkcs: https://github.com/AktivCo/RutokenPkcs11Interop
Единственное ограничение, которое пока существует - поддержка только коротких ключей для ГОСТ-2012.

Ну так как мне он не для гостовых, а для РСА в основном, думаю не критично ...
Спасибо!

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Владимир Салыкин) — Thu, 09 Aug 2018 11:57:37 +0000

Добрый день, enzain.

Враппер для PKCS11 библиотеки на языке C# вы можете скачать через NuGet (ищите RutokenPkcs11Interop). Или можете собрать его самостоятельно.

Ссылка на репозиторий с примерами: https://github.com/AktivCo/RutokenPkcs11Interop.Samples
Ссылка на репозиторий с исходным кодом обертки pkcs: https://github.com/AktivCo/RutokenPkcs11Interop

Единственное ограничение, которое пока существует - поддержка только коротких ключей для ГОСТ-2012.

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (enzain) — Thu, 09 Aug 2018 07:45:48 +0000

Здравствуйте, для c# библиотеки не сделали еще? Где нибудь выложенной

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Кирилл Мещеряков) — Thu, 24 May 2018 10:00:17 +0000

Добрый день, wwago.

Да, обновление запланировано и выйдет ориентировочно к середине года.
Однако, мы не рекомендуем пользоваться PKCS#11 интерфейсом для создания запросов, гораздо лучше для этого подходит более высокоуровневый интерфейс PKI-Core. В нем кстати поддержка длинных ключей реализована уже давно.

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (wwago) — Thu, 24 May 2018 03:28:38 +0000

Добрый день!
У вас на тестовом центре регистрации http://ra.rutoken.ru/#/ реализована возможность формирования запроса на сертификат для ГОСТ 34.10-2012 с длиной закрытого ключа 512 бит.
Но в существующем релизе SDK функция C_EX_CreateCSR поддерживает только алгоритмы ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 (256 бит) (см. CreateCSR-PKCS10-2012.c).

Подскажите, пожалуйста, когда ждать обновление SDK в этом вопросе?

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Michael Falcone) — Fri, 06 Apr 2018 08:48:21 +0000

Да, теперь все заработало правильно, спасибо!

Аникушин Евгений пишет:

на сервер нужно отправлять

E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083
236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Аникушин Евгений) — Thu, 05 Apr 2018 07:43:43 +0000

Аникушин Евгений пишет:

Здесь не до конца был прав, данные с токена возвращаются в таком виде, но в PKCS дополнительно разворачиваются, чтобы соответстовать стандарту:
pkcs-11v2-30m1-d7 пишет:
The signature octets correspond to the concatenation of the
GOST R 34.10-2001 values s and r’, both represented as a 32 bytes octet string in big
endian order with the most significant byte first [RFC 4490] section 3.2, and [RFC 4491]
section 2.2.2.

Значит для при таком значении подписи с токена

Michael Falcone пишет:

Подпись на выходе C_Sign:
236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E
E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083

на сервер нужно отправлять

E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083
236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Michael Falcone) — Wed, 04 Apr 2018 18:48:49 +0000

При развороте строки "Hello" получается последовательность без нуля в начале:

0x6f, 0x6c, 0x6c, 0x65, 0x48

Вообще функция подписи выглядит так:

{

    returnValue = pFunctionList->C_SignInit(hSession,         
                                            &ckmGOST_34_10_2012_512_with_34_11_2012_512 ,   
                                            *hPrivateKey);      

    char* str = QStringToCharArray(data);

    std::reverse(str, str + strlen(str));

    CK_BYTE_PTR pbtSignature = NULL_PTR;               
    CK_ULONG ulSignatureSize = 0;

    returnValue = pFunctionList->C_Sign(hSession,           
                                        (CK_BYTE_PTR)str,           
                                        strlen(str),      
                                        pbtSignature,      
                                        &ulSignatureSize);  

    pbtSignature = (CK_BYTE*)malloc(ulSignatureSize);
    memset( pbtSignature, 0, ulSignatureSize * sizeof(CK_BYTE));
    returnValue = pFunctionList->C_Sign(hSession,
                                        (CK_BYTE_PTR)str,
                                        strlen(str),
                                        pbtSignature,
                                        &ulSignatureSize);

    QByteArray result = QByteArray::fromRawData((const char*)pbtSignature, ulSignatureSize);

    std::reverse(result.begin(), result.begin() + result.length() / 2);
    std::reverse(result.begin() + result.length() / 2, result.end());
}

Данные подписаны тем же ключом. Результат хеширования неразвернутый (совпадает с развернутым хэшом сервера):

E08F335F5D02A6F1E70ABDDAD6EEE020C9E9DBD6307E28EEA9A126A3BC246612CEFBC6FC9E7A242FD7AE90D19AC8E5A2F63E12723E53A0AC2F17A24616995827

Подпись на выходе C_Sign:

236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E
E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083

Аникушин Евгений пишет:

3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40
CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,
0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};
Здесь не до конца был прав, данные с токена возвращаются в таком виде, но в PKCS дополнительно разворачиваются, чтобы соответстовать стандарту:
pkcs-11v2-30m1-d7 пишет:
The signature octets correspond to the concatenation of the
GOST R 34.10-2001 values s and r’, both represented as a 32 bytes octet string in big
endian order with the most significant byte first [RFC 4490] section 3.2, and [RFC 4491]
section 2.2.2.
Аналогично реализован и ГОСТ34.10-2012. То есть C_Sign вернёт
CK_BYTE sign[] = {
  0x01, 0x45, 0x6c, 0x64, 0xba, 0x46, 0x42, 0xa1, 0x65, 0x3c, 0x23, 0x5a, 0x98, 0xa6, 0x02, 0x49,
  0xbc, 0xd6, 0xd3, 0xf7, 0x46, 0xb6, 0x31, 0xdf, 0x92, 0x80, 0x14, 0xf6, 0xc5, 0xbf, 0x9c, 0x40,
  
  0x41, 0xaa, 0x28, 0xd2, 0xf1, 0xab, 0x14, 0x82, 0x80, 0xcd, 0x9e, 0xd5, 0x6f, 0xed, 0xa4, 0x19,
  0x74, 0x05, 0x35, 0x54, 0xa4, 0x27, 0x67, 0xb8, 0x3a, 0xd0, 0x43, 0xfd, 0x39, 0xdc, 0x04, 0x93,
}
По вашему примеру с "КриптоПро А". К сожалению пока проверка не сходится и на самом токене. Возможно в предоставленные данные закралась ошибка ? или при подписи использовалась другая ключевая пара ?
CK_BYTE message[] = {
 0x00, 0x6f, 0x6c, 0x6c, 0x65, 0x48
}

C_Digest(...)

hash[] = {
 0xB3, 0x9D, 0xDB, 0x1C, 0x9E, 0x03, 0x27, 0xDD, 0x20, 0x8D, 0x51, 0xFD, 0xD8, 0x5D, 0xD9, 0x53,
 0x3B, 0x4E, 0xBD, 0x5D, 0x37, 0xA6, 0xCA, 0xD9, 0xCF, 0xBC, 0x01, 0xA5, 0x90, 0xEE, 0xFC, 0xB5,
 0xF5, 0xD6, 0xE7, 0x78, 0xB7, 0xFE, 0xA9, 0x2A, 0x8D, 0x5B, 0x9F, 0xA4, 0x30, 0xD0, 0x4D, 0x1D,
 0x98, 0xA7, 0xAF, 0x85, 0x00, 0xF3, 0x91, 0x41, 0x91, 0x32, 0x22, 0x30, 0x04, 0xB7, 0xB2, 0x2E 
};

signature[] = {
 0xCC, 0xC4, 0xA8, 0x43, 0x7E, 0xA3, 0x9B, 0xD0, 0xAC, 0x5D, 0x53, 0xCE, 0x8E, 0xEE, 0x8F, 0x01,
 0xDD, 0x24, 0x01, 0xA1, 0x0A, 0xEC, 0x46, 0xF3, 0xDE, 0xF4, 0x14, 0xBF, 0xCD, 0x51, 0xA7, 0x2A, 
 0xBF, 0x00, 0x1C, 0xB6, 0xA4, 0x9C, 0xB1, 0xB3, 0xD6, 0x35, 0xAA, 0xB8, 0xA6, 0x66, 0x43, 0xD7,
 0xB7, 0xDB, 0xAC, 0x7B, 0xC5, 0x40, 0x09, 0x10, 0x34, 0x38, 0xEF, 0x9C, 0x3F, 0x21, 0x8D, 0xC7,
 
 0xBE, 0xF4, 0x98, 0xA1, 0x0D, 0x0A, 0x39, 0x71, 0x56, 0x7A, 0x16, 0x50, 0x85, 0x35, 0x6F, 0x88,
 0x82, 0x73, 0x50, 0x54, 0x68, 0x68, 0x36, 0xC8, 0x3F, 0xBC, 0x55, 0x18, 0xAD, 0xD9, 0x08, 0x33,
 0x38, 0x76, 0x38, 0x81, 0xBC, 0x0B, 0x10, 0x48, 0x6E, 0x20, 0x07, 0x93, 0x88, 0xDD, 0x4E, 0x89,
 0xF1, 0x88, 0x22, 0xED, 0x52, 0x63, 0x9E, 0x6E, 0x09, 0x24, 0x63, 0xE7, 0xDD, 0x80, 0x7D, 0x34 };

C_Verify(...) = 0xC0 (CKR_SIGNATURE_INVALID)

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Аникушин Евгений) — Wed, 04 Apr 2018 11:54:02 +0000

3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40
CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,
0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};

Здесь не до конца был прав, данные с токена возвращаются в таком виде, но в PKCS дополнительно разворачиваются, чтобы соответстовать стандарту:

pkcs-11v2-30m1-d7 пишет:

The signature octets correspond to the concatenation of the
GOST R 34.10-2001 values s and r’, both represented as a 32 bytes octet string in big
endian order with the most significant byte first [RFC 4490] section 3.2, and [RFC 4491]
section 2.2.2.

Аналогично реализован и ГОСТ34.10-2012. То есть C_Sign вернёт

CK_BYTE sign[] = {
  0x01, 0x45, 0x6c, 0x64, 0xba, 0x46, 0x42, 0xa1, 0x65, 0x3c, 0x23, 0x5a, 0x98, 0xa6, 0x02, 0x49,
  0xbc, 0xd6, 0xd3, 0xf7, 0x46, 0xb6, 0x31, 0xdf, 0x92, 0x80, 0x14, 0xf6, 0xc5, 0xbf, 0x9c, 0x40,
  
  0x41, 0xaa, 0x28, 0xd2, 0xf1, 0xab, 0x14, 0x82, 0x80, 0xcd, 0x9e, 0xd5, 0x6f, 0xed, 0xa4, 0x19,
  0x74, 0x05, 0x35, 0x54, 0xa4, 0x27, 0x67, 0xb8, 0x3a, 0xd0, 0x43, 0xfd, 0x39, 0xdc, 0x04, 0x93,
}

По вашему примеру с "КриптоПро А". К сожалению пока проверка не сходится и на самом токене. Возможно в предоставленные данные закралась ошибка ? или при подписи использовалась другая ключевая пара ?

CK_BYTE message[] = {
 0x00, 0x6f, 0x6c, 0x6c, 0x65, 0x48
}

C_Digest(...)

hash[] = {
 0xB3, 0x9D, 0xDB, 0x1C, 0x9E, 0x03, 0x27, 0xDD, 0x20, 0x8D, 0x51, 0xFD, 0xD8, 0x5D, 0xD9, 0x53,
 0x3B, 0x4E, 0xBD, 0x5D, 0x37, 0xA6, 0xCA, 0xD9, 0xCF, 0xBC, 0x01, 0xA5, 0x90, 0xEE, 0xFC, 0xB5,
 0xF5, 0xD6, 0xE7, 0x78, 0xB7, 0xFE, 0xA9, 0x2A, 0x8D, 0x5B, 0x9F, 0xA4, 0x30, 0xD0, 0x4D, 0x1D,
 0x98, 0xA7, 0xAF, 0x85, 0x00, 0xF3, 0x91, 0x41, 0x91, 0x32, 0x22, 0x30, 0x04, 0xB7, 0xB2, 0x2E 
};

signature[] = {
 0xCC, 0xC4, 0xA8, 0x43, 0x7E, 0xA3, 0x9B, 0xD0, 0xAC, 0x5D, 0x53, 0xCE, 0x8E, 0xEE, 0x8F, 0x01,
 0xDD, 0x24, 0x01, 0xA1, 0x0A, 0xEC, 0x46, 0xF3, 0xDE, 0xF4, 0x14, 0xBF, 0xCD, 0x51, 0xA7, 0x2A, 
 0xBF, 0x00, 0x1C, 0xB6, 0xA4, 0x9C, 0xB1, 0xB3, 0xD6, 0x35, 0xAA, 0xB8, 0xA6, 0x66, 0x43, 0xD7,
 0xB7, 0xDB, 0xAC, 0x7B, 0xC5, 0x40, 0x09, 0x10, 0x34, 0x38, 0xEF, 0x9C, 0x3F, 0x21, 0x8D, 0xC7,
 
 0xBE, 0xF4, 0x98, 0xA1, 0x0D, 0x0A, 0x39, 0x71, 0x56, 0x7A, 0x16, 0x50, 0x85, 0x35, 0x6F, 0x88,
 0x82, 0x73, 0x50, 0x54, 0x68, 0x68, 0x36, 0xC8, 0x3F, 0xBC, 0x55, 0x18, 0xAD, 0xD9, 0x08, 0x33,
 0x38, 0x76, 0x38, 0x81, 0xBC, 0x0B, 0x10, 0x48, 0x6E, 0x20, 0x07, 0x93, 0x88, 0xDD, 0x4E, 0x89,
 0xF1, 0x88, 0x22, 0xED, 0x52, 0x63, 0x9E, 0x6E, 0x09, 0x24, 0x63, 0xE7, 0xDD, 0x80, 0x7D, 0x34 };

C_Verify(...) = 0xC0 (CKR_SIGNATURE_INVALID)

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Michael Falcone) — Tue, 03 Apr 2018 20:11:35 +0000

В панели управления записан открытый ключ в виде:

3134BE49E99351EBD0F249D488DBDA754E42AB20D5B34B495B3AA16F2417DB28D4963852C569440EFE05C5F4A5028C4C47E8CA366C0ED17F55EED778F83ED65E
D926D5E1BAEC93196C07ADFD412C64B064446B57333132935C32F63EB736789F30E9F8B193AC3EFF20F7E9F76F5E0E796B17F16E74753D7695FF7BE291D3248B

Ключ на сервере хранится перевернутыми половинами:

5ED63EF878D7EE557FD10E6C36CAE8474C8C02A5F4C505FE0E4469C5523896D428DB17246FA13A5B494BB3D520AB424E75DADB88D449F2D0EB5193E949BE3431
8B24D391E27BFF95763D75746EF1176B790E5E6FF7E9F720FF3EAC93B1F8E9309F7836B73EF6325C93323133576B4464B0642C41FDAD076C1993ECBAE1D526D9

На сервере реализована схема в точности соответствующая стандарту (big endian). Параметры схемы:

p:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFDC7

a:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFDC4

b:
E8C2505DEDFC86DDC1BD0B2B6667F1DA
34B82574761CB0E879BD081CFD0B6265
EE3CB090F30D27614CB4574010DA90DD
862EF9D4EBEE4761503190785A71C760

q 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
27E69532F48D89116FF22B8D4E056060
9B4B38ABFAD2B85DCACDB1411F10B275

x = 3

y:
7503CFE87A836AE3A61B8816E25450E6
CE5E1C93ACF1ABC1778064FDCBEFA921
DF1626BE4FD036E93D75E6A50E3A41E9
8028FE5FC235F5B889A589CB5215F2A4

Для подписи используется механизм

ckmGOST_34_10_2012_512_with_34_11_2012_512  = { CKM_GOSTR3410_WITH_GOSTR3411_12_512, NULL_PTR, 0 };

При подписи строки "Hello" она разворачивается и передается в функцию C_Sign, после чего на выходе получается подпись:

CCC4A8437EA39BD0AC5D53CE8EEE8F01DD2401A10AEC46F3DEF414BFCD51A72ABF001CB6A49CB1B3D635AAB8A66643D7B7DBAC7BC54009103438EF9C3F218DC7
BEF498A10D0A3971567A165085356F8882735054686836C83FBC5518ADD9083338763881BC0B10486E20079388DD4E89F18822ED52639E6E092463E7DD807D34

Разворачиваются половины подписи:

C78D213F9CEF3834100940C57BACDBB7D74366A6B8AA35D6B3B19CA4B61C00BF2AA751CDBF14F4DEF346EC0AA10124DD018FEE8ECE535DACD09BA37E43A8C4CC
347D80DDE76324096E9E6352ED2288F1894EDD889307206E48100BBC813876383308D9AD1855BC3FC836686854507382886F358550167A5671390A0DA198F4BE

Затем происходит отправка данной подписи на сервер для проверки. При этом результат проверки отрицательный и подпись не принимается.

Аникушин Евгений пишет:

Всё верно. Единственное что проверить это с нашей библиотекой у вас не получится, так как там нет поддержки тестовых параметров подписи (будет ошибка при создании ключа). Но для понимания того как работать с данными в формате big-endian всё же приведу пример:
А.1 Пример 1. для ГОСТ34.10-2012(256)
1. Для импорта открытого ключа, нужно разворачивать координаты, а не весь ключ полностью:
X:7F2B49E270DB6D90D8595BEC458B50C58585BA1D4E9B788F6689DBD8E56FD80B
Y:26F1B489D6701DD185C8413A977B3CBBAF64D1C593D26627DFFB101A87FF77DA
CK_BYTE public_key[] = {
0x0b, 0xd8, 0x6f, 0xe5, 0xd8, 0xdb, 0x89, 0x66, 0x8f, 0x78, 0x9b, 0x4e, 0x1d, 0xba, 0x85, 0x85,
0xc5, 0x50, 0x8b, 0x45, 0xec, 0x5b, 0x59, 0xd8, 0x90, 0x6d, 0xdb, 0x70, 0xe2, 0x49, 0x2b, 0x7f,

0xda, 0x77, 0xff, 0x87, 0x1a, 0x10, 0xfb, 0xdf, 0x27, 0x66, 0xd2, 0x93, 0xc5, 0xd1, 0x64, 0xaf, 
0xbb, 0x3c, 0x7b, 0x97, 0x3a, 0x41, 0xc8, 0x85, 0xd1, 0x1d, 0x70, 0xd6, 0x89, 0xb4, 0xf1, 0x26
};
Также значение параметров подписи в атрибутах ключа должно соответствовать тестовым "1.2.643.2.2.35.0"
CK_BYTE gost_3410_test_parameters[] = {
 0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x23, 0x00
 };

CK_ATTRIBUTE sign_oid_attribute = {
 CKA_GOSTR3410_PARAMS, gostR3410params_oid, sizeof(gostR3410params_oid)
 };
2. Хеш разворачивается без особенностей
H: 2DFBC1B372D89A1188C09C52E0EEC61FCE52032AB1022E8E67ECE6672B043EE5
CK_BYTE hash[] = {
0xe5, 0x3e, 0x04, 0x2b, 0x67, 0xe6, 0xec, 0x67, 0x8e, 0x2e, 0x02, 0xb1, 0x2a, 0x03, 0x52, 0xce, 
0x1f, 0xc6, 0xee, 0xe0, 0x52, 0x9c, 0xc0, 0x88, 0x11, 0x9a, 0xd8, 0x72, 0xb3, 0xc1, 0xfb, 0x2d
};
3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40
CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,

0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};
Замечу, что большинство софта использует при работе "little-endian" (в ГОСТ всё же big-endian), при работе с тем же CryptoPro данные видоизменять никак не нужно.

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Аникушин Евгений) — Mon, 02 Apr 2018 13:19:12 +0000

Всё верно. Единственное что проверить это с нашей библиотекой у вас не получится, так как там нет поддержки тестовых параметров подписи (будет ошибка при создании ключа). Но для понимания того как работать с данными в формате big-endian всё же приведу пример:

А.1 Пример 1. для ГОСТ34.10-2012(256)

1. Для импорта открытого ключа, нужно разворачивать координаты, а не весь ключ полностью:
X:7F2B49E270DB6D90D8595BEC458B50C58585BA1D4E9B788F6689DBD8E56FD80B
Y:26F1B489D6701DD185C8413A977B3CBBAF64D1C593D26627DFFB101A87FF77DA

CK_BYTE public_key[] = {
0x0b, 0xd8, 0x6f, 0xe5, 0xd8, 0xdb, 0x89, 0x66, 0x8f, 0x78, 0x9b, 0x4e, 0x1d, 0xba, 0x85, 0x85,
0xc5, 0x50, 0x8b, 0x45, 0xec, 0x5b, 0x59, 0xd8, 0x90, 0x6d, 0xdb, 0x70, 0xe2, 0x49, 0x2b, 0x7f,

0xda, 0x77, 0xff, 0x87, 0x1a, 0x10, 0xfb, 0xdf, 0x27, 0x66, 0xd2, 0x93, 0xc5, 0xd1, 0x64, 0xaf, 
0xbb, 0x3c, 0x7b, 0x97, 0x3a, 0x41, 0xc8, 0x85, 0xd1, 0x1d, 0x70, 0xd6, 0x89, 0xb4, 0xf1, 0x26
};

Также значение параметров подписи в атрибутах ключа должно соответствовать тестовым "1.2.643.2.2.35.0"

CK_BYTE gost_3410_test_parameters[] = {
 0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x23, 0x00
 };

CK_ATTRIBUTE sign_oid_attribute = {
 CKA_GOSTR3410_PARAMS, gostR3410params_oid, sizeof(gostR3410params_oid)
 };

2. Хеш разворачивается без особенностей
H: 2DFBC1B372D89A1188C09C52E0EEC61FCE52032AB1022E8E67ECE6672B043EE5

CK_BYTE hash[] = {
0xe5, 0x3e, 0x04, 0x2b, 0x67, 0xe6, 0xec, 0x67, 0x8e, 0x2e, 0x02, 0xb1, 0x2a, 0x03, 0x52, 0xce, 
0x1f, 0xc6, 0xee, 0xe0, 0x52, 0x9c, 0xc0, 0x88, 0x11, 0x9a, 0xd8, 0x72, 0xb3, 0xc1, 0xfb, 0x2d
};

3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40

CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,

0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};

Замечу, что большинство софта использует при работе "little-endian" (в ГОСТ всё же big-endian), при работе с тем же CryptoPro данные видоизменять никак не нужно.

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Michael Falcone) — Mon, 02 Apr 2018 11:24:22 +0000

Да, спасибо, все заработало верно. С подписью ГОСТ 34.10-2012 точно также поступать?

Аникушин Евгений пишет:

Данные в примерах ГОСТ34.11-2012 представлены в формате "little-endian". Для сверки с нашим PKCS#11 необходимо разворачивать входной и выходной буферы.

 CK_BYTE message[] = {
    0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
    0x38, 0x39, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35,
    0x36, 0x37, 0x38, 0x39, 0x30, 0x31, 0x32, 0x33,
    0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x30, 0x31,
    0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39,
    0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
    0x38, 0x39, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35,
    0x36, 0x37, 0x38, 0x39, 0x30, 0x31, 0x32,
}

CK_BYTE expected_hash[] = {
    0x1b, 0x54, 0xd0, 0x1a, 0x4a, 0xf5, 0xb9, 0xd5,
    0xcc, 0x3d, 0x86, 0xd6, 0x8d, 0x28, 0x54, 0x62,
    0xb1, 0x9a, 0xbc, 0x24, 0x75, 0x22, 0x2f, 0x35,
    0xc0, 0x85, 0x12, 0x2b, 0xe4, 0xba, 0x1f, 0xfa,
    0x00, 0xad, 0x30, 0xf8, 0x76, 0x7b, 0x3a, 0x82,
    0x38, 0x4c, 0x65, 0x74, 0xf0, 0x24, 0xc3, 0x11,
    0xe2, 0xa4, 0x81, 0x33, 0x2b, 0x08, 0xef, 0x7f,
    0x41, 0x79, 0x78, 0x91, 0xc1, 0x64, 0x6f, 0x48,
}

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Аникушин Евгений) — Mon, 02 Apr 2018 08:19:28 +0000

Данные в примерах ГОСТ34.11-2012 представлены в формате "big-endian". Для сверки с нашим PKCS#11 необходимо разворачивать входной и выходной буферы.

 CK_BYTE message[] = {
    0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
    0x38, 0x39, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35,
    0x36, 0x37, 0x38, 0x39, 0x30, 0x31, 0x32, 0x33,
    0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x30, 0x31,
    0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39,
    0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
    0x38, 0x39, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35,
    0x36, 0x37, 0x38, 0x39, 0x30, 0x31, 0x32,
}

CK_BYTE expected_hash[] = {
    0x1b, 0x54, 0xd0, 0x1a, 0x4a, 0xf5, 0xb9, 0xd5,
    0xcc, 0x3d, 0x86, 0xd6, 0x8d, 0x28, 0x54, 0x62,
    0xb1, 0x9a, 0xbc, 0x24, 0x75, 0x22, 0x2f, 0x35,
    0xc0, 0x85, 0x12, 0x2b, 0xe4, 0xba, 0x1f, 0xfa,
    0x00, 0xad, 0x30, 0xf8, 0x76, 0x7b, 0x3a, 0x82,
    0x38, 0x4c, 0x65, 0x74, 0xf0, 0x24, 0xc3, 0x11,
    0xe2, 0xa4, 0x81, 0x33, 0x2b, 0x08, 0xef, 0x7f,
    0x41, 0x79, 0x78, 0x91, 0xc1, 0x64, 0x6f, 0x48,
}

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (Michael Falcone) — Sun, 01 Apr 2018 13:18:00 +0000

Добрый день! Использую функцию хэширования ГОСТ34.11-2012 (512) на токене ЭЦП 2.0 следующим образом:

QByteArray Token::Hash(CK_SESSION_HANDLE &hSession)
{
    CK_BYTE data[] = { 
        0x32,0x31,0x30,0x39,0x38,0x37,0x36,0x35,0x34,0x33,0x32,0x31,0x30,0x39,0x38,0x37,
        0x36,0x35,0x34,0x33,0x32,0x31,0x30,0x39,0x38,0x37,0x36,0x35,0x34,0x33,0x32,0x31,
        0x30,0x39,0x38,0x37,0x36,0x35,0x34,0x33,0x32,0x31,0x30,0x39,0x38,0x37,0x36,0x35,
        0x34,0x33,0x32,0x31,0x30,0x39,0x38,0x37,0x36,0x35,0x34,0x33,0x32,0x31,0x30 
    };

    CK_ULONG hashSize;
    CK_BYTE_PTR hash;
    returnValue = pFunctionList->C_DigestInit(hSession, &ckmGOST34_11_2012_512Mech);

    if(returnValue != CKR_OK)
    {
        return NULL;
    }

    returnValue = pFunctionList->C_Digest(hSession, data, arraysize(data), NULL_PTR, &hashSize);

    if(returnValue != CKR_OK)
    {
        return NULL;
    }

    hash = (CK_BYTE_PTR)malloc(hashSize * sizeof(CK_BYTE));
    memset(hash, 0, hashSize * sizeof(CK_BYTE));
    pFunctionList->C_Digest(hSession, data, arraysize(data), hash, &hashSize);

    if(returnValue != CKR_OK)
    {
        return NULL;
    }

    QByteArray result = QByteArray::fromRawData((const char*)hash, hashSize);
    qDebug() << result.toHex();
    return result;
}

В массиве data содержится тестовый набор №1 из ГОСТ34.11-2012. В результате хеширования получается следующий массив байт: "150fd4d141347ae78253b1fc9fcd2522aaad2bf06316a5e9189b7487835bc022b85a503627136177c9d6f133a3f338c83
277ca5798bd6bc0ee34282ba0a3d353".

А по стандарту должно получиться:
"486f64c1917879417fef082b3381a4e211c324f074654c38823a7b76f830ad00fa1fbae42b1285c0352f227524bc9ab1
6254288dd6863dccd5b9f54a1ad0541b"

Делал все по примерам из SDK. В чем может заключаться ошибка?

Re: Работа с функциями библиотеки rtPKCS11ECP

null@example.com (mikrob24RUS) — Tue, 27 Mar 2018 08:34:44 +0000

Инициализации происходит кажется в строке:
using (var pkcs11 = new Pkcs11(Settings.RutokenEcpDllDefaultPath, Settings.OsLockingDefault))
Может какая-то проблема с путями, что dll не "цепляются"!?