Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1680 / 52 | Длительность: 24:05:00
Лекция 8:

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

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >

Так или иначе, мы полагаем априори, что к началу розыска соседа разыскиваемый адрес IPv6 известен достоверно. Почему бы нам не превратить адрес IPv6 в контейнер для нужной информации? Если префикс подсети задан точкой подключения узла, то идентификатор интерфейса по-прежнему в нашем распоряжении. Мы уже помещали в него канальные адреса (§5.4.1) и даже случайные числа (§6.3), а теперь сохраним в нем отпечаток (fingerprint) открытого ключа. Тогда другие соседи смогут проверить, своими ли ключами пользуется данный узел.

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

  1. сгенерировать пару ключей для узла;
  2. вычислить идентификатор интерфейса как отпечаток открытого ключа, используя заранее утвержденный алгоритм;
  3. составить адрес из префикса подсети (согласно точке подключения) и идентификатора интерфейса (получен на шаге 2);
  4. внести ключи в настройки узла;
  5. назначит адрес сетевому интерфейсу узла;
  6. распространить сведения о новом адресе в сети:

    зарегистрировать в DNS (см. §2.11);

    а)

    внести в настройки удаленных приложений;

    б)

    сообщить заинтересованным лицам.

Так мы получаем криптографически произведенный адрес, сокращенно CGA (cryptographically generated address ). Полные правила работы с CGA существенно сложнее, они приведены в RFC 3972. Стоящая за ними идея, тем не менее, довольно прозрачна. А среди интересных подробностей RFC 3972 мы отметим две.

Во-первых, если узел — это рабочая станция пользователя, которая устанавливает только исходящие сеансы, то ее текущий адрес вполне может время от времени меняться. Именно этим мы уже пользовались в §6.2, когда работали над расширениями для конфиденциальности. Для такого узла шаг 6 вышеуказанной процедуры не имеет особого смысла.

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

Шаги 2, 3 и 5 такой узел может выполнить самостоятельно, располагая стандартным алгоритмом. При постоянных ключах это позволяет узлу автоматически менять свой адрес CGA. Но как отпечаток ключа может стать переменным? Для этого он должен зависеть от дополнительного аргумента, известного всем сторонам протокола. Этот аргумент, модификатор CGA, не представляет тайны, так что передавать его можно вместе с открытым ключом. Вместе с еще несколькими величинами он составляет параметры CGA — см. рис. 6.3. Отпечаток зависит от всех этих параметров, поэтому они обязательно сопровождают открытый ключ.

Блок параметров CGA

Рис. 6.3. Блок параметров CGA

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

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

Во-вторых, в идентификаторе интерфейса доступны только 62 бита, так как значения битов U/L и I/G заданы форматом "модифицированный EUI 64" (§2.7). То есть без дополнительных ухищрений атака на CGA методом грубой силы имела бы сложность порядка 2^62. Учитывая рост вычислительных мощностей по закону Мура, это не так уж много. Поэтому три старших бита в идентификаторе интерфейса CGA выделены под специальное поле Sec. Протокол CGA остроумно использует эти три бита, чтобы плавно управлять сложностью грубой атаки на адрес за счет более трудоемкой генерации такого адреса [§7.2 RFC 3972].

Техника этого трюка напоминает поиск прообраза хэш-функции перебором. А именно ставится задача найти такой модификатор CGA, для которого хэш H(модификатор | открытый ключ | прочее) содержит ноль в 16 \ast Sec старших разрядах. Все прочие модификаторы считаются недействительными. Это повышает сложность грубой атаки на отпечаток ключа до O(2^{59+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(2^{16*Sec}), но проверить уже подобранный модификатор можно за время O(1): достаточно вычислить указанный хэш и проверить, что 16\times 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 в качестве стандарта еще не ставит крест на N \ne 64, потому что IPv6 вполне может работать и без CGA. С другой стороны, на тех каналах, где CGA действительно нужен, N = 64.

Отлично, мы наметили решение поставленной задачи: настройка CGA требует усилий порядка O(N) , где N — число узлов на канале. Теперь давайте в общих чертах скажем, какие изменения потребуются в протоколе ND.

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >
Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.

Дмитрий Сирош
Дмитрий Сирош
Украина, Черкассы
Игорь Акулич
Игорь Акулич
Россия, с. Самара