ГОСТ 28147-89 Набор алгоритмов шифрования для протокола
advertisement
Проект рекомендации RFC.
Предполагаемый статус: информационный
Срок действия истекает: 11 июня 2009 г.
Г. Чудов, ред.
С. Леонтьев, ред.
Компания «КРИПТО-ПРО»
8 декабря 2008 г.
ГОСТ 28147-89 Набор алгоритмов шифрования для протокола безопасности
транспортного уровня (TLS)
draft-chudov-cryptopro-cptls-04
Статус этого документа
Этот проект рекомендации RFC представляется в Группу инженерной поддержки
Интернета (IETF) в полном соответствии с положениями стандартов BCP 78 и BCP 79.
Проекты рекомендаций RFC являются рабочими документами Группы инженерной
поддержки Интернета(IETF), ее областей применения и ее рабочих групп. Обратите
внимание, что другие группы также могут распространять рабочие документы в виде
проектов рекомендаций RFC.
Проекты рекомендаций RFC являются проектными документами, действительными в
течение не более шести месяцев, которые в любое время могут быть обновлены,
заменены или перекрыты другими документами. Проекты рекомендаций RFC
нецелесообразно использовать в качестве справочного материала или ссылаться на
них иначе, чем как на «незавершенный проект».
Список текущих проектов рекомендаций RFC можно получить по адресу
http://www.ietf.org/ietf/1id-abstracts.txt.
Список альтернативных каталогов проектов рекомендаций RFC можно получить по
адресу http://www.ietf.org/shadow.html.
Срок действия этого проекта рекомендации RFC истекает 11 июня 2009 г.
Уведомление об авторских правах
© Доверенные лица IETF и лица, определенные как авторы документа, 2008. Все
права защищены.
Этот документ является объектом прав, лицензий и ограничений, описанных в BCP 78
и правовых положениях IETF, относящимся к документам IETF
(http://trustee.ietf.org/license-info), действующим на момент опубликования
данного документа. Мы настоятельно рекомендуем внимательно ознакомиться с
вышеуказанными документами, поскольку в них описываются ваши права и
накладываемые ограничения в отношении настоящего документа.
Аннотация
Настоящий документ предназначен для регистрации новых наборов алгоритмов
шифрования протокола безопасности транспортного уровня (Transport Layer Security,
TLS) в соответствии с процедурой,
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 1]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
указанной в стандартах протокола TLS. Эти наборы алгоритмов шифрования основаны
на российских государственных криптографических стандартах – открытые ключи в
соответствии со стандартами ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001, алгоритм
шифрования ГОСТ 28147-89 и алгоритм хеширования ГОСТ Р 34.11-94.
Оглавление
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Определения наборов алгоритмов шифрования . . . . . . . .3
2.1. Обмен ключами . . . . . . . . . . . . . . . . . . . . .3
2.2. Псевдослучайная функция, подпись и
хеширование . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Алгоритм шифрования и MAC . . . . . . . . . . . . . . .4
3. Структуры данных и вычисления . . . . . . . . . . . . . .5
3.1. Алгоритмы . . . . . . . . . . . . . . . . . . . . . . .5
3.2. Вычисление ключей . . . . . . . . . . . . . . . . . . .5
3.3. Сертификат сервера . . . . . . . . . . . . . . . . . . 5
3.4. Обмен серверными ключами . . . . . . . . . . . . . . . 5
3.5. Запрос на получение сертификата . . . . . . . . . . . .6
3.6. Сообщение об обмене ключа клиента . . . . . . . . . . .6
3.7. Проверка сертификата . . . . . . . . . . . . . . . . . 8
3.8. Завершение . . . . . . . . . . . . . . . . . . . . . . 9
4. Совместимость . . . . . . . . . . . . . . . . . . . . . .9
5. Вопросы безопасности . . . . . . . . . . . . . . . . . . 9
6. Согласование с IANA . . . . . . . . . . . . . . . . . . .9
7. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Ссылки на нормативные документы . . . . . . . . . . . .10
7.2. Информационные ссылки . . . . . . . . . . . . . . . . .12
Приложение A. Модули ASN.1 . . . . . . . . . . . . . . . . .12
A.1 ГОСТ КриптоПро-TLS . . . . . . . . . . . . . . . . . . .12
Приложение Б. Благодарности . . . . . . . . . . . . . . . . 14
Адреса авторов . . . . . . . . . . . . . . . . . . . . . . .15
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 2]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
1. Введение
В этом документе представлены новые дополнительные наборы алгоритмов шифрования
к протоколу безопасности транспортного уровня (Transport Layer Security, TLS)
для поддержки хеширования ГОСТ Р 34.11-94, шифрования ГОСТ 28147-89 и алгоритмов
обмена ключами ГОСТ Р ВКО 34.10-94/2001. Определенные тут наборы алгоритмов
шифрования были предложены компанией «КРИПТО-ПРО» для участников Соглашения о
совместимости криптографических средств российских разработчиков.
Алгоритмы ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001, ГОСТ 28147-89 и ГОСТ Р 34.11-94
разработаны Российским федеральным агентством правительственной связи и
информации (ФАПСИ) и Всероссийским научно-исследовательским институтом
стандартизации. Они описаны в [GOSTR341094], [GOSTR341001], [GOSTR341194] и
[GOST28147] ([GOST3431095], [GOST3431004], [GOST3431195]).
Алгоритмы ВКО ГОСТ Р 34.10-94/2001 и PRF_GOSTR3411 описаны в [CPALGS].
В этом документе определяются две конфигурации: анонимный клиент –
аутентифицированный сервер (сертификат предоставляет только сервер);
аутентифицированный клиент - аутентифицированный сервер (клиент и сервер
обмениваются сертификатами).
Используемый здесь язык представления такой же, как и в [TLS1.2].
Так как эта спецификация расширяет [TLS1.2], эти описания должны быть объединены
с теми, которые находятся в спецификации протокола TLS, и всеми другими, которые
расширяют протокол TLS. Это означает, что перечисляемые типы могут не определять
все возможные значения и структуры с множеством форматов, выбранных с помощью
оператора select(). Они могут не отображать все возможные случаи.
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «НУЖНО», «НЕ НУЖНО»,
«СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО»,
встречающиеся в данном документе, следует интерпретировать в соответствии с
положениями [RFC2119].
2. Определения наборов алгоритмов шифрования
2.1. Обмен ключами
Определенные здесь наборы алгоритмов шифрования используют следующие алгоритмы
обмена ключами:
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 3]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
+-------------------------------------+------------------------+
| Набор алгоритмов шифрования | Алгоритм обмена ключами |
+-------------------------------------+------------------------+
| TLS_GOSTR341094_WITH_28147_CNT_IMIT | ВКО ГОСТ Р 34.10-94 |
| TLS_GOSTR341001_WITH_28147_CNT_IMIT | ВКО ГОСТ Р 34.10-2001 |
| TLS_GOSTR341094_WITH_NULL_GOSTR3411 | ВКО ГОСТ Р 34.10-94 |
| TLS_GOSTR341001_WITH_NULL_GOSTR3411 | ВКО ГОСТ Р 34.10-2001 |
+-------------------------------------+------------------------+
Алгоритмы создания производного ключа, основанные на открытых ключах ГОСТ Р
34.10-94 и ГОСТ Р 34.10-2001 (ВКО ГОСТ Р 34.10-94, ВКО ГОСТ Р 34.10-2001),
описаны в [CPALGS].
2.2. Псевдослучайная функция, подпись и хеширование
Описанные здесь наборы алгоритмов шифрования используют псевдослучайные функции
HMAC и TLS в соответствии с описанием, представленным в разделе 5 [TLS1.2], на
основе хеш-функции ГОСТ Р 34.11-94 (HMAC_GOSTR3411 и PRF_GOSTR3411), с набором
параметров, определенным в документе id-GostR3411-94-CryptoProParamSet (см.
[CPALGS]). Те же псевдослучайные функции ДОЛЖНЫ использоваться для всех
соответствующих протоколов, таких как [EAP-TLS].
Подпись ГОСТ Р 34.10-94/2001 используется для сообщения CertificateVerify.
Алгоритм хеширования ГОСТ Р 34.11 ([GOSTR341194]) используется для
CertificateVerify.signature.gostR3411_hash и Finished.verify_data
(см. разделы 7.4.10 и 7.4.11 в [TLS1.2])
2.3. Алгоритм шифрования и MAC
Используются следующие алгоритмы шифрования и MAC-функции (подробнее см. раздел
3.1):
+-------------------------------------+-----------+----------------+
| Наборов алгоритмов шифрования | Алгоритм шифрования | MAC |
+-------------------------------------+-----------+----------------+
| TLS_GOSTR341094_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 |
| TLS_GOSTR341001_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 |
| TLS_GOSTR341094_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 |
| TLS_GOSTR341001_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 |
+-------------------------------------+-----------+----------------+
Для всех четырех наборов алгоритмов шифрования практическое применение МАС
немного отличается от описания, указанного в разделе 6.2.3.1 [TLS1.2] для
стандартных потоковых алгоритмов шифрования, где MAC рассчитывается исходя из
следующих данных:
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 4]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
MACed_data[seq_num] = seq_num +
TLSCompressed.type +
TLSCompressed.version +
TLSCompressed.length +
TLSCompressed.fragment;
Определенные в этом документе наборы алгоритмов шифрования используют одинаковые
входные данные для первой записи, но для каждой последующей записи входные
данные от всех предыдущих записей объединяются:
MACed_data[0] + ... + MACed_data[n]
3. Структуры данных и вычисления
3.1. Алгоритмы
ГОСТ 28147-89 [GOST28147] использует 256-битовый размер ключа и 8-байтовый
вектор инициализации (IV).
Определенные здесь наборы алгоритмов шифрования используют ГОСТ 28147-89 в
качестве потокового алгоритма шифрования в режиме счетчика с параметром S-box из
id-Gost28147-89-CryptoPro-A-ParamSet (см. [CPALGS]) и алгоритм
криптографического преобразования ключа КриптоПро.
IMIT_GOST28147 является ГОСТом 28147-89 [GOST28147] в режиме IMITOVSTAVKA (4
байта)
3.2. Вычисление ключей
Вычисление ключей производится в соответствии с разделом 6.3 [TLS1.2] с
использованием PRF_GOSTR3411. Используются следующие параметры:
SecurityParameters.enc_key_length = 32
SecurityParameters.mac_key_length = 32
SecurityParameters.fixed_iv_length = 8
Длина необходимого ключевого материала составляет 144 байта.
3.3. Сертификат сервера
Для данных наборов алгоритмов шифрования требуется такое сообщение, и оно ДОЛЖНО
содержать сертификат с алгоритмом открытого ключа, соответствующим
ServerHello.cipher_suite.
3.4. Обмен серверными ключами
В этих наборах алгоритмов шифрования данное сообщение использоваться НЕ ДОЛЖНО,
так как все необходимые параметры присутствуют в сертификате сервера (см.
[CPPK]).
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 5]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
3.5. Запрос на получение сертификата
Это сообщение используется в соответствии с описанием, представленным в разделе
7.4.4 [TLS1.2], а также в расширенном виде:
enum {
gostr341094(21), gostr34102001(22),(255)
} ClientCertificateType;
Типы сертификатов gostr341094 и gostr34102001 указывают на то, что сервер
принимает сертификаты открытых ключей ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001.
enum{
gostr3411(XX)
} HashAlgorithm;
enum{
gostr341094(XX), gostr34102001(XX)
} SignatureAlgorithm;
Тип хеширования gostr3411 означает, что сервер принимает функцию хеширования
ГОСТ Р 34.11-94.
В том случае, когда выбран один из описанных в данном документе наборов
алгоритмов шифрования, РЕКОМЕНДУЕТСЯ заполнять
CertificateRequest.certificate_hash только значением gostr3411.
Серверу СЛЕДУЕТ заполнить поле supported_signature_algorithm парами
SignatureAndHashAlgorithm, где HashAlgorithm равно gostr3411, а
SignatureAlgorithm совпадает с соответствующим ClientCertificateType.
3.6. Сообщение об обмене ключа клиента
Это сообщение используется в соответствии с описанием, представленным в разделе
7.4.7 [TLS1.2]. Оно необходимо для данных наборов и содержит DER-кодированную
структуру TLSGostKeyTransportBlob [X.660].
enum { vko_gost } KeyExchangeAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
case vko_gost: TLSGostKeyTransportBlob;
} exchange_keys;
} ClientKeyExchange;
Синтаксис данных ASN1 для этой структуры:
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 6]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
TLSGostKeyTransportBlob ::= SEQUENCE {
keyBlob GostR3410-KeyTransport,
proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL
}
TLSProxyKeyTransportBlob ::= SEQUENCE {
keyBlob GostR3410-KeyTransport,
cert OCTET STRING
}
GostR3410-KeyTransport определен в [CPCMS].
ДОЛЖЕН присутствовать keyBlob.transportParameters.
В том случае, если сервер не запрашивал сертификат клиента или алгоритм и
параметры открытого ключа клиента не совпадают с алгоритмом и параметрами
открытого ключа получателя, то ДОЛЖЕН присутствовать
keyBlob.transportParameters.ephemeralPublicKey, иначе его следует пропустить.
proxyKeyBlobs – (не обязательно) содержит обмен ключами для вторичных
получателей (например, для межсетевого экрана, который проверяет соединения).
cert - содержит сертификат вторичного получателя.
Действия клиента
Сначала клиент генерирует случайное 32-байтовое значение premaster_secret.
Затем shared_ukm вычисляется как первые 8 байт хеш-значения объединенных
случайных значений клиента и сервера:
shared_ukm = GOSTR3411(client_random|server_random)[0..7]
Затем клиент выбирает ключ отправителя. Если
keyBlob.transportParameters.ephemeralPublicKey присутствует, то в качестве ключа
отправителя ДОЛЖЕН быть использован соответствующий секретный ключ. Если он
отсутствует, ДОЛЖЕН использоваться секретный ключ, соответствующий сертификату
клиента.
Для создания ключа шифрования ключей (key-encrypting key, KEK) применяется
алгоритм ВКО ГОСТ Р 34.10-94 или ВКО ГОСТ Р 34.10-2001 (описанные в [CPALGS]).
При этом используются ключ отправителя и открытый ключ получателя. ВКО ГОСТ Р
34.10-2001 используется вместе с shared_ukm в качестве материала ключа
пользователя (UKM).
Затем применяется алгоритм КриптоПро для шифрования premaster_secret CEK_ENC и
генерации CEK_ENC и CEK_MAC. В этом случае shared_ukm также используется в
качестве материала ключа пользователя.
keyBlob.transportParameters.encryptionParamSet используется для всех операций
шифрования.
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 7]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
Полученный зашифрованный ключ (CEK_ENC) помещается в поле
keyBlob.sessionEncryptedKey.encryptedKey, его mac (CEK_MAC) помещается в поле
keyBlob.sessionEncryptedKey.macKey, а shared_ukm (UKM) - в поле
keyBlob.transportParameters.ukm.
Действия сервера:
Сервер ДОЛЖЕН проверить, что keyBlob.transportParameters.ukm равен GOSTR3411
(client_random|server_random)[0..7] до начала расшифровки premaster_secret.
Сервер применяет ВКО ГОСТ Р 34.10-94 или ВКО ГОСТ Р 34.10-2001 (в зависимости от
типа открытого ключа клиента) и аналогичным образом алгоритм расшифровки ключа
КриптоПро для расшифровки premaster_secret.
После расшифровки premaster_secret сервер ДОЛЖЕН проверить
keyBlob.sessionEncryptedKey.macKey.
3.7. Проверка сертификата
Это сообщение используется в соответствии с положениями раздела 7.4.8 [TLS1.2].
Если клиент послал и сертификат клиента, и эфемерный открытый ключ, он ДОЛЖЕН
послать сообщение о проверке сертификата в качестве доказательства владения
закрытым ключом для предоставленного сертификата.
Структуры TLS расширены следующим образом:
enum { gostr341094, gostr34102001 }
SignatureAlgorithm;
select (SignatureAlgorithm) {
case gostr341094:
digitally-signed struct {
opaque gostr341194_hash[32];
};
case gostr34102001:
digitally-signed struct {
opaque gostr341194_hash[32];
};
} Signature;
CertificateVerify.signature.gostR3411_hash =
GOSTR3411(handshake_messages)
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 8]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
3.8. Завершение
Это сообщение используется в соответствии с описанием, приведенным в разделе
7.4.9 из [TLS1.2].
Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label,
GOSTR3411(handshake_messages)) [0..11]
4. Совместимость
По историческим причинам некоторые приложения используют наборы алгоритмов
шифрования, определенные в настоящем документе и в [TLS1.0], частично используя
функционал из [TLS1.2], включая вычисление псевдослучайной функции, зависимой от
набора алгоритмов шифрования, сообщения о завершении и сообщения о проверке
сертификата.
5. Вопросы безопасности
РЕКОМЕНДУЕТСЯ проводить проверку программным обеспечением значения подписи,
открытые ключи субъекта и параметры алгоритма на предмет их соответствия
стандартам [GOSTR341001], [GOSTR341094] до начала их использования.
Использовать один и тот же ключ для подписи и для создания производного ключа НЕ
РЕКОМЕНДУЕТСЯ.
Если данное расширение присутствует в сертификате, и для клиента, и для сервера
РЕКОМЕНДУЕТСЯ выполнять проверку срока использования закрытого ключа.
Предлагаемые здесь наборы алгоритмов шифрования
TLS_GOSTR341094_WITH_28147_CNT_IMIT и TLS_GOSTR341001_WITH_28147_CNT_IMIT были
проанализированы специальной лабораторией сертификации «Научно-технического
центра «Атлас» в соответствии с уровнями target_of_evaluation (TOE).
РЕКОМЕНДУЕТСЯ направить эти наборы алгоритмов шифрования в уполномоченный орган
для рассмотрения с учетом утвержденных методов криптографического анализа.
6. Согласование с IANA
В этом документе определяются следующие новые наборы алгоритмов шифрования,
значения которых используются в нескольких реализациях одних и тех же наборов
алгоритмов шифрования протокола TLS 1.0, и которые были описаны в предыдущих
проектах. В настоящее время они перечислены в реестре в качестве
зарезервированных. Произведен запрос в IANA на обновление реестра набора
алгоритмов шифрования протокола TLS, определенного в [RFC5246] такими значениями.
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 9]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
CipherSuite
CipherSuite
CipherSuite
CipherSuite
TLS_GOSTR341094_WITH_28147_CNT_IMIT
TLS_GOSTR341001_WITH_28147_CNT_IMIT
TLS_GOSTR341094_WITH_NULL_GOSTR3411
TLS_GOSTR341001_WITH_NULL_GOSTR3411
=
=
=
=
{0x00,0x80}
{0x00,0x81}
{0x00,0x82}
{0x00,0x83}
В этом документе определяются следующие новые типы клиентских сертификатов. Их
значения, представленные здесь, используются несколькими реализациями одних и
тех же наборов алгоритмов шифрования протокола TLS 1.0 и описаны в предыдущих
проектах.
В настоящее время они перечислены в реестре в качестве зарезервированных.
Произведен запрос в IANA на обновление реестра идентификаторов TLS
ClientCertificateType, определенного в [RFC5246], такими значениями:
enum {
gostr341094(21), gostr34102001(22)
} ClientCertificateType;
В этом документе определяются следующие новые типы алгоритмов подписи, чьи
значения следует присвоить из реестра TLS SignatureAlgorithm, определенного в
[RFC5246].
enum{
gostr341094(XX), gostr34102001(XX)
} SignatureAlgorithm;
В этом документе определяются следующие новые типы алгоритма хеширования, чьи
значения следует присвоить из реестра TLS HashAlgorithm, определенного в
[RFC5246].
enum {
gostr3411(XX)
} HashAlgorithm;
7. Ссылки
7.1. Ссылки на нормативные документы
[CPALGS] В. Попов, И. Курепкин и С. Леонтьев, «Дополнительные алгоритмы
шифрования для использования с алгоритмами ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ
Р 34.10-2001 и ГОСТ Р 34.11-94», RFC 4357, январь 2006 г.
[CPCMS] С. Леонтьев и Г. Чудов, «Использование алгоритмов ГОСТ 28147-89, ГОСТ Р
34.11-94, ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001 с синтаксисом криптографических
сообщений (CMS)», RFC 4490 , май 2006 г.
[CPPK] С. Леонтьев и Д. Шефановский, «Использование ГОСТ Р
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 10]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94.
Инфраструктура открытого ключа Интернет X.509.
Профиль сертификата инфраструктуры и списка отзыва сертификатов (CLR)», RFC
4491, май 2006 г.
[GOST28147]
Государственный комитет СССР по стандартам, «Системы обработки информации.
Защита криптографическая. Алгоритм криптографического преобразования.
Государственный стандарт СССР (на русском языке)», ГОСТ 28147-89, 1989.
[GOST3431004]
Межгосударственный совет по стандартизации, метрологии и сертификации
Содружества Независимых Государств (EASC), Минск, «Информационная технология.
Криптографическая защита информации.
Процессы формирования и проверки электронной цифровой подписи на базе
асимметричного криптографического алгоритма (на русском языке)», ГОСТ 34.3102004, 2004.
[GOST3431095]
Межгосударственный совет по стандартизации, метрологии и сертификации
Содружества Независимых Государств (EASC), Минск, «Информационная технология.
Криптографическая защита информации.
Процедуры выработки и проверки электронной цифровой подписи на базе
асимметричного криптографического алгоритма (на русском языке)», ГОСТ 34.310-95,
1995.
[GOST3431195]
Межгосударственный совет по стандартизации, метрологии и сертификации
Содружества Независимых Государств (EASC), Минск, «Информационная технология.
Криптографическая защита информации.
Хеш-функция (на русском языке)», ГОСТ 34.311-95, 1995.
[GOSTR341001]
Государственный комитет Российской Федерации по стандартизации, «Информационная
технология. Криптографическая защита информации. Процессы формирования и
проверки электронной цифровой подписи. Государственный стандарт Российской
Федерации (на русском языке)», ГОСТ Р 34.10-2001, 2001.
[GOSTR341094]
Государственный комитет Российской Федерации по стандартизации, «Информационная
технология. Криптографическая защита информации.
Процедуры выработки и проверки электронной цифровой подписи на базе
асимметричного криптографического алгоритма. Государственный стандарт Российской
Федерации (на русском языке)», ГОСТ Р 34.10-94, 1994.
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 11]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
[GOSTR341194]
Государственный комитет Российской Федерации по стандартизации, «Информационная
технология. Криптографическая защита информации.
Хеш-функция. Государственный стандарт Российской Федерации (на русском языке)»,
ГОСТ Р 34.11-94, 1994.
[TLS1.2] Т. Диркс (T. Dierks) и Е. Рескорла (E. Rescorla), «Протокол TLS»,
draft-ietf-tls-rfc4346-bis-01(незавершенная работа), июнь 2006 г.
7.2. Информационные ссылки
[EAP-TLS] Б. Эбоба (Б. Aboba) и Д. Саймон (D. Simon), «Протокол аутентификации
PPP EAP TLS», RFC 2716, октябрь 1999 г.
[RFC2119] С. Браднер (S. Bradner), «Ключевые слова для использования в
рекомендациях RFC для указания уровня требований», стандарт BCP 14, RFC 2119,
март 1997 г.
[TLS1.0] Т. Диркс (Т. Dierks) и С. Аллен (C. Allen), «Протокол TLS версии 1.0»,
RFC 2246, январь 1999 г.
[X.660] ИСО/МЭК, «Рекомендация МСЭ-Т Х.660 Информационная технология - правила
кодирования ASN.1: Спецификация базовых правил кодирования (BER), канонических
правил кодирования (CER) и отличительных правил кодирования (DER)», МСЭ-Т X.660,
1997.
Приложение A. Модули ASN.1
Указанные здесь дополнительные модули ASN.1 можно найти в [CPALGS] и [CPCMS].
A.1 ГОСТ КриптоПро-TLS
ГОСТ КриптоПро-TLS
{ iso(1) member-body(2) ru(643) rans(2)
cryptopro(2) other(1) modules(1) gost-CryptoPro-TLS(16) 1 }
DEFINITIONS ::=
BEGIN
-- Экспорт всех -Типы и значения, определенные в этом модуле, экспортируются для использования в
других модулях ASN.1, содержащихся в российских криптографических спецификациях
«ГОСТ» и «ГОСТ Р», и для использования другими приложениями для получения
доступа к российским службам криптографии. Другие приложения могут использовать
их в своих целях, но это не накладывает никаких ограничений на расширения и
изменения, необходимые для поддержания или улучшения российских служб
криптографии.
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 12]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
IMPORTS
Certificate,
AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}
id-CryptoPro-algorithms, gostR3410-EncryptionSyntax
FROM Cryptographic-Gost-Useful-Definitions
{ iso(1) member-body(2) ru(643) rans(2)
cryptopro(2) other(1) modules(1)
cryptographic-Gost-Useful-Definitions(0) 1 }
GostR3410-KeyTransport
FROM GostR3410-EncryptionSyntax
gostR3410-EncryptionSyntax
;
id-PRF-GostR3411-94 OBJECT IDENTIFIER ::=
{ id-CryptoPro-algorithms prf-gostr3411-94(23) }
TLSProxyKeyTransportBlob ::=
SEQUENCE {
keyBlob GostR3410-KeyTransport,
cert OCTET STRING
}
TLSGostKeyTransportBlob ::=
SEQUENCE {
keyBlob GostR3410-KeyTransport,
proxyKeyBlobs SEQUENCE OF
TLSProxyKeyTransportBlob OPTIONAL
}
TLSGostSrvKeyExchange ::=
SEQUENCE OF
OCTET STRING (CONSTRAINED BY {Certificate})
TLSGostExtensionHashHMACSelect ::=
SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hmacAlgorithm AlgorithmIdentifier,
prfAlgorithm AlgorithmIdentifier
}
TLSGostExtensionHashHMACSelectClient ::=
SEQUENCE OF
TLSGostExtensionHashHMACSelect
TLSGostExtensionHashHMACSelectServer ::=
TLSGostExtensionHashHMACSelect
END -- Gost-CryptoPro-TLS
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 13]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
Приложение Б. Благодарности
Этот документ был создан в соответствии с документом «Соглашение о совместимости
российского криптографического программного обеспечения», подписанным ФГУП «НТЦ
«Атлас», компаниями «КРИПТО-ПРО», «Фактор-ТС», МОПНИЭИ, ОАО «ИнфоТеКС», СПБ РЦЗИ,
«Криптоком», «Р-Альфа». Целью данного соглашения является достижение взаимной
совместимости продуктов и решений.
Авторы выражают благодарность:
- компании Microsoft Corporation Russia за предоставленную информацию о
продуктах и решениях компании, а также за техническую консультацию по
инфраструктуре открытого ключа (PKI);
- компаниям RSA Security Russia и «Демос» за активное сотрудничество и ценное
содействие в создании этого документа;
- компании НИП «Информзащита» за проверку на совместимость предлагаемых форматов
данных при использовании их в продуктах компании;
- компании Citrix Inc за помощь в проверке их продуктов на совместимость с ОС
Microsoft Windows;
- Русу Хаусли (Russ Hously, компания Vigil Security, LLC, housley@vigilsec.com)
и Василию Сахарову (компания «Демос» , svp@dol.ru) за инициативу, проявленную
при создании этого документа.
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 14]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
Адреса авторов
Александр Афанасьев
Фактор-ТС
Пресненский вал, 14, офис 711,
Москва, 123557, Россия
Эл. адрес: afa1@factor-ts.ru
Николай Никишин
ОАО «ИнфоТеКС»
Ленинградский проспект, 80-5, а/я 35,
Москва, 125315, Россия
Эл. адрес: nikishin@infotecs.ru
Болеслав Изотов
ФГУП НТЦ «Атлас»
Ул. Образцова, 38,
Москва, 127018, Россия
Эл. адрес: izotov@nii.voskhod.ru
Елена Минаева
МОПНИЭИ
Второй Троицкий пер., 6А, строение 3
Москва, Россия
Эл. адрес: evminaeva@mail.ru
Сергей Муругов
Р-Альфа
Ул. Расплетина, 4/1,
Москва, 123060, Россия
Эл. адрес: msm@top-cross.ru
Игорь Устинов
Криптоком
Ленинский проспект, 51, офис 239,
Москва, 119991, Россия
Эл. адрес: igus@cryptocom.ru
Анатолий Эркин
СПБ РЦЗИ
Ул. Обручева, 1,
Санкт-Петербург, 195220, Россия
Эл. адрес: erkin@nevsky.net
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 15]
Проект рекомендации RFC. Наборы алгоритмов шифрования ГОСТ для протокола TLS.
Декабрь 2008 г.
Адреса авторов
Григорий С. Чудов (редактор)
ООО «КРИПТО-ПРО»
Сущевский вал, 16/5
Москва, 127018
Россия
Телефон: +7 (495) 780 48 20
Факс: +7 (495) 660 2330
Эл. адрес: chudov@CryptoPro.ru
Сайт: http://www.CryptoPro.ru
Сергей Е. Леонтьев (редактор)
ООО «КРИПТО-ПРО»
Сущевский вал, 16/5
Москва, 127018
Россия
Телефон: +7 (495) 933 11 68
Факс: +7 (495) 933 11 68
Эл. адрес: lse@CryptoPro.ru
Сайт: http://www.CryptoPro.ru
Чудов и Леонтьев. Срок действия: до 11 июня 2009 г. [Страница 16]