Między końcem grudnia 2024 a końcem stycznia 2025 SSP przeszło trzy niezależne audyty bezpieczeństwa z Halborn, firmą stojącą za przeglądami bezpieczeństwa dla projektów w całym ekosystemie Web3. Przeglądy objęły trzy filary SSP — aplikacje wallet i key, smart kontrakty stojące za multisig ERC-4337, oraz SDK, z którym mogą integrować się inni deweloperzy. Wszystkie trzy raporty są publiczne.
Ten post to krótkie podsumowanie: co znalazło się w zakresie, w jakich datach trwał każdy audyt, co znalazł Halborn i gdzie możesz przeczytać raporty samodzielnie.
W skrócie
- Trzy audyty w jednym oknie (23 grudnia 2024 – 22 stycznia 2025).
- Zakres: rozszerzenie przeglądarkowe SSP Wallet i aplikacja mobilna SSP Key, serwer relay, przez który się komunikują, smart kontrakty ERC-4337 + Schnorr na Ethereum, oraz publiczny SDK.
- Wyniki: żadnych problemów krytycznych ani wysokich. Niewielka liczba wyników o niskiej i informacyjnej istotności — większość w nieużywanych lub martwych ścieżkach kodu — wszystkie zaadresowane.
- Raporty są publiczne na stronie Halborn i odzwierciedlone w repozytoriach SSP.
Trzy audyty, jedno okno
Audyty toczyły się równolegle zamiast jeden po drugim, co jest nietypowe dla projektu wielkości SSP. Powód jest strukturalny: trzy komponenty, które Halborn przejrzał, stale ze sobą rozmawiają, a threat model każdego z nich zakłada konkretne gwarancje od dwóch pozostałych. Audytowanie ich w tym samym oknie dało Halborn pełny widok na to, jak prawdziwa transakcja SSP przepływa z przeglądarki, przez relay, do smart kontraktu i z powrotem — zamiast jednego wycinka na raz.
1. SSP Wallet, SSP Key i SSP Relay
Daty: 30 grudnia 2024 – 22 stycznia 2025 Raport publiczny: halborn.com — SSP Wallet, Relay & Key
To było najszersze zlecenie. Halborn przyjrzał się:
- Klientowi rozszerzenia przeglądarkowego (generowanie kluczy, szyfrowanie at rest, przepływy podpisu).
- Mobilnej aplikacji towarzyszącej (Android i iOS), która trzyma drugi klucz w konfiguracji multisig 2-z-2 SSP.
- Serwerowi relay, który pośredniczy między dwoma — łącznie z kształtem protokołu i tym, jak utrzymuje się przy złośliwym lub źle uformowanym ruchu.
- Prymitywom kryptograficznym używanym end-to-end: jak generowane są seedy, jak stosowany jest AES-GCM, jak produkowane i weryfikowane są podpisy.
- Mechanizmom 2FA nałożonym powyżej.
Jeśli używałeś SSP, prawie wszystko, czego dotykasz bezpośrednio, mieści się w zakresie tego audytu.
2. Smart kontrakty: ERC-4337 + Schnorr
Daty: 23 grudnia 2024 – 3 stycznia 2025 Raport publiczny: halborn.com — Account Abstraction Schnorr MultiSig
Strona on-chain SSP — jego implementacja account abstraction na Ethereum i łańcuchach EVM-kompatybilnych — to oddzielna baza kodu z innym threat modelem. Bugi w smart kontraktach są bezlitosne: gdy kontrakt jest już wdrożony i przechowuje wartość, nie możesz po cichu go załatać.
Zakres Halborn tutaj:
- Integracja z EntryPoint ERC-4337 i specyficzne dla SSP account contracts.
- Agregacja podpisów Schnorr i weryfikacja on-chain.
- Kontrola dostępu, ownership i procedury upgrade.
- Wzorce optymalizacji gazu (w tym czy jakaś optymalizacja otworzyła footgun).
- Każde wywołanie zewnętrzne, jakie kontrakty wykonują.
3. SDK
Daty: 2 stycznia – 14 stycznia 2025 Raport publiczny: halborn.com — Schnorr Signatures SDK
Strony trzecie nie konsumują SSP wyłącznie przez UI walleta — mogą też integrować podstawowe prymitywy account abstraction bezpośrednio przez SDK. To czyni z SDK osobną powierzchnię do utwardzenia: każdy niedbały default, który shipuje, staje się problemem-każdego-kto-go-importuje.
Halborn przyjrzał się ergonomii API z perspektywy bezpieczeństwa, walidacji wejścia, praktykom bezpiecznego logowania i temu, czy dokumentacja SDK kieruje integratorów ku bezpiecznym wzorcom użycia zamiast popularnych pułapek.
Co Halborn znalazł
Sumując trzy audyty, nagłówkowa liczba to zero wyników krytycznych i zero wysokiej istotności. Raporty zawierają natomiast niewielki zestaw pozycji niskiej istotności i informacyjnych — większość w nieużywanych gałęziach lub martwych ścieżkach kodu, które i tak były już przewidziane do usunięcia. Każda zgłoszona pozycja została zaadresowana, zanim raporty zostały opublikowane.
Ta ostatnia klauzula ma znaczenie. „Audytowane" samo w sobie jest słabym twierdzeniem, jeśli wyniki pozostają niepoprawione. Wersja SSP, którą możesz dziś zainstalować, to ta, która zawiera poprawki post-audytowe.
Co to dla ciebie oznacza
Czysty audyt to migawka, nie wieczna obietnica. Ląduje nowy kod, zależności się zmieniają, threat modele ewoluują. Ale przeglądy z 2025 dają ci trzy rzeczy, których wcześniej nie miałeś:
- Niezależne potwierdzenie kryptografii. Twierdzenie SSP o bezpieczeństwie opiera się na prawdziwym multisig 2-z-2 z każdym kluczem na osobnym urządzeniu. Halborn przyjrzał się temu, jak generowane są klucze, jak są przechowywane i jak są łączone w podpisy. Protokół spina się z twierdzeniem.
- Publiczny threat model. Raporty opisują, co było testowane, nie tylko co znaleziono. Jeśli oceniasz SSP pod kątem self-custody, możesz przeczytać te same dokumenty zakresu, na podstawie których pracował Halborn.
- Poprzeczka utrzymaniowa. Przyszłe wydania SSP będą mierzone względem post-audytowej bazy. Jeśli coś się zregresuje, diff jest widoczny.
Jak to zweryfikować samodzielnie
Nie musisz wierzyć temu postowi w żadną z tych rzeczy na słowo. Pełne PDF-y są podlinkowane powyżej na stronie Halborn, a zespół SSP odzwierciedla je w repozytorium dokumentacji projektu — łącznie z indeksem podsumowującym audyty w ssp-docs. Każdy PDF zawiera metodologię, pełną listę wyników, klasyfikacje istotności i status remediacji. Są napisane dla czytelnika-inżyniera bezpieczeństwa, ale są przystępne.
Jeśli wolisz zacząć od samego protokołu zanim sięgniesz po audyt, wprowadzenie do multisig 2-z-2 jest właściwym punktem wejścia.
