COLDCARD: słaby PRNG zagroził kluczom portfeli Bitcoin

Coinkite opublikowało pilny komunikat dotyczący generatora losowego w portfelach sprzętowych COLDCARD. Błąd integracji, obecny w kilku generacjach firmware’u, sprawiał, że kod odpowiedzialny za tworzenie sekretów korzystał z deterministycznego generatora Yasmarang zamiast z właściwego sprzętowego źródła losowości. Skutkiem nie jest „słabszy PIN”, lecz możliwość odtworzenia ograniczonej przestrzeni kandydatów na seed i sprawdzania ich wobec publicznych adresów Bitcoin.

Sprawa zbiegła się z analizą serii 1 196 adresów opróżnionych 30 lipca w ciągu 41 minut. Łącznie przeniesiono 1 082,65 BTC, warte wtedy około 70,2 mln USD. Publiczne analizy wiążą wzorzec z błędem COLDCARD, ale ważne zastrzeżenie brzmi: nie opublikowano dowodu polegającego na odtworzeniu konkretnego seedu ofiary i przypisaniu go do opróżnionego adresu. Związek z kradzieżą pozostaje oceną badaczy, natomiast błąd firmware’u i konieczność migracji potwierdza sam producent.

Co zepsuło się w generatorze

Analiza Block Bitcoin Engineering and Security wskazuje na pozornie niewielką różnicę w preprocesorze. Konfiguracja produkcyjna definiowała MICROPY_HW_ENABLE_RNG jako 0, ponieważ COLDCARD miał własną otoczkę sprzętowego RNG. Biblioteka libngu sprawdzała jednak tylko, czy makro istnieje, a nie czy ma wartość włączającą funkcję.

W efekcie wywołanie trafiało do programowego generatora Yasmarang w MicroPythonie. Stan był inicjalizowany m.in. identyfikatorem układu i rejestrami czasu. To dane stałe albo możliwe do ograniczenia, nie świeża entropia kryptograficzna. Po inicjalizacji generator nie pobierał nowej losowości.

Dla Mk2/Mk3 z firmware’em v4 strumień był deterministyczny po ustaleniu UID, czasu i historii wywołań. Nowsze Mk4, Q i Mk5 dodawały dane z secure elementu, ale do funkcji reseed() trafiały tylko cztery bajty skrótu. Oznacza to najwyżej 2^32 bezpiecznie rozróżnialnych wariantów dla ustalonego stanu generatora, a późniejsze haszowanie nie tworzy utraconej entropii.

Które seedy wymagają uwagi

Liczy się firmware użyty podczas tworzenia sekretu, a nie obecna wersja ani data zakupu urządzenia. Komunikat Coinkite wymienia:

Model i kanał	Wersja naprawiona
Mk2/Mk3	4.2.0 lub nowsza
Mk4/Mk5 standard	5.6.0 lub nowsza
Q standard	1.5.0Q lub nowsza
Mk4/Mk5 Edge	6.6.0X lub nowsza
Q Edge	6.6.0QX lub nowsza

Coinkite wskazuje jako podatne seedy utworzone na Mk2/Mk3 4.0.1–4.1.9, Mk4/Mk5 przed poprawionymi wydaniami i Q przed poprawionymi wydaniami. Analiza Block obejmuje też Mk2/Mk3 4.0.0. Bezpiecznym podejściem przy niepewnej historii jest przyjęcie szerszego zakresu i migracja.

TAPSIGNER, OPENDIME i SATSCARD korzystają z innych baz kodu i nie są objęte tym błędem.

Aktualizacja nie naprawia starego seedu

To najważniejsza lekcja operacyjna. Firmware koryguje przyszłe generowanie sekretów. Nie dodaje losowości do istniejących słów BIP-39. Odtworzenie starego seedu w zaktualizowanym urządzeniu lub innym portfelu przenosi problem razem z nim.

Procedura powinna wyglądać następująco:

1. Potwierdź model, kanał aktualizacji i wersję firmware’u.
2. Zainstaluj poprawione wydanie wyłącznie z oficjalnego źródła i zweryfikuj wersję na ekranie urządzenia.
3. Utwórz nowy seed po aktualizacji, zapisz kopię i sprawdź fingerprint oraz adres odbiorczy na ekranie COLDCARD.
4. Wyślij małą transakcję testową i potwierdź jej zaksięgowanie.
5. Dopiero wtedy przenieś pozostałe środki. Starą kopię zachowaj do pełnego potwierdzenia migracji, później traktuj ją jako sekret wycofany.

Nie wykonuj migracji pod presją wiadomości prywatnej, reklamy ani „pomocy technicznej”. Taki incydent natychmiast tworzy okazję do phishingu. Seed, sekwencja rzutów i passphrase nigdy nie powinny trafiać na stronę internetową ani do osoby podającej się za wsparcie.

Wyjątki: kości, passphrase i multisig

Coinkite uznaje, że co najmniej 50 uczciwych, niezależnych i prywatnych rzutów kością wniesionych podczas generowania dawało co najmniej 128 bitów własnej entropii. Jeżeli liczba lub prywatność rzutów jest niepewna, zalecenie pozostaje jedno: migracja.

Silna, unikalna BIP-39 passphrase tworzy osobny portfel, do którego same słowa seed nie wystarczą. Producent nadal zaleca wymianę seedu; krótka, wzorcowa albo ponownie używana fraza może zostać odgadnięta. Nie należy mylić passphrase z PIN-em urządzenia.

Multisig ogranicza ryzyko tylko wtedy, gdy kworum nie składa się wyłącznie z kluczy wygenerowanych na dotkniętych urządzeniach. Trzy portfele tego samego typu nie są niezależnością, jeśli wszystkie dzielą tę samą wadę procesu generowania.

Co powinny zrobić firmy i zespoły custody

• zinwentaryzować urządzenia, wersje i pochodzenie każdego aktywnego klucza;
• oznaczyć seedy utworzone w podatnym oknie, także te później importowane do innych portfeli;
• przygotować zatwierdzony, dwuosobowy runbook migracji z transakcją testową;
• ocenić, czy konfiguracje multisig rzeczywiście wykorzystują różne implementacje i źródła entropii;
• monitorować stare adresy po migracji i zachować dowody wersji, fingerprintów oraz transakcji;
• przeszkolić właścicieli środków z rozpoznawania fałszywych aktualizacji i próśb o seed.

Przy kluczach firmowych problem RNG jest problemem zarządzania aktywami i dowodami, nie tylko urządzenia. Przydatne są zasady z naszego przewodnika po zarządzaniu sekretami i rotacji oraz formalny plan reagowania na incydenty.

Fakty źródłowe a wnioski Breachroad

Faktem potwierdzonym przez Coinkite jest podatność wskazanych wydań, dostępność poprawionego firmware’u i konieczność utworzenia nowego seedu. Techniczny mechanizm i granice przestrzeni stanów opisuje Block, zaznaczając, że nie przeprowadził pełnego testu end-to-end dla każdego scenariusza. Dane o dużym transferze pochodzą z publicznej analizy blockchain; przypisanie go do odzyskania seedów nie zostało publicznie udowodnione.

Wnioskiem Breachroad jest traktowanie wszystkich niepewnych seedów jako wymagających kontrolowanej migracji oraz projektowanie multisig z niezależnością implementacji. Szkolenia cyberbezpieczeństwa dla zespołów technicznych i finansowych pomagają przećwiczyć migrację bez ujawniania sekretów, a audyt bezpieczeństwa IT może ocenić custody, uprawnienia, dowody i procedury reagowania.