SSP Wallet v2.1.2 i SSP Key v2.1.1: podpisywanie firmowe na Ethereum przywrócone
Dziś dwa wydania i idą razem: SSP Wallet v2.1.2 oraz SSP Key v2.1.1. Zaktualizuj oba.
To poprawki błędów, ale jedna z nich nie jest drobna. Podpisywanie firmowych skarbców na Ethereum było zepsute od v2.0.0, a ta para właśnie to naprawia.
Komunikat, który wyglądał jak atak
Jeśli kiedykolwiek od v2.0.0 próbowałeś zatwierdzić transakcję skarbca Ethereum w SSP Key, zobaczyłeś to:
transakcja nie zgadza się z tym, co pokazano do zatwierdzenia
To z założenia jeden z najbardziej alarmujących komunikatów, jakie SSP Key może ci wyświetlić. Pojawia się, gdy urządzenie przelicza transakcję na nowo i otrzymuje inną odpowiedź niż to, co kazano mu podpisać — dokładnie to, czego spodziewałbyś się, gdyby coś na drodze między portfelem a twoim telefonem zmanipulowało płatność.
Nic nie zostało zmanipulowane. Zepsuty był sam mechanizm sprawdzania.
SSP Key weryfikuje transakcję skarbca, przeliczając jej skrót niezależnie na urządzeniu i porównując z tym, co mu pokazano. Przeliczenie skrótu transakcji EVM wymaga identyfikatora łańcucha — liczby, która odróżnia Ethereum od każdej innej sieci EVM i zapobiega odtworzeniu podpisu z jednego łańcucha na drugim. Konfiguracjom Ethereum i Sepolia jej brakowało. Przeliczenie zawodziło więc, zanim miało cokolwiek do porównania, a weryfikacja zgłaszała niezgodność, której nigdy nie zdążyła sprawdzić.
Poprawka dodaje brakujący identyfikator, a test pilnuje teraz każdego łańcucha EVM przed tą samą luką, żeby żadna przyszła sieć nie mogła zostać dodana bez niego.
Warto nazwać po imieniu, czym to było: mechanizm bezpieczeństwa zawodzący „na zamknięcie". To właściwy kierunek awarii dla błędu tego rodzaju — Key odmówił podpisu, zamiast podpisać coś, czego nie potrafił zweryfikować — ale to nadal błąd, i przez miesiące uczynił firmowe skarbce Ethereum bezużytecznymi.
Dwa kolejne problemy, schowane za pierwszym
Identyfikator łańcucha był przyczyną. Sprawę pogorszyło to, co stało się dalej, i jest to dobra ilustracja tego, jak błędy się nawarstwiają.
Każda odrzucona próba spalała nonce. SSP Key rezerwuje nonce podpisu, zanim zweryfikuje żądanie. Ponieważ weryfikacja zawodziła, każda próba zużywała nonce i nie dawała nic — a gdy pula się wyczerpała, ponowna próba kończyła się zupełnie innym błędem: „nonce wymagają synchronizacji". Kto ścigał pierwszy błąd, trafiał na drugi, wyglądający na niezwiązany. Nonce jest teraz zużywany dopiero po pomyślnej weryfikacji, tuż przed wytworzeniem podpisu.
A synchronizacja — oczywisty środek zaradczy — mogła pogorszyć sprawę. Wymuszona synchronizacja czyściła wcześniej każdy nonce na przekaźniku przed uzupełnieniem. Jeśli uzupełnienie zawiodło, zostawałeś bez czegokolwiek do podpisania. Czyszczenie po stronie portfela odrzucało też nonce już zarezerwowane przez oczekujące propozycje, przez co te propozycje stawały się trwale niepodpisywalne. Synchronizacja uzgadnia teraz przekaźnik z nonce, które portfel i Key faktycznie posiadają, i uzupełnia wyłącznie braki. Okno Synchronizuj nonce uczciwie zgłasza także awarię po stronie portfela, zamiast pokazywać sukces wyłącznie na podstawie potwierdzenia z Key.
Zatem: zepsute sprawdzenie dawało przerażający komunikat, ponowne próby po cichu drenowały zasób, a udokumentowany sposób naprawy tego zasobu potrafił zniszczyć oczekującą pracę. Każde z osobna to błąd. Razem są powodem, dla którego potrzeba było dwóch skoordynowanych wydań, a nie łatki.
Poprawiono także
Wysłana transakcja jest teraz pokazywana jako wysłana. Po podpisaniu, rozgłoszeniu i potwierdzeniu przelewu nieudane powiadomienie o statusie do przekaźnika mogło mimo to pojawić się jako Request failed with status code 401 — komunikat błędu o transakcji, która w istocie się powiodła. Ekran potwierdzenia z identyfikatorem transakcji pojawia się teraz zawsze, wywołanie przekaźnika jest ponawiane raz ze świeżym uwierzytelnieniem, a awaria tam schodzi do rangi informacji. Twoje pieniądze się przemieściły; błędne było tylko sprawozdanie.
Podpisy rejestrują się, nawet jeśli karta się zamknie. Żądanie podpisu z portfela niesie teraz odniesienia do organizacji, skarbca i propozycji, więc przekaźnik może dołączyć twój podpis wprost do propozycji. Wcześniej, jeśli strony aplikacji firmowej, która o podpis prosiła, już nie było w chwili zatwierdzenia na telefonie, odpowiedź nie miała gdzie wylądować.
Pobieranie oczekujących żądań nie może już zawisnąć. Zapytanie do przekaźnika o oczekujące działania jest teraz ograniczone limitem czasu.
Co powinieneś zrobić
Zaktualizuj obie aplikacje. Te poprawki są rozdzielone między portfel i Key, a naprawa podpisywania na Ethereum potrzebuje obu połówek — aktualizacja tylko jednej jej nie przywróci.
Rozszerzenia przeglądarki aktualizują się same, więc strona portfela jest zapewne już aktualna. SSP Key to aplikacja mobilna i może potrzebować szturchnięcia ze sklepu.
Jeśli masz firmowy skarbiec Ethereum z propozycjami, które nie chciały się podpisać, teraz powinny. Jeśli masz propozycje trwale zablokowane, bo wymuszona synchronizacja odrzuciła ich zarezerwowane nonce, trzeba je utworzyć na nowo — poprawka zapobiega powtórce, ale nie odzyska nonce, który już wyrzucono.
Żadne klucze nie są dotknięte, nic nie wymaga przekonfigurowania i przez cały ten czas żadne środki nie były zagrożone: weryfikacja zawodząca na zamknięcie nie podpisuje, a przeniesienie środków i tak wymaga obu urządzeń.
O poprzednim wydaniu i tym, co naprawiało, przeczytasz w SSP Wallet v2.1.1.
