Перейти к содержанию
Financial Context Wiki

Дальние атаки на PoS: исторические ключи, риск начальной синхронизации и контрольные точки

При дальней атаке на PoS узлу предъявляют альтернативную историю, подписанную полномочиями прежних валидаторов. Разберитесь, какие узлы уязвимы, что должен воспроизвести атакующий и как контрольные точки слабой субъективности и правила синхронизации конкретного протокола ограничивают риск.

Обновлено

Материал предназначен только для изучения безопасности протоколов. Устойчивость к дальним атакам зависит от протокола и его версии; прежде чем полагаться на недавно синхронизированный или долго не работавший узел, получите начальные данные из аутентифицированных и независимо проверенных источников.

Краткий ответ

Дальняя атака на proof-of-stake — это попытка придать достоверность конфликтующей истории с помощью полномочий валидаторов, которые действовали в далеком прошлом. В распространенном варианте, часто называемом последующей компрометацией, атакующий получает или компрометирует ключи уже вышедших валидаторов, чей залог больше нельзя подвергнуть штрафному списанию. Поскольку создание старых подписей не требует повторять энергозатраты proof-of-work, злоумышленник может построить внутренне согласованную ветвь относительно дешево по сравнению с историческими затратами честной цепочки.

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

Одних исторических ключей недостаточно для произвольной подделки. Альтернативная история должна удовлетворять требованиям целевого протокола к доменам подписей, переходам состояния, изменению набора валидаторов, времени, доказательствам финализации или выбора цепочки, а также ограничениям на эволюцию ключей и контрольные точки. Одни PoS-протоколы требуют свежую контрольную точку слабой субъективности; другие предусматривают начальную синхронизацию от генезиса либо иные предположения о доверии и доступности. Следует анализировать конкретную цепочку, сеть, версию форка, клиент и режим синхронизации, а не считать PoS единым механизмом.

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

Путь атаки и проверки

  1. Выбрать старую точку разветвления. Злоумышленник находит историческое состояние, полномочия валидаторов которого с тех пор сменились или которое новому узлу трудно аутентифицировать самостоятельно.
  2. Получить достаточный исторический вес подписей. После выхода валидаторов их ключи могут быть куплены, украдены, сохранены, восстановлены из резервных копий или раскрыты через скомпрометированные системы подписания. Необходимый вес и типы сообщений зависят от протокола; одного старого ключа предлагающего блок валидатора автоматически недостаточно.
  3. Построить допустимую по протоколу альтернативу. Злоумышленник создает блоки, голоса, сертификаты и изменения набора валидаторов, которые проходят исторические проверки клиента жертвы. Недопустимый переход состояния, неверный домен, невозможное время или отсутствие доказательства все равно делают ветвь недействительной.
  4. Продлить и предъявить ветвь. Дешевое создание подписей может позволить заполнить длинную историю, но само количество блоков не является решающим. Ветвь должна победить или обойти точную процедуру выбора, применяемую в данном режиме синхронизации.
  5. Контролировать представление при начальной синхронизации. Жертву изолируют от свежей аутентифицированной контрольной точки и свидетельств честных пиров, а альтернативную историю показывают как единственного или предпочтительного кандидата.
  6. Добиться доверия зависимых систем. Если узел примет неверное состояние, его RPC, кошелек, индексатор, монитор моста или приложение могут показывать балансы, события и состав валидаторов, которые допустимы по протоколу в ветви атакующего, хотя действующая сеть следует другой цепочке.

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

Подробный пример

Предположим, что набор валидаторов V_old контролировал гипотетическую PoS-цепочку на эпохе 120,000. Через несколько лет более 2/3 этого исторического веса вышло из системы и больше не подпадает под санкции протокола. Злоумышленник получает старые ключи и начинает конфликтующую историю сразу после контрольной точки C_old.

В искусственной ветви злоумышленник подписывает голоса, необходимые гипотетическому протоколу, затем меняет состав валидаторов и продолжает историю до эпохи 420,000. Честная сеть также достигла эпохи 420,000, поэтому одинаковые номера эпох или более длинный файл не сообщают синхронизирующемуся узлу, какая ветвь является канонической для сообщества и действующих систем. Допустимость искусственной ветви зависит от всех исторических правил протокола.

Узел N_live наблюдал настоящую финализированную контрольную точку C_recent на эпохе 419,936. Поскольку атакующая ветвь не происходит от C_recent, N_live ее отклоняет. Узел N_new, напротив, начинает от генезиса, подключается только к пирам злоумышленника и не имеет свежей аутентифицированной опорной точки. Если его протокол и режим синхронизации не позволяют отличить истории только по внутренним доказательствам, он может принять атакующую ветвь.

Если предоставить N_new аутентифицированную пару C_recent = (root, 419,936), граница принятия решения изменится. Клиент обязан потребовать, чтобы путь синхронизации содержал именно эту контрольную точку, и безопасно прекратить работу, если это невозможно. Эпохи и порог 2/3 в примере иллюстрируют одну схему с финализацией; это не универсальные параметры PoS и не текущие настройки какой-либо названной сети.

Меры защиты и контрольный список

Проектирование протокола

  • Точно опишите модель безопасности от дальних атак: последующую компрометацию, ротацию валидаторов, адаптивную компрометацию ключей, сетевую изоляцию и доступность данных.
  • Определите, какие финализированные состояния нельзя отменять и как правило выбора ветви обрабатывает конфликт с локально доверенной опорной точкой.
  • Ограничьте выход и вывод средств валидаторов и ротацию набора так, чтобы предположения безопасности сохраняли смысл, а противоречивые подписи можно было обнаружить и наказать.
  • Задавайте период слабой субъективности или альтернативное предположение о безопасности синхронизации как величину, вычисляемую из текущего состояния и констант протокола, а не как неизменный календарный срок.
  • Рассмотрите подписи с эволюцией ключей или устойчивостью к последующей компрометации, если их поддерживает архитектура протокола; обычное удаление ключей полезно для безопасности, но не является полной защитой консенсуса.
  • Отдельно тестируйте первую синхронизацию, синхронизацию от контрольной точки, восстановление снимка и возврат после долгого отключения. Безопасное правило выбора ветви в работающей сети не делает начальную синхронизацию безопасной автоматически.

Начальная синхронизация и эксплуатация узла

  • До синхронизации запишите корень контрольной точки или хеш блока, эпоху или высоту, идентификатор цепочки, сеть, версию форка, время получения и поставщика.
  • Получайте опорные точки по аутентифицированным каналам и сопоставляйте несколько действительно независимых источников. Несколько сайтов, работающих от одного узла или оператора, не независимы.
  • Отклоняйте устаревшие, поврежденные, относящиеся к другой сети или конфликтующие контрольные точки. После ошибки проверки не переходите незаметно к синхронизации без опорной точки.
  • Требуйте, чтобы синхронизированная цепочка содержала точную опорную точку, и проверяйте всех ее потомков предназначенными для этого клиентами консенсуса и исполнения.
  • Обеспечьте разнообразие пиров, клиентов, операторов и RPC; отслеживайте признаки eclipse-атаки, расхождение финализированных корней, необычные откаты и длительные сбои финализации.
  • Повторно проверяйте опорную точку после восстановления старой базы данных или резервной копии и обновляйте ее в пределах безопасного периода, указанного в документации протокола.

Доверие приложений

  • Не освобождайте депозиты и сообщения мостов и не проводите необратимые сделки лишь потому, что недавно синхронизированный RPC сообщил об успехе.
  • Перед важным действием сопоставьте идентичность цепочки, финализированную контрольную точку и происхождение событий по независимым узлам.
  • Отделяйте историю консенсуса от истины на уровне приложения: каноническая цепочка не доказывает корректность оракула, безопасность контракта, доступность данных вне протокола или платежеспособность хранителя.
  • Подготовьте политику остановки при конфликтующих финализированных контрольных или доверенных опорных точках. Такая ситуация может указывать на сбой консенсуса, поврежденные начальные данные или неверную сеть; ее нельзя автоматически разрешать выбором более длинной ветви.

Распространенные заблуждения

  • Все PoS-цепочки уязвимы одинаково. Устойчивость к дальним атакам зависит от изменения валидаторов, подписей, финализации, выбора ветви, контрольных точек и предположений синхронизации конкретного протокола.
  • Старые ключи позволяют без ограничений переписать любую транзакцию. Атакующий все равно должен создать историю, которую примут все правила проверки жертвы; исторические полномочия необходимы лишь в некоторых схемах атаки и могут быть недостаточны.
  • Настоящей является цепочка с наибольшим числом блоков, эпох или подписей. Выбор зависит от определенных протоколом допустимости, веса, сертификатов и опорных точек, а не от универсального сравнения длины.
  • Одной финализации достаточно, чтобы узел от генезиса определил признанную сообществом цепочку. Две внутренне допустимые финализированные истории могут быть неразличимы для узла без свежего аутентифицированного представления; финализация защищает узел, который уже знает соответствующую контрольную точку.
  • Штрафное списание всегда сдерживает атаку. У полностью вышедших валидаторов может не остаться залога для списания, а доказательство должно однозначно указывать виновника и быть обработано, пока санкции еще исполнимы.
  • Контрольная точка означает вечное доверие одной компании. Доверие можно ограничить конкретной свежей опорной точкой и снизить благодаря аутентифицированному распространению, независимым сверкам и последующей локальной проверке.
  • Удаление ключей вышедших валидаторов решает проблему протокола. Безопасное уничтожение снижает риск компрометации, но надежные правила консенсуса и начальной синхронизации должны допускать, что некоторые исторические ключи станут доступны.

Связанные темы

Источники

Навигация

Поиск по вики...