Doszły nas słuchy, że wykryta luka w zabezpieczeniach kryptowalut opartych na konsensusie Proof of Stake nadal powoduje problemy w wielu topowych kryptowalutach i pomimo bieżących zmian i aktualizacji, w wielu przypadkach są one nadal podatne na ataki. Na czym polegają zaburzenia bezpieczeństwa w kontekście Proof of Stake i jakie są widoki na przyszłość w tym temacie?
Decentralized Systems Lab na tropie luk
Fake stake jest ostatnio na tapecie. Zespół, który odkrył te luki, przetestował je dokładnie i pokazał światu to grupa młodych ludzi z Decentralized Systems Lab @UIUC z Illinois, USA. W skład zespołu weszli: Sanket Kanjalkar (sanket1729, smk7@illinois.edu), Yunqi Li, Yuguang Chen, Joseph Kuo oraz Andrew Miller(socrates1024).
Wykryte i opisane przez nich luki dotyczą generalnie dwudziestu sześciu kryptowalut opartych o POS. Polegają one na umożliwieniu atakującemu przeprowadzenia ataku pomimo posiadania bardzo małego udziału w stake’u lub nie posiadając takiego udziału w ogóle. Osoba dokonująca ataku może w bardzo prosty sposób zaatakować dowolny węzeł sieci wykorzystując do tego celu specjalne oprogramowanie.
Zespół z Illinois rozpoczął swoje badania nad tym problemem już jakiś czas temu, a w końcu w październiku ubiegłego roku po raz pierwszy ujawnili problem. Skontaktowali się z zespołami projektów, które według nich były zagrożone atakami. Większość z nich już wdrożyła odpowiednie usprawnienia, jednakże są tacy, którzy nadal poddają to w wątpliwość.
Wiemy, że coś jest na rzeczy i wady tego systemu nie zostały jeszcze z powodzeniem usunięte w wielu projektach kryptowalutowych. Tym bardziej warto zapoznać się z tematem i z uwagą śledzić dalszy rozwój sytuacji w tym zakresie.
Ten tekst stanowi omówienie najważniejszych zagadnień związanych z wykrytymi lukami. W dużej mierze stanowi parafrazę opracowania opublikowanego przez DSL na platformie Medium. Celem niniejszej publikacji jest uświadomienie problemu tym wszystkim, którzy jeszcze nie mieli okazji zapoznać się z tym zagadnieniem.
Co to jest Fake Stake?
Kryptowaluty Proof of Stake (PoS), szczególnie te oparte na PoSv3 (Proof-of-Stake version 3) są podobne do Bitcoina, ponieważ używają modelu UTXO i najdłuższego łańcucha reguł konsensusu. Podstawową różnicą jest to, że zastępują POW dowodem POS.
Wiele kryptowalut to w rzeczywistości forki (lub przynajmniej potomkowie) bazy kodu Bitcoin, z wbudowaną funkcjonalnością PoS. Jednak niektóre pomysły projektowe są niepoprawnie kopiowane, co prowadzi do nowych luk, które nie istniały w nadrzędnej bazie kodów.
Autorzy badania nazwali możliwość ataku spowodowanego luką mianem „Fake Stake”. Co do zasady atak tego rodzaju działa na takiej zasadzie, że implementacje PoSv3 nie sprawdzają poprawnie danych sieciowych przed zatwierdzeniem cennych zasobów (dysku i pamięci RAM). Konsekwencją jest to, że atakujący bez stake’a odpowiedniej wielkości (w niektórych przypadkach w ogóle go nie posiadając) może spowodować awarię węzła ofiary przez wypełnienie jego dysku lub pamięci RAM fałszywymi danymi.
Zdaniem zespołu z Illinois, wszystkie waluty oparte na UTXO i najdłuższym łańcuchowym modelu Proof of of Stake są podatne na ataki „Fake Stake”.
W tym artykule znajdziesz wyjaśnienie, na czym dokładnie polegają ataki Fake Stake. Chociaż sama wada, która je powoduje jest relatywnie prosta, to samo rozwiązanie problemów, które może je powodować już nie do końca. Wszystkie działania, które prowadzą do ograniczenia istniejącego ryzyka ataku prowadzą w prostej linii do ryzyka podziałów łańcucha.
Zrozumieć Proof of Stake
Żeby w całości zrozumieć omawiany problem, musimy sięgnąć do teorii Proof of Stake. W poniższym paragrafie znajdziecie garść informacji, które niewtajemniczonym przybliżą nieco zagadnienie, a starym wyjadaczom nakreślą w sposób oczywisty szerszy kontekst dla całego problemu.
Uwaga!
Jeżeli jesteś kompletnie „zielony” w temacie algorytmów konsensusu, takich jak PoW czy PoS, polecam sięgnąć do przygotowanego przez naszą redakcję opracowania, które w prosty i przystępny sposób nakreśli Ci cały temat.
Możesz również spokojnie kontynuować lekturę niniejszego artykułu. Spróbujemy w tym miejscu w jak najprostszy sposób wyjaśnić podstawowe kwestie związane z tymi metodami osiągania konsensusu abyś mógł zrozumieć to, o czym będzie mowa w dalszej części tekstu.
Mówiąc prosto, metoda wydobywania POS polega na tym, że każdy uczestnik sieci, który posiada określoną ilość danej kryptowaluty trzyma ją na dedykowanym serwerze zewnętrznym lub na własnym komputerze. W zależności od wielkości zasobów portfela (stake’u), taki uczestnik sieci otrzymuje kryptowaluty wprost proporcjonalnie do zasobności jego portfela. To oczywiście duże uproszczenie.
Stakeholder otrzyma swoja nagrodę jedynie pod warunkiem nieustannej aktywności swojego portfela. Idzie za tym, rzecz jasna, konieczność posiadania stałego łącza internetowego oraz komputera, który będzie działał 24 godziny na dobę. W ten sposób moc obliczeniowa sieci jest wspierana przez aktywne, podłączone do niej węzły. Pozwala to oczywiście na szybszy przepływ informacji i sprawniejsze wydobywanie bloków.
Jak to działa?
Podobnie, jak ma to miejsce w przypadku PoW, wydobywanie PoS polega na porównywaniu skrótu nagłówka bloku do wyznacznika trudności kopania. Jednym z podstawowych celów PoS jest zapewnienie, że szansa każdego zainteresowanego na wydobycie następnego bloku jest proporcjonalna do liczby monet, które kontroluje. Aby to osiągnąć, w przypadku PoS hash zależy nie tylko od nagłówka bloku, ale także od ilości monet zawartych w specjalnej transakcji „coinstake” wstawionej do bloku przez interesariusza.
W kontekście naszych rozważań na temat luk w bezpieczeństwie kryptowalut opartych na Pos kluczowe jest natomiast zrozumienie dwóch kwestii:
PoS zależy od:
- transakcji coinstake
- czasu UTXO wydanego przez transakcję coinstake
UTXO (Unspent Transsaction Output) oznacza niewydane dane wyjściowe z transakcji bitcoin. Każda transakcja bitcoin zaczyna się od monet używanych do zbilansowania księgi głównej. UTXO są przetwarzane w sposób ciągły i są odpowiedzialne za rozpoczynanie i kończenie każdej transakcji. Potwierdzenie transakcji skutkuje usunięciem zużytych monet z bazy danych UTXO. Zapis o wykorzystanych monetach nadal istnieje w głównym rejestrze.
Czym to się różni od Proof of Work?
Wszyscy doskonale zdajemy sobie sprawę z tego, ze w strukturze Bitcoina podstawową metodą walidacji poprawności wydobycia bloków jest Proof of Work. Pełni on w algorytmie sieci Bitcoina rolę absolutnie podstawową i nadrzędną.
Istnieje jednak druga strona mocy… Jest nią często niedoceniana rola, dzięki której chroniony jest dostęp do ograniczonych zasobów węzła, takich jak dysk, przepustowość, pamięć i procesor.
Aby zapobiec atakom polegającym na wyczerpaniu zasobów, węzły Bitcoin najpierw sprawdzają PoW dla wszystkich odebranych bloków, zanim zaangażują więcej zasobów, takich jak przechowywanie bloku w pamięci RAM lub na dysku. Okazuje się jednak, że sprawdzanie PoS jest o wiele bardziej skomplikowane i kontekstowe niż PoW. W rezultacie tego wiele opartych na łańcuchach implementacji PoS poskąpiło odpowiedniego poziomu walidacji poprawności działania sieci.
Aby zrozumieć, w jaki sposób prowadzi to do podatności na wyczerpanie zasobów, trzeba podać trochę szczegółów na temat przechowywania bloków przed sprawdzeniem poprawności. Węzeł musi nie tylko śledzić najdłuższy łańcuch w bieżącej chwili, ale także drzewo łańcuchów forkowych (każdy z nich może okazać się najdłuższym łańcuchem, w którym to przypadku węzeł musi „przeorganizować”, aby się do niego przełączyć ). Może się to zdarzyć, na przykład, podczas nieudanej aktualizacji, ataku polegającym na podwójnym wydaniu (ETC under 51% attack) lub tymczasowym podzieleniu sieci.
Trzeba sobie uświadomić, że sprawdzanie poprawności bloków łańcucha poza główną siecią jest dosyć trudne. W celu pełnej weryfikacji bloku potrzebny jest zestaw monet, które nie zostały wydane (UTXO) w czasie poprzedniego bloku. Sieć Bitcoin nie podtrzymuje zestawu UTXO dla wszystkich poprzednich bloków, od których mógłby rozpocząć się fork. W związku z tym istnieją dwa podejścia do sprawy rozwiązania procesu sprawdzenia poprawności bloków na forku:
- przywrócenie bieżącego widoku danych (zestawu UTXO) do punktu przed rozpoczęciem forka
- przechowywanie kopii zestawu UTXO dla wszystkich wcześniejszych bloków.
Jak to ogarnąć?
Podkreślmy to raz jeszcze: Bitcoin nie obsługuje przechowywania kopii zestawu UTXO dla wszystkich wcześniejszych bloków. Nawet, gdyby to umożliwiał, nałożyłby dodatkowy koszt przechowywania. Trzeba bowiem pamiętać, że wydajność węzła Bitcoin opiera się na oczyszczaniu niepotrzebnych danych.
Przywracanie bieżącego widoku danych jest zatem sposobem, w jaki sposób baza kodów Bitcoin aktualnie obsługuje reorg. Może to być jednakże bardzo kosztowne przez wzgląd na fakt, że wycofanie i pełna walidacja są odłożone do ostatniej możliwej chwili. Dokładnie rzecz biorąc do momentu, kiedy PoW na forku jest już większy niż obecny łańcuch główny.
W związku z powyższym, gdy uczestnik najpierw otrzymuje blok lub nagłówek, który nie jest częścią najdłuższego łańcucha pełna weryfikacja jest pomijana, a blok jest zapisywany w pamięci lokalnej.
Przed przechowywaniem bloku na dysku, baza danych Bitcoin wykonuje wstępną walidację na podstawie PoW, ignorując póki co transakcje. Takie wstępne sprawdzenie zależy wyłącznie od poprzedniego nagłówka bloku i bieżącego nagłówka, więc węzeł jest w stanie osiągnąć pożądany efekt relatywnie szybko.
Skuteczna obrona
Ekipa z Illinois zwraca uwagę, że to jest właśnie skuteczna obrona, ponieważ generowanie prawidłowego PoW, który przechodzi taką kontrolę jest bardzo kosztowne. Na przykład, mimo że możliwe jest oszukiwanie węzła Bitcoin w celu przechowywania nieprawidłowego bloku na dysku, jest zbyt drogie, aby przeprowadzić w ten sposób atak nastawiony na wyczerpanie zasobów.
Analogicznie przeprowadzany jest proces wstępnej kontroli w Proof of Stake. Ma on na celu sprawdzenie transakcji coinstake i utwierdzenie się w przekonaniu, czy przechodzi ona przez difficulty target, gdy zostanie zaszyfrowany z jądrem poprzedniego bloku. Obliczanie skrótu transakcji coinstake jest łatwe, ale najtrudniejsze jest sprawdzenie, czy wejściowy UTXO do niej jest poprawny i niewydany, ponieważ wymaga to sprawdzenia zestawu UTXO, który jak wspomniano wcześniej, nie jest dostępny dla poprzednich bloków. Ponieważ pełna weryfikacja transakcji coinstake jest trudna, większość opartych na łańcuchach implementacji PoS zapewnia zamiast tego kontrolę heurystyczną lub przybliżoną. Okazuje się, że te przybliżenia są często niewystarczające i można je wykorzystać.
Luki bezpieczeństwa Proof of Stake
Luka numer 1
Wariant 1
Decentralized Systems Lab odkryło, że Qtum, Particl, Navcoin, HTMLcoin i Emercoin, przejawiają dość banalną formę tej luki:
nie sprawdzają w ogóle żadnej transakcji coinstake przed zatwierdzeniem bloku do pamięci RAM lub nadysk.
Te pięć kryptowalut łączy fakt, że zaadoptowały cechę Bitcoina „headers first”. W tym typie funkcji, propagacja bloku została podzielona na dwie oddzielne wiadomości: Blokuj (Block) i Nagłówek (Header).
Węzły żądają wiadomości Block wyłącznie po tym, jak nagłówek przejdzie testy PoW i jest to najdłuższy (lub dłuższy) łańcuch. Ponieważ transakcja coinstake jest obecna tylko w bloku, ale nie w nagłówku, węzeł nie może samodzielnie zatwierdzić nagłówka. Zamiast tego węzeł bezpośrednio przechowuje nagłówek do struktury danych w pamięci (mapBlockIndex). W rezultacie dowolny atakujący sieci, nawet bez żadnego udziału, może wypełnić pamięć RAM węzła ofiary.
Wariant nr 2
Wykorzystanie opisanej luki można przeprowadzić bez posiadania jakiegokolwiek udziału w atakowanej kryptowalucie. Atak można przeprowadzić zarówno w wersji RAM, jak i drugiej wersji – na dysk. Wersja ataku RAM jest szczególnie trywialna, ale ze względów technicznych atak na dysk wymaga nieco więcej uwagi (choć nadal nie jest wymagana żaden stake). Szczegóły wyjaśniono w krótkim dokumencie Financial Cryptography 2019
Luka nr 2 – Spent Stake Attack
Zauważono, że luka nr 1 została pierwotnie wprowadzona podczas łączenia funkcji „header-first” Bitcoina z kodem PoSv3. Atak nie działa na wcześniejszych wersjach (na przykład Peercoin), ponieważ przed przechowywaniem bloków na dysku przeprowadzane są dwie dodatkowe wstępne kontrole:
- czy zużyty produkt wyjściowy znajduje się w głównym łańcuchu
- czy hash jądra PoS spełnia difficulty target
Punkt 1 jest wykonywany przez wyszukiwanie w bazie danych transakcji (TxDB), która śledzi dotychczas wszystkie transakcje w bieżącym łańcuchu głównym. Innymi słowy, wstępna walidacja jest lepsza niż brak walidacji, ale wciąż heurystyczną i niepełną aproksymacją jej pełnej wersji.
W tym miejscu rodzą się dwa przypadki:
A: Kontrola 1 zapewnia, że moneta istnieje, ale NIE ZAPEWNIA, że nie została wydana.
B: Nawet jeśli blok zostaje zatwierdzony na forku głównego łańcucha, transakcja coinstake jest walidowana względem TxDB dla samego łańcucha głównego.
Skoordynowane ujawnianie luk
Zespół z Illinois jako pierwszą zbadał lukę w zabezpieczeniach numer 1 w kontekście kryptowalut Particl i Qtum. Aby określić rozmiar tej luki, zebrali listę znanych kryptowalut z serwisu coinmarketcap.com (z dnia 9 sierpnia 2018 r.) posortowaną według pułapu rynkowego, oraz przefiltrowaną według konsensusu PoS opartego na łańcuchach. Przyjrzeli się tylko kryptowalutom, których baza stanowił potomstwo Bitcoina, tj. W C ++. W sumie zbadali 26 kryptowalut i stwierdzili, że luka dotyczyła tylko pięciu z nich (Qtum, Navcoin, HTMLcoin, Emercoin i Particl). Próby przeprowadzenia ataku na pozostałe kryptowaluty zakończyły się niepowodzeniem.
Następnie pogrzebali jeszcze trochę, aby zrozumieć, dlaczego nietknięte kryptowaluty nie były podatne na pierwszy atak i zdali sobie sprawę, że luka numer 2 była znacznie bardziej wszechobecna.
Ostatecznie zdecydowali się skupić uwagę na komunikowaniu się z piętnastoma zespołami programistów związanymi z kryptowalutami, które najprawdopodobniej mogły zostać zaatakowane.
Jednym z komplikujących sprawę czynników było to, że większość tych baz kodów nie zawierała trybu regtest, więc nie było możliwe łatwe zademonstrowanie ataku lub dostarczenie zestawu odtwarzalności dla każdego z nich.
Dlatego udostępnili tylko demonstrację w bazie kodu języka C ++ dla stratisX. W oparciu o podobieństwo w bazach kodu, poinformowali o swoim odkryciu wszystkie piętnaście zespołów. Pięć zespołów przyznało się do luki, trzy nadal prowadzą dochodzenie, trzy odrzuciły je (wskazały zmiany w implementacji, które miały efekt łagodzący), a cztery zespoły nie udzieliły odpowiedzi. W przypadku czterech zespołów, które nie odpowiedziały, skontaktowali się z nimi za pośrednictwem kanałów, które można znaleźć na ich stronach internetowych. Zestaw odtwarzalności Github dla obu luk można znaleźć tutaj, a krótki artykuł na temat luki # 1 można znaleźć tutaj.
Działania łagodzące
W odpowiedzi na ujawnione luki, niektóre zespoły wdrożyły szereg działań, dzięki którym możliwe było złagodzenie lub wyeliminowanie podatności na ataki spowodowane przez luki.
Stan na 07.02.2019:
| Name | Ticker | MarketCap | Vulnerability #1: No Stake | Vulnerability #2: Spent Stake | ||
| Exploitable | Status | Exploitable | Status | |||
| Qtum | QTUM | 952,265,768 | ✓ | Fixed | ✗ | |
| Emercoin | EMC | 110,386,208 | ✓ | Fixed | ✗ | |
| Particl | PART | 47,065,433 | ✓ | Fixed | ✗ | |
| NavCoin | NAV | 39,029,633 | ✓ | Fixed | ✗ | |
| HTMLCOIN | HTML | 25,447,981 | ✓ | Fixed | ✗ | |
| StratisX | STRAT | 302,105,983 | ✗ | Moved to different node software | ||
| PIVX | PIVX | 153,755,781 | ✗ | ✓ | Fixed | |
| ReddCoin | RDD | 147,438,673 | ✗ | ✓ | Not informed(no recent github activity) | |
| Neblio | NEBL | 66,347,971 | ✗ | ✓ | Acknowledged; working on fix | |
| Peercoin | PPC | 40,556,844 | ✗ | ✓ | Rebutted | |
| CloakCoin | CLOAK | 28,772,914 | ✗ | ✓ | Pending confirmation | |
| Experience-Points | XP | 24,227,526 | ✗ | ✓ | Pending confirmation | |
| BitBay | BAY | 24,064,909 | ✗ | ✓ | Not informed(no recent github activity) | |
| Linda | LINDA | 21,960,091 | ✗ | ✓ | ||
| Phore | PHR | 19,628,809 | ✗ | ✓ | Fixed | |
| ColossusCoinXT | COLX | 17,028,079 | ✗ | ✓ | Acknowledged; working on fix | |
| PotCoin | POT | 16,212,367 | ✗ | ✓ | Not informed(no recent github activity) | |
| DeepOnion | ONION | 14,740,554 | ✗ | ✓ | Rebutted; Fixed | |
| ALQO | ALQO | 14,205,565 | ✗ | ✓ | No response | |
| Bean-Cash | BITB | 13,475,106 | ✗ | ✓ | Not informed(no recent github activity) | |
| Divi | DIVX | 13,349,316 | ✗ | ✓ | Pending confirmation | |
| NoLimitCoin | NLC2 | 12,941,709 | ✗ | ✓ | Fixed | |
| HempCoin | THC | 12,779,111 | ✗ | ✓ | Not informed(no recent github activity) | |
| LUXCoin | LUX | 11,046,202 | ✗ | ✓ | Fixed | |
| BlackCoin | BLK | 10,848,600 | ✗ | ✓ | Acknowledged; working on fix | |
| Diamond | DMD | 10,158,775 | ✗ | ✓ | Acknowledged; working on fix |
źródło: tutaj
Zestawienie aktualizowane na bieżąco
Zestawienie jest na bieżąco aktualizowane o informacje odnośnie postępu prac zespołów programistycznych i stopnia pomyślnego usunięcia zagrożeń z kodu. Na stronie źródłowej znajdziecie również komentarze odnośnie wielu kryptowalut z tego zestawienia na temat poczynionych dotychczas działań zmierzających w kierunku jak najszybszego rozwiązania problemów.
Trzeba dodać, że niektóre kryptowaluty zastosowały ograniczenia, które wykrywają ataki i odłączają się od szkodliwych uczestników. W prostych słowach, węzeł monitoruje swoich rówieśników pod kątem nietypowego zachowania (np. wysyłając wiele nagłówków na forkach). Wyzwanie związane z takimi heurystykami polega na tym, że trudno odróżnić rzeczywisty atak od uczciwego węzła – istnieje ryzyko błędnego zablokowania uczciwych węzłów.
W efekcie prowadzonych działań zaobserwowano szereg działań łagodzących wdrażanych przez zespoły w odpowiedzi na ujawnienie problemów. Niektóre kryptowaluty zastosowały ograniczenia, które wykrywają ataki i odłączają się od szkodliwych uczestników.
Dodawały częściową walidację do określonej długości. Jeśli uczestnik otrzymuje blok, który widzi z głównego łańcucha po tej długości, blok jest po prostu odrzucany. Takie podejście jest również podejmowane, na przykład, w bazie kodów ABC BCH (Bitcoin Cash), która wykorzystuje 10-blokowy kroczący punkt kontrolny.
Wadą tego podejścia jest to, że wprowadza on możliwość „podziału łańcucha”. Podział łańcucha zachodzi, gdy „uczciwe” węzły trafiają na różne rozbieżne widełki łańcucha blokowego. Może się tak zdarzyć, na przykład, jeśli słaba łączność sieciowa powoduje, że węzły nie są zsynchronizowane ze sobą przez wystarczająco długi czas, aby utworzyć kolidujące punkty kontrolne. Nawet jeśli węzły odzyskają połączenie, nie będą w stanie osiągnąć wspólnego widoku łańcucha.
Co z górnikami?
Ryzyko podziału łańcucha wprowadza również nowe możliwości ataku dla górników. Osoba atakująca może próbować w tajemnicy wydłużyć długi łańcuch, a następnie opublikować go w podzbiorze węzłów, aby spowodować podział łańcucha. Węzły w IBD (Initial Block Download) lub węzły, które zostały ponownie uruchomione po długim okresie offline, są szczególnie narażone na ten atak.
Wszystkie te działania powodują, że atak jest trudny do przeprowadzenia. Niektóre kryptowaluty, takie jak Qtum, planują przejść do pełnej walidacji bloków spoza łańcucha głównego w przyszłych wydaniach.
Użytkownikom poniższych kryptowalut należy zwrócić uwagę, aby zaktualizować swoje węzły do najnowszego uaktualnionego oprogramowania i mieć świadomość, że ta luka może zostać wykorzystana w celu zwiększenia pamięci RAM lub zużycia dysku i ewentualnej awarii.
Podsumowanie
Chociaż ataki „fake stake” są z zasady proste w swojej konstrukcji i łatwe do przeprowadzenia, podkreślają trudne wyzwanie projektowe: niektóre pomysły, które mają sens w Proof of Work, nie przekładają się bezpiecznie na Proof of Stake.
Biorąc pod uwagę wysoki stopień dzielenia kodu z Bitcoin Core jako „upstream” wśród kryptowalut PoSv3, należy uznać, że zasługuje on na objęcie go jeszcze większą kontrolą. Podczas badania tych luk znaleziono kilka przykładów w różnych bazach kodu work-in-progress (lub skomentowanego kodu), które mają na celu wprowadzanie różnych ograniczeń i mechanizmów obronnych ad hoc.
Można na tej podstawie stwierdzić, że kompromisy i wymagania przestrzeni projektowej Proof-of-Stake nie są jeszcze w pełni zrozumiałe. Wyzwanie polega na tym, że z jednej strony chcemy jak najszybciej odrzucić nieprawidłowe bloki, ale z drugiej strony nie chcemy utknąć w łańcuchu podziału lub opóźnić przetwarzania tego, co jest w rzeczywistości głównym łańcuchem. Systematyczny sposób radzenia sobie z tym pozostaje otwartym problemem dla przyszłych prac w ramach PoS.