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