Комментарии 33
Я не до конца понял модель угроз. От кого и зачем защищаются с использованием секретных (?) ipv6 адресов. Каким образом эти адреса остаются секретными?
Секретными являются приватные ключи, публичные от которых формируют адрес IPv6. Публичный — общеизвестен, приватный ключ — секретный и хранится в тайне, чтобы в сети не появился левый ресурс с вашим адресом. Похожим образом публичные ключи формируют внутрисетевые адреса в Tor и I2P, где потеря ключей также является потерей домена -onion или -i2p.
В статье используется термин "высоких адресов", подбор которых в теории намного сложнее. Их отличие — большое значение во втором байте адреса, который отображает количество лидирующих единиц в хеше от публичного ключа. Количество лидирующих единиц в хеше (в бинарном виде) после подсчета записывается во второй байт адреса, затем они урезаются, а последующие 14 байт хеша формируют оставшуюся часть IPv6-адреса. То есть: чем больше значение второго байта адреса, тем большее количество бит формирует адрес, и в этом его дополнительная надежность.
Я всё равно не понимаю модель угроз. Почему ip-адрес кто-то будет "перебирать"? Что мне мешает провести сессию с каким-то узлом и присвоить себе его же адрес (который я получил в силу коннективити с этим узлом)? У меня ощущение, что вы слишком тщательно считаете биты и слишком мало описываете модель угроз.
Кажется, вы не совсем знакомы с темой ассиметричного шифрования, в котором существуют две неотъемлемые сущности: открытый ключ и закрытый. Открытым ключом, который распространяется свободно, информация шифруется. Затем информация может быть расшифрована исключительно секретным (приватным) ключом из той же связки.
Устанавливая соединение с кем угодно (в том числе в сетях Тоr и I2P) вы получаете лишь публичный ключ абонента, который формирует его адрес, и которым вы шифруете трафик, отправляемый ему. Но расшифровать массив данных конечный пользователь может только благодаря секретному ключу. В свою очередь воспроизведение секретного ключа из публичного практически (и даже в адекватной теории) невозможно. На этом стоит вся современная криптография.
Отсюда следует, что заполучить чужой адрес можно двумя путями: либо украсть из конфига, получив доступ к серверу, либо смайнить. Однако майнинг здесь чаще всего принимает вселенские масштабы в категориях тысяч и миллионов лет с гугловскими мощностями.
Используется именно хеш публичного ключа. Только он конвертируется в IPv6 для соответствующей логической маршрутизации. Я не утверждаю, что это лучшее решение (даже наоброт, в рамках статьи сею семя сомнения). Именно в силу преобразования хеша в адрес IPv6 (грубо говоря, из 64 байт в 16) происходит сомнительная потеря большой части уникального хеша и коллизия становится более вероятной, т.к. подобрать два ключа с одинаковыми N-байтами в начале хеша проще, чем независимо найти два ключа с одинаковым хешем.
Под майнингом адреса понимается скоростной перебор секретных ключей x25519 и проверка IPv6 от их публичных ключей, выведенных обозначенным выше алгоритмом. Майнингом занимаются либо для поиска "красивого" адреса (например, 200:dead:ded:cafe:babe:...), либо в попытках подобрать уже существующий адрес с целью нарушить обращение к нему (пока практически не удалось никому).
То есть в майнинге речь идет просто о подборе приватного ключа к публичным? И как проверять есть ли такой узел в сети Ygg, пингом? Расчет на то, что в сети много открытых ключей и какой-то, но попадется?
Адрес майнится по конкретному паттерну: не случайное попадание пальцем в небо, а намеренная атака. Например, я знаю ваш адрес и буду майнить именного его. Если проверять каждый адрес пингом, скорость майнинга станет столь малой, что об успехе даже в теории говорить не придется.
По поводу обоснованности использования той или иной схемы преобразования изначального ключа в конечный IPv6-адрес: я не разработчик Yggdrasil, чтобы адекватно судить и аргументировать причины этого. В статье я изложил лишь очевидную суть, а глубинные замыслы от меня сокрыты.
Я сам задумываюсь над потенциальной возможностью преобразования публичного ключа вовсе без хеша сразу в IPv6, и немного удивляюсь, что это реализовано более замудренно.
Второй вариант верен: подразумевается генерация новой пары ключей, у которой часть хеша, образующая IPv6-адрес, будет такой же, как и у целевого адреса, т.е. IPv6 адреса совпадут.
Так как мы поняли, что при формировании адреса используется не весь хеш (64 байта), а только часть (т.к. адрес IPv6 всего 16 байт), видим умозрительную возможность нахождения коллизии: возможно разных ключей, но с одинаковым началом хеша.
Об этой теории как раз заголовок "Почва для размышлений".
Был проведен тест: в сети подняли два узла с одинаковыми ключами. В итоге трафик терялся: шел то на один узел, то на другой. Практического теста с разными ключами, но одинаковыми IPv6-адресами проведено не было, т.к. такие коллизии еще не были найдены. Как минимум, включение в сеть стороннего узла с вашим адресом нарушит вашу работу с сетью. Весьма вероятно, что сделает ее вовсе невозможной на прежнем адресе. Только такой сценарий в настоящее время может быть целью описанной нами атаки с майнингом уже существующего адреса.
Спасибо за сомнения в моей квалификации.
Я вас попросил ответить какая тут модель угроз, а вы мне рассказываете, что я плохо разбираюсь в асимметричной криптографии.
Насколько я понимаю у ноды Yggdrasil при начальном установлении соединения нет никакой информации о пире кроме его IPv6 адреса. Биты этого адреса и используются для поиска ноды в простанстве ключей DHT.
А т.к. NodeID длиной 512 бит, а IPv6 только 121 (весь меш живёт в 200::/7, но по факту и того меньше) то два NodeID вполне могут смапиться на один и тот же адрес. И твои пакетики полетят к другому адресату...
Не думал, что такие дебри будут интересны читателям!
Маршрутизация в Yggdrasil происходит по DHT-координатам, которые отталкиваются от реальной топологии, а корень этого DHT-дерева определяется по некоторому критерию ключа подписи EdDSA. Т.е. ключи, образующие IPv6, в логике маршрутизации практически не участвуют.
Если тема интересна, могу оформить всё в небольшую статью.
P.S. Когда ковырялся в дебрях кода Yggdrasil, заметил, что NodeID там называется сырой хеш SHA512 от ключа. От него потом образуется IPv6.
Я читал whitepaper.
С маршрутизацией это отдельная песня, это следующий этап. Но вот момент когда хост с адресом А хочет отправить пакет хосту с адресом B — ему нужно выяснить NodeID адресата имея только биты IPv6 адреса. И вот тут, как я понимаю, возможны коллизии.
Ага. Тогда, вроде бы, модель угроз в себя включает противника, пытающегося нарушить связность, за счёт коллизии по IP-адресам. Теперь вопрос интереснее — нарушить связность конкретного узла, или "хоть какого-то"? Потому что если "хоть какого-то", то угроза куда более серьёзная из-за birthday paradox.
Вы будто мстите мне, осыпая занятной терминологией :) При написании статьи я имел ввиду связность конкретного узла.
Однако можно разобрать примерную схему против "хоть кого-то": предварительно сканируем сеть, записываем все обнаруженные IPv6 (которых сейчас в сети ~1500), затем запускаем майнер, и проверяем получаемые адреса на коллизию. Будет медленнее, чем с коротким паттерном поиска, но намного эффективнее пингования каждого полученного адреса.
Тут, как мне кажется, не просто нарушение связности — а полная замена адресата собой. Эдакий аналого старого доброго ARP Spoofing.
Спуфинг — уместный термин. Статья с подобным заголовком и теоритическим разбором угрозы была написана еще минувшим летом на howto.ygg — внутрисетевой wiki Yggdrasil.
http://[300:529f:150c:eafe::6]/doku.php?id=yggdrasil:spoofing_theory
Если я правильно понимаю комментарии выше, то тут именно коллизия, а не подмена адресата.
Узел А хочет связаться с узлом B. У узла A есть публичный ключ 'b'. Узел A вычисляет адрес из публичного ключа 'b'.
Узел E хочет помешать (или даже имперсонализироваться). Он подбирает такую пару приватного и публичного ключа 'e', что адрес получается такой же.
(дальше я не знаю подробностей работы сети)
Но имперсонализация не получится, потому что A хочет общаться с B, а приватный ключ b (соответствующий ожиданию A) есть только у B.
Узел А хочет связаться с узлом B. У узла A есть публичный ключ 'b'.
Нет у него ничего, откуда ключ?
С точки зрения ОС есть tun/tap интерфейс с твоим IPv6 адресом, полученным хешированием и прочей магией из твоего публичного ключа. И есть маршрут до 200::/7 в этот интерфейс.
Соответственно делая образный ping 200::<какой-то адрес> пакет улетает через tun в демона Yggdrasil и он уже каким-то образом должен сопоставить IP получателя с каким-либо из NodeID/TreeID/whatever в DHT сети и потом уже получить публичный ключ чтобы настроить криптографию.
И вот на этом этапе коллизия приведёт к тому, что получить можно не тот публичный ключ, на который ты рассчитываешь, а вражины злобной.
Я не претендую на полное понимание, но механизм примерно такой как я понял.
Узел А хочет связаться с Б, но ничего не знает про "Б".
Мне кажется, это нерешаемая задача. По какому признаку "Б" отличается от "В"?
Он знает IP-адрес. Который как-то зависит от NodeID, который есть SHA512 от публичного ключа.
Т.е. вся безопасность основана на том, что коллизий нет (хотя это бред), как только коллизия — извините, вы пишите не Алисе, а Бобу, не зная про это.
Насколько я знаю, yggdrasil использует криптографическую идентификацию узла, т.е. вам надо знать public key пира для общения с ним (иначе, зачем там приватные и публичные ключи?). Если нет, то для обсуждения возможности "самозахвата" IP нужно разбираться с протоколом маршрутизации.
… Потому что прямо сейчас я могу себе на интерфейс вписать любой ipv6-адрес. от захвата Ipv6 адреса гугла меня будет останавливать ближайший bgp-маршрутизатор, который трафик на этот адрес будет отправлять в AS гугла, а не в мою AS.
Насколько я знаю, yggdrasil использует криптографическую идентификацию узла, т.е. вам надо знать public key пира для общения с ним
Там нет PKI, центральных реестров и нет механизма ручного маппинга IP-адресов в публичные ключи. А автоматический маппинг — это то, о чём я тут пишу уже не первый коммент.
иначе, зачем там приватные и публичные ключи?
Для шифрования и аутентификации, очевидно.
Аутентификация тупая, как я уже выше писал — проверяем что из данного публичного ключа получается тот IPv6 адрес, на который мы долбимся. В случае коллизии это условие как раз выполняется и мы имеем спуфинг.
Потому что прямо сейчас я могу себе на интерфейс вписать любой ipv6-адрес. от захвата Ipv6 адреса гугла меня будет останавливать ближайший bgp-маршрутизатор, который трафик на этот адрес будет отправлять в AS гугла, а не в мою AS.
Ну, не совсем так, скорее у пира будет просто стоять фильтр на твои анонсы, где разрешены только префиксы твоей AS. В случае Yggrasil ничего такого нет, максимум — можно сделать вайтлист публичных ключей, от которых ты хочешь получать пакеты (AllowedEncryptionPublicKeys).
А откуда "данный публичный ключ" берётся? Пир "б" показывает или у "А" эта информация уже есть?
В контексте нормальной маршрутизацией, если я впишу на себя чужой IP, то трафик я слать могу (если нет выходных фильтров), а вот получать не смогу, потому что я (пользователь обычного компьютера) никак не могу убедить маршрутизатор слать мне трафик. Сессий с ними (маршрутизаторами) у меня нет, так что маршрутизатору даже не надо ничего фильтровать, достаточно просто не принимать bgp от кого попало.
А вот как в Y это сделано — вопрос интересный.
А откуда "данный публичный ключ" берётся? Пир "б" показывает или у "А" эта информация уже есть?
Почитай вайтпейпер, там всё есть.
Если упрощённо:
- Из IP-адреса получателя ты получаешь, по сути, маску полного NodeID ноды, чей это адрес
- Запускаешь поиск по DHT с этой маской и ближайший сосед искомого NodeID тебе отвечает его полным публичным ключом
- Ну и уже имея публичный ключ можно начинать сессию
Сессий с ними (маршрутизаторами) у меня нет, так что маршрутизатору даже не надо ничего фильтровать
Просто ты начал говорить про AS, а это обычно подразумевает BGP-пиринг. В случае статики, конечно, всё проще.
Ага, тогда звучит рисованно. (Я не готов весь whitepaper вычитывать).
Насчёт bgp — я показал, что я (пользователь и админ localhost) могу творить что угодно с любыми адресами, но "интернетам" на это почти пофигу, потому что где-то там маршрутизаторы, которые на своём языке говорят и на мои настройки localhost им глубоко пофигу.
Криптографическое образование адреса IPv6 в Yggdrasil