Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Portfele sprzętowe od lat uchodzą za jeden z najbezpieczniejszych sposobów przechowywania kryptowalut, ponieważ izolują klucze prywatne od systemów podłączonych do internetu. Ich bezpieczeństwo nie zależy jednak wyłącznie od samego urządzenia, lecz również od jakości procesu generowania seeda, czyli frazy odzyskiwania stanowiącej podstawę dostępu do środków.
Najnowszy incydent związany z urządzeniami Coldcard pokazuje, że nawet wyspecjalizowany hardware wallet może stać się punktem krytycznej awarii, jeśli podczas tworzenia seeda wykorzystano przewidywalne źródło losowości. W praktyce oznacza to, że problem nie musi wynikać z malware’u, phishingu czy fizycznego przejęcia urządzenia, ale z błędu obecnego na poziomie firmware’u.
W skrócie
Badacze powiązali skoordynowane opróżnienie 1 196 adresów bitcoinowych z wadą w oprogramowaniu portfeli Coldcard. W ciągu 41 minut skradziono 1 082,65 BTC, co w chwili zdarzenia odpowiadało około 70,2 mln USD.
- Źródłem problemu był błąd w generowaniu seedów.
- Podatne wersje firmware’u używały niewłaściwego generatora pseudolosowego zamiast sprzętowego RNG.
- Aktualizacja oprogramowania nie naprawia seedów utworzonych wcześniej w podatnym środowisku.
- Użytkownicy zagrożonych urządzeń powinni wygenerować nowy seed i przenieść środki.
Kontekst / historia
Sprawa nabrała rozgłosu po dużym sweepie środków z 30 lipca 2026 roku, który objął ponad tysiąc adresów BTC i nosił cechy automatycznej, wcześniej przygotowanej operacji. Analizy wskazały, że źródło problemu mogło sięgać marca 2021 roku, kiedy zmiana w firmware skierowała proces tworzenia seeda do deterministycznego programowego PRNG zamiast do właściwego sprzętowego generatora liczb losowych.
To szczególnie istotne z punktu widzenia rynku bezpieczeństwa kryptowalut, ponieważ coraz częściej obserwuje się incydenty, w których kompromitacja nie wynika z klasycznego ataku na użytkownika, lecz z błędów w implementacji kryptografii. W tym modelu zagrożenia zawodzi nie ochrona perymetru, ale fundament całego procesu tworzenia materiału kluczowego.
Analiza techniczna
Sedno podatności polegało na tym, że część wersji firmware’u nie korzystała prawidłowo z hardware RNG podczas generowania seeda. Zamiast tego aktywowany był fallback do programowego generatora pseudolosowego, którego stan można było częściowo odtworzyć lub znacząco zawęzić na podstawie znanych parametrów wejściowych.
Według dostępnych ustaleń taki PRNG mógł być inicjalizowany m.in. danymi związanymi z unikalnym identyfikatorem układu, stanem timera i historią wcześniejszych wywołań RNG. To z kolei otwierało drogę do ataku offline: napastnik mógł generować kandydackie seedy, wyprowadzać z nich adresy i porównywać je z publicznymi danymi blockchain.
Jeżeli seed został utworzony z ograniczoną entropią, koszt brute force spada dramatycznie względem założeń bezpieczeństwa standardu BIP-39. Opublikowane analizy wskazywały, że efektywna entropia mogła wynosić około 40 bitów dla modelu Mk3 oraz około 72 bity dla modeli Mk4, Mk5 i Q. Dla porównania standardowy 12-wyrazowy seed BIP-39 powinien zapewniać 128 bitów bezpieczeństwa.
Znaczenie ma również moment utworzenia seeda. O zagrożeniu decyduje wersja firmware’u użyta w chwili generowania portfela, a nie ta zainstalowana obecnie. Za podatne uznawano między innymi następujące zakresy:
- Mk3 w wersjach 4.0.1–4.1.9,
- Mk4 i Mk5 w wersjach wcześniejszych niż 5.6.0,
- Q w wersjach wcześniejszych niż 1.5.0Q,
- wybrane buildy edge wcześniejsze niż odpowiadające im wydania naprawcze.
Kluczowy wniosek jest prosty: przywrócenie starego seeda na zaktualizowanym urządzeniu nie usuwa ryzyka, ponieważ słabość dotyczy samego materiału kryptograficznego wygenerowanego wcześniej.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją tej podatności jest możliwość cichej kompromitacji kluczy prywatnych bez fizycznego naruszenia urządzenia i bez widocznych oznak ataku. Użytkownik może przez długi czas pozostawać w przekonaniu, że środki są bezpieczne wyłącznie dlatego, że portfel pozostaje offline.
W realiach rynku kryptowalut skutki takiego błędu są wyjątkowo dotkliwe:
- transakcje blockchain są nieodwracalne,
- przejętych środków zazwyczaj nie da się odzyskać,
- publiczny charakter łańcucha bloków ułatwia automatyczne testowanie poprawności kandydackich seedów,
- duże, długo nieaktywne salda mogą stać się celem masowych operacji sweepujących.
Dodatkowe ryzyko wynika z błędnego założenia, że sam patching rozwiązuje problem. W tym przypadku aktualizacja zatrzymuje jedynie dalsze tworzenie słabych seedów, ale nie eliminuje podatności z portfeli utworzonych wcześniej. Ryzyko pozostaje aktywne aż do pełnej migracji środków na nowy seed wygenerowany po usunięciu błędu.
Rekomendacje
Użytkownicy indywidualni, zespoły bezpieczeństwa oraz podmioty zarządzające aktywami cyfrowymi powinny potraktować ten incydent jako przykład kompromitacji łańcucha generowania kluczy i wdrożyć działania naprawcze bez zwłoki.
Najważniejsze kroki operacyjne obejmują:
- ustalenie modelu urządzenia oraz wersji firmware’u użytej w chwili tworzenia seeda,
- weryfikację, czy seed powstał na podatnej wersji oprogramowania,
- aktualizację urządzenia do wydania naprawczego,
- wygenerowanie nowego seeda wyłącznie na poprawionym firmware,
- natychmiastowe przeniesienie środków na nowy portfel,
- unikanie przywracania starego seeda jako rozwiązania tymczasowego.
Warto również rozważyć dodatkowe mechanizmy ochrony:
- stosowanie silnej i unikalnej passphrase BIP-39,
- wykorzystanie architektury multisig, o ile nie opiera się ona wyłącznie na urządzeniach obciążonych tym samym błędem,
- dokumentowanie procesu inicjalizacji portfeli i użytych wersji firmware’u,
- przeprowadzanie niezależnych audytów funkcji kryptograficznych, zwłaszcza w obszarze RNG i fallbacków bezpieczeństwa.
Dla producentów sprzętu incydent stanowi wyraźne ostrzeżenie, że mechanizmy awaryjne związane z generowaniem losowości nie mogą prowadzić do cichego obniżenia poziomu bezpieczeństwa. Jeżeli system nie ma dostępu do właściwego źródła entropii, generowanie kluczy powinno zostać zablokowane, a użytkownik jednoznacznie ostrzeżony.
Podsumowanie
Przypadek Coldcard to jeden z najpoważniejszych przykładów praktycznych skutków słabej entropii w systemach chroniących aktywa cyfrowe. Powiązanie błędu firmware’u z kradzieżą przekraczającą 70 mln USD pokazuje, że bezpieczeństwo portfela sprzętowego zależy nie tylko od izolacji kluczy, ale przede wszystkim od poprawności implementacji kryptografii i jakości źródeł losowości.
Dla użytkowników najważniejszy wniosek jest jednoznaczny: jeśli seed został wygenerowany na podatnej wersji firmware’u, sama aktualizacja nie wystarczy. Konieczna jest pełna regeneracja materiału kryptograficznego i migracja środków na nowy, bezpiecznie utworzony portfel.
Źródła
- The Hacker News — https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
- Ill Bloom: Crypto Wallet Vulnerability — https://illbloom.org/
- Report a COLDCARD Security Issue — https://coldcard.com/resources/security/report-a-security-issue