Rozbicie oryginalnego portfela Ledger: TBC omawia prawdziwe granice samodzielnego zarządzania

Portfel sprzętowy zakupiony z legalnego źródła, w nienaruszonym opakowaniu, z nietkniętą naklejką zabezpieczającą, uruchamia się i przechodzi testy diagnostyczne bez problemów. Jednak wewnątrz został zainstalowany ukryty komponent do przechwytywania fraz odzyskiwania.

15 października 2026 roku, firma Ledger odpowiedziała na ten incydent: napastnicy zakupili oryginalne urządzenia, rozebrali je, zainstalowali sprzęt, a następnie ponownie wprowadzili na rynek przez kanały dystrybucji w Azji Południowo-Wschodniej. Ledger podkreślił, że chipy, system operacyjny i serwery nie zostały złamane, a incydent został zakwalifikowany jako atak na lokalne kanały dystrybucji, a nie systemowy atak na łańcuch dostaw.

14 października, Tom's Hardware powołując się na raport Bloomberga oszacował straty na około 93 miliony dolarów. Należy wyjaśnić: ta liczba pochodzi z mediów zewnętrznych, a nie z oficjalnego oświadczenia Ledger.

Kto jest właścicielem tej liczby, nie ma znaczenia. Ważne jest to, co ona ujawnia.

I Samodzielne zarządzanie nie eliminuje ryzyka, tylko przenosi je w inne miejsce

Przez ostatnie dziesięć lat branża opowiadała czystą historię: trzymając kryptowaluty na giełdzie, oddajesz swoje losy w ręce firmy; trzymając klucz prywatny w swoich rękach, zyskujesz wolność.

Ta historia ma w sobie ziarno prawdy.

Ryzyko związane z giełdami jest skoncentrowane i widoczne: malwersacje, panika, bankructwa, zamrożenie przez regulacje. Po FTX, hasło „Nie twoje klucze, nie twoje monety” zostało zaakceptowane przez większą liczbę użytkowników, a branża zaczęła poważniej dyskutować o narzędziach do samodzielnego zarządzania i przechowywania fraz mnemonicznych.

Jednak samodzielne zarządzanie nie jest końcem ryzyka, a jedynie jego przeniesieniem.

Zamiast pytania „czy platforma może działać w złej wierze”, pojawia się nowa seria pytań: skąd pochodzi twoje urządzenie? Czy oprogramowanie układowe zostało zmienione? W jakim środowisku została wygenerowana fraza mnemoniczna? Czy treść wyświetlana na ekranie podczas podpisywania jest zgodna z transakcją, którą faktycznie podpisujesz? Kto ma prawo zainicjować tę transakcję?

W tej serii pytań, jakikolwiek błąd w jednym z etapów prowadzi do skutków porównywalnych z upadkiem giełdy. Oszacowanie strat na 93 miliony dolarów w rzeczywistości kupuje tę lekcję.

Co gorsza, forma tych ataków się zmieniła. Nie łamią one kryptografii, nie łamią chipów, nie łamią algorytmu konsensusu. Atakują one miejsce styku fizycznego świata i łańcucha zaufania: kanały dystrybucji, proces rozbiórki, wtórne pakowanie, transport logistyczny.

Kryptografia może potwierdzić, że podpis jest ważny, ale nie może udowodnić, że ręka, która go złożyła, nie była przymuszana, ani nie może potwierdzić, że urządzenie nie wysłało w ukryty sposób frazy mnemonicznej.

Najbardziej wrażliwym ogniwem w modelu bezpieczeństwa nigdy nie były algorytmy, ale ludzie, urządzenia i procesy.

II Rozdzielenie klucza prywatnego na wiele weryfikowalnych warunków

Prawdziwa lekcja z incydentu Ledger nie brzmi „nie używaj portfeli sprzętowych”, lecz: poleganie wyłącznie na założeniu „klucz prywatny jest w moich rękach” jest samo w sobie punktem awarii.

Właściwym kierunkiem jest wymaganie, aby transfer funduszy spełniał jednocześnie wiele warunków, które są rozproszone w różnych obszarach zaufania.

Stanowisko TBC w tej sprawie należy wyrazić z umiarem. Nie twierdzi, że może wyeliminować ataki na terminale; żaden łańcuch nie jest w stanie tego zrobić. Jego wartość polega na tym, że kontrakty UTXO i narzędzia multi-signature pozwalają projektom rozdzielić ryzyko związane z pojedynczym kluczem prywatnym na wiele weryfikowalnych warunków.

Mówiąc konkretnie, TBC wykorzystuje model SHA256 PoW i UTXO, a kod węzła TBCNODE jest publicznie dostępny do weryfikacji. Naturalną cechą modelu UTXO jest to, że każdy niewydany wyjście może być ograniczone przez niezależne warunki skryptowe, a nie zawieszone na globalnym saldzie konta. Oznacza to, że zasady wydatków mogą być zapisane na łańcuchu, a nie w jakiejś usłudze zaplecza.

tbc-contract SDK oferuje zapytania na łańcuchu, uzyskiwanie UTXO, konstrukcję transakcji, podpisywanie i nadawanie, a także zawiera MultiSig, NFT, FT i przepływy pracy Pool. Oficjalny przykład MultiSig wspiera ustawienie progu podpisów od 1 do 6 wśród 3 do 10 kluczy publicznych, a dokumentacja zawiera przykład 2-of-3.

Należy jednak jasno powiedzieć: multi-signature to konfigurowalne narzędzie do kontroli ryzyka, nie automatyczne zabezpieczenie, ani tym bardziej absolutne bezpieczeństwo.

Jeśli ktoś myśli, że ustawienie 2-of-3 rozwiązuje wszystkie problemy, to popełnia ten sam błąd, co ci, którzy wierzą, że „zakup portfela sprzętowego zapewnia bezpieczeństwo”. Multi-signature zmienia strukturę kosztów ataku, a nie prawdopodobieństwo ataku.

Dokumentacja TBC AMM wyjaśnia jeszcze jedną rzecz: SDK lokalnie konstruuje, wycenia i podpisuje, a nadawanie jest inicjowane przez aplikację. Stan puli i kontrola aktywów opierają się na UTXO i zasadach skryptowych. To stanowi podstawę transakcji bez zarządzania i separacji uprawnień.

Również należy wyraźnie określić granice: to nie oznacza, że AMM nie ma ryzyka kontraktowego, ryzyka cenowego czy ryzyka front-end. Lokalne podpisywanie rozwiązuje problem „klucz prywatny nie opuszcza urządzenia”, ale nie rozwiązuje problemu „czy transakcja, którą podpisałeś, jest tym, co naprawdę chciałeś podpisać”.

III Dlaczego multi-signature często jest tylko formalnym rozdzieleniem

To jest najłatwiejsza do pominięcia, a zarazem najbardziej śmiertelna część.

Jeśli wiele kluczy podpisowych pochodzi z tej samej frazy mnemonicznej, jest przechowywanych na tym samym urządzeniu lub kontrolowanych przez tę samą osobę, multi-signature jest tylko formalnym rozdzieleniem.

Napastnik, który uzyska frazę mnemoniczną, zdobywa wszystkie prawa do podpisu. Jeśli urządzenie zostało zainstalowane, to wszystkie progi są jednocześnie naruszone. Taka konfiguracja wygląda na 3-of-5 na łańcuchu, ale w rzeczywistości jest 1-of-1.

Dlatego prawdziwe pytanie nie brzmi „ile podpisów mam”, ale kilka trudniejszych pytań:

• Czy środowisko generowania tych kluczy jest niezależne?
• Czy są one przechowywane na fizycznie odizolowanych różnych urządzeniach?
• Czy osoba inicjująca transakcję i osoba zatwierdzająca transakcję to ta sama grupa ludzi?
• Czy wysokiego ryzyka transfer ma opóźnienie i wymaga ręcznej weryfikacji?
• Czy proces wymiany kluczy i przywracania został przetestowany?

Model UTXO TBC nie naprawi automatycznie skradzionego klucza prywatnego. To trzeba przyznać. Zasady na łańcuchu mogą jedynie zapobiec nieautoryzowanemu transferowi funduszy, gdy jakiś warunek zostanie naruszony; nie mogą jednak przywrócić aktywów, gdy klucz prywatny już wyciekł.

Powiązane praktyki inżynieryjne wciąż są niezbędne: niezależne urządzenia do podpisywania, wymiana kluczy, limity transakcji i dzienne, blokady czasowe, wielostronna weryfikacja wysokiego ryzyka transakcji oraz wykonalne plany przywracania.

Należy również przyznać, że TBC musi nadal się poprawiać. Łatwość interakcji multi-signature, głębokość kompatybilności z głównymi portfelami sprzętowymi, gotowe do użycia szablony uprawnień, niezależne testy porównawcze oraz ciągłe audyty SDK, portfela i komponentów AMM są w toku.

TBCNODE ma już wersjonowane zapisy audytów bezpieczeństwa CertiK i SlowMist. Jednak audyt może jedynie potwierdzić, że konkretna wersja i zakres zostały sprawdzone; nie obejmuje on terminali sprzętowych, nie obejmuje nawyków zarządzania kluczami przez użytkowników, nie obejmuje przyszłych kodów, ani całej logiki warstwy aplikacji. Traktowanie raportu audytowego jako certyfikatu bezpieczeństwa to inna forma lenistwa.

IV Prawdziwe samodzielne zarządzanie to zasada na łańcuchu

Wracając do rozebranego urządzenia.

Przypomina nam, że „klucz prywatny w moich rękach” jest warunkiem koniecznym, ale nie wystarczającym. Źródło urządzenia, przydział praw do podpisu i zasady wydatków na łańcuchu muszą być jednocześnie spełnione, aby struktura bezpieczeństwa mogła się utrzymać.

Przyszłe zmiany w branży prawdopodobnie będą polegały na tym, że producenci portfeli sprzętowych wzmocnią kontrolę kanałów i projektowanie zabezpieczeń przed rozbiórką, usługi ubezpieczeniowe i zarządzające na nowo wycenią ryzyko fizycznego łańcucha dostaw, a strony projektowe zaczną traktować „projektowanie uprawnień” jako równie ważny temat inżynieryjny jak „audyt kodu”.

Stanowisko TBC w tym kontekście nie polega na „rozwiązaniu ataków sprzętowych”, lecz na dostarczeniu narzędzi do zapisania zasad uprawnień na łańcuchu: kontrakty UTXO ograniczają zasady wydatków, multi-signature dzieli prawa do podpisu na różne obszary zaufania, a komponenty transakcji bez zarządzania zapewniają, że klucz prywatny nie opuszcza lokalizacji.

Prawdziwe samodzielne zarządzanie to nie tylko posiadanie jednego klucza prywatnego, ale także zapewnienie, że po każdym punkcie awarii zasady na łańcuchu nadal mogą zapobiegać nieautoryzowanemu transferowi funduszy.

Źródło informacji Link źródłowy: Ledger · Tom's Hardware · TBCNODE · Contract SDK · MultiSig · AMM · CertiK · SlowMist