Идентификаторы интерфейса с особыми свойствами и протоколы на их основе

Тем не менее, даже в этом случае адрес полезно зарегистрировать в DDNS. Причину мы обсудили в §6.2, говоря о расширениях для конфиденциальности.

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

Еще один параметр CGA — это счетчик коллизий. Адрес CGA зависит от случайного модификатора и потому сам он тоже случайный, а значит, есть вероятность коллизии с уже существующим адресом. Эта коллизия не вызовет проблем, так как ее вовремя обнаружит DAD (§5.4.1), но что делать дальше? В этом случае достаточно увеличить на единицу счетчик коллизий и повторить вычисление хэш-функции, дающей отпечаток ключа. Если хэш-функция сильная, то новый идентификатор интерфейса окажется совершенно другим. Почему нельзя просто сгенерировать новый случайный модификатор, мы увидим в следующем пункте.

Техника этого трюка напоминает поиск прообраза хэш-функции перебором. А именно ставится задача найти такой модификатор CGA, для которого хэш H(модификатор | открытый ключ | прочее) содержит ноль в 16 Sec старших разрядах. Все прочие модификаторы считаются недействительными. Это повышает сложность грубой атаки на отпечаток ключа до [§7.2 RFC 3972 ,^{6 T. Aura, M. Roe. Strengthening Short Hash Values http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.145.7681} . Создание CGA усложняется до , но проверить уже подобранный модификатор можно за время O(1): достаточно вычислить указанный хэш и проверить, что Sec старших разрядов в нем нулевые.

Очевидный недостаток исходного протокола CGA — это фиксированная хэш-функция, SHA 1. Исследователи активно ищут слабые стороны распространенных хэш-функций, так что нельзя исключать, что бастион SHA 1 когда-нибудь падет. Если это произойдет, то перейти на новую хэш-функцию, не расширяя протокола и не ломая совместимости, будет нельзя. Чтобы убедиться в этом, рассмотрим наивный подход: новые реализации на выходе используют более устойчивую хэш-функцию, скажем, SHA 3, а на входе пробуют и старую, и новую функции, так как заранее не знают, какой функцией создан данный CGA. Тогда злоумышленник сможет провести разновидность атаки понижением уровня безопасности (downgrade attack): взять доверенный адрес CGA, созданный при помощи SHA 3, и найти для него пару ключей, дающую такой же отпечаток при использовании уже взломанной функции SHA 1. Обратно совместимая реализация примет подпись злоумышленника, потому что попробует SHA 1 наряду с SHA 3.

Отметим, что для взлома CGA необходимо найти второй прообраз SHA 1, но исследователи достаточно близко подобрались только к поиску коллизий этой хэш-функции. О типах атак на хэш-функции см. [RFC 4270] и^{7 A.J. Menezes, P.C. van Oorschot, S.A. Vanstone. Handbook of Applied Cryptography http://www.cacr.math.uwaterloo.ca/hac/} [ ].

Чтобы не дожидаться взлома SHA 1, технические условия протокола CGA уже пришлось модифицировать [RFC 4982]. Увы, расширение CGA для поддержки разных хэш-функций — типичный пример того, как потом приходится расплачиваться за негибкость первой версии протокола. Предложенное решение лишено технического изящества и изменяет уже опубликованный протокол. А именно у поля Sec теперь новая, довольно запутанная интерпретация. К счастью, CGA все еще носит де-факто экспериментальный статус, и цена таких изменений в протоколе относительно невелика.

Механизм CGA явным образом рассчитан на то, что длина идентификатора интерфейса N равна 64 битам. Это упрощает устройство CGA, хотя и нарушает исходное положение [§2.5.4 RFC 4291], что на архитектурном уровне N — по-прежнему величина переменная. Впрочем, с самого начала было понятно, что это положение рано или поздно принесут в жертву хотя бы в частном случае. Так, принятие CGA в качестве стандарта еще не ставит крест на , потому что IPv6 вполне может работать и без CGA. С другой стороны, на тех каналах, где CGA действительно нужен, N = 64.