Криптографически сгенерированный адрес - Cryptographically Generated Address

А Криптографически сгенерированный адрес (CGA) является Интернет-протокол версии 6 (IPv6) адрес, для которого идентификатор хоста вычисляется из криптографическая хеш-функция.^[1] Эта процедура является методом привязки открытый ключ подписи для IPv6-адрес в Протокол обнаружения безопасного соседа (ОТПРАВИТЬ).^[2]

Методология

Криптографически сгенерированный адрес формируется путем замены 64 младших разрядов 128-битного адреса IPv6 криптографическим хешем открытого ключа владельца адреса. Сообщения подписываются соответствующим закрытым ключом. Только если исходный адрес и открытый ключ известны, верификатор может аутентифицировать сообщение от соответствующего отправителя. Этот метод не требует инфраструктура открытого ключа. Допустимые CGA могут быть созданы любым отправителем, включая потенциального злоумышленника, но они не могут использовать какие-либо существующие CGA.

Характеристики

Криптографически сгенерированный адрес - это IPv6-адрес, идентификатор интерфейса которого был сгенерирован в соответствии с методом генерации CGA. Идентификатор интерфейса состоит из 64 младших битов IPv6-адреса и используется для идентификации сетевого интерфейса хоста в его подсети. Подсеть определяется старшими 64 битами, префиксом подсети.

Формат IPv6-адреса

биты	64	64
поле	префикс подсети	идентификатор интерфейса

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

Структура данных CGA Parameters состоит из:

• модификатор: случайный 128-битный беззнаковый целое число;
• subnetPrefix: 64-битный префикс, определяющий, к какой подсети принадлежит CGA;
• collCount: 8-битовое целое число без знака, которое должно быть 0, 1 или 2;
• publicKey: открытый ключ как DER -кодированный ASN.1 структура типа SubjectPublicKeyInfo;
• extFields: необязательное поле переменной длины (длина по умолчанию 0).

Дополнительно параметр безопасности Сек определяет силу CGA против атаки методом перебора. Это 3-битовое целое число без знака, которое может иметь любое значение от 0 до 7 (включительно) и закодировано в трех крайних левых битах идентификатора интерфейса CGA. Чем выше значение Сек, тем выше уровень безопасности, но и тем больше времени обычно требуется для создания CGA. Для удобства промежуточный Сек Предполагается, что значения в псевдокоде ниже хранятся как 8-битовые целые числа без знака, которые не могут иметь значение больше 7.

Метод генерации CGA

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

 1  процедура generateCGA (Сек, subnetPrefix, publicKey, extFields): 2      модификатор : = random (0x00000000000000000000000000000000, // 16 октетов (128 бит) 3 0xffffffffffffffffffffffffffffff) 4 5 label1: 6      concat : = объединить (модификатор, 0x000000000000000000, // 9 нулевых октетов 7 publicKey, extFields) 8 9      переваривать : = SHA1 (concat)10      Hash2 := переваривать[0:14] // 14 * 8 = 112 крайних левых битов 1112 если Сек ≠ 0 и Hash2[0:2*Сек] ≠ 0: // 2 * сек * 8 = 16 * сек крайние левые биты 13 модификатор := модификатор + 114          идти к этикетка115 конец, если1617      collCount : = 0x00 // 8-битный счетчик конфликтов 1819 label2:20      concat : = объединить (модификатор, subnetPrefix, collCount,21                            publicKey, extFields)2223      переваривать : = SHA1 (concat)24      Hash1 := переваривать[0: 8] // 8 * 8 = 64 крайних левых бита 2526 intID := Hash1                                             // Hash1 становится идентификатором интерфейса ... 27 intID[0] := intID[0] двоичный и 0x1c двоичный или (Сек << 5) // ... после записи Sec и u / g бит 2829 CGA : = объединить (subnetPrefix, intID) // объединяем, чтобы сформировать CGA3031 если дубликат (CGA):32          collCount := collCount + 13334          если collCount = 3:35              прервать36          конец, если3738          идти к этикетка239 конец, если4041      возвращаться [CGA, [модификатор, subnetPrefix, collCount, publicKey, extFields]]42  конец процедуры

Идентификатор интерфейса CGA в значительной степени состоит из Hash1, который берется из первых 64 бит структуры данных переваренных CGA Parameters (строки с 20 по 24). В строке 27 первые три бита перезаписываются Сек значение и зарезервированные биты «u» и «g» (седьмой и восьмой бит) установлены в 0.

В Сек параметр реализует расширение хэша, принудительно вводя первые 16 раз Сек биты другого хеша, Hash2, равным 0. Этот хэш является результатом переваренной структуры данных параметров CGA с subnetPrefix и collCount по существу установлено на 0. A перебор выполняется для поиска подходящего Hash2, увеличивая модификатор на 1 каждую итерацию (строки с 6 по 15). Поскольку больше битов должно быть 0 с более высоким Сек значение, среднее время, необходимое для выполнения поиска, увеличивается экспоненциально со значением Сек.

После объединения префикса подсети и сгенерированного идентификатора интерфейса для создания 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 : = объединить (модификатор, subnetPrefix, collCount, 7                            publicKey, extFields) 8 9      переваривать : = SHA1 (concat)10      Hash1 := переваривать[0: 8] // 8 * 8 = 64 крайних левых бита 11 Hash1[0] := Hash1[0] двоичный и 0x1c // игнорировать биты Sec и u / g 1213 intID := CGA[8:16] // идентификатор интерфейса (64 крайних правых бита) 14 intID[0] := intID[0] двоичный и 0x1c // игнорировать биты Sec и u / g 1516 если Hash1 ≠ intID:17          возвращаться ложь18 конец, если1920      Сек := CGA[8] >> 5 // извлекаем сек из идентификатора интерфейса 2122 concat : = объединить (модификатор, 0x000000000000000000, // 9 нулевых октетов23 publicKey, extFields)2425      переваривать : = SHA1 (concat)26      Hash2 := переваривать[0:14] // 14 * 8 = 112 крайних левых бит 2728 если Сек ≠ 0 и Hash2[0:2*Сек] ≠ 0: // 2 * сек * 8 = 16 * сек крайние левые биты 29 возвращаться ложь30 конец, если3132      возвращаться true // проверка прошла успешно33 конец процедуры

Метод начинается с проверки, если collCount из структуры данных CGA Parameters имеет допустимое значение, и если subnetPrefix из той же структуры данных соответствует префиксу подсети CGA (в строке 2). Это сделано для причины безопасности.

С 6 по 18 строки Hash1 вычисляется из структуры данных CGA Parameters (которая включает открытый ключ и префикс подсети), и соответствующие биты сравниваются с битами идентификатора интерфейса CGA. В данном случае это делается путем установки первых трех битов (Сек) и седьмой и восьмой бит (биты "u" и "g") обоих Hash1 и идентификатор интерфейса на 0 в строках 11 и 14 для удобства сравнения.

После извлечения Сек из идентификатора интерфейса CGA, Hash2 рассчитывается и первые 16 раз Сек биты хэша сравниваются с 0 (строки с 22 по 30). Если все проверки прошли успешно, значит, открытый ключ был проверен на привязку к этому CGA (т.е. действительный для него).

Безопасность

Для того, чтобы злоумышленник сделать клиент полагая, что он получил действительное сообщение от определенного CGA, который не принадлежит злоумышленнику, злоумышленник должен найти хэш-коллизия для соответствующих битов Hash1 и Hash2 путем выполнения атака грубой силой. Если злоумышленник находит набор параметров CGA (включая открытый ключ, секретный ключ которого злоумышленник знает), которые можно использовать для генерации того же CGA, что и целевой CGA, то злоумышленник может выдать себя за хост, который фактически владеет CGA, без обнаруживается (кроме, возможно, случаев, когда клиент ранее связывался с хостом и замечает, что открытый ключ изменился, а CGA - нет).

Из 64 бит Hash1, только 59 используются в идентификаторе интерфейса, поскольку перезаписываются 5 бит. Для CGA с Сек равно 0, это означает, что стоимость поиска набора параметров CGA, который дает желаемые 59 бит, составляет приблизительно ${\displaystyle O(2^{59})}$ (в нотация большой O ). Большее значение Сек, однако увеличивает эту стоимость в раз ${\displaystyle 2^{16\times Sec}}$ к ${\displaystyle O(2^{59+16\times Sec})}$ потому что первые 16 раз Сек кусочки Hash2 затем становится актуальным (т.е. он реализует расширение хэша, требуя, чтобы эти биты были равны 0). В процессе генерации CGA стоимость генерации адреса увеличивается во столько же раз в зависимости от значения Сек, но стоимость использования и проверки CGA остается постоянной.

Потому что Сек не является частью структуры данных CGA Parameters, а является частью самого адреса, злоумышленник не может использовать Сек значение меньше, чем у целевого адреса (например, 0) в попытке пропустить (или уменьшить) атаку грубой силы на Hash2. В частности, это приведет к получению CGA, отличного от целевого CGA, поскольку по крайней мере один из трех крайних левых битов идентификатора интерфейса не будет совпадать. Если цель Сек значение все равно записывается в идентификатор интерфейса, тогда Hash2 (почти наверняка) будет обнаружено отсутствие необходимого количества крайних левых 0-бит в процессе проверки.

В процессе генерации CGA очень маловероятно, что произойдет три столкновения адресов. Если дублирующийся адрес будет обнаружен в третий раз, то это, скорее всего, будет из-за ошибки конфигурации или реализации или атака отказа в обслуживании. По этой причине количество допустимых значений для collCount ограничен диапазоном от 0 до 2. Этот параметр должен быть подтвержден на предмет того, чтобы он находился в этом диапазоне во время процесса проверки CGA, чтобы предотвратить его использование злоумышленником и попытку всех различных значений без необходимости выполнять еще один поиск грубой силы для Hash2 каждый раз пробует другое значение.

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

Смотрите также

• SHA-1

Рекомендации

1. RFC 3972, Криптографически сгенерированные адреса (CGA), Т. Аура (март 2005 г.)
2. RFC 3971, Обнаружение безопасного соседа (ОТПРАВИТЬ), J. Arkko (ed.), J. Kempf, B. Zill, P. Nikander (март 2005 г.)