Криптографически сгенерированный адрес ( CGA ) представляет собой интернет - протокол версии 6 (IPv6) адрес , который имеет идентификатор хоста , вычисленную из криптографической хэш - функции . [1] Эта процедура представляет собой метод привязки открытого ключа подписи к IPv6-адресу в протоколе обнаружения безопасного соседа (SEND). [2]
Методология
Криптографически сгенерированный адрес формируется путем замены младших 64 битов 128-битного адреса IPv6 криптографическим хешем открытого ключа владельца адреса. Сообщения подписываются соответствующим закрытым ключом. Только если адрес источника и открытый ключ известны, верификатор может аутентифицировать сообщение от соответствующего отправителя. Этот метод не требует инфраструктуры открытого ключа . Допустимые CGA могут быть созданы любым отправителем, включая потенциального злоумышленника, но они не могут использовать какие-либо существующие CGA.
Характеристики
Криптографически сгенерированный адрес - это IPv6-адрес, идентификатор интерфейса которого был сгенерирован в соответствии с методом генерации CGA. Идентификатор интерфейса состоит из 64 младших битов IPv6-адреса и используется для идентификации сетевого интерфейса хоста в его подсети. Подсеть определяется старшими 64 битами, префиксом подсети.
Формат адреса IPv6 биты 64 64 поле префикс подсети идентификатор интерфейса
Помимо открытого ключа, который должен быть привязан к CGA, метод генерации CGA принимает несколько других входных параметров, включая предопределенный префикс подсети. Эти параметры вместе с другими параметрами, которые генерируются во время выполнения метода генерации CGA, образуют набор параметров, называемый структурой данных параметров CGA. Полный набор параметров CGA должен быть известен, чтобы иметь возможность проверить соответствующий CGA.
Структура данных CGA Parameters состоит из:
modifier
: случайное 128-битное целое число без знака ;subnetPrefix
: 64-битный префикс, определяющий, к какой подсети принадлежит CGA;collCount
: 8-битовое целое число без знака, которое должно быть 0, 1 или 2;publicKey
: открытый ключ в виде структуры ASN.1, закодированной в DER, типа SubjectPublicKeyInfo;extFields
: необязательное поле переменной длины (длина по умолчанию 0).
Кроме того, параметр безопасности Sec
определяет стойкость CGA к атакам методом грубой силы . Это 3-битовое целое число без знака, которое может иметь любое значение от 0 до 7 (включительно) и закодировано в трех крайних левых битах идентификатора интерфейса CGA. Чем выше значение Sec
, тем выше уровень безопасности, но и тем больше времени обычно требуется для создания CGA. Для удобства Sec
предполагается , что промежуточные значения в псевдокоде ниже хранятся как 8-битовые целые числа без знака, которые не могут иметь значение больше 7.
Метод генерации CGA
Следующий фрагмент псевдокода представляет метод генерации CGA, который используется для создания нового криптографически сгенерированного адреса.
1 процедура generateCGA ( Sec , subnetPrefix , publicKey , extFields ): 2 модификатор : = random (0x00000000000000000000000000000000, // 16 октетов (128 бит) 3 0xffffffffffffffffffffffffffffff) 4 5 label1 : 6 concat : = concatenate ( модификатор , 0x000000000000000000, // 9 нулевых октетов 7 publicKey , extFields ) 8 9 дайджест : = SHA1 ( concat )10 Hash2 : = digest [0:14] // 14 * 8 = 112 крайних левых бит1112, если Sec ≠ 0 и Hash2 [0: 2 * Sec ] ≠ 0: // 2 * Sec * 8 = 16 * Sec крайние левые биты13 модификатор : = модификатор + 114 перейти label115 конец, если1617 collCount : = 0x00 // 8-битный счетчик столкновений1819 label2 :20 concat : = concatenate ( модификатор , subnetPrefix , collCount ,21 publicKey , extFields )22Дайджест 23 : = SHA1 ( concat )24 Hash1 : = digest [0: 8] // 8 * 8 = 64 крайних левых бита2526 intID : = Hash1 // Hash1 становится идентификатором интерфейса ...27 intID [0]: = intID [0] двоичный и 0x1c двоичный или ( Sec << 5) // ... после записи битов Sec и u / g28 год29 CGA : = concatenate ( subnetPrefix , intID ) // объединение для формирования CGA3031 при дублировании ( CGA ):32 collCount : = collCount + 13334, если collCount = 3:35 отменить 36 конец, если3738 перейти label239 конец, если4041 возврат [ CGA , [ модификатор , subnetPrefix , collCount , publicKey , extFields ]]42 конец процедуры
Идентификатор интерфейса CGA в значительной степени формируется Hash1
из первых 64 бит структуры данных переваренных параметров CGA (строки с 20 по 24). В строке 27 первые три бита перезаписываются Sec
значением, а зарезервированные биты «u» и «g» (седьмой и восьмой бит) устанавливаются в 0.
В Sec
реализует параметр расширение хеш путем применения первых 16 раз Sec
биты другой хэш, Hash2
, равным 0. Этот хэш является результатом расщепленной структуры данных CGA Параметры с subnetPrefix
и по collCount
существу установлен на 0. А полный перебор выполняется , чтобы найти подходящий Hash2
, увеличивая на modifier
1 каждую итерацию (строки с 6 по 15). Поскольку большее количество битов должно быть равным 0 с более высоким Sec
значением, среднее время, необходимое для выполнения поиска, увеличивается экспоненциально с увеличением значения Sec
.
После объединения префикса подсети и сгенерированного идентификатора интерфейса для создания CGA может быть выполнено обнаружение повторяющегося адреса . Если адрес уже используется, счетчик конфликтов collCount
увеличивается на 1 и генерируется новый идентификатор интерфейса (строки с 20 по 39). Поскольку collCount
он не используется при вычислении Hash2
, нет необходимости искать новый Hash2
при возникновении конфликта адресов. По той же причине subnetPrefix
он также не используется, так что если префикс подсети адреса изменяется, а открытый ключ хоста - нет, то тот же модификатор можно использовать повторно, и нет необходимости искать новый Hash2
.
В строке 41 возвращается CGA вместе со структурой данных CGA Parameters.
Метод проверки CGA
Криптографически сгенерированный адрес используется для проверки того, что полученные подписанные сообщения были отправлены хостом, которому был назначен этот адрес. Это делается путем проверки того, что пара ключей, используемая для подписи, привязана к CGA. Поскольку таким способом можно проверить подлинность открытого ключа, нет необходимости в инфраструктуре открытого ключа. Однако, если сам хост также должен быть аутентифицирован, тогда сам CGA должен быть аутентифицирован заранее, поскольку связанный открытый ключ не может быть доверенным, если адрес не является доверенным в таком случае (при условии, что он не был проверен другими методы, чем CGA).
Метод проверки CGA, при котором проверяется привязка открытого ключа к CGA, требует соответствующей структуры данных CGA Parameters в качестве входных данных и может быть реализован следующим образом.
1 процедура verifyCGA ( CGA , [ модификатор , subnetPrefix , collCount , publicKey , extFields ]): 2, если collCount > 2 или CGA [0: 8] ≠ subnetPrefix : 3 вернуть ложь 4 конец, если 5 6 concat : = concatenate ( модификатор , subnetPrefix , collCount , 7 publicKey , extFields ) 8 9 дайджест : = SHA1 ( concat )10 Hash1 : = digest [0: 8] // 8 * 8 = 64 крайних левых бита11 Hash1 [0]: = Hash1 [0] binary and 0x1c // игнорировать биты Sec и u / g1213 intID : = CGA [8:16] // идентификатор интерфейса (64 крайних правых бита)14 intID [0]: = intID [0] binary и 0x1c // игнорировать биты Sec и u / g1516, если Hash1 ≠ intID :17 вернуть ложь18 конец, если1920 сек : = CGA [8] >> 5 // извлекаем сек из идентификатора интерфейса21 год22 concat : = concatenate ( модификатор , 0x000000000000000000, // 9 нулевых октетов23 publicKey , extFields )24Дайджест 25 : = SHA1 ( concat )26 Hash2 : = digest [0:14] // 14 * 8 = 112 крайних левых бит2728, если Sec ≠ 0 и Hash2 [0: 2 * Sec ] ≠ 0: // 2 * Sec * 8 = 16 * Sec крайние левые биты29 вернуть ложь30 конец, если31 год32 return true // проверка прошла успешно33 окончание процедуры
Метод начинается с проверки того, имеет ли collCount
структура данных параметров CGA допустимое значение и subnetPrefix
совпадает ли из той же структуры данных с префиксом подсети CGA (в строке 2). Это сделано из соображений безопасности .
В строках 6–18 Hash1
вычисляется структура данных параметров CGA (которая включает открытый ключ и префикс подсети), и соответствующие биты сравниваются с битами идентификатора интерфейса CGA. В этом случае это делается путем установки первых трех битов ( Sec
), седьмого и восьмого бита (биты «u» и «g») обоих Hash1
и идентификатора интерфейса на 0 в строках 11 и 14 для облегчения сравнения.
После извлечения Sec
из идентификатора интерфейса CGA Hash2
вычисляется, и первые 16 Sec
разрядов хэша сравниваются с 0 (строки с 22 по 30). Если все проверки прошли успешно, значит, открытый ключ был проверен на привязку (т. Е. На то, что он действителен) для этого CGA.
Безопасность
Чтобы злоумышленник убедил клиента, что он получил действительное сообщение от определенного CGA, который не принадлежит злоумышленнику, злоумышленник должен найти хэш-коллизию для соответствующих битов Hash1
и Hash2
выполнить атаку грубой силы . Если злоумышленник находит набор параметров CGA (включая открытый ключ, для которого злоумышленник знает закрытый ключ), которые можно использовать для генерации того же CGA, что и целевой CGA, то злоумышленник может выдать себя за хост, который фактически владеет CGA, без обнаруживается (кроме, возможно, случаев, когда клиент ранее связался с хостом и заметил, что открытый ключ изменился, а CGA - нет).
Из 64 битов Hash1
только 59 используются в идентификаторе интерфейса, так как 5 бит перезаписываются. Для CGA с Sec
равным 0 это означает, что стоимость поиска набора параметров CGA, который дает желаемые 59 бит, составляет приблизительно(в большой нотации O ). Однако большее значение Sec
увеличивает эту стоимость в раз к потому что первые 16 Sec
разрядов Hash2
становятся релевантными (т. е. он реализует расширение хэша, требуя, чтобы эти биты были равны 0). В процессе генерации CGA стоимость генерации адреса увеличивается на тот же коэффициент в зависимости от значения Sec
, но стоимость использования и проверки CGA остается постоянной.
Поскольку Sec
он не является частью структуры данных CGA Parameters, а является частью самого адреса, злоумышленник не может использовать Sec
значение, меньшее, чем значение целевого адреса (например, 0), в попытке пропустить (или уменьшить масштаб) атаку методом перебора Hash2
. Это, в частности, приведет к получению CGA, отличного от целевого CGA, поскольку по крайней мере один из трех крайних левых битов идентификатора интерфейса не будет совпадать. Если целевое Sec
значение все равно записывается в идентификатор интерфейса, тогда Hash2
(почти наверняка) будет обнаружено, что в процессе проверки не хватает необходимого количества крайних левых 0-битов.
В процессе генерации CGA очень маловероятно, что произойдет три столкновения адресов. Если дублирующийся адрес будет обнаружен в третий раз, то это, скорее всего, будет из-за ошибки конфигурации или реализации или атаки типа «отказ в обслуживании» . По этой причине количество допустимых значений для collCount
ограничено диапазоном от 0 до 2. Этот параметр должен быть проверен, чтобы он находился в этом диапазоне во время процесса проверки CGA, чтобы злоумышленник не воспользовался им и попробовал все разные значения без необходимость выполнять новый поиск методом перебора Hash2
каждый раз, когда пробуется другое значение.
Включив префикс подсети в итоговую операцию дайджеста Hash1
, можно предотвратить использование злоумышленником единой предварительно вычисленной базы данных для атаки на адреса с разными префиксами подсети. Проверяющий также может быть уверен, что открытый ключ привязан именно к этому адресу, а не к адресу с тем же идентификатором интерфейса, но с другим префиксом подсети. Поскольку спецификация CGA предписывает использовать subnetPrefix
структуру данных параметров CGA для операций дайджеста, необходимо проверить, соответствует ли она префиксу подсети CGA во время процесса проверки CGA.