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

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline sushev_a_a  
#11 Оставлено : 11 апреля 2017 г. 17:04:42(UTC)
sushev_a_a

Статус: Участник

Группы: Участники
Зарегистрирован: 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?
Offline Сонина Лолита  
#12 Оставлено : 11 апреля 2017 г. 17:29:11(UTC)
Сонина Лолита

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

Группы: Участники
Зарегистрирован: 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 для эфемерного ключа.
Техническую поддержку оказываем тут
Наша база знаний
thanks 1 пользователь поблагодарил Сонина Лолита за этот пост.
sushev_a_a оставлено 12.04.2017(UTC)
Offline sushev_a_a  
#13 Оставлено : 11 мая 2017 г. 12:59:48(UTC)
sushev_a_a

Статус: Участник

Группы: Участники
Зарегистрирован: 28.11.2016(UTC)
Сообщений: 19
Российская Федерация

Сказал(а) «Спасибо»: 7 раз
добрый день.
подскажите, пожалуйста, как из мастер-ключа получить векторы инициализации?
или векторы инициализации автоматически устанавливаются в ключи шифрования в CryptDeriveKey(...CALG_TLS1_ENC_KEY...)
и их отдельно получать не надо?
Offline Сонина Лолита  
#14 Оставлено : 11 мая 2017 г. 16:53:12(UTC)
Сонина Лолита

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

Группы: Участники
Зарегистрирован: 20.11.2014(UTC)
Сообщений: 27
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 19 раз в 17 постах
Добрый день!

При выработке ключей шифрования из мастер-хэша с помощью вызова CryptDeriveKey(CALG_TLS1_ENC_KEY) нужная синхропосылка будет установлена в ключ автоматически, дополнительно ничего делать не нужно.
Если Вам необходимо получить непосредственно значение установленной синхропосылки, то Вы можете сделать это с помощью вызова CryptGetKeyParam(KP_IV).
Техническую поддержку оказываем тут
Наша база знаний
thanks 1 пользователь поблагодарил Сонина Лолита за этот пост.
sushev_a_a оставлено 11.05.2017(UTC)
Offline sushev_a_a  
#15 Оставлено : 11 мая 2017 г. 17:52:44(UTC)
sushev_a_a

Статус: Участник

Группы: Участники
Зарегистрирован: 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-сообщения, вот пытаюсь разобраться где неправильно сделал)
Offline Сонина Лолита  
#16 Оставлено : 11 мая 2017 г. 18:19:16(UTC)
Сонина Лолита

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

Группы: Участники
Зарегистрирован: 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().
Техническую поддержку оказываем тут
Наша база знаний
thanks 1 пользователь поблагодарил Сонина Лолита за этот пост.
sushev_a_a оставлено 11.05.2017(UTC)
Offline sushev_a_a  
#17 Оставлено : 22 мая 2017 г. 17:20:12(UTC)
sushev_a_a

Статус: Участник

Группы: Участники
Зарегистрирован: 28.11.2016(UTC)
Сообщений: 19
Российская Федерация

Сказал(а) «Спасибо»: 7 раз
добрый день.
при экспорте эфемерного открытого ключа 512 бит через CryptExportKey( ...PUBLICKEYBLOB...) получаем блок данных длиной 101 байт.
на сколько я понял, первые 81 байт - это структура CRYPT_PUBLICKEYBLOB (16 байт заголовок, 1 байт - пустые параметры открытого ключа, 64 байта - открытый ключ)
подскажите, пожалуйста, что из себя представляют последние 20 байт?
Offline Сонина Лолита  
#18 Оставлено : 22 мая 2017 г. 19:43:44(UTC)
Сонина Лолита

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

Группы: Участники
Зарегистрирован: 20.11.2014(UTC)
Сообщений: 27
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 19 раз в 17 постах
Добрый вечер!

Сначала в блобе идет CRYPT_PUBKEY_INFO_HEADER (16 байт), далее параметры открытого ключа, за ними следуют непосредственно байты открытого ключа.

Параметры открытого ключа не пусты - это закодированная ASN1 структура GostR3410-2001-PublicKeyParameters, описанная в RFC 4357.
Техническую поддержку оказываем тут
Наша база знаний
thanks 1 пользователь поблагодарил Сонина Лолита за этот пост.
sushev_a_a оставлено 23.05.2017(UTC)
Offline sushev_a_a  
#19 Оставлено : 21 июня 2017 г. 10:55:11(UTC)
sushev_a_a

Статус: Участник

Группы: Участники
Зарегистрирован: 28.11.2016(UTC)
Сообщений: 19
Российская Федерация

Сказал(а) «Спасибо»: 7 раз
добрый день.
подскажите, пожалуйста, как правильно работать с сессионными ключами после установления TLS-соединения?
ситуация такая: нормально зашифровываю finished-сообщение клиентским ключом key_write, сервер норм расшифровывает своим ключом key_read, но после следующего шифрования клиентом key_write-ключом сервер уже расшифровывает неправильно...
и у ключей client.key_write и server.key_read становятся разными вектора инициализации (KP_IV) после первого шифрования-расшифрования...
Offline Сонина Лолита  
#20 Оставлено : 21 июня 2017 г. 11:00:19(UTC)
Сонина Лолита

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

Группы: Участники
Зарегистрирован: 20.11.2014(UTC)
Сообщений: 27
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 19 раз в 17 постах
Добрый день!

В протоколе TLS используется "сквозное" шифрование, т.е. состояние ключа не должно сбрасываться между шифрованиями разных пакетов.
Для этого необходимо все шифрования/расшифрования выполнять с флагом bFinal = FALSE.
Техническую поддержку оказываем тут
Наша база знаний
thanks 1 пользователь поблагодарил Сонина Лолита за этот пост.
sushev_a_a оставлено 21.06.2017(UTC)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.