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

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

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

Чтобы проверить подлинность подписанного сообщения ND, получатель рассматривает само сообщение, его цифровую подпись, открытый ключ источника, параметры CGA, а также адрес IPv6, на который претендует источник этого сообщения. Этот заявленный адрес зависит от типа сообщения [§5.1.1 RFC 3971], как показано в Табл. 6.1.

Таблица 6.1. Заявленные адреса разных типов сообщений ND
Тип сообщения Заявленный адрес
NS с неопределенного адреса (DAD) Адрес цели
NA Адрес источника = адрес цели (см. примечание)
RS Адрес источника (если он определенный)
RA Адрес источника
Переадресовка Адрес источника

Данный механизм не поддерживает защиту ответов proxy, потому что proxy не знает закрытого ключа узла, от имени которого отвечает. Поэтому защита NA возможна только при условии, что адрес источника равен адресу цели [§7.4 RFC 3971]. Метод защиты ответов proxy находится в разработке [draft-krishnan-cgaext-proxy-send]. Проработав текущий раздел до конца, подумайте, на каком основании хост может доверять адресу маршрутизатора, приславшего подписанную переадресовку. (Ответ: Если адрес маршрутизатора известен заранее из ручной настройки или сертифицированного объявления RA.)

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

Таким образом, к дополнительным сведениям, которые еще нет в сообщении ND, относятся: параметры CGA, открытый ключ и цифровая подпись. Эти сведения источник сообщения помещает в специально отведенные для них опции ND. Правила работы с такими опциями составляют часть протокола SEND (Secure ND, безопасный ND) [RFC 3971].

Точнее, параметры CGA и открытый ключ попадают в одну опцию "CGA". Защищенное сообщение ND может и не содержать опции "CGA", если открытый ключ соседа известен из других источников. В таком случае достаточно одной цифровой подписи.

Механизм CGA в составе SEND работает при условии, что доверенный адрес предлагает узел, проводящий аутентификацию. В ответ он должен получить сообщение ND, касающееся именно этого адреса. Только в этом случае весь механизм надежно опирается на доверенность исходного адреса IPv6. Например, мы начинаем ping вполне определенного доверенного адреса, и наш локальный узел, рассылая вызовы NS, добивается объявления NA именно об этом адресе, а не каком-то другом. Таким образом, при разрешении адресов это условие выполняется.

Между тем, злоумышленник вполне может сгенерировать новый адрес CGA и вызвать создание записи NC о нем, например, послав NS с опцией SLLA. Однако такая запись не принесет заметного вреда, если не будет обращений по этому адресу на прикладном уровне или попыток использовать его как маршрутизатор. В этом и состоит модель защиты при помощи CGA: обращение идет только по доверенным адресам IPv6.

Хотя CGA можно применять не только в рамках SEND, делать это надо с большой осторожностью, так как разные применения одного и того же механизма защиты могут открыть лазейку для перекрестных атак, например, атак воспроизведением, когда злоумышленник предъявляет в одном протоколе защитные данные, перехваченные из другого протокола [§7.4 RFC 3972].

В то же время, при автоматическом розыске маршрутизаторов хост заранее не знает, какие адреса ему предъявят в объявлениях RA. Не исключено, что часть объявлений принадлежит незаконным маршрутизаторам [RFC 6104], но механизм CGA бессилен их разоблачить. Все, на что способен механизм CGA, — это помешать краже заранее известного адреса.

Чтобы защитить розыск маршрутизаторов, можно сертифицировать их в этой роли. То есть законному маршрутизатору выдают сертификат, подписанный удостоверяющим центром (возможно, по цепочке доверия). В процессе предварительной ручной настройки каждый хост получает копию корневого сертификата. После этого хост может проверить сертификат маршрутизатора, от которого пришло подписанное объявление RA.

Закрытый ключ удостоверяющего центра заперт в надежном сейфе, так что злоумышленник не может создать новый сертификат — он способен только похитить сертификат и закрытый ключ законного маршрутизатора, например, взломав его. Если злоумышленник сделает это, то он сможет присвоить себе полномочия данного маршрутизатора, но не более того. Когда взлом будет раскрыт, старый сертификат придется отозвать с помощью списка отозванных сертификатов (certificate revocation list, CRL) — это обычная практика работы с цифровыми сертификатами. Поэтому хосты должны проверять, не отозван ли сертификат маршрутизатора. Нет ли здесь "проблемы курицы и яйца"? Список CRL доступен для загрузки по сети ,8 Например, по HTTP или LDAP. и загрузить его в общем случае можно, только выбрав маршрутизатор. Если же маршрутизатор незаконный или взломан, то он может манипулировать загрузкой CRL. К счастью, список CRL подписан удостоверяющим центром, сертификат которого есть у хоста, так что фальсифицировать CRL нельзя. Все, что остается незаконному маршрутизатору — это помешать загрузке CRL. Следовательно, хост должен прекратить работу через выбранный маршрутизатор, если загрузка CRL не удалась. То есть хост вначале выбирает маршрутизатор условно, чтобы загрузить CRL, и переходит к обычной работе в сети, только если выполнены все перечисленные условия:

  • список CRL успешно загружен;
  • список CRL заверен действительной подписью удостоверяющего центра;
  • сертификат выбранного маршрутизатора не значится в CRL.

В противном случае хосту следует сообщить оператору о проблеме и попытать счастья с другим маршрутизатором, рассылающим объявления RA [§6.3.1 RFC 3971].

На этих довольно простых идеях и основана авторизация маршрутизаторов в рамках SEND [§6 RFC 3971]. Дальше углубляться в нее мы не будем, а только отметим, что львиную долю в ней занимает механизм розыска и передачи цепочек доверия ADD (Authorization Delegation Discovery).

К сожалению, ND подвержен не только прямым атакам путем подделки сообщений протокола. Конечный автомат ND реагирует и на другие события. Например, приход транзитного пакета IPv6 может вызвать создание записи NC в состоянии НЕПОЛНАЯ. Теперь представьте себе, что злодей бомбардирует маршрутизатор транзитными пакетами, адресованными несуществующим узлам подсети [§4.3.2 RFC 3756]. Очевидно, что в этом случае неосторожная реализация маршрутизатора может исчерпать записями НЕПОЛНАЯ всю доступную память и потерпеть крах. Помочь здесь может только предусмотрительное управление кэшем NC, например, адаптивное удаление записей НЕПОЛНАЯ по мере роста их числа. Те же соображения актуальны и для хоста, если злоумышленник может запускать на нем приложения, передающие пакеты произвольным адресатам.

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

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

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

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

 

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

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

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