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

( Криптографически сгенерированный адрес CGA ) — это адрес Интернет-протокола версии 6 (IPv6), идентификатор хоста которого вычисляется с помощью криптографической хэш-функции . ^[1] Эта процедура представляет собой метод привязки открытого ключа подписи к адресу IPv6 в протоколе обнаружения безопасного соседа (SEND). ^[2]

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

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

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

Структура данных параметров CGA состоит из:

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

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

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

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

 1  procedure generateCGA(Sec, subnetPrefix, publicKey, extFields):
 2      modifier := random(0x00000000000000000000000000000000,     // 16 octets (128 bits)
 3                         0xffffffffffffffffffffffffffffffff)
 4
 5  label1:
 6      concat := concatenate(modifier, 0x000000000000000000,      // 9 zero octets
 7                            publicKey, extFields)
 8
 9      digest := SHA1(concat)
10      Hash2 := digest[0:14]                                      // 14*8 = 112 leftmost bits
11
12      if Sec ≠ 0 and Hash2[0:2*Sec] ≠ 0:                         // 2*Sec*8 = 16*Sec leftmost bits
13          modifier := modifier + 1
14          goto label1
15      end if
16
17      collCount := 0x00                                          // 8-bit collision count
18
19  label2:
20      concat := concatenate(modifier, subnetPrefix, collCount,
21                            publicKey, extFields)
22
23      digest := SHA1(concat)
24      Hash1 := digest[0:8]                                       // 8*8 = 64 leftmost bits
25
26      intID := Hash1                                             // Hash1 becomes interface identifier...
27      intID[0] := intID[0] binary and 0x1c binary or (Sec << 5)  // ...after writing Sec and u/g bits
28
29      CGA := concatenate(subnetPrefix, intID)                    // concatenate to form the CGA
30
31      if duplicate(CGA):
32          collCount := collCount + 1
33
34          if collCount = 3:
35              abort
36          end if
37
38          goto label2
39      end if
40
41      return [CGA, [modifier, subnetPrefix, collCount, publicKey, extFields]]
42  end procedure

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

The 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.

Метод проверки CGA

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

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

 1  procedure verifyCGA(CGA, [modifier, subnetPrefix, collCount, publicKey, extFields]):
 2      if collCount > 2 or CGA[0:8] ≠ subnetPrefix:
 3          return false
 4      end if
 5
 6      concat := concatenate(modifier, subnetPrefix, collCount,
 7                            publicKey, extFields)
 8
 9      digest := SHA1(concat)
10      Hash1 := digest[0:8]                                   // 8*8 = 64 leftmost bits
11      Hash1[0] := Hash1[0] binary and 0x1c                   // ignore Sec and u/g bits
12
13      intID := CGA[8:16]                                     // interface identifier (64 rightmost bits)
14      intID[0] := intID[0] binary and 0x1c                   // ignore Sec and u/g bits
15
16      if Hash1 ≠ intID:
17          return false
18      end if
19
20      Sec := CGA[8] >> 5                                     // extract Sec from interface identifier
21
22      concat := concatenate(modifier, 0x000000000000000000,  // 9 zero octets
23                            publicKey, extFields)
24
25      digest := SHA1(concat)
26      Hash2 := digest[0:14]                                  // 14*8 = 112 leftmost bits
27
28      if Sec ≠ 0 and Hash2[0:2*Sec] ≠ 0:                     // 2*Sec*8 = 16*Sec leftmost bits
29          return false
30      end if
31
32      return true                                            // verification succeeded
33  end procedure

Метод начинается с проверки того, 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(2^{59})$ (в большом обозначении О ). Большее значение Sec, однако увеличивает эту стоимость в раз. $2^{16\times Sec}$ к $O(2^{59+16\times Sec})$ потому что первые 16 раз Sec кусочки Hash2 затем становится актуальным (т. е. реализует расширение хеша, требуя, чтобы эти биты были равны 0). В процессе генерации CGA стоимость генерации адреса увеличивается на тот же коэффициент в зависимости от значения Sec, но стоимость использования и проверки CGA остается постоянной.

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

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

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

См. также

ША-1

Ссылки

^ RFC 3972, Криптографически генерируемые адреса (CGA) , T. Aura (март 2005 г.)
^ RFC 3971, Secure Neighbor Discovery (SEND) , Дж. Аркко (редактор), Дж. Кемпф, Б. Зилл, П. Никандер (март 2005 г.)

[1] RFC 3972, Криптографически генерируемые адреса (CGA) , T. Aura (март 2005 г.)

[2] RFC 3971, Secure Neighbor Discovery (SEND) , Дж. Аркко (редактор), Дж. Кемпф, Б. Зилл, П. Никандер (март 2005 г.)

[1]

[2]