Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo portfeli sprzętowych dla kryptowalut zależy przede wszystkim od jakości procesu tworzenia frazy seed, która stanowi podstawę do wyprowadzania kluczy prywatnych i adresów. Jeżeli źródło entropii wykorzystane podczas inicjalizacji portfela jest przewidywalne lub zbyt słabe, atakujący może odtworzyć możliwe wartości offline i następnie porównać je z danymi widocznymi w blockchainie.
Właśnie taki scenariusz opisano w odniesieniu do portfeli Coldcard. Problem nie dotyczył samego przechowywania środków, lecz etapu ich kryptograficznego „narodzenia”, czyli chwili wygenerowania seed. To szczególnie niebezpieczny typ błędu, ponieważ użytkownik może działać ostrożnie, korzystać z urządzenia offline, a mimo to pozostać narażony na utratę aktywów.
W skrócie
Według opublikowanych ustaleń część urządzeń Coldcard mogła generować seed z użyciem deterministycznego programowego generatora pseudolosowego zamiast sprzętowego generatora liczb losowych. Taka pomyłka miała wynikać z błędu integracyjnego we firmware i mogła obniżyć poziom entropii do wartości znacząco niższych od oczekiwanych w standardowym modelu bezpieczeństwa portfela.
- problem miał dotyczyć określonych wersji firmware z linii 4.x i nowszych wariantów urządzeń,
- analiza on-chain wskazała skoordynowane opróżnianie wielu adresów Bitcoin w krótkich oknach czasowych,
- aktualizacja firmware nie naprawia seed wygenerowanych wcześniej,
- najważniejszym środkiem zaradczym pozostaje wygenerowanie nowego seed i migracja środków.
Kontekst / historia
Sprawa nabrała rozgłosu po analizach wskazujących na zmasowane transfery środków z dużej liczby adresów w dniu 30 lipca 2026 roku. Wstępne szacunki mówiły o około 70,2 mln USD strat, a późniejsze analizy rozszerzyły potencjalną skalę incydentu do około 88,6 mln USD oraz większej liczby adresów powiązanych z podejrzaną aktywnością.
W tle znajduje się szerszy problem projektowy znany od lat w kryptografii: urządzenie może być poprawnie odizolowane od internetu, a mimo to pozostać podatne, jeśli już na etapie tworzenia seed wykorzystuje wadliwe źródło losowości. Tego rodzaju słabości często ujawniają się dopiero po czasie, gdy badacze lub przestępcy zrozumieją implementację i zaczną przeszukiwać przestrzeń możliwych wartości kluczy.
Analiza techniczna
Opis błędu wskazuje, że źródłem problemu była ścieżka kompilacji firmware odpowiedzialna za obsługę generatora losowości. W praktyce część logiki miała sprawdzać obecność określonego makra konfiguracyjnego zamiast jego faktycznej wartości logicznej. To mogło skutkować użyciem zapasowego mechanizmu programowego PRNG zamiast natywnego sprzętowego RNG mikrokontrolera.
Różnica między tymi mechanizmami jest fundamentalna. Sprzętowy RNG korzysta z fizycznych właściwości układu i dostarcza świeżą, trudną do przewidzenia entropię. Z kolei PRNG, jeśli zostanie zainicjalizowany ograniczonym zestawem parametrów, może generować ciąg, który da się odtworzyć lub znacząco zawęzić.
W analizowanym przypadku atakujący nie musiał infekować komputera ofiary ani przejmować fizycznie portfela. Wystarczało odtworzenie kandydackich wartości seed na podstawie znanych lub częściowo przewidywalnych parametrów startowych, wyprowadzenie z nich adresów Bitcoin i porównanie z publicznym stanem blockchain. To model ataku cichy, zautomatyzowany i trudny do zauważenia z perspektywy użytkownika końcowego.
Szczególnie niepokojące były szacunki efektywnej entropii. W opisywanym scenariuszu miała ona wynosić około 40 bitów dla modelu Mk3 oraz około 72 bitów dla modeli Mk4, Mk5 i Q, podczas gdy standardowa 12-wyrazowa fraza BIP-39 powinna zapewniać poziom odpowiadający 128 bitom. Taka różnica oznacza radykalne osłabienie odporności na ataki brute force i ataki oparte na zawężonej przestrzeni poszukiwań.
Kluczowe znaczenie ma też moment wygenerowania seed. Nawet jeśli użytkownik zaktualizował później firmware, nie oznacza to usunięcia ryzyka dla już utworzonego sekretu. Jeżeli seed powstał w podatnym okresie, pozostaje słaby niezależnie od obecnej wersji oprogramowania czy urządzenia, na którym jest później używany.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest możliwość pełnego przejęcia środków bez jakiejkolwiek interakcji z ofiarą. To odróżnia ten incydent od klasycznych kampanii phishingowych, złośliwego oprogramowania czy przejęcia sesji. Użytkownik może przestrzegać dobrych praktyk operacyjnych, a mimo to stracić aktywa z powodu historycznego błędu w procesie inicjalizacji portfela.
Ryzyko dotyczy przede wszystkim osób, które utworzyły seed na podatnych wersjach firmware. Wskazywano między innymi na modele Mk3 w wersjach 4.0.1–4.1.9, Mk4 i Mk5 przed 5.6.0, Q przed 1.5.0Q oraz odpowiednie warianty eksperymentalne Edge. Jednocześnie podkreślano, że seed wygenerowane z użyciem uczciwej, niezależnej entropii z rzutów kością nie powinny podlegać temu konkretnemu wektorowi ataku.
Incydent pokazuje także ograniczenia analizy śledczej opartej wyłącznie na blockchainie. On-chain można wykryć wzorce transferów i zidentyfikować skoordynowane działania, ale nie zawsze da się w sposób absolutnie rozstrzygający potwierdzić pochodzenie każdego pojedynczego seed. Oznacza to, że rzeczywista skala szkód może być zarówno większa, jak i częściowo obciążona niepewnością analityczną.
Rekomendacje
Najważniejszym krokiem jest ustalenie, kiedy i na jakiej wersji firmware został wygenerowany seed. Sama aktualizacja urządzenia jest konieczna, ale nie wystarcza, jeśli tajemnica początkowa powstała w czasie, gdy błąd mógł występować. W takim przypadku należy uznać seed za potencjalnie skompromitowany i przygotować pełną migrację środków.
- przeprowadzić inwentaryzację modeli Coldcard i używanych wersji firmware,
- ustalić datę utworzenia seed dla każdego urządzenia,
- wygenerować nowy seed na poprawionej wersji firmware,
- przenieść wszystkie środki do nowo utworzonego portfela,
- rozważyć użycie silnej i unikalnej passphrase BIP-39 jako dodatkowej warstwy ochrony,
- unikać budowania całego środowiska multisig wyłącznie z urządzeń narażonych na tę samą klasę błędu,
- dokumentować proces inicjalizacji portfeli na potrzeby przyszłej oceny ryzyka.
Dla producentów to z kolei ważna lekcja inżynierska. Systemy kryptograficzne powinny być testowane nie tylko funkcjonalnie, ale również pod kątem poprawnego doboru źródeł entropii, zachowania ścieżek fallback oraz skutków błędów w konfiguracji kompilacyjnej. W obszarze bezpieczeństwa nawet drobna pomyłka logiczna może przełożyć się na katastrofalne skutki finansowe.
Podsumowanie
Przypadek Coldcard pokazuje, że bezpieczeństwo portfela sprzętowego nie kończy się na izolacji urządzenia od internetu. Fundamentem całego modelu ochrony pozostaje jakość wygenerowanego seed, a każda słabość entropii może prowadzić do cichego i masowego przejmowania aktywów. Z praktycznego punktu widzenia wniosek jest jednoznaczny: jeśli seed został utworzony na potencjalnie podatnej wersji firmware, należy potraktować go jako zagrożony i niezwłocznie przeprowadzić migrację środków do nowego portfela.
Źródła
- The Hacker News — Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes — https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
- COINKITE Blog — Version 4.0.0 Released (Major Internal Improvements) — https://blog.coinkite.com/version-4.0.0-released/
- COINKITE Blog — Understanding The COLDCARD Mk4 Security Model and Secure Element Use — https://blog.coinkite.com/understanding-mk4-security-model/
- COINKITE Blog — COLDCARD 5.5.1 and 1.4.1Q — https://blog.coinkite.com/coldcard-5.5.1-1.4.1q-release/
- COINKITE Blog — Offline Is Not Enough: COLDCARD vs a Disconnected Phone — https://blog.coinkite.com/offline-is-not-enough/