COLDCARD RNG Incident (2026)

Coinkite i Block opublikowały pierwsze analizy 30 lipca 2026 roku po zgłoszeniach strat. Według producenta napastnicy nie musieli sterować cudzym urządzeniem: mogli odtworzyć słabo wygenerowane sekrety i uzyskać odpowiadające im klucze prywatne, które pozwalają podpisywać przelewy. Samo odłączenie portfela od internetu nie wystarczało. Opis incydentu nie rozstrzyga jednak przyczyny każdej pojedynczej straty; nie można jej ustalić tylko na podstawie marki urządzenia. [2] [3]

Portfel miał korzystać ze sprzętowego źródła losowości, zwanego TRNG. Po włączeniu biblioteki libNgU wywołanie ngu.random.bytes trafiało jednak do funkcji rng_get w MicroPythonie i jej programowego generatora Yasmarang. Podczas budowania programu połączono niewłaściwe składniki. MICROPY_HW_ENABLE_RNG miało wartość 0, a #ifndef sprawdzało tylko istnienie ustawienia, nie jego wartość. Właściwy kod sprzętowy mógł zatem być w pliku, lecz nie uczestniczyć w tworzeniu seeda. Nie była to awaria układu ani celowo zaprojektowany tryb awaryjny. [1]

Napastnik ma łatwiej, gdy sekret pochodzi z mniejszego zbioru możliwości. Tutaj stan programu zależał od danych urządzenia, liczników czasu i wcześniejszych wywołań. Dla Mk4, Mk5 oraz Q Block opisuje dodatkowe odświeżenie stanu ograniczone do 32 bitów: najwyżej 2^32 różne ciągi wyjściowe przy niezmienionej reszcie. Coinkite wstępnie szacowało całkowitą entropię, czyli miarę niepewności, na około 40 bitów dla Mk2/Mk3 i 72 bity dla nowszych modeli. Te liczby mają różne założenia. Nie określają kosztu każdego ataku ani nie dowodzą, że każdy portfel można złamać natychmiast. [3] [1]

Oficjalne ostrzeżenie wymienia Mk2/Mk3 z 4.0.1–4.1.9. Pierwsza analiza Block obejmuje już 4.0.0 i zmianę z marca 2021 roku. Źródła różnią się więc co do początkowej granicy; nie należy zastępować tej niepewności domysłem. Przy niejasnym pochodzeniu seeda poradnik migracji zaleca traktować portfel jako dotknięty błędem. Mk4/Mk5 oraz Q również były dotknięte przed poprawką odpowiedniej gałęzi firmware. Dawne stwierdzenie o wszystkich wersjach produkcyjnych nie opisuje późniejszych naprawionych wydań. [2] [3] [5]

Pierwsze poprawione wersje to Mk2/Mk3 4.2.0, Mk4/Mk5 Standard 5.6.0, Q Standard 1.5.0Q, Mk4/Mk5 Edge 6.6.0X i Q Edge 6.6.0QX. Standard oraz Edge są oddzielnymi gałęziami; wyższy numer innej gałęzi sam niczego nie dowodzi. W chwili tej rewizji producent zaleca Standard 5.6.3 dla Mk4/Mk5 oraz 1.5.3Q dla Q. Przed instalacją sprawdź aktualną oficjalną stronę, hash pliku i podpis wydania. Hash jest odciskiem treści, a podpis pomaga sprawdzić jej pochodzenie. Nawet poprawna aktualizacja nie zmienia istniejącego seeda. [4]

Wyobraź sobie odtworzenie słabo utworzonego seeda na nowym urządzeniu. Sprzęt jest inny, ale sekret pozostał ten sam. Tak samo działa klonowanie lub przeniesienie portfela. Haszowanie, czyli obliczanie odcisku danych, nie dodaje możliwych wejść; BIP39 Checksum pomaga wykrywać błędy w słowach, a nie uzupełnia brakującą losowość. W drugą stronę: seed bezpiecznie utworzony gdzie indziej nie zostaje osłabiony przez ten konkretny błąd tylko dlatego, że zaimportowano go do COLDCARD. Rozstrzyga jego pochodzenie. [3] [5]

Wyjątek producenta wymaga co najmniej 50 niezależnych rzutów prawidłowo wyważoną kością, wprowadzonych pierwotną funkcją Add Dice Rolls. Kolejność nie mogła zostać zapisana ani ujawniona, a portfel musiał używać końcowych słów po dodaniu rzutów. Przy mniejszej liczbie lub wątpliwościach zalecana jest migracja. BIP39 Passphrase to inny środek: dodatkowy tajny tekst, który wraz z seedem określa inny portfel. Silna i unikalna passphrase stawia napastnikowi kolejną przeszkodę, lecz nie naprawia seeda; producent zaleca migrację również jej użytkownikom. PIN chroni tylko dostęp do urządzenia. Dzisiejsze zasady tworzenia nowych seedów to coś innego niż ten historyczny wyjątek. [2]

Najpierw upewnij się, że masz użyteczną kopię pierwotnego portfela. Następnie zgodnie z poradnikiem migracji utwórz naprawdę nowy seed na poprawionym firmware i sprawdź jego kopię. Zweryfikuj fingerprint, krótki identyfikator portfela, oraz adres odbiorczy na ekranie urządzenia. Wyślij małą kwotę testową; dopiero po potwierdzeniu celu i odbioru prześlij resztę. Uwzględnij wszystkie konta ze środkami, portfele z passphrase, portfele pochodne i układy multisig. Zachowaj starą kopię do potwierdzenia całości. Przy rozbieżności niczego nie wysyłaj ani nie usuwaj. Nigdy nie wpisuj tajnych danych odzyskiwania do formularza internetowego. [5]

Multisig wymaga do przelewu określonej liczby podpisów z kilku kluczy. Jeśli napastnik pozyska dość kluczy, aby spełnić regułę, ochrona przestaje wystarczać. Trzeba ocenić pozostałe klucze, przygotować i sprawdzić na urządzeniu nową regułę podpisywania oraz przenieść do niej środki. Block opisuje też inne zastosowania tego samego generatora: samodzielne klucze Paper Wallet i niektóre tymczasowe klucze szyfrowania. Skutki zależą od konkretnego użycia i danych dostępnych napastnikowi; nie są jednakowe dla każdej funkcji. [3] [5]

Strona stanu wymienia test generatora sprzętowego na rzeczywistym Mk4, przegląd kodu źródłowego i niezależne powtórzenie budowania konkretnej poprawki. Pomaga to zweryfikować opisany mechanizm, ale nie dowodzi bezpieczeństwa każdego opublikowanego pliku. Obecny Standard wymaga również własnego wkładu losowości użytkownika przy tworzeniu nowego seeda. Dawna rada, że zawsze jest on opcjonalny, nie jest więc aktualnym sposobem postępowania dla tej gałęzi. Strona dokumentuje naprawy na bieżąco; osobny szczegółowy raport techniczny o przyczynach nadal określa jako przygotowywany. [4]