Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline ac  
#1 Оставлено : 24 февраля 2008 г. 4:25:39(UTC)
ac

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.02.2008(UTC)
Сообщений: 7
Откуда: Moscow

Допустим, на одной стороне стоит Крипто-Про, а на другой стороне нечто тоже работающее по ГОСТ Р 34.10-2001, но только без CryptoAPI.
Необходимо обменяться открытыми ключами.
1) Каким образом можно выгрузить из Крипто-Про открытый ключ в сыром виде (64 байта) ?
2) Каким образом можно загрузить в Крипто-Про открытый ключ в сыром виде (64 байта) ?
Offline ac  
#2 Оставлено : 25 февраля 2008 г. 0:47:52(UTC)
ac

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.02.2008(UTC)
Сообщений: 7
Откуда: Moscow

Возьмем для примера результат работы функции CryptExportKey(hKey,0,PUBLICKEYBLOB,0,pbKeyBlob,&dwBlobLen) с моими комментариями:

BYTE pbKeyBlob[]={
0x06, // bType = PUBLICKEYBLOB
0x20, // bVersion = 0x20
0x00,0x00, // reserved
0x23,0x2E,0x00,0x00, // KeyAlg = ALG_SID_GR3410EL
0x4D,0x41,0x47,0x31, // Magic = MAG1
0x00,0x02,0x00,0x00, // BitLen = 512
// bASN1GostR3410_94_PublicKeyParameters - вот тут я не разобрался что здесь за параметры такие...
0x30,0x12,
0x06,0x07,
0x2A,0x85,0x03,0x02,0x02,0x24,0x00,
0x06,0x07,
0x2A,0x85,0x03,0x02,0x02,0x1E,0x01,
// bPublicKey
0xE5,0x8E,0x60,0x9E,0x9A,0x8E,0xEE,0x03,0xD0,0xE6,0x2B,0xDD,0x56,0xDC,0x5A,0x17,
0x8F,0x06,0x14,0xA5,0x78,0xF3,0x71,0x75,0xE1,0x47,0xA7,0x8C,0xF3,0xD2,0x7E,0x7B,
0x77,0x05,0x26,0xE1,0x58,0xDC,0x55,0x33,0x06,0x78,0x31,0xF7,0xCF,0x5B,0x29,0x2E,
0x2E,0x44,0x3E,0x20,0xD4,0xED,0x4B,0x1C,0xB3,0xC3,0xE8,0x40,0xE8,0x09,0xE4,0x81
};

Если я правильно понимаю, то открытый ключ - это должны быть последние 64 байта.
И этот блок успешно импортируется функцией CryptImportKey(hCryptProv,pbKeyBlob,dwBlobLen,0,CRYPT_EXPORTABLE,&hKey).
Но стоит поменять эти 64 байта на открытый ключ, полученный не от КриптоПро (но тоже от криптобиблиотеки с сертификатом ФСБ),
функция будет возвращать ошибку NTE_BAD_DATA.

И если для расчета хэша параметры методом экспериментов подобрать удалось, то с ключами как-то вообще никак...
Offline ac  
#3 Оставлено : 27 февраля 2008 г. 13:09:59(UTC)
ac

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.02.2008(UTC)
Сообщений: 7
Откуда: Moscow

А программисты Крипто-Про этот форум читают?

Отредактировано пользователем 27 февраля 2008 г. 13:11:34(UTC)  | Причина: Не указана

Offline Юрий  
#4 Оставлено : 27 февраля 2008 г. 14:00:18(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 671
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
Я не программист Крипто-ПРО, но предположу, что публичный ключ экспортируется в "сыром виде" в так называемом "little-endian" формате. То есть последний байт ключа меняется с первым. Согласен, ерунда, но это правило операционной системы Windows.
С уважением,
Юрий Строжевский
Offline Максим Коллегин  
#5 Оставлено : 27 февраля 2008 г. 21:48:55(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,092
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 19 раз
Поблагодарили: 613 раз в 546 постах
А параметры ключей совпадают?
Знания в базе знаний, поддержка в техподдержке
Offline Григорий Чудов  
#6 Оставлено : 27 февраля 2008 г. 22:27:23(UTC)
Григорий Чудов

Статус: Эксперт

Группы: Участники
Зарегистрирован: 27.02.2008(UTC)
Сообщений: 4
Мужчина

При импорте открытого ключа осуществляется ряд проверок, на предмет того является ли данная последовательность бит открытым ключем, т.е. выполнен ли ряд математических соотношений. Это позволяет выявить ошибки при импорте, такие как несоответствие указанных в блобе параметров алгоритма тем, которые использовались при создании данного ключа, или неверный порядок байт.

Убедитесь что ключ, созданный альтернативным СКЗИ был создан с такими же параметрами алгоритма, и что он передаётся в правильном порядке байт - little endian.

Судя по комментарию
// bASN1GostR3410_94_PublicKeyParameters - вот тут я не разобрался что здесь за параметры такие
самая вероятная проблема - это параметры алгоритма.
Здесь указывается DER-encoding для OID, закреплённого за набором параметров ключа (a, b, p, q, x, y)

a, b - coefficients a and b of the elliptic curve E;
p - prime number - elliptic curve modulus;
q - prime number - order of cyclic group;
x, y - base point p coordinates.

OIDы известных науке наборов параметров приводятся в RFC 4357 (см. в частности секции 10.8 и 11.4).
Offline ac  
#7 Оставлено : 27 февраля 2008 г. 23:54:47(UTC)
ac

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.02.2008(UTC)
Сообщений: 7
Откуда: Moscow

Юрий
Спасибо, дельный совет, но в данном случае не помогло...
И скорее всего дело не в порядке байт, т.к. вариант расчета хэша я подобрал методом перебора возможных вариантов,
причем по их классификации он называется "КриптоПро H", а по классификации КриптоПро это "OID_HashVerbaO".
Все остальные комбинации вариантов не прошли.

maxdm
Там есть такие параметры для ГОСТ Р 34.10-2001 (по их классификации):
- "Oscar 2 (совпадает с КриптоПро B)"
- "КриптоПро A"
- "КриптоПро C"
- "стандартные (из стандарта)"

Перебор возможных вариантов пока результатов не дал (то ли я вообще делаю?):

1) вызываю CryptAcquireContext(&hProv,Container,NULL,PROV_GOST_2001_DH,0)
2) вызываю CryptSetProvParam(hProv,PP_SIGNATUREOID,OID_...,0)
- кроме параметра PP_SIGNATUREOID на выбор набора параметров ключей (a,b,p,q,x,y) еще какой-то параметр влияет ?
- каков диапазон значений OID_ ? только эти: OID_ECCTest3410, OID_ECCSignDHPRO, OID_ECCSignDHOSCAR, OID_ECCSignDHVar_1 ?
3) вызываю CryptGenKey(hProv,AT_SIGNATURE,0,&hKey), затем CryptExportKey(hKey,0,PUBLICKEYBLOB,0,pbKeyBlob,&dwBlobLen), и получаю структуру pbKeyBlob, в поле bPublicKey которого потом буду подставлять чужой ключ
4) генерирую чужие ключи на другом СКЗИ, перебирая по очереди возможные варианты, пишу их в поле bPublicKey и вызываю CryptImportKey(hProv,pbKeyBlob,dwBlobLen,0,CRYPT_EXPORTABLE,&hKey) -> получаю ошибку NTE_BAD_DATA
5) перебрав все варианты в п.4 иду в п.2 и повторяю с другим параметром PP_SIGNATUREOID

Григорий Чудов
Собственно как раз про проверки я и подозревал (по аналогии с ключиками DES).
Спасибо, что развеяли мои сомнения!
И вообще спасибо за интересную информацию, буду копать в этом направлении.

Как читать DER-кодировку я еще не совсем понял, поэтому поправьте пожалуйста, если не так:

// bASN1GostR3410_94_PublicKeyParameters
0x30,0x12, // SEQUENCE, size = 0x12
0x06,0x07, // OBJECT, size = 0x07
0x2A,0x85,0x03, // (1.2.643) - очевидно должно быть 1.2.643, но как это закодировано не понимаю
0x02,0x02,0x23,0x02, // .2.2.35.2 = OID_ECCSignDHOSCAR
0x06,0x07, // OBJECT, size = 0x07
0x2A,0x85,0x03, // (1.2.643) - аналогично предыдущему
0x02,0x02,0x1E,0x01, // .2.2.30.1 = OID_HashVerbaO

Отредактировано пользователем 29 февраля 2008 г. 1:42:54(UTC)  | Причина: Не указана

Offline Григорий Чудов  
#8 Оставлено : 29 февраля 2008 г. 21:27:30(UTC)
Григорий Чудов

Статус: Эксперт

Группы: Участники
Зарегистрирован: 27.02.2008(UTC)
Сообщений: 4
Мужчина

1. Во первых, вы осознанно работаете с ключами подписи? Дело в том, что сама задача обмена открытыми ключами возникает обычно для ключей _обмена_ :) А если речь шла о ключах обмена, то надо использовать не AT_SIGNATURE а AT_KEYEXCHANGE, не PP_SIGNATUREOID а PP_DHOID, и там другие наборы параметров (OID_ECCDHPRO, OID_ECCDHPVar_1)

2. Перебор тут может не спасти, поскольку неизвестно какие параметры используются в другом СКЗИ, теоретически там может оказаться какая-то экзотика вообще не поддерживаемая CryptoPro CSP. Попробуйте почитать документацию/связаться с разработчиками этого другого СКЗИ и выяснить что у них там с параметрами ключей.

3. Для разбора asn1 есть полезная утилита от Питера Гутмана, http://www.cs.auckland.ac.nz/~pgut001/. Да, вы правильно разобрали структуру параметров.

Отредактировано пользователем 3 марта 2008 г. 6:00:31(UTC)  | Причина: Не указана

Offline ac  
#9 Оставлено : 13 марта 2008 г. 2:26:36(UTC)
ac

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.02.2008(UTC)
Сообщений: 7
Откуда: Moscow

Всем откликнувшимся спасибо!
Разработчики того другого СКЗИ помогли решить вопрос.
Нужно было переворачивать задом наперед не все 64 байта одним махом, а два раза по 32 байта.
Offline Юрий  
#10 Оставлено : 13 марта 2008 г. 13:38:09(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 671
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
Кстати, выдержка из RFC4491:

The GOST R 34.10-2001 public key MUST be ASN.1 DER encoded as an
OCTET STRING; this encoding shall be used as the contents (i.e., the
value) of the subjectPublicKey component (a BIT STRING) of the
SubjectPublicKeyInfo data element.

GostR3410-2001-PublicKey ::= OCTET STRING -- public key vector, Q

According to [GOSTR341001], a public key is a point on the elliptic
curve Q = (x,y).

GostR3410-2001-PublicKey MUST contain 64 octets, where the first 32
octets contain the little-endian representation of x and the second
32 octets contain the little-endian representation of y. This
corresponds to the binary representation of from
[GOSTR341001], ch. 5.3.
С уважением,
Юрий Строжевский
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.