Sierpniowe aktualizacje blokują krytyczne wycieki kluczy prywatnych w portfelu kryptowalutowym Vultisig

Vultisig, portfel kryptowalutowy wykorzystujący wspólne podpisy, niewłaściwie obsługiwał krytyczny sygnał stop w swojej implementacji podpisu ECDSA, jak odkryli badacze bezpieczeństwa z ChainSecurity.

Oświadczenie badaczy z 21 października opisuje, jak kontynuowanie po błędzie mogłoby pozwolić już skompromitowanemu podpisującemu na odzyskanie pełnego klucza prywatnego.

Zarówno utrzymujący Androida, jak i iOS opisali kod, który ponawiał próby po tym, jak biblioteka zidentyfikowała złośliwego uczestnika, a następnie dodała obsługę, aby zatrzymać te ponowne próby i ostrzec użytkownika. Zmiany te pojawiają się w kolejnych notatkach wydania repozytorium.

Wymaganie kilku urządzeń zapewnia ochronę tylko wtedy, gdy oprogramowanie zachowuje ten wymóg, gdy jeden z uczestników zaczyna się źle zachowywać.

Portfel obliczeń wielopartyjnych (MPC wallet) rozdziela władzę podpisu między udziały kluczy. Wystarczająca liczba udziałów współpracuje, aby wygenerować standardowy podpis blockchain bez składania pełnego klucza prywatnego podczas normalnej operacji.

W układzie z dwoma urządzeniami wymagającym obu uczestników, skompromitowanie jednego powinno pozostawić atakującego zależnego od zatwierdzenia drugiego urządzenia.

Odkryta wada dotyczyła podpisu ECDSA i wymagała początkowego kompromisu. Atakujący mógłby następnie wysłać wiele złośliwych wiadomości podpisujących i obserwować, czy drugi podpisujący zwrócił błąd.

Te odpowiedzi ujawniały fragmenty wewnętrznego nasionka protokołu, co ostatecznie umożliwiało odzyskanie drugiego udziału i pełnego klucza, według ChainSecurity.

To nasionko jest wewnętrzną tajemnicą ustawień, a biblioteka zakładała, że dalsze podpisywanie zatrzyma się po krytycznym błędzie, aż nasionko zostanie obrócone. Aplikacja wyświetlała ogólny błąd i nie egzekwowała tej odpowiedzi.

Historyczny przepływ ECDSA Vultisig mógł ujawniać materiały klucza poprzez powtarzające się odpowiedzi błędów; sierpniowe aktualizacje teraz zatrzymują ponowne próby i identyfikują skompromitowane urządzenie.

Konsekwencją bezpieczeństwa jest to, że nieudana próba podpisu może mieć znaczenie, nawet gdy nie produkuje użytecznego podpisu transakcji.

Jeśli kontynuowanie wymiany ujawnia więcej tajnych informacji, samo odrzucenie transakcji nie zachowuje obiecanego rozdzielenia między podpisującymi. Aplikacja musi odpowiedzieć na samą awarię protokołu.

Co pokazują sierpniowe zmiany

Zmiana na Androidzie (#5658) i zmiana na iOS (#5235) zostały połączone 21 sierpnia, dwa miesiące przed publicznym ujawnieniem.

Ich opisy mówią, że stary kod porównywał niepowodzenia podpisu z wynikiem sukcesu biblioteki, nie obsługując oddzielnie błędów zakazu złośliwych stron. Rutyny podpisu mogły ponawiać próby do trzech razy, podczas gdy użytkownik otrzymywał ogólną wiadomość o niepowodzeniu.

Ta liczba ponownych prób nie ustala, ile wiadomości mogłoby odzyskać klucz, ani ile sesji potrzebowałby atakujący.

Zmiany kodu Androida i zmiany iOS uznają kody błędów złośliwych stron biblioteki podpisów DKLS w trakcie konfiguracji sesji, przetwarzania wiadomości i zakończenia podpisu.

Obie mapują oznaczonego uczestnika do identyfikatora urządzenia, przenoszą dedykowany błąd poza automatycznymi ponownymi próbami i wyświetlają zlokalizowane ostrzeżenie przed ponownym użyciem tego urządzenia. Na Androidzie wyjątek również omija odzyskiwanie przekaźnika.

Razem te zmiany pokazują, że aplikacje rozróżniają kryptograficzny werdykt dotyczący uczestnika od zwykłego niepowodzenia podpisu.

Zachowanie ponawiania odpowiednie dla tymczasowej awarii może stać się niebezpieczne, gdy biblioteka mówi wywołującemu, aby przestał wchodzić w interakcje z złośliwym podpisującym.

Notatki GitHub dla iOS v1.45.71, datowane na 21 sierpnia, wymieniają #5235. Wydanie Android v1.0.118, datowane na 25 sierpnia, wymienia #5658.

Liczby portfela i zakres audytu potrzebują kontekstu

Opisy skarbców Vultisig rozróżniają, kto kontroluje podpisujących. Fast Vault używa jednego urządzenia użytkownika, a VultiServer trzyma drugi udział i współpodpisuje. Secure Vault używa dwóch lub więcej urządzeń użytkowników bez VultiServer.

Portfel wspomagany przez dostawcę i portfel rozłożony na własnych urządzeniach użytkownika mogą oba korzystać z rozproszonego podpisywania, ale ich zależności operacyjne różnią się. Dwaj uczestnicy w wymianie podpisów nie muszą również oznaczać, że skarbiec ma tylko dwa udziały w sumie.

Przeglądane ujawnienie i materiały aplikacji nie dostarczają pełnej macierzy wersji dotkniętych i konfiguracji skarbców.

Dokumentacja bezpieczeństwa Vultisig mówi, że Trail of Bits audytował bibliotekę DKLS23 Silence Laboratories w 2024 roku. Mówi, że raporty z audytów aplikacji mobilnych i desktopowych będą połączone, gdy zostaną opublikowane.

Przy ujawnieniu ChainSecurity powiedział, że nie przeglądał poprawek Vultisig ani nie audytował innych części protokołu, więc poprawki pozostały poza tą oceną.

Przydatne szczegóły dotyczące naprawy łączyłyby dotknięte konfiguracje z wydanymi wersjami i wyjaśniały egzekwowanie po automatycznych i inicjowanych przez użytkownika restartach. Przegląd obejmujący te zachowania zająłby się opisanym tutaj niepowodzeniem na poziomie aplikacji.

Posiadacze ochrony są obiecani, że egzekwowanie zależy od aplikacji egzekwującej warunek zatrzymania biblioteki przez cały czas podpisywania, w tym gdy użytkownicy zaczynają ponownie po awarii.