117 / 736ECL

Eclipse Attack

Węzeł jest połączony, ale napastnik zasłania mu resztę sieci

Internet działa, połączenia są otwarte, a mimo to węzeł nie widzi rzeczywistej sytuacji w Bitcoinie. Przy Eclipse Attack przeciwnik kontroluje jego drogi do innych węzłów i wybiera, które wiadomości docierają.

Eclipse Attack to celowe odizolowanie węzła od uczciwych partnerów przy zachowaniu połączenia z napastnikiem. Full Node to program, który samodzielnie sprawdza reguły Bitcoina. Nadal wykonuje tę kontrolę, ale może otrzymywać jedynie niepełny lub nieaktualny obraz sieci. Atak nie zmienia danych nieprawidłowych w poprawne — wykorzystuje to, czego węzeł nie może zobaczyć.

Anna przyjmuje płatność w bitcoinie i obserwuje własny węzeł, czyli komputer z programem uczestniczącym w sieci Bitcoin. Pokazuje on aktywne połączenia, lecz przeciwnik kontroluje wszystkie istotne drogi na zewnątrz. Wiadomości nadchodzą, ale tylko te, które pozwala zobaczyć. To istota Eclipse Attack. Jedno złośliwe połączenie zwykle nie wystarczy: działająca droga do uczciwego węzła może dostarczyć zatajone bloki i naruszyć kontrolę napastnika. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. [1] [6]

Ethan Heilman, Alison Kendler, Aviv Zohar i Sharon Goldberg opisali w 2015 roku ataki na ówczesną sieć Bitcoin. Badali, jak zapełnić tablice adresowe węzła adresami napastnika, aby przy ponownym łączeniu trafiał wyłącznie na jego komputery. Wykorzystali mechanizm wyboru połączeń, nie łamiąc metod matematycznych chroniących między innymi podpisy cyfrowe. Zaproponowali także zabezpieczenia; historyczne wyniki nie mierzą skuteczności ataku na dzisiejszą wersję Bitcoin Core. [1] [7]

Po uzyskaniu izolacji może wybierać, które bloki i transakcje przekaże Annie, a które zatrzyma. Może też blokować rozchodzenie się jej własnych transakcji lub obserwować ich pochodzenie. Samo opanowanie połączeń nie wymaga większości mocy wydobywczej. Nie oznacza to jednak, że każdy dalszy atak uda się bez dodatkowego wysiłku: tworzenie nowych bloków wymaga rzeczywistej pracy. [1] [6]

Full Node Anny nadal sprawdza podpisy, warunki wydawania środków i dozwoloną nagrodę górnika. Podpisanie oznacza tu użycie klucza prywatnego, czyli tajnej wartości liczbowej, do utworzenia sprawdzalnego dowodu autoryzacji płatności. Inni mogą zweryfikować podpis, nie znając tej tajnej wartości. Węzeł Anny nie przyjmie błędnej transakcji tylko dlatego, że przysłało ją jedyne dostępne źródło. Weryfikacja nie ujawni jednak poprawnego bloku, który nigdy nie dotarł. Podobnie można rozpoznać autentyczny list, nie wiedząc, że ktoś zatrzymał wszystkie nowsze. Poprawność i kompletność dostępnej informacji to różne pytania. [5] [9]

Węzeł może zatrzymać się na ostatnim znanym bloku, podczas gdy inne postępują dalej. Odizolowany górnik może nawet nadal pracować nad porzuconą gałęzią i stracić oczekiwaną nagrodę. Długie czekanie na blok samo nie dowodzi jednak ataku: wydobywanie jest losowe, a zwykła awaria również powoduje problemy. Ważna jest zbieżność kilku objawów, nie samo powolne odświeżanie ekranu. [1] [5] [8]

Napastnik może pokazywać Annie poprawną prywatną gałąź z jej płatnością, a w pozostałej sieci wydać te same środki inaczej. Po odzyskaniu połączenia węzeł może wybrać poprawną gałąź z większą skumulowaną pracą. To Reorg, czyli zastąpienie części przyjętej historii. Płatność z porzuconej gałęzi może utracić potwierdzenie. Napastnik musi jednak zapewnić swoim blokom Proof of Work. To sprawdzalny wynik kosztownego obliczeniowo poszukiwania, którym również te bloki muszą się wykazać. Potrzebną pracę mogą wykonać także górnicy odizolowani przez napastnika. Zmyślona liczba potwierdzeń nie oszuka Full Node; powodzenie zależy też od czasu izolacji i zasobów przeciwnika. [1] [5] [6]

Obrona próbuje zapobiec temu, by wszystkie połączenia trafiły do jednego przeciwnika. Bitcoin Core grupuje znane adresy i wspiera różnorodność sieci przy wyborze połączeń wychodzących. Adres IP wskazuje miejsce w sieci, z którym program nawiązuje połączenie. Różne IP mogą jednak należeć do jednego operatora lub korzystać z tej samej infrastruktury. Zabezpieczenia ograniczają koncentrację i utrudniają atak, ale nie dowodzą niezależności każdego partnera. [3] [4]

Bitcoin Core używa krótkich połączeń feeler do sprawdzania osiągalności kolejnych adresów. Dodatkowe połączenia przekazujące bloki mają inną rolę: mogą dostarczać nowe nagłówki — zwięzłe techniczne zapisy bloków — i kolejny obraz rozwoju łańcucha. Nie jest więc prawdą, że każdy feeler od razu pobiera aktualną historię. Wskazany kod Bitcoin Core 29.0 pokazuje te różne mechanizmy obrony; żaden sam nie gwarantuje końca izolacji. [4] [8]

Znany partner dodany ręcznie może zapewnić dodatkową drogę, jeśli jest dostępny i faktycznie połączony z resztą sieci. Kilka połączeń przez jednego dostawcę nie musi jednak być niezależnych. Warto używać wspieranego oprogramowania i rozumieć ustawienia zamiast bezmyślnie kopiować cudze listy adresów. Własna weryfikacja pozostaje w mocy: zaufanie do dostępności źródła nie daje mu prawa przesyłać nieprawidłowych bloków. [2] [4] [6]

Sybil Attack oznacza działanie jednego przeciwnika pod wieloma tożsamościami; może to ułatwić Eclipse Attack. Eclipse opisuje skuteczne odcięcie konkretnego węzła lub wybranej grupy od uczciwych źródeł. Szerszy podział sieci oddziela całe jej części i nie musi powstawać w ten sposób. Dla użytkownika ważne jest, że Full Node daje samodzielną weryfikację, ale potrzebuje też informacji spoza kontroli napastnika. [1] [6]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Sybil Attack, Block Propagation, Compact Blocks, Nakamoto Consensus, Bitcoin, Full Node. Do tego hasła prowadzą również odsyłacze z Podwójne wydanie, Byzantine Generals Problem, Nakamoto Consensus, Sybil Attack.

DOC · 001Heilman et al. — Eclipse Attacks on BitcoinŹródło pierwotne DOC · 002Bitcoin Developer Guide — P2P NetworkDokumentacja DOC · 003Bitcoin Core v29.0 — addrmanDokumentacja DOC · 004Bitcoin Core v29.0 — Peer connectionsDokumentacja DOC · 005Bitcoin Developer Guide — Block ChainDokumentacja DOC · 006Bitcoin Optech — Eclipse attacksDokumentacja DOC · 007USENIX Security 2015 — Eclipse Attacks on Bitcoin’s Peer-to-Peer NetworkŹródło pierwotne DOC · 008Bitcoin Core v29.0 — Message processingDokumentacja DOC · 009Bitcoin Core v29.0 — Block validationDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna