Статус: Участник
Группы: Участники
Зарегистрирован: 28.11.2016(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 7 раз
|
добрый день. разбираюсь с формированием client_key_exchange сообщения в TLS. посмотрел TK26TLS и TK26CMS, там должна идти структура GostR3410-KeyTransport. и для ситуации, когда идет только аутентификация сервера, и клиент создает эфемерный ключ, она будет иметь вид { sessionEncryptedKey, encryptionParamSet, ephemeralPublicKey, ukm } предположил, что sessionEncryptedKey - это premaster_secret экспортированный на ключе согласования в SIMPLEBLOB, а ephemeralPublicKey - это эфемерный открытый ключ экспортированный в PUBLICKEYBLOB. но есть сомнения.
подскажите пожалуйста, какую структуру имеют sessionEncryptedKey, encryptionParamSet и ephemeralPublicKey?
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 20.11.2014(UTC) Сообщений: 27 Сказал(а) «Спасибо»: 1 раз Поблагодарили: 19 раз в 17 постах
|
Добрый вечер!
Сама структура GostR3410-KeyTransport описана в документе TK26CMS.
GostR3410-KeyTransport ::= SEQUENCE { sessionEncryptedKey Gost28147-89-EncryptedKey, transportParameters [0] IMPLICIT GostR3410-TransportParameters OPTIONAL }
GostR3410-TransportParameters ::= SEQUENCE { encryptionParamSet OBJECT IDENTIFIER, ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, ukm OCTET STRING }
Структура Gost28147-89-EncryptedKey была определена в RFC 4357:
Gost28147-89-Key ::= OCTET STRING (SIZE (32)) Gost28147-89-MAC ::= OCTET STRING (SIZE (1..4)) Gost28147-89-EncryptedKey ::= SEQUENCE { encryptedKey Gost28147-89-Key, maskKey [0] IMPLICIT Gost28147-89-Key OPTIONAL, macKey Gost28147-89-MAC (SIZE (4)) }
Поле encryptedKey содержит зашифрованный premaster_secret, macKey - имитовставку на premaster_secret. Поле maskKey не используется.
encryptionParamSet должен содержат идентификатор узлов замены, используемых при шифровании premaster_secret.
ephemeralPublicKey имеет следующий вид:
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }
Правила заполнения структуры SubjectPublicKeyInfo для ключей ГОСТ Р 34.10-2012 описаны в документе ТК26ИОК (п.4.3.1).
Получить закодированные ASN-структуры напрямую из интерфейса CryptoAPI 1.0 нельзя, однако все требуемые для заполнения ASN данные содержатся в SIMPLEBLOB для premaster_secret и PUBLICKEYBLOB для эфемерного ключа. |
|
1 пользователь поблагодарил Сонина Лолита за этот пост.
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 28.11.2016(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 7 раз
|
добрый день. подскажите, пожалуйста, как из мастер-ключа получить векторы инициализации? или векторы инициализации автоматически устанавливаются в ключи шифрования в CryptDeriveKey(...CALG_TLS1_ENC_KEY...) и их отдельно получать не надо?
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 20.11.2014(UTC) Сообщений: 27 Сказал(а) «Спасибо»: 1 раз Поблагодарили: 19 раз в 17 постах
|
Добрый день!
При выработке ключей шифрования из мастер-хэша с помощью вызова CryptDeriveKey(CALG_TLS1_ENC_KEY) нужная синхропосылка будет установлена в ключ автоматически, дополнительно ничего делать не нужно. Если Вам необходимо получить непосредственно значение установленной синхропосылки, то Вы можете сделать это с помощью вызова CryptGetKeyParam(KP_IV). |
|
1 пользователь поблагодарил Сонина Лолита за этот пост.
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 28.11.2016(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 7 раз
|
добрый день. есть еще вопросы про выработку ключей)
в описании ф-ции CryptDeriveKey указано, что объект функции хеширования закрывается во время вызова. получается, когда я создал хеш, получил ключ записи CryptDeriveKey(...CALG_TLS1_ENC_KEY...), перед следующим вызовом CryptDeriveKey(...CALG_TLS1_MAC_KEY...) должен сделать CryptSetHashParam(...HP_OPEN...) c TRUE? и важна ли последовательность получения ключей функцией CryptDeriveKey?
пробую установить соединение с SSPI/WebServer из sdk и стабильно получаю в нем ошибку SEC_E_DECRYPT_FAILURE после клиентского finished-сообщения, вот пытаюсь разобраться где неправильно сделал)
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 20.11.2014(UTC) Сообщений: 27 Сказал(а) «Спасибо»: 1 раз Поблагодарили: 19 раз в 17 постах
|
Закрытие объекта хэширования означает, что после этого для него не может быть вызвана функция CryptHashData(...). В Вашем случае вызов CryptSetHashParam(...HP_OPEN...) не требуется. Результат работы последовательности вызовов CryptDeriveKey(...CALG_TLS1_ENC_KEY...) и CryptDeriveKey(...CALG_TLS1_MAC_KEY...) не зависит от порядка вызовов.
Если ошибка возникает при расшифровании, возможно, при зашифровании были использованы нестандартные узлы замены. Предполагается использование узлов замены szOID_Gost28147_89_CryptoPro_A_ParamSet (1.2.643.2.2.31.1) для сюиты 2001 года и szOID_Gost28147_89_TC26_Z_ParamSet (1.2.643.7.1.2.5.1.1) для сюиты 2012 года. Узлы замены необходимо установить на ключи шифрования и имитовставки сразу после их получения с помощью функции CryptDeriveKey(). |
|
1 пользователь поблагодарил Сонина Лолита за этот пост.
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 28.11.2016(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 7 раз
|
добрый день. при экспорте эфемерного открытого ключа 512 бит через CryptExportKey( ...PUBLICKEYBLOB...) получаем блок данных длиной 101 байт. на сколько я понял, первые 81 байт - это структура CRYPT_PUBLICKEYBLOB (16 байт заголовок, 1 байт - пустые параметры открытого ключа, 64 байта - открытый ключ) подскажите, пожалуйста, что из себя представляют последние 20 байт?
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 20.11.2014(UTC) Сообщений: 27 Сказал(а) «Спасибо»: 1 раз Поблагодарили: 19 раз в 17 постах
|
Добрый вечер!
Сначала в блобе идет CRYPT_PUBKEY_INFO_HEADER (16 байт), далее параметры открытого ключа, за ними следуют непосредственно байты открытого ключа.
Параметры открытого ключа не пусты - это закодированная ASN1 структура GostR3410-2001-PublicKeyParameters, описанная в RFC 4357. |
|
1 пользователь поблагодарил Сонина Лолита за этот пост.
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 28.11.2016(UTC) Сообщений: 19 Сказал(а) «Спасибо»: 7 раз
|
добрый день. подскажите, пожалуйста, как правильно работать с сессионными ключами после установления TLS-соединения? ситуация такая: нормально зашифровываю finished-сообщение клиентским ключом key_write, сервер норм расшифровывает своим ключом key_read, но после следующего шифрования клиентом key_write-ключом сервер уже расшифровывает неправильно... и у ключей client.key_write и server.key_read становятся разными вектора инициализации (KP_IV) после первого шифрования-расшифрования...
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 20.11.2014(UTC) Сообщений: 27 Сказал(а) «Спасибо»: 1 раз Поблагодарили: 19 раз в 17 постах
|
Добрый день!
В протоколе TLS используется "сквозное" шифрование, т.е. состояние ключа не должно сбрасываться между шифрованиями разных пакетов. Для этого необходимо все шифрования/расшифрования выполнять с флагом bFinal = FALSE. |
|
1 пользователь поблагодарил Сонина Лолита за этот пост.
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close