By Bitcoin Журнал - 6 месяца назад - Время чтения: 6 минуты
Посмертное заключение о велосипедной атаке на замену Lightning
Поэтому вокруг было поднято много шума. Уязвимость к молниям недавно раскрытый Антуаном Риаром. Многие люди утверждают, что небо падает, что Молния фундаментально сломана, и ничто не может быть дальше от истины. Я думаю, что отчасти проблема в том, что люди на самом деле не понимают, как работает эта уязвимость, во-первых, а во-вторых, многие люди не понимают, как эта отдельная уязвимость перекрывается с другими известными проблемами в сети Lightning, имеющими известные решения.
Итак, для начала давайте разберемся и попытаемся понять саму уязвимость. Когда платеж Lightning маршрутизируется по сети, важно понять, как работают временные блокировки для возврата средств за неудавшийся платеж. Переход, ближайший к получателю, имеет временную блокировку «x», а каждый переход, возвращающийся к отправителю, имеет один из «x+1», «x+2» и т. д. Временные блокировки становятся все длиннее по мере того, как вы проходите каждый переход от получателя обратно к отправителю. Причина этого в том, что если платеж достигает получателя, но какая-то проблема мешает распространению прообраза обратно к отправителю, узел, на котором он остановился, успевает применить его в цепочке и поместить прообраз туда, и все это происходит. предыдущие переходы должны подтвердить оплату. Другойwise кто-то посередине, где происходит сбой, может потребовать, чтобы их исходящий переход запросил средства с помощью прообраза, а переход, который переслал им их, запросил их с помощью своего пути возврата, и оставил этого человека посередине, черт возьми, не повезло, проиграв средства.
Атака с циклической заменой — это сложный способ попытаться добиться именно этого нежелательного результата: целевой узел теряет деньги, поскольку исходящий узел требует средства в результате успешной транзакции, а входящий узел требует средства посредством транзакции возврата. Это требует остановки узла-жертвы и предотвращения просмотра прообраза в успешной транзакции на одной стороне до тех пор, пока не истечет временная блокировка на другой стороне, чтобы они могли потребовать возмещение там.
Это требует очень целенаправленной и сложной игры по манипулированию мемпулом жертвы. Давайте посмотрим на фактическую структуру транзакции, задействованную здесь. У вас есть транзакция фиксации, которая является основной транзакцией, представляющей состояние канала Lightning. Он имеет выходные данные для каждой стороны канала, представляющие средства, полностью находящиеся под контролем того или иного участника, а также выходные данные для каждого HTLC, находящегося в процессе маршрутизации. Именно эти результаты нас и интересуют. Каждый вывод HTLC можно потратить либо сразу в любой момент вместе с прообразом от приёмника, либо после истечения таймлока на возврат.
Атака требует, чтобы злоумышленник или две сговорившиеся стороны имели канал по обе стороны от узла жертвы, направляющий платеж. Таким образом, у Боба, жертвы, есть канал с Алисой и Кэрол, злоумышленниками, и платеж направляется от Кэрол к Бобу и Алисе. Помните, что срок действия временной блокировки между Алисой и Бобом истечет и станет действительным до момента возврата средств между Кэрол и Бобом.
Злоумышленники направляют платеж через Боба, и тогда Алиса откажется отправить Бобу прообраз для завершения платежа, когда она его получит. Теперь Боб будет ждать, пока истечет время временной блокировки между ним и Алисой, и перейдет к трансляции транзакции фиксации канала и транзакции возврата, чтобы получить ее подтверждение до истечения срока временной блокировки. Затем Алиса потратит транзакцию прообраза, чтобы потребовать средства с выходом, не связанным с каналом, и сразу после этого дважды потратит второй вход в успешной транзакции прообраза. Цель здесь — исключить транзакцию тайм-аута Боба из мемпула, а также исключить успешную транзакцию прообраза, чтобы Боб ее не увидел. Если он это сделает, он узнает прообраз и сможет просто потребовать средства в своем канале с Кэрол до того, как ее транзакция по тайм-ауту станет действительной для расходования.
Алисе и Кэрол приходится делать это постоянно, каждый раз, когда Боб ретранслирует свою транзакцию тайм-аута Алисе, пока высота блока не достигнет уровня, при котором транзакция тайм-аута Кэрол действительна. Затем они могут отправить успешную транзакцию на стороне Алисы и транзакцию тайм-аута на стороне Кэрол, и оставить Бобу держать сумку, потеряв стоимость платежа, который он направлял.
Проблема здесь двоякая. Во-первых, жертва Bitcoin Базовый узел должен быть специально нацелен, чтобы гарантировать, что успешная транзакция прообраза никогда не распространится в их мемпул, где их узел Lightning сможет получить прообраз. Во-вторых, если вторая транзакция, которую Алиса использует для исключения транзакции прообраза, подтверждается, Алиса несет затраты (помните, идея состоит в том, чтобы заменить транзакцию тайм-аута прообразом, чтобы он был исключен из мемпула, а затем заменить транзакцию прообраза на транзакцию прообраза). второй — двойная трата дополнительных входных данных в транзакции прообраза). Это означает, что каждый раз, когда Боб повторно передает свою транзакцию тайм-аута, Алисе приходится платить более высокую комиссию за ее повторное выселение, и когда это подтверждается, она фактически несет затраты.
Таким образом, Боб может заставить Алису понести большие затраты, просто регулярно ретранслируя свою транзакцию тайм-аута с более высокой комиссией, а это означает, что если вывод платежа HTLC не стоит значительно больше, чем комиссии, которые может понести Алиса, атака экономически нецелесообразна для осуществления . Также можно было бы полностью предотвратить атаку, изменив способ построения HTLC-транзакций успеха и тайм-аута. Использование флага SIGHASH_ALL означает, что подпись фиксирует всю транзакцию и становится недействительной, если изменяется мельчайшая деталь (например, добавление новых входных данных в транзакцию прообраза, необходимую для этой атаки). Это не будет работать с текущей версией каналов Lightning, используя якорные выходы, но это полностью решило бы проблему. Питер Тодд также предложил новая функция консенсуса это полностью решило бы проблему, по сути, это обратная блокировка времени, при которой транзакция стала бы недействительной. после определенное время или высоту блока вместо того, чтобы стать действительным после этого. Однако, на мой взгляд, заходить так далеко не обязательно.
Простая регулярная ретрансляция вашей транзакции с небольшим увеличением комиссии — это значительное смягчение атаки, но существует также множество динамики, которые в любом случае делают это несерьезной проблемой. Во-первых, если вы не являетесь узлом маршрутизации, это не является серьезной проблемой. Таким образом, большинство конечных пользователей застрахованы от этой атаки. Во-вторых, существует множество причин, по которым узлы не позволяют случайному человеку открывать к ним каналы. Крупные узлы очень избирательно относятся к тому, с кем они взаимодействуют, поскольку случайные каналы, которые не управляются эффективно или профессионально, имеют издержки в виде потерянного или потраченного впустую капитала в неиспользуемых каналах. Таким образом, к любому крупному узлу, который может стать интересной целью для этой атаки, не так просто даже подключиться, не говоря уже о том, чтобы подключиться к нему по нескольким каналам, чтобы в первую очередь осуществить атаку. Наконец, как Я писал об этом в прошлом, другие несвязанные атаки, возможные в сети, уже требуют фильтров и ограничений на то, как узлы решают обрабатывать HTLC, которые они могут пересылать. Т.е. ограничения на размер платежей, которые они будут пересылать, сколько они разрешат в любой момент времени и т. д. Таким образом, даже если вы сможете открыть канал с узлом, достойным атаки, по мере развития сети будет больше продуманных критериев и фильтров. для принятия решения о том, следует ли вообще пересылать платеж.
В целом это вполне законная проблема и возможная атака, но как с точки зрения прямых мер по смягчению последствий, так и того, как атака будет взаимодействовать с решениями других проблем в долгосрочной перспективе, это не неразрешимая проблема. Это вполне законная проблема, и отбрасывать ее как чисто FUD — неправильная реакция, но утверждать, что небо рушится и сеть Lightning Network как протокол обречена, — это сильно преувеличивать проблему.
Время идет, мы сталкиваемся с проблемами, и мы будем решать эти проблемы по мере их поступления. Как у нас всегда.
Исходный источник: Bitcoin Журнал