Network Working Group D. Stebila
Request for Comments: 5656 Queensland University of Technology
Category: Standards Track J. Green
Queen's University
December 2009
Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
Интеграция алгоритмов на основе эллиптической кривой с транспортным протоколом SSH
Аннотация
В документе описаны основанные на криптографии эллиптических кривых (Elliptic Curve Cryptography или ECC) алгоритмы для использования с транспортным протоколом Secure Shell (SSH). В частности, задано согласование ключей ECDH (Elliptic Curve Diffie-Hellman) и ECMQV (Elliptic Curve Menezes-Qu-Vanstone) а также алгоритм цифровой подписи ECDSA (Elliptic Curve Digital Signature Algorithm) для использования в транспортном протоколе SSH.
Статус документа
Данный документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдёте в документе Internet Official Protocol Standards (STD 1). Документ можно распространять без ограничений.
Авторские права
Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права, этот документ не может быть изменён вне рамок процесса IETF Standards и не могут также создаваться производные документы за рамками процесса IETF Standards, за исключением форматирования документа для публикации или перевода с английского языка на другие языки.
1. Введение
Этот документ добавляет в арсенал Secure Shell криптографические алгоритмы на основе эллиптических кривых ECDH (Elliptic Curve Diffie-Hellman) и ECDSA (Elliptic Curve Digital Signature Algorithm), а также семейство защищённых алгоритмов хэширования SHA2. Кроме того, предусмотрена поддержка ECMQV (Elliptic Curve Menezes-Qu-Vanstone).
Благодаря малому размеру ключей и включению в стандарт National Security Agency Suite B, криптография на основе эллиптических кривых (Elliptic Curve Cryptography или ECC) становится широко используемой и привлекательной криптосистемой с открытым ключом.
По сравнению с такими криптосистемами, как RSA, DSA (Digital Signature Algorithm1) и обмен ключами Диффи-Хеллмана (Diffie-Hellman или DH), варианты ECC обеспечивают такой же уровень защиты при меньшем размере ключа. Это показано в приведённой ниже таблице на основе параграфа 5.6.1 в NIST 800-57 [NIST-800-57], где приведены сравнимые размеры ключей для симметричной и асимметричной криптографии в широко известных алгоритмах. L указывает размер поля, N — размер субполя.
|
Симметричный ключ |
Дискретный логарифм (например, DSA, DH) |
RSA |
ECC |
|---|---|---|---|
|
80 |
L = 1024, N = 160 |
1024 |
160-223 |
|
112 |
L = 2048, N = 256 |
2048 |
224-255 |
|
128 |
L = 3072, N = 256 |
3072 |
256-383 |
|
192 |
L = 7680, N = 384 |
7680 |
384-511 |
|
256 |
L = 15360, N = 512 |
15360 |
512+ |
Для реализации этой спецификации требуется знакомство с SSH [RFC4251] [RFC4253] [RFC4250] и ECC [SEC1] (дополнительные сведения о ECC содержатся в [HMV04], [ANSI-X9.62], [ANSI-X9.63]).
Документ сосредоточен на деталях реализации SSH, а спецификации базовых криптоалгоритмов оставлены для других стандартов.
2. Обозначения
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].
Типы данных boolean, byte, uint32, uint64, string, mpint интерпретируются в соответствии с [RFC4251].
Размер набора параметров области эллиптической кривой на первичной (prime) кривой определяется как число битов в двоичном представлении порядка полей, обычно обозначаемого p. Размер на кривой characteristic-2 определяется числом битов в двоичном представлении поля, обычно обозначаемого m. Параметры области эллиптической кривой определяют группу порядка n, генерируемую базовой точкой P.
3. Алгоритм с открытым ключом SSH ECC
Алгоритм с открытым ключом SSH ECC определяется форматом ключа, соответствующим алгоритмом подписи, кодированием подписи и идентификаторами алгоритмов. В этом разделе определяется семейство форматов с открытым ключом ecdsa-sha2-* и соответствующие форматы подписей. Этот формат открытого ключа должна поддерживать каждая совместимая реализация SSH ECC.
3.1. Формат ключа
Все форматы ключей ecdsa-sha2-* используют кодирование
string "ecdsa-sha2-[identifier]"
byte[n] ecc_key_blob
В поле ecc_key_blob применяется кодирование
string [identifier]
string Q
Элемент string [identifier] является идентификатором параметров области эллиптической кривой. Формат строки задан в параграфе 6.1, сведения о рекомендуемых и обязательных наборах параметров для использования с алгоритмами приведены в разделе 10. Q — это открытый ключ, закодированный из точки эллиптической кривой в строку октетов в соответствии с параграфом 2.3.3 в [SEC1] (может применяться сжатие точки). Алгоритм генерации ключей ECC описан в параграфе 3.2 [SEC1]. С учётом некоторых параметров области эллиптической кривой может быть создана пара ECC из секретного (целое число d) и открытого (точка эллиптической кривой Q) ключей.
3.1.1. Алгоритм подписи
Подпись и проверка выполняются с помощью алгоритма ECDSA, заданного в [SEC1]. Должен применяться алгоритм хэширования из семейства SHA2 [FIPS-180-3], выбираемый по размеру кривой, как указано в параграфе 6.2.1.
3.1.2. Кодирование подписи
Кодирование подписи показано ниже.
string "ecdsa-sha2-[identifier]"
string ecdsa_signature_blob
Строка [identifier] указывает идентификатор параметров области эллиптической кривой в формате, заданном в параграфе 6.1. Сведения о рекомендуемых и обязательных наборах параметров для использования с алгоритмами приведены в разделе 10. Кодирование значения ecdsa_signature_blob представлено ниже.
mpint r
mpint s
Целые числа r и s являются выводом алгоритма ECDSA. Размер целочисленных полей определяется используемой кривой. Отметим, что r и s являются целыми числами по модулю порядка криптографической подгруппы, который может быть больше размера конечного поля.
4. Обмен ключами ECDH
Метод обмена ключами ECDH создаёт общий секрет из эфемерного секретного ключа локальной эллиптической кривой и эфемерного открытого ключа удалённой эллиптической кривой. Этот метод обеспечивает явную аутентификацию сервера, как указано в [RFC4253], с использованием подписи в хэше обмена. Обмен ключами ECDH должна поддерживать каждая совместимая реализация SSH ECC.
Примитивом, используемым для генерации общего ключа, является произведение ECDH и сомножителя, полная спецификация которого содержится в параграфе 3.3.2 [SEC1]. Алгоритм генерации пары ключей описан в параграфе 3.2.1 [SEC1].
Семейство имён методов для использования в этом обмене ключами описано в параграфе 6.3. При согласовании выбирается алгоритм подписи с открытым ключом и имя метода обмена ключами, которые определяют параметры области эллиптической кривой, которая используется ниже. Сведения о рекомендуемых и обязательных наборах параметров для использования с алгоритмами приведены в разделе 10.
Все открытые ключи эллиптической кривой должны проверяться после получения. Пример алгоритма проверки представлен в параграфе 3.2.2 [SEC1]. Если проверка не прошла, обмен ключами должен завершаться отказом.
Ключи эллиптической кривой (точки) для передачи кодируются перед отправкой в строку октетов. Преобразования между точками и строками октетов описаны в параграфах 2.3.3 и 2.3.4 [SEC1] (может применяться сжатие точек). Результатом генерации общего ключа является элемент поля xp. SSH требует, чтобы общие ключи были целочисленными значениями, преобразования между элементами поля и целыми числами описаны в параграфе 2.3.9 [SEC1].
Номера сообщений SSH_MSG_KEX_ECDH_INIT и SSH_MSG_KEX_ECDH_REPLY указаны в разделе 7.
Ниже показан процесс обмена ключами.
Клиент Сервер
Генерация эфемерной пары ключей.
SSH_MSG_KEX_ECDH_INIT -------------->
Проверка полученного ключа.
Генерация эфемерной пары ключей.
Расчёт общего секрета.
Генерация и подписание хэша обмена.
<-------------- SSH_MSG_KEX_ECDH_REPLY
Проверка полученного ключа.
Проверка принадлежности ключа хоста серверу2.
Расчёт общего секрета.
Генерация хэша обмена.
Проверка подписи сервера.
Обмен реализуется с использованием показанных ниже сообщений.
Сообщение от клиента
byte SSH_MSG_KEX_ECDH_INIT
string Q_C - строка октетов эфемерного открытого ключа клиента
Отклик сервера
byte SSH_MSG_KEX_ECDH_REPLY
string K_S - открытый ключ серверного хоста
string Q_S - строка октетов эфемерного открытого ключа сервера
string подпись хэша обмена
Хэш обмена H рассчитывается для конкатенации приведённых ниже значений.
string V_C - строка идентификации клиента (без CR и LF)
string V_S - строка идентификации сервера (без CR и LF)
string I_C - содержимое клиентского SSH_MSG_KEXINIT
string I_S - содержимое серверного SSH_MSG_KEXINIT
string K_S - открытый ключ серверного хоста
string Q_C - строка октетов эфемерного открытого ключа клиента
string Q_S - строка октетов эфемерного открытого ключа сервера
mpint K - общий секрет
5. Обмен ключами ECMQV
Алгоритм обмена ключами ECMQV генерирует общий секрет из двух локальных пар ключей эллиптической кривой и двух удалённых открытых ключей. Этот метод обеспечивает неявную аутентификацию сервера, как указано в [RFC4253] [RFC4253]. Метод обмена ключами ECMQV является необязательным. Этот метод обмена ключами именуется ecmqv-sha2 и задаёт алгоритм хэширования, который ниже используется для хэшированного кода аутентификации сообщений (Hashed Message Authentication Code или HMAC). В будущих RFC могут быть заданы новые имена методов с новыми алгоритмами хэширования для ECMQV. Дополнительные сведения об имени метода и HMAC приведены в параграфе 6.4.
В общем случае обмен ключами ECMQV выполняется с использованием эфемерных и долгосрочных пар ключей клиента и сервера (всего 4 ключа). В SSH у клиента нет долгосрочной пары ключей, которые требуется аутентифицировать. Поэтому в качестве обоих ключей используется сгенерированный эфемерный ключ. Это более эффективно, чем использование двух разных эфемерных ключей, и не оказывает негативного влияния на безопасность (как в однопроходном протоколе из параграфа 6.1 в [LMQSV98]). Полное описание примитива ECMQV представлено в параграфе 3.4 [SEC1], генерация ключевых пар описана в параграфе 3.2.1 [SEC1].
В процессе согласования алгоритма с помощью сообщений SSH_MSG_KEXINIT метод обмена ключами ECMQV может быть выбран лишь в том случае, когда можно выбрать также алгоритм с открытым ключом, поддерживающий ключи ECC для хостов. Это связано с использованием в этом методе неявной аутентификации сервера. Этот случай обрабатывается так же, как обмены ключами, требующие использования алгоритмов с открытым ключом, поддерживающих шифрование и подписи, как описано в параграфе 7.1 [RFC4253]. При выборе обмена ключами ECMQV должен выбираться также алгоритм с открытым ключом, поддерживающий ключи ECC для хостов.
ECMQV требует, чтобы все ключи, применяемые при создании общего секрета, генерировались с использованием одних и тех же параметров области эллиптической кривой. Поскольку при создании общего секрета применяются ключи хостов, позволяющие проверить подлинность сервера неявно, в этом параграфе используются параметры области, связанные с ключами хостов.
Все открытые ключи эллиптической кривой должны проверяться после получения. Пример алгоритма проверки представлен в параграфе 3.2.2 [SEC1]. Если проверка не прошла, обмен ключами должен завершаться отказом.
Ключи эллиптической кривой (точки) для передачи кодируются перед отправкой в строку октетов. Преобразования между точками и строками октетов описаны в параграфах 2.3.3 и 2.3.4 [SEC1] (может применяться сжатие точек). Результатом генерации общего ключа является элемент поля xp. SSH требует, чтобы общие ключи были целочисленными значениями, преобразования между элементами поля и целыми числами описаны в параграфе 2.3.9 [SEC1].
Ниже показан процесс обмена ключами.
Клиент Сервер
Генерация эфемерной пары ключей.
SSH_MSG_KEX_ECMQV_INIT ------------->
Проверка полученного ключа.
Генерация эфемерной пары ключей.
Расчёт общего секрета.
Генерация хэша обмена и расчёт для
него HMAC с использованием общего секрета.
<------------- SSH_MSG_KEX_ECMQV_REPLY
Проверка полученного ключа.
Проверка принадлежности ключа хоста серверу3.
Расчёт общего секрета.
Проверка HMAC.
Номера сообщений SSH_MSG_ECMQV_INIT и SSH_MSG_ECMQV_REPLY указаны в разделе 7.
Обмен реализуется с использованием показанных ниже сообщений.
Сообщение от клиента
byte SSH_MSG_ECMQV_INIT
string Q_C - строка октетов эфемерного открытого ключа клиента
Отклик сервера
byte SSH_MSG_ECMQV_REPLY
string K_S - открытый ключ серверного хоста
string Q_S - строка октетов эфемерного открытого ключа сервера
string тег HMAC для H с использованием общего секрета
Хэш H рассчитывается по алгоритму HASH для конкатенации приведённых ниже значений.
string V_C - строка идентификации клиента (без CR и LF)
string V_S - строка идентификации сервера (без CR и LF)
string I_C - содержимое клиентского SSH_MSG_KEXINIT
string I_S - содержимое серверного SSH_MSG_KEXINIT
string K_S - открытый ключ серверного хоста
string Q_C - строка октетов эфемерного открытого ключа клиента
string Q_S - строка октетов эфемерного открытого ключа сервера
mpint K - общий секрет
6. Имена методов
Этот документ определяет новое семейство имён методов обмена ключами, новое имя метода обмена и новое семейство имён алгоритмов с открытым ключом в реестре имён SSH.
6.1. Идентификаторы параметров области эллиптической кривой
В этом разделе заданы идентификаторы параметров области эллиптической кривой, которые применяются в документе для указания кривых, используемых в формате открытых ключей SSH ECC, блобов подписи ECDSA и имён методов ECDH. Для обязательных эллиптических кривых nistp256, nistp384, nistp521 такими идентификаторами являются nistp256, nistp384 и nistp521.
Для остальных эллиптических кривых, включая все кривые NIST и другие рекомендуемые кривые, идентификаторы параметров области эллиптической кривой представляются в нотации ASN.1 (Abstract Syntax Notation One) [ASN1]) десятичными значениями (в кодировке ASCII) через точку идентификаторов объектов (Object Identifier или OID) для параметров области именованной кривой, связанных с ключами ECC серверного хоста. Идентификаторы определяются с условием, что размер конкатенации идентификаторов формата открытого ключа (или имени метода) и параметров области эллиптической кривой не превышает максимум, заданный архитектурой протокола SSH [RFC4251] (64 символа). В противном случае идентификатор данной кривой будет не определён, а кривая не будет поддерживаться данной спецификацией.
Список обязательных и рекомендуемых кривых с их OID приведён в разделе 10.
Отметим, что в реализациях должны применяться строковые идентификаторы для всех трёх обязательных кривых NIST даже при наличии у них OID.
6.2. Алгоритм ECC с открытым ключом (ecdsa-sha2-*)
Алгоритм SSH ECC с открытым ключом задаётся семейством идентификаторов формата открытых ключей. Каждый идентификатор указывается конкатенацией строки ecdsa-sha2- с идентификатором параметров области эллиптической кривой, заданным в параграфе 6.1. Список обязательных и рекомендуемых кривых с их OID приведён в разделе 10. Например, именем метода для алгоритма SSH ECC с
открытым ключом, использующего кривую
nistp256, будет ecdsa-sha2-nistp2564.
6.2.1. Алгоритм цифровой подписи на основе эллиптической кривой
Алгоритм ECDSA задан для применения с алгоритмом открытых ключей SSH ECC. Алгоритмами хэширования, заданными этим семейством имён методов, являются алгоритмы семейства SHA2 [FIPS-180-3]. Выбор алгоритма из семейства SHA2 определяется размером именованной кривой, заданной в открытом ключе.
|
Размер кривой |
Алгоритм хэширования |
|---|---|
|
b <= 256 |
SHA-256 |
|
256 < b <= 384 |
SHA-384 |
|
384 < b |
SHA-512 |
6.3. Имена методов обмена ключами ECDH (ecdh-sha2-*)
Обмен ключами ECDH определяется семейством имён методов, каждое из которых является конкатенацией строки ecdh-sha2- и идентификатора параметров области эллиптической кривой, как указано в параграфе 6.1. Список обязательных и рекомендуемых кривых с их OID приведён в разделе 10. Например, именем метода обмена ключами ECDH с эфемерными ключами, генерируемыми по кривой sect409k1, будет ecdh-sha2-1.3.132.0.36.
Алгоритмами хэширования, заданными этим семейством имён методов, являются алгоритмы семейства SHA2 [FIPS-180-3]. Алгоритм хэширования для этих методов определён так, чтобы оставить место для других алгоритмов в будущих документах. Выбор алгоритма из семейства SHA2 определяется размером именованной кривой, заданной в открытом ключе, как показано в таблице из параграфа 6.2.1.
Конкатенации ecdh-sha2- с любыми ASN.1 OID, задающими набор параметров области эллиптической кривой, неявно регистрируются в соответствии с этой спецификацией.
6.4. Имя метода обмена ключами и верификации ECMQV (ecmqv-sha2)
Обмен ключами ECMQV определяется методом ecmqv-sha2. В отличие от обмена ECDH, метод ECMQV основан на алгоритме с открытым ключом, использующем ключи ECC, и ему не требуется имя семейства методов, поскольку сведения о кривой можно получить из алгоритма с открытым ключом.
Алгоритмы хэширования и кода аутентификации сообщений определены в этом методе так, чтобы оставить место для других алгоритмов, используемых с ECMQV в будущих документах.
Алгоритмами хэширования, заданными этим семейством имён методов, являются алгоритмы семейства SHA2 [FIPS-180-3]. Выбор алгоритма из семейства SHA2 определяется размером именованной кривой, заданной в открытом ключе, как показано в таблице из параграфа 6.2.1.
Хэшированный с ключом код аутентификации сообщения, служащий для идентификации сервера и проверки коммуникаций, основывается на выбранном выше хэше. Сведения о реализации HMAC на основе выбранного алгоритма можно найти в [RFC2104].
7. Сообщения обмена ключами
Сообщения с номерами 30 — 49 предназначены для обмена ключами и относятся к частному пространству имён, определённому в [RFC4250], которое может быть переопределено любым методом обмена ключами [RFC4253] без регистрации в IANA. В следующих параграфах указаны сообщения, определённые этим документом.
7.1. Номера сообщений ECDH
#define SSH_MSG_KEX_ECDH_INIT 30
#define SSH_MSG_KEX_ECDH_REPLY 31
7.2. Номера сообщений ECMQV
#define SSH_MSG_ECMQV_INIT 30
#define SSH_MSG_ECMQV_REPLY 31
8. Вопросы управляемости
В этом документе рассмотрены новые алгоритмы с открытым ключом и методы обмена ключами в существующей архитектуре Secure Shell, поэтому возникают несколько соображений по обеспечению управляемости в дополнение к тем, которые применимы к имеющимся реализациям Secure Shell. Эти вопросы рассматриваются ниже.
8.1. Управление функциями через настройку и правила
В разделе 10 указаны обязательные и рекомендуемые параметры области эллиптической кривой для использования с алгоритмами и методами обмена ключами, определёнными в этом документе. Разработчикам следует предоставлять системному администратору возможность отключения запрета кривых (включая обязательные и рекомендуемые) в соответствии с локальной политикой безопасности.
8.2. Влияние на работу сети
Этот документ расширяет функциональность архитектуры Secure Shell и его единственным влиянием на сетевые операции является воздействие на имеющиеся реализации Secure Shell. Протокол Secure Shell обеспечивает механизмы согласования алгоритмов с открытым ключом и методов обмена ключами. Реализации, не распознающие определённые здесь алгоритмы и методы, будут игнорировать их в процессе согласования и выбирать следующий алгоритм или метод, поддерживаемый обеими сторонами, поэтому негативного влияния на совместимость с прежними версиями не возникает.
Использование криптографии на основе эллиптических кривых не должно вносить существенную вычислительную нагрузку на реализующий такую криптографию сервер. На деле, благодаря меньшим размерам ключей, криптография на основе эллиптических кривых может быть реализована при том же уровне безопасности более эффективно, чем RSA, Diffie-Hellman в конечном поле или DSA.
9. Вопросы безопасности
В этом документе представлены новые алгоритмы с открытым ключом и новые методы согласования ключей для протокола Secure Shell. По большей части к ним применимы соображения безопасности, связанные с использованием Secure Shell. Кроме того, при реализации следует учитывать соображения безопасности для криптографии с эллиптическими кривыми.
Для всех трёх классов функциональности, добавленных в этом документе (алгоритмы с открытым ключом, включающие ECDSA, обмен ключами, включающий ECDH, и аутентифицированный обмен ключами, включающий ECMQV), наиболее известным сегодня методом взлома криптосистем является решение задачи дискретного логарифма на эллиптической кривой (elliptic curve discrete logarithm problem или ECDLP). Сложность этого зависит от размера и качества параметров эллиптической кривой и некоторые типы кривых могут быть более подвержены атакам, чем другие. Например, кривые над конечными полями GF(2^m), где m — составное число, могут быть более подвержены атакам на основе снижения Вейля. Для всех кривых, рекомендованных в разделе 10, такой проблемы не возникает. Системным администраторам следует проявлять осторожность при выборе кривых, не указанных в разделе 10, и более детально исследовать безопасность выбираемых кривых.
Считается (см., например, параграф B.2.1 в [SEC1]), что при случайной генерации параметров кривые будут устойчивы к специальным атакам и нужно учитывать более общие атаки. Все обязательные кривые из раздела 10 были сгенерированы проверяемым псевдослучайным образом. Время выполнения (runtime) атак общего назначения зависит от используемого алгоритма. В настоящее время наиболее известен алгоритм Ро Полларда (Pollard-rho)5.
На основе прогнозов вычислительной мощности можно оценить время выполнения наиболее известных атак, исходя из размера конечного поля. В таблице раздела 1 приведены оценки эквивалентности размера симметричных ключей и поля эллиптической кривой. Грубо говоря, эллиптическая кривая с N битов столь же безопасна, как симметричный шифр с ключом N/2 битов. Поэтому 256-битовая эллиптическая кривая (например, обязательная кривая nistp256) подходит, например, для использования со 128-битовым ключом AES.
По многим оценкам выполнение 280-290 операций представляется нереальным, поэтому предлагается использовать эллиптические кривые размером не менее 160-180 битов. Обязательные кривые в этом документе имеют 256, 384 и 521 битов. Разработчикам не следует применять кривые меньше 160 битов. Вопросы безопасности, связанные с параметрами области эллиптической кривой и алгоритмами ECDH, ECDSA, ECMQV, рассмотрены в Приложении B к [SEC1].
Методы обмена ключами, заданные в этом документе, основаны на семействе хэш-функций SHA2, определённом в [FIPS-180-3]. Изложенные в упомянутом документе соображения безопасности применимы и здесь. Хотя в предшественнике (SHA-1) обнаружены некоторые недостатки, их не отмечено в SHA2. Семейство SHA2 содержит 4 варианта — SHA-224, SHA-256, SHA-384, SHA-5126, названные по размерам их дайджестов. В отсутствие специальных атак, использующих структуру хэш-функции, сложность обнаружения коллизий, прообразов и вторых прообразов для хэш-функции определяется размером дайджеста. В параграфе 6.2.1 указано, какой из вариантов SHA2 следует использовать с каким размером эллиптической кривой, на основе этой рекомендации.
Поскольку ECDH и ECMQV допускают эллиптические кривые произвольного размера и, следовательно, произвольной стойкости, важно выбирать размер эллиптической кривой в соответствии со стойкостью других элементов согласования SSH. В частности, размер ключей хостов, алгоритмы хэширования и массового шифрования должны выбираться подобающим образом. Сведения об оценочной эквивалентности размеров ключей приведены в [NIST-800-57]. Актуально также обсуждение в [RFC3766]. Отметим, в частности, что при использовании алгоритма подписи ECDSA и метода обмена ключами ECDH с разными размерами кривых можно применять разные функции семейства SHA2.
Считается, что обязательные и рекомендуемые кривые из этого документа обеспечивают уровень безопасности, указанный в этом разделе и таблице раздела 1. Системным администраторам и разработчикам следует внимательно относиться к вопросам безопасности при включении других кривых. Не все эллиптические кривые безопасны даже при большом поле. При внедрении следует обеспечивать создание эфемерных секретных ключей и иных случайных значений, включая k для подписей ECDSA и значения эфемерных секретных ключей для ECDH и ECMQV, с помощью генератора случайных чисел или генератора псевдослучайных чисел с подобающей затравкой (seed), защищённого от утечки, предотвращение повторного использования значений вне контекста описанного здесь протокола и удаление значений из памяти, когда они становятся ненужными.
10. Именованные параметры области эллиптической кривой
Реализации могут поддерживать любые идентификаторы объекта ASN.1 OID из дерева объектов ASN.1, который определяет набор параметров области эллиптической кривой [ASN1].
10.1. Обязательные кривые
Каждая реализация SSH ECC должна поддерживать указанные в таблице кривые, которые определены в [SEC2]. Кривые NIST исходно заданы в [NIST-CURVES]. Эти кривые следует разрешать всегда, если они явно не отключены локальной политикой безопасности.
|
NIST7 |
SEC |
OID |
|---|---|---|
|
nistp256 |
secp256r1 |
1.2.840.10045.3.1.7 |
|
nistp384 |
secp384r1 |
1.3.132.0.34 |
|
nistp521 |
secp521r1 |
1.3.132.0.35 |
10.2. Рекомендуемые кривые
Реализациям SSH ECC рекомендуется поддерживать указанные ниже кривые, которые определены в [SEC2].
|
NIST |
SEC |
OID8 |
|---|---|---|
|
nistk163 |
sect163k1 |
1.3.132.0.1 |
|
nistp192 |
secp192r1 |
1.2.840.10045.3.1.1 |
|
nistp224 |
secp224r1 |
1.3.132.0.33 |
|
nistk233 |
sect233k1 |
1.3.132.0.26 |
|
nistb233 |
sect233r1 |
1.3.132.0.27 |
|
nistk283 |
sect283k1 |
1.3.132.0.16 |
|
nistk409 |
sect409k1 |
1.3.132.0.36 |
|
nistb409 |
sect409r1 |
1.3.132.0.37 |
|
nistt571 |
sect571k1 |
1.3.132.0.38 |
11. Взаимодействие с IANA
В соответствии с разделом 8 в [RFC4251] и параграфом 4.6 в [RFC4250] этот документ вносит ряд изменений,
В реестр Public Key Algorithm Names добавляется семейство имён алгоритмов SSH с открытым ключом, начинающихся с ecdsa-sha2- и не включающих символ @, для алгоритмов с открытым ключом, заданных в разделе 3.
В реестр Key Exchange Method Names добавляется семейство имён алгоритмов SSH с открытым ключом, начинающихся с ecdh-sha2- и не включающих символ @, для алгоритмов с открытым ключом, заданных в разделе 4.
В реестр Key Exchange Method Names добавляется имя метода обмена ключами SSH ecmqv-sha2, описанного в разделе 5.
Документ не добавляет новых реестров.
12. Литература
12.1. Нормативные документы
[ASN1] International Telecommunications Union, «Abstract Syntax Notation One (ASN.1): Specification of basic notation», X.680, July 2002.
[FIPS-180-3] National Institute of Standards and Technology, «Secure Hash Standard», FIPS 180-3, October 2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
[RFC3766] Orman, H. and P. Hoffman, «Determining Strengths For Public Keys Used For Exchanging Symmetric Keys», BCP 86, RFC 3766, April 2004.
[RFC4250] Lehtinen, S. and C. Lonvick, «The Secure Shell (SSH) Protocol Assigned Numbers», RFC 4250, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Protocol Architecture», RFC 4251, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, January 2006.
[SEC1] Standards for Efficient Cryptography Group, «Elliptic Curve Cryptography», SEC 1, May 2009, <http://www.secg.org/sec1-v2.pdf>9.
[SEC2] Standards for Efficient Cryptography Group, «Recommended Elliptic Curve Domain Parameters», SEC 2, September 2000, <http://www.secg.org/SEC2-Ver-1.0.pdf>10.
12.2. Дополнительная литература
[ANSI-X9.62] American National Standards Institute, «Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)», ANSI X9.62, 1998.
[ANSI-X9.63] American National Standards Institute, «Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography», ANSI X9.63, January 1999.
[HMV04] Hankerson, D., Menezes, A., and S. Vanstone, «Guide to Elliptic Curve Cryptography», Springer ISBN 038795273X, 2004.
[LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. Vanstone, «An Efficient Protocol for Authenticated Key Agreement», University of Waterloo Technical Report CORR 98-05, August 1998, <http://www.cacr.math.uwaterloo.ca/techreports/1998/corr98-05.pdf>.
[NIST-800-57] National Institute of Standards and Technology, «Recommendation for Key Management — Part 1: General (Revised)», NIST Special Publication 800-57, March 2007.
[NIST-CURVES] National Institute of Standards and Technology, «Recommended Elliptic Curves for Federal Government Use», July 1999.
Приложение A. Благодарности
Авторы благодарны за полезные замечания James Blaisdell, David Harrington, Alfred Hoenes, Russ Housley, Jeffrey Hutzelman, Kevin Igoe, Rob Lambert, Jan Pechanek, Tim Polk, Sean Turner, Nicolas Williams, а также участникам почтовой конференции ietf-ssh@netbsd.org.
Адреса авторов
Douglas Stebila
Queensland University of Technology
Information Security Institute
Level 7, 126 Margaret St
Brisbane, Queensland 4000
Australia
EMail: douglas@stebila.ca
Jon Green
Queen’s University
Parallel Processing Research Laboratory
Department of Electrical and Computer Engineering
Room 614, Walter Light Hall
Kingston, Ontario K7L 3N6
Canada
EMail: jonathan.green@queensu.ca
Перевод на русский язык
Николай Малых
1Алгоритм цифровой подписи.
2Клиенту рекомендуется удостовериться, что ключ передавшего хоста является ключом хоста сервера (например, по локальной базе данных). Клиент может воспринимать ключ хоста без проверки, но это делает протокол не защищённым от активных атак (см. параграф 4.1 в [RFC4251]).
3Клиенту рекомендуется удостовериться, что ключ передавшего хоста является ключом хоста сервера (например, по локальной базе данных). Клиент может воспринимать ключ хоста без проверки, но это делает протокол не защищённым от активных атак (см. параграф 4.1 в [RFC4251]).
4В оригинале было другое предложение. См. https://errata.rfc-editor.org/eid1960/. Прим. перев.
5Алгоритм Шора для квантовых компьютеров может решить ECDLP за полиномиальное время, но в настоящее время больших квантовых компьютеров ещё нет и для их создания требуются масштабные исследования в области физики и техники. Нет точной оценки, когда такие компьютеры появятся, но широко распространено мнение, что до этого пройдёт не менее 20 лет.
6В оригинале ошибочно сказано SHA-521. См. https://errata.rfc-editor.org/eid2710/. Прим. перев.
7Для этих трёх обязательных кривых идентификатором области эллиптической кривой является строка, указанная в первом столбце таблицы (см. параграф 6.1).
8Для этих рекомендуемых кривых идентификатором области эллиптической кривой является строка, указанная в третьем столбце таблицы (ASCII-представление OID, см. параграф 6.1).
9В оригинале указана иная ссылка. См. https://errata.rfc-editor.org/eid4207/. Документ доступен также по ссылке. Прим. перев.
10В оригинале указана иная ссылка. См. https://errata.rfc-editor.org/eid4207/. Документ доступен также по ссылке. Прим. перев.