WWW.LIB.KNIGI-X.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные материалы
 

«Криптонаборы протокола TLS на основе криптографических алгоритмов ГОСТ 28147-89, СТБ 1176.1-99, СТБ 1176.2-99, СТБ П 34.101.31-2007, РД РБ 07040.1202-2003 и ...»

Криптонаборы протокола TLS на основе криптографических алгоритмов ГОСТ 28147-89,

СТБ 1176.1-99, СТБ 1176.2-99, СТБ П 34.101.31-2007, РД РБ 07040.1202-2003

и криптографических протоколов проекта РД РБ «Банковские технологии. Протоколы

формирования общего ключа»

1. Введение

Протокол TLS (Transport Layer Security) служит для обеспечения конфиденциальности,

контроля подлинности и целостности данных, передаваемых между двумя сторонами –

клиентом и сервером. Для решения задач протокола используются криптонаборы (cipher suites), которые включают криптографические алгоритмы различного назначения.

Дополнительно применяются методы аутентификации сервера и клиента, основанные на проверке сертификатов открытых ключей. В TLS предусмотрена возможность расширения перечня криптонаборов и методов аутентификации.

В настоящем документе определяется криптонабор, основанный на криптографических алгоритмах ГОСТ 28147-89 [GOST28147], РД РБ 07040.1202-2003 [RDPRNG] и криптографических протоколах проекта РД РБ «Банковские технологии. Протоколы формирования общего ключа» [RDPFOK]. Дополнительно определяются методы аутентификации, состоящие в проверке электронной цифровой подписи сертификатов открытых ключей сторон и в проверке знания сторонами соответствующих личных ключей. Форматы сертификатов соответствуют СТБ 34.101.19 *STB3410119] и РД РБ 07040.1206-2004 [RDCERT]. Электронная цифровая подпись сертификатов вычисляется и проверяется по алгоритмам, определенным в СТБ 1176.2-99 [STB11762]. В алгоритмах СТБ 1176.2-99 и РД РБ 07040.1202-2003 используется вспомогательный алгоритм хэширования, заданный в СТБ 1176.1-99 [STB11761]. Еще один алгоритм хэширования, определенный в СТБ П 34.101.31-2007 [STBP3410131+, может использоваться для предварительного хэширования подписываемых данных.



Определения криптонаборов и методов аутентификации даются для протокола TLS версии 1.2, определенного в стандарте [TLS12]. Используется терминология и соглашения данного стандарта, в частности, соглашения по описанию структур данных (см. [TLS12, раздел 4+).

Стек протоколов TLS состоит из двух уровней. На нижнем уровне действует протокол Record, обеспечивающий защищенный транспорт данных, поступающих от протоколов верхнего уровня. На верхнем уровне действуют протоколы Handshake, Application Data, Change Cipher Spec и Alert. Протокол Handshake согласует алгоритмы и параметры защиты, используемые протоколом Record. В частности, протокол Handshake согласует параметр pre_master_secret. Данный параметр используется алгоритмом генерации псевдослучайных данных для выработки параметра master_secret, на основе которого вырабатываются ключи протокола Record. Протокол Alert извещает об ошибках, произошедших при выполнении других протоколов. Протокол Change Cipher Spec сообщает о смене параметров защиты на новые, согласованные при выполнении протокола Handshake.

Далее применяются следующие сокращения: ЭЦП – электронная цифровая подпись, ПФОК – протокол формирования общего ключа.

2. Криптонаборы

–  –  –

3. Алгоритмы криптонаборов

3.1. Алгоритм шифрования Для шифрования используется алгоритм, определенный в [GOST28147]. Шифрование выполняется в режиме гаммирования. Алгоритм шифрования классифицируется как поточный и действуют правила, определенные в [TLS12, п. 6.2.3.1].

Ключ шифрования вырабатывается в процессе выполнения протокола Handshake. В качестве синхропосылки используется 64-разрядный счетчик записей (sequence number), определенный в *TLS12, п. 6.1].





Блок подстановки, который используется для шифрования, определяется в процессе выполнения протокола Handshake при пересылке сообщений Server Key Exchange (см.

п. 5.4) и Client Key Exchange (см. п. 5.8).

3.2. Алгоритм имитозащиты

Для имитозащиты используется алгоритм MAC. Входными данными алгоритма являются 32-байтовый ключ key и подлежащие имитозащите данные data. Выходными данными является 8-байтовая имитовставка.

В MAC используется вспомогательный алгоритм gostMAC, который берет на вход (key, data) и возвращает 4-байтовую имитовставку, определенную в соответствии с [GOST28147]. В алгоритме gostMAC используется тот же блок подстановки, что и в алгоритме шифрования (см. подраздел 3.1).

Алгоритм MAC дважды дублирует имитовставку gostMAC:

MAC(key, data) = gostMAC(key, data) + gostMAC(key, data) (знак + в соответствии с *TLS12, раздел 5] обозначает конкатенацию байтовых блоков).

Согласно [GOST28147] блок data должен состоять не менее чем из 9 байтов. Алгоритм MAC используется в TLS так, что данное требование обязательно выполняется.

3.3. Алгоритм выработки псевдослучайных данных

Для выработки псевдослучайных данных используется алгоритм PRF. Входными данными алгоритма являются ключ secret, ASCII-строка label и затравочное значение seed. Алгоритм вырабатывает последовательность псевдослучайных данных требуемой длины.

В PRF используется вспомогательный алгоритм rdprng, определенный в *RDPRNG].

Алгоритм берет на вход 32-байтовый секретный параметр K и 32-байтовый счетчик C.

Дополнительные входные данные, определенные в [RDPRNG], не используются. Выходом rdprng(K, C) является последовательность псевдослучайных данных требуемой длины.

В PRF используется также вспомогательный алгоритм хэширования stb11761, определенный в *STB11761+. Алгоритм берет на вход блок данных X и возвращает его 32байтовое хэш-значение stb11761(X). Стартовый вектор H, который используется при хэшировании, выбирается так же, как в [RDPRNG].

Алгоритм PRF определяется следующим образом:

PRF(secret, label, seed) = rdprng(stb11761(secret), stb11761(label + seed)).

3.4. Алгоритмы формирования общего ключа

–  –  –

3.4.1. Алгоритм RDPFOK_DHE Алгоритм RDPFOK_DHE состоит в выполнении сторонами определенного в [RDPFOK] протокола формирования общего ключа без аутентификации сторон. Для применения RDPFOK_DHE сертификат сервера ДОЛЖЕН содержать открытый ключ ЭЦП, соответствующий *STB11762].

Сервер выбирает параметры протокола, вырабатывает эфемерный личный ключ uB и находит соответствующий открытый ключ vB. Затем сервер подписывает структуру, составленную из параметров, vB и блоков client_random, server_random. При выработке ЭЦП используется личный ключ, которому соответствует открытый ключ сертификата сервера. Сервер передает параметры, vB и выработанную ЭЦП клиенту в сообщении Server Key Exchange (см. п. 5.4).

Клиент проверяет ЭЦП, затем вырабатывает эфемерный личный ключ uA, находит соответствующий открытый ключ vA и передает vA серверу в сообщении Client Key Exchange (см. п. 5.8).

Сервер по uB и vA, а клиент по uA и vB, находят общий секретный ключ pre_master_secret.

3.4.2. Протокол RDPFOK_DHT

Алгоритм RDPFOK_DHT состоит в выполнении сторонами определенного в [RDPFOK] протокола одностороннего формирования общего ключа. Для применения RDPFOK_DHT сертификат сервера ДОЛЖЕН содержать открытый ключ ПФОК, соответствующий [RDPFOK].

Клиент разбирает сертификат сервера и определяет размещенные в нем параметры ПФОК и открытый ключ vB. Клиент вырабатывает эфемерный личный ключ uA и находит соответствующий открытый ключ vA. По vB и uA клиент находит общий секретный ключ K (32 байта). Клиент генерирует случайный pre_master_secret, зашифровывает его на K с помощью алгоритма *GOST28147+ в режиме простой замены и передает результат зашифрования серверу вместе с vA и gostMAC(K, pre_master_secret) в сообщении Client Key Exchange (см. п. 5.8).

Сервер определяет K по uB и vA, выполняет расшифрование pre_master_secret и проверяет имитовставку gostMAC(K, pre_master_secret). Если имитовставка корректна, то сервер принимает pre_master_secret.

4. Методы аутентификации

4.1. Аутентификация сервера При использовании криптонаборов настоящего документа сервер в сообщении Server Certificate (см. п. 5.3) ДОЛЖЕН переслать клиенту свой сертификат. Последующее успешное завершение протокола Handshake означает, что проведена аутентификация сервера: сертификат сервера действителен и сервер знает личный ключ, соответствующий открытому ключу сертификата.

4.2. Аутентификация клиента

Для аутентификации клиента могут использоваться следующие методы:

Метод аутентификации клиента Идентификатор STB11762_SIGN 224 STB11762_SIGN_PRO 225 Для применения данных методов сервер в сообщение Certificate Request (см. п. 5.5) ДОЛЖЕН запросить у клиента его сертификат. После получения сообщения Certificate Request клиент ДОЛЖЕН отправить сообщение Client Certificate (см. п. 5.7). В сообщении Client Certificate клиент ДОЛЖЕН представить запрашиваемый сертификат. При использовании метода STB11762_SIGN сертификат ДОЛЖЕН содержать открытый ключ ЭЦП, соответствующий *STB11762]. При использовании метода STB11762_SIGN_PRO сертификат ДОЛЖЕН содержать открытый ключ ЭЦП, соответствующий *STB11762] с предварительным хэшированием согласно *STBP3410131].

Последующее успешное завершение протокола Handshake означает, что проведена аутентификация клиента:

сертификат клиента действителен и клиент знает личный ключ, соответствующий открытому ключу сертификата.

Методы STB11762_SIGN и STB11762_SIGN_PRO не применяются и предыдущие ограничения не действуют, если клиент передает в сообщении Client Certificate пустую цепочку сертификатов. В этом случае согласно *TLS12] сервер может либо прервать протокол Handshake, либо продолжить его, но уже без аутентификации клиента.

4.3. Алгоритмы ЭЦП

В *TLS12+ для идентификации пар (алгоритм хэширования, алгоритм ЭЦП) используется тип struct { HashAlgorithm hash;

SignatureAlgorithm signature;

} SignatureAndHashAlgorithm;

При использовании методов аутентификации настоящего документа вложенные типы

HashAlgorithm и SignatureAlgorithm определяются следующим образом:

enum {stb11761(224), hbelt(225)} HashAlgorithm;

stb11761: Алгоритм хэширования, определенный в *STB11761].

hbelt: Алгоритм хэширования, определенный в *STBP3410131].

enum {stb11762(224) } SignatureAlgorithm;

stb11762: Алгоритмы ЭЦП, определенные в *STB11762].

Сочетание,stb11761, stb11762- означает, что проверка и выработка ЭЦП выполняются без предварительного хэширования.

Сочетание,hbelt, stb11762- означает, что ЭЦП вырабатывается согласно *STB11762+ от предварительно вычисленного хэш-значения по алгоритму *STBP3410131].

5. Сообщения и шаги

5.1. Уточнения В настоящем разделе проводится уточнение сообщений и шагов протокола Handshake.

Уточнения касаются деталей использования определенных выше криптонаборов и методов аутентификации при выполнении протокола.

Сообщения и шаги протоколов Record, Application Data, Change Cipher Spec и Alert не уточняются, в этом нет необходимости.

5.2. Сообщения Client Hello, Server Hello, Hello Request

Целью обмена сообщениями Client Hello и Server Hello является формирование случайных данных клиента (client_random) и сервера (server_random), а также согласование криптонабора, используемого при обработке последующих сообщений.

Для использования криптонаборов настоящего документа стороны указывают их идентификаторы (см. раздел 2) в поле cipher_suites сообщения Client Hello и в поле cipher_suite сообщения Server Hello.

Расширения сообщений Client Hello и Server Hello не используются.

Сообщение Hello Request не уточняется.

5.3. Сообщение Server Certificate

Сообщение Server Certificate содержит цепочку сертификатов сервера. Каждый следующий сертификат цепочки заверяет подлинность предыдущего. Корневой сертификат может быть опущен.

Если сторонами был выбран алгоритм формирования общего ключа RDPFOK_DHE, то сертификат сервера должен содержать открытый ключ и параметры ЭЦП согласно [STB11762]. Ключ ЭЦП используется клиентом для проверки подписанных сервером сообщений.

Если сторонами был выбран алгоритм формирования общего ключа RDPFOK_DHT, то сертификат сервера должен содержать открытый ключ идентификации и параметры протокола формирования общего ключа согласно [RDPFOK].

5.4. Сообщение Server Key Exchange

–  –  –

5.5. Сообщение Certificate Request Сервер может отправить сообщение Certificate Request для аутентификации клиента. В этом случае поля структуры CertificateRequest должны быть заданы следующим образом:

certificate_types: Идентификаторы методов аутентификации STB11762_SIGN, STB11762_SIGN_PRO (см. п. 4.2).

supported_signature_algorithms: Определенные в п. 4.3 пары идентификаторов (алгоритм хэширования, алгоритм ЭЦП);

certificate_authorities: Без уточнений относительно [TLS12].

5.6. Сообщение Server Hello Done Без уточнений относительно [TLS12].

5.7. Сообщение Client Certificate Сообщение посылается клиентом, если сервер прислал запрос Certificate Request.

Сообщение содержит сертификат клиента с открытым ключом, соответствующему одному из запрошенных методов аутентификации: STB11762_SIGN или STB11762_SIGN_PRO.

5.8. Сообщение Client Key Exchange Сообщение Server Key Exchange определяется по следующим правилам.

enum {rdpfok_dhe, rdpfok_dht} KeyExchangeAlgorithm;

rdpfok_dhe: Используется алгоритм формирования общего ключа RDPFOK_DHE.

rdpfok_dht: Используется алгоритм формирования общего ключа RDPFOK_DHT.

struct { opaque vA80..368;

OID oid0..

1;

select (KeyExchangeAlgorithm) {

case rdpfok_dhe:

struct {} ;

case rdpfok_dht:

opaque encrypted_secret[48];

opaque mac_secret[4];

};

} ClientKeyExchange;

vA: Открытый ключ клиента. Открытый ключ определяется по личному ключу uA.

При использовании алгоритма RDPFOK_DHE открытый ключ определяется согласно [RDPFOK, п. 4.1.4.2+. Используются параметры ПФОК, переданные сервером в сообщении Server Key Exchange (см. п. 5.4).

При использовании алгоритма RDPFOK_DHT открытый ключ определяется согласно [RDPFOK, п. 4.3.4.2+. Используются параметры ПФОК из сертификата сервера, переданного в сообщении Server Certificate (см. п. 5.3).

oid: Список, который определяет выбранный клиентом блок подстановки и который ДОЛЖЕН использоваться в протоколе Record для шифрования и имитозащиты данных (см. п. 3.1, 3.2).

Если список состоит из одного элемента, то ДОЛЖЕН использоваться блок подстановки, который соответствует данному элементу.

Если список пуст, а в сообщении Server Key Exchange блок подстановки был задан явно, то ДОЛЖЕН использоваться данный блок подстановки.

Если список пуст, а в сообщении Server Key Exchange блоки подстановки не передавались, то ДОЛЖЕН использоваться блок подстановки, указанный при описании поля encrypted_secret (см. ниже).

–  –  –

5.9. Сообщения Certificate Verify, Finished Сообщения Certificate Verify, Finished не уточняются относительно спецификации *TLS12+.

Для выработки ЭЦП при формировании сообщения Certificate Verify используются алгоритмы ЭЦП, определенные в п. 4.3.

В качестве алгоритма PRF при формировании сообщения Finished используется алгоритм, определенный в п. 3.3. Параметр verify_data_length выбирается равным 12.

6. Совместимость Определения криптонаборов и методов аутентификации, сделанные в настоящем документе, полностью соответствуют соглашениям TLS версии 1.2.

7. Безопасность Протокол TLS и его предшественник – протокол SSL – активно исследовались криптографическим сообществом на протяжении последних 20 лет. Для устранения обнаруженных уязвимостей, для повышения расширяемости и гибкости TLS вводились в действие новые версии протокола. Криптонаборы и методы аутентификации настоящего документа применяются для TLS последней на сегодняшний день версии 1.2.

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

Длина имитовставки ГОСТ 28147-89 (4 байта) на сегодняшний день считается неудовлетворительно малой. Для преодоления данного недостатка в алгоритме MAC она дублируется дважды. С учетом того, что выходные данные алгоритма MAC зашифровываются (см. *TLS12, п. 6.2.3.1+), дублирование имитовставки ГОСТ 28147-89 снижает вероятность ее случайного угадывания с 2-32 до 2-64, что повышает надежность имитозащиты.

Алгоритмы формирования общего ключа RDPFOK_DHE и RDPFOK_DHT позволяют серверу передавать клиентам блок подстановки ГОСТ 28147-89, используемый протоколом Record для шифрования и имитозащиты. Безопасность сообщений протокола Record существенно зависит от данного блока. Блок должен быть рекомендован для использования в Республике Беларусь.

При выборе алгоритма RDPFOK_DHT блок подстановки, передаваемый сервером в сообщении Server Key Exchange может отличаться от фиксированного блока, используемого клиентом для зашифрования сообщения Client Key Exchange.

Использование фиксированного блока подстановки в сообщении Client Key Exchange необходимо для предотвращения атаки активного противника по подмене блока с целью выдачи себя за сервер.

Ссылки

[GOST28147] Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. ГОСТ 28147-89. Москва, 1989.

[GOST34973] Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1). ГОСТ 34.973-91 (ИСО 8824-87).

Москва, 1991.

[GOST34974] Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1).

ГОСТ 34.974-91 (ИСО 8825-87).

Москва, 1991.

[RDCERT+ Руководящий документ Республики Беларусь. Банковские технологии. Формат сертификатов открытых ключей и списков отозванных сертификатов. РД РБ 07040.1206-2004.

Национальный банк Республики Беларусь. Минск, 2004.

*RDPFOK+ Проект руководящего документа Республики Беларусь «Банковские технологии.

Протоколы формирования общего ключа». Минск, 1997.

[RDPRNG+ Руководящий документ Республики Беларусь. Автоматизированная система межбанковских расчетов. Процедура выработки псевдослучайных данных с использованием секретного параметра. РД РБ 07040.1206-2003. Национальный банк Республики Беларусь. Минск, 2003.

*STB11761+ Государственный стандарт Республики Беларусь. Информационная технология. Защита информации. Функция хэширования. СТБ 1176.1-99. Минск, 1999.

*STB11762+ Государственный стандарт Республики Беларусь. Информационная технология. Защита информации. Процедуры выработки и проверки электронной цифровой подписи. СТБ 1176.2-99. Минск, 1999.

*STB3410119+ Информационные технологии. Форматы сертификатов и списков отозванных сертификатов инфраструктуры открытых ключей. СТБ 34.101.19-2009. Минск, 2009.

[STBP3410131+ Информационные технологии. Защита информации. Криптографические алгоритмы шифрования и контроля целостности. СТБ П 34.101.31-2007. Минск, 2007.

[TLS12] T. Dierks, E. Rescorla The Transport Layer Security (TLS) Protocol. Version 1.2. RFC 5246.

Похожие работы:

«АМЕРИКАНО-ЯПОНСКИЙ АНТАГОНИЗМ В ХОДЕ РЕАЛИЗАЦИИ ДОКТРИНЫ ОТКРЫТЫХ ДВЕРЕЙ В КИТАЕ В ПЕРВОЙ ПОЛОВИНЕ ХХ В. Рязанцев Д.Р. Амурский государственный университет Благовещенск, Россия THE ANTAGONISM BETWEEN JAPAN AND THE USA DURING OPEN DOOR POLICY REALIZATION IN CHINA IN THE FIRST HALF OF THE 20th CENTUR...»

«ГОСУДАРСТВЕННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА ЖИЛИЩНО-КОММУНАЛЬНОГО ХОЗЯЙСТВА (ГИС ЖКХ) ТЕХНОЛОГИЧЕСКАЯ ИНСТРУКЦИЯ ПО РАБОТЕ В ЛИЧНОМ КАБИНЕТЕ АДМИНИСТРАТОРА ОБЩЕГО СОБРАНИЯ СОБСТВ...»

«03/2016 Развитие Персонал Признание Офис "ИТСК" начал "ИТСК" получила премию Рунета Награда на WorldSkills ДЕКАБРЬ работу в Сколково за разработку и внедрение Hi-Tech в Екатеринбурге системы "Мобильный оператор" www.it-sk.ru ИНФОРМ Ж У Р Н А Л И...»

«MICROTEC РУКОВОДСТВО ПО ЭКСПЛУАТАЦИИ МОДЕЛЬ MT1500S / MT2500 © 2006 ИНЖИНИРИНГОВАЯ КОМПАНИЯ ООО ТЕСИС МОСКВА, УЛ. ЮННАТОВ, 18. (495) 612-44-22, 612-42-62 Пожалуйста, внимательно прочитайте данное руководство перед использованием аппаратов Microtec Model MT1500S and Model MT2500. Модели Microtec MT1500S и MT2500 являются н...»

«Лечебно-консультативная поликлиника 680054, г. Хабаровск, ул. профессора Даниловского, 20 тел.: (4212) 766-240, 766-230 ИНН 2725064020 Лицензия № ЛО-27-01-001096 от 22.05.2013г. ПРЕЙСКУРАНТ ЦЕН НА ПЛАТНЫЕ УСЛУГИ, ОКАЗЫВАЕМЫЕ ПОЛИКЛИНИКОЙ "НЕФЕРТИТИ" Утверждаю с 01.10.16г...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего профессионального образования Казанский (Приволжский) федеральный университет Утверждаю Проректор по образовательной деятельности _ _ Р.Г.Минзарипов...»

«CONFERENCE ROOM PAPER 3 ECE/OSCE CPR: 3 26 April 2002 Unofficial Russian Translation ECONOMIC COMMISSION FOR EUROPE Fifty-seventh session Item 6: УКРЕПЛЕНИЕ ОРГАНИЗАЦИИ Оценка Секретариата ЕЭК ООН Приступив к выполнению своих обязанностей на второй срок, Генеральный секретарь ООН выразил свое намерение продолжать процесс укрепления Организации в свет...»

«УДК 821.133.1-311.6 ББК 84(4Фра)-44 Д78 Maurice Druon LA LOUVE DE FRANCE Originally published under the title "LES ROIS MAUDITS" including: Vol. 5: LA LOUVE DE FRANCE © 1966 by Maurice Druon, Librairie Plon...»








 
2017 www.lib.knigi-x.ru - «Бесплатная электронная библиотека - электронные материалы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.