Firmware to oprogramowanie sterujące urządzeniem, na przykład Hardware Wallet. Jego kompilacja jest odtwarzalna, gdy ten sam kod źródłowy, określone środowisko i instrukcje dają dokładnie takie same, wcześniej wskazane pliki. Nie wystarczy, że program działa tak samo: porównuje się same dane. Przy podpisanych wydaniach trzeba też jasno określić sposób postępowania z podpisem.
Producent może opublikować kod, który programista potrafi przeczytać. W portfelu instalujesz jednak zwykle gotowy plik w postaci maszynowej, nazywany plikiem binarnym. Te dwie formy łączy proces kompilacji. Niezależna osoba może go powtórzyć i porównać wynik z wydaniem producenta. Szuka identycznych bajtów, czyli poszczególnych jednostek danych, często za pomocą skrótu kryptograficznego: odcisku obliczonego z zawartości. Sprawdzenie dotyczy określonych wyników, na przykład pliku firmware, a nie automatycznie wszystkich plików roboczych i dzienników. [1] [4]
Wyobraź sobie dwóch programistów sprawdzających jedną aktualizację. Nazwa projektu nie wystarczy: potrzebują tego samego commitu, czyli dokładnie określonej rewizji kodu. Muszą znać także wersje użytych bibliotek i kompilatora, narzędzia przekształcającego kod w postać maszynową. Jego opcje, istotne ustawienia środowiska i model portfela również należą do procedury. Dane te trzeba ustalić wcześniej lub zapisać podczas kompilacji. Inaczej obaj mogą pracować uczciwie, a mimo to uzyskać różne wyniki. [1] [2]
Różnica nie musi oznaczać, że ktoś zmienił działanie programu. Kompilator może zapisać ścieżkę folderu roboczego w informacjach pomocnych przy szukaniu błędów. Jeżeli programiści przechowują projekt w różnych miejscach, pliki mogą się różnić. Rozwiązaniem bywa wskazana z góry ścieżka lub obsługiwana metoda ujednolicenia ścieżek. Taka reguła musi być znaną częścią procedury. Usuwanie niewyjaśnionych różnic po nieudanej kontroli tylko po to, by uzyskać zgodność, odbiera sprawdzeniu sens. [3]
Podpis cyfrowy pozwala sprawdzić, czy plik odpowiada podpisowi utworzonemu odpowiednim kluczem. Powiązanie tego klucza z producentem jest kolejnym elementem zaufania. Odtwarzalna kompilacja odpowiada na inne pytanie: czy plik odpowiada określonemu kodowi źródłowemu? Obie kontrole się uzupełniają. Oficjalna aktualizacja może jednak zawierać dane podpisu nieobecne w lokalnym wyniku. Porównanie całych plików bez znajomości formatu może więc wykazać różnicę nawet przy poprawnie skompilowanym programie. [5]
Dokumentacja Trezor opisuje wybór wersji i modelu, kompilację firmware oraz porównanie z oficjalnym plikiem. Wynik lokalny nie jest podpisany tak samo jak wydanie producenta, dlatego procedura najpierw zeruje dokładnie wskazane pola podpisu. Starsze formaty różnią się też nagłówkami, czyli początkowymi częściami plików zawierającymi informacje o nich. Układ zależy od modelu i wersji, więc instrukcji dla jednego urządzenia nie wolno bez sprawdzenia przenosić na inne. Oryginalny podpis weryfikuje się osobno; porównanie zmodyfikowanych kopii tego nie zastępuje. [5]
Najpierw trzeba ustalić, czy rzeczywiście porównywano tę samą rewizję, model i wariant firmware. Następnie sprawdza się narzędzia, biblioteki i wymagane przekształcenia pliku. Oryginalne pliki oraz zapis różnic powinny pozostać zachowane. Przyczyną może być błąd środowiska lub instrukcji, ale również ingerencja w rozpowszechniany program. Sama rozbieżność nie wskazuje ani sprawcy, ani przyczyny. Dopóki nie zostanie wyjaśniona, a kontrola powtórzona, nie należy uznawać kompilacji za zweryfikowaną. [1] [4]
Jeżeli błąd znajduje się już w opublikowanym kodzie, każda ponowna kompilacja może go wiernie zachować. Wspólny niezaufany kompilator również może dodać tę samą szkodliwą zmianę do wszystkich wyników; ponowne użycie nie jest niezależną kontrolą narzędzia. Zamknięte komponenty binarne ograniczają to, co można odtworzyć z dostępnego kodu. A zgodny plik na komputerze nie dowodzi, że konkretny portfel jest autentyczny ani że działa na nim właśnie ten firmware. Sprawdzenie pochodzenia pliku to ważny element bezpieczeństwa, lecz nie jego pełny dowód. [6] [1]
Informacja „zweryfikowano” jest przydatna, gdy wiadomo, kto przeprowadził kontrolę, jaką rewizję skompilował, dla którego modelu i według jakiej procedury. Raport powinien wskazywać porównane pliki, funkcję skrótu, wyniki oraz dokładny sposób postępowania z podpisami. Inne osoby mogą wtedy przeanalizować lub powtórzyć pracę. Więcej niezależnych kompilacji zmniejsza zależność od jednego wydawcy. Nadal potrzebna jest kontrola kodu, procesu aktualizacji i samego urządzenia. [2] [4]
Dwa zgodne wyniki i inny skrót
Dwaj programiści kompilują tę samą rewizję firmware dla tego samego modelu w tym samym środowisku. Skróty SHA-256 ich plików są zgodne, ale oficjalna podpisana wersja ma inny skrót. Jeżeli dokumentacja dokładnie określa pola podpisu, wykonują wskazane przekształcenie na kopiach i porównują ponownie. Zgodność dotyczy wtedy tak określonej zawartości. Oryginalny podpis nadal wymaga oddzielnej weryfikacji; innych niewyjaśnionych różnic nie wolno po prostu usuwać.
Pełniejszy obraz uzyskasz, czytając to hasło razem z Hardware Wallet, Private Key, Cold Storage, Secure Element. Do tego hasła prowadzą również odsyłacze z COLDCARD RNG Incident (2026).
01Czy jako użytkownik muszę sam kompilować firmware?+
Nie musisz być programistą, żeby zrozumieć wynik sprawdzenia. Upewnij się jednak, że niezależny raport wskazuje konkretną wersję, model i porównane pliki. Zgodny skrót nie dowodzi braku błędów: ten sam szkodliwy kod lub kompilator może tworzyć takie same pliki. Ocena kodu i zaufanie do urządzenia pozostają oddzielnymi kwestiami.
02Czy inny skrót podpisanej aktualizacji oznacza atak?+
Nie automatycznie. Plik może zawierać inne dane podpisu lub nagłówki, które procedura sprawdzania już uwzględnia. Trzeba zweryfikować wersję, model i dokładną instrukcję. Niewyjaśniona różnica nie jest jednak pomyślną weryfikacją i nie można jej obejść przez dowolne usuwanie danych.