Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Криптографически сгенерированный адрес (CGA) — это адрес протокола Интернет версии 6 (IPv6), идентификатор хоста которого вычисляется с помощью криптографической хеш-функции. Эта процедура представляет собой способ привязки ключа цифровой подписи к IPv6-адресу в протоколе безопасного обнаружения соседей (SEND).
A Cryptographically Generated Address (CGA) is an Internet Protocol Version 6 (IPv6) address that has a host identifier computed from a cryptographic hash function. This procedure is a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery Protocol (SEND).
Безопасность
Для того, чтобы злоумышленник заставил клиента поверить, что он получил действительное сообщение от определенного CGA, которому злоумышленник не владеет, ему необходимо найти коллизию хешей для соответствующих бит Hash1 и Hash2, применив атаку полным перебором. Если злоумышленник обнаружит набор параметров 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, отличного от целевого, поскольку по крайней мере один из трех самых левых битов идентификатора интерфейса не совпал бы. Если целевое значение Sec все равно записывается в идентификатор интерфейса, то Hash2 (весьма вероятно) не пройдет проверку из-за недостаточного количества нулей в старших битах. В процессе генерации CGA крайне маловероятно возникновение трех коллизий адресов. Если дубликат адреса будет обнаружен в третий раз, это, скорее всего, будет вызвано ошибкой конфигурации или реализации, либо атакой типа «отказ в обслуживании». Поэтому число допустимых значений для collCount ограничено диапазоном от 0 до 2. Этот параметр должен проверяться на принадлежность к этому диапазону в процессе проверки CGA, чтобы предотвратить попытки злоумышленника использовать его и перебирать различные значения без необходимости каждый раз выполнять новый поиск коллизий Hash2. Включение префикса подсети в операцию хеширования, приводящую к Hash1, предотвращает использование злоумышленником единой предварительно вычисленной базы данных для атаки на адреса с разными префиксами подсети. Верификатор также может быть уверен, что открытый ключ привязан именно к этому адресу, а не к адресу с тем же идентификатором интерфейса, но другим префиксом подсети. Поскольку спецификация CGA предписывает использовать префикс подсети из структуры данных параметров CGA для операций хеширования, необходимо убедиться в его соответствии префиксу подсети CGA в процессе проверки CGA.
In order for an attacker to make a client believe it received a valid message from a certain CGA that isn't owned by the attacker, the attacker must find a hash collision for the relevant bits of Hash1 and Hash2 by performing a brute force attack. If the attacker finds a set of CGA Parameters (including a public key for which the attacker knows the private key) that can be used to generate the same CGA as the target CGA, then the attacker can impersonate the host who actually owns the CGA without being detected (except perhaps when the client has contacted the host before and notices that the public key has changed but the CGA has not). Of the 64 bits of Hash1, only 59 are used in the interface identifier since 5 bits are being overwritten. For a CGA with Sec equal to 0, this means that the cost of finding a set of CGA Parameters that yield the desired 59 bits is approximately (in big O notation). A larger value of Sec, however, increases this cost by a factor of to because the first 16 times Sec bits of Hash2 then become relevant (i. e. it implements a hash extension by demanding those bits to be equal to 0). In the CGA generation process, the cost of generating an address is increased by the same factor depending on the value of Sec, but the cost of using and verifying a CGA remains constant. Because Sec is not part of the CGA Parameters data structure but of the address itself, an attacker cannot use a Sec value smaller than that of the target address (like 0) in an attempt to skip (or scale down) the brute force attack on Hash2. This would namely yield a different CGA from the target CGA since at least one of the three leftmost bits of the interface identifier would not match. If the target Sec value is written to the interface identifier anyway, then Hash2 will (almost certainly) be found to lack the required amount of leftmost 0 bits during the verification process. During the CGA generation process, it is very unlikely that three address collisions occur. If a duplicate address would be detected for the third time, then this would most likely be due to a configuration or implementation error or a denial of service attack. For this reason, the number of valid values for collCount is limited to the range from 0 to 2. This parameter must be verified to be in this range during the CGA verification process in order to prevent an attacker from exploiting it and trying all different values without the need to perform another brute force search for Hash2 each time a different value is tried. By including the subnet prefix in the digest operation that results in Hash1, it can be prevented that an attacker is able to use a single pre computed database to attack addresses with different subnet prefixes. A verifier can also be sure that the public key has been bound to this exact address and not possibly to an address with the same interface identifier but a different subnet prefix. Since the CGA specification prescribes to use the subnetPrefix from the CGA Parameters data structure for the digest operations, it must be verified that it matches the subnet prefix of the CGA during the CGA verification process.