Tra fine dicembre 2024 e fine gennaio 2025, SSP ha attraversato tre audit di sicurezza indipendenti con Halborn, la società dietro le revisioni di sicurezza per progetti in tutto lo stack Web3. Le revisioni hanno coperto i tre pilastri di SSP: le applicazioni wallet e key, gli smart contract dietro il multisig ERC-4337, e l'SDK contro cui altri sviluppatori possono integrarsi. Tutti e tre i report sono pubblici.
Questo post è un breve riassunto: cosa è stato in scope, in che date ogni audit è stato condotto, cosa ha trovato Halborn, e dove puoi leggere i report da te.
In sintesi
- Tre audit nella stessa finestra (23 dicembre 2024 – 22 gennaio 2025).
- Scope: l'estensione browser SSP Wallet e l'app mobile SSP Key, il server relay che le mette in comunicazione, gli smart contract ERC-4337 + Schnorr su Ethereum, e l'SDK pubblico.
- Risultati: nessun problema critico o alto. Un piccolo numero di finding di severità bassa e informativi — la maggior parte in percorsi di codice non usati o morti — tutti risolti.
- I report sono pubblici sul sito di Halborn e replicati nei repository SSP.
Tre audit, una sola finestra
Gli audit sono andati in parallelo invece che in sequenza, cosa insolita per un progetto delle dimensioni di SSP. Il motivo è strutturale: i tre componenti che Halborn ha revisionato si parlano costantemente, e il threat model di ognuno assume garanzie specifiche dagli altri due. Auditarli nella stessa finestra ha dato a Halborn una vista completa di come una vera transazione SSP fluisce dal browser, attraverso il relay, dentro lo smart contract, e indietro — invece di una fetta alla volta.
1. SSP Wallet, SSP Key e SSP Relay
Date: 30 dicembre 2024 – 22 gennaio 2025 Report pubblico: halborn.com — SSP Wallet, Relay & Key
Questa è stata l'analisi più ampia. Halborn ha esaminato:
- Il client estensione browser (generazione delle chiavi, cifratura a riposo, flussi di firma).
- L'app mobile companion (Android e iOS) che custodisce la seconda chiave nello schema multisig 2-di-2 di SSP.
- Il server relay che fa da intermediario tra le due — incluso il formato del protocollo e come tiene di fronte a traffico malevolo o malformato.
- Le primitive crittografiche usate end-to-end: come vengono generati i seed, come viene applicato AES-GCM, come vengono prodotte e verificate le firme.
- I meccanismi 2FA stratificati sopra.
Se hai usato SSP, quasi tutto ciò che tocchi direttamente è dentro lo scope di questo audit.
2. Smart contract: ERC-4337 + Schnorr
Date: 23 dicembre 2024 – 3 gennaio 2025 Report pubblico: halborn.com — Account Abstraction Schnorr MultiSig
Il lato on-chain di SSP — la sua implementazione di account abstraction su Ethereum e su catene EVM-compatibili — è una codebase separata con un threat model diverso. I bug negli smart contract sono spietati: una volta che un contratto è deployato e custodisce valore, non puoi patcharlo silenziosamente.
Lo scope di Halborn qui:
- L'integrazione con l'EntryPoint ERC-4337 e gli account contract specifici di SSP.
- Aggregazione delle firme Schnorr e verifica on-chain.
- Controllo accessi, ownership, e procedure di upgrade.
- Pattern di ottimizzazione del gas (incluso se qualche ottimizzazione abbia aperto un footgun).
- Ogni chiamata esterna che i contratti effettuano.
3. L'SDK
Date: 2 gennaio – 14 gennaio 2025 Report pubblico: halborn.com — Schnorr Signatures SDK
Le terze parti non consumano SSP solo attraverso la UI del wallet — possono anche integrare le primitive sottostanti di account abstraction direttamente via l'SDK. Questo rende l'SDK una superficie a sé da indurire: qualunque default sciatto che spedisce diventa il problema di chiunque lo importi.
Halborn ha guardato all'ergonomia delle API da un'angolatura di sicurezza, alla validazione degli input, alle pratiche di logging sicuro, e a se la documentazione dell'SDK guida gli integratori verso pattern d'uso sicuri invece dei tranelli comuni.
Cosa ha trovato Halborn
Sui tre audit combinati, il numero da titolo è zero finding critici e zero di severità alta. I report contengono sì un piccolo set di item di severità bassa e informativi — la maggior parte in branch non usati o percorsi di codice morto già destinati alla rimozione. Ogni item segnalato è stato risolto prima che i report fossero pubblicati.
Quest'ultima clausola conta. "Auditato" da solo è un'affermazione debole se i finding restano non corretti. La versione di SSP che puoi installare oggi è quella che include i fix post-audit.
Cosa significa per te
Un audit pulito è un'istantanea, non una promessa eterna. Atterra codice nuovo, le dipendenze cambiano, e i threat model evolvono. Ma le revisioni del 2025 ti danno tre cose che prima non avevi:
- Conferma indipendente della crittografia. L'affermazione di sicurezza di SSP poggia su multisig 2-di-2 reale con ogni chiave su un dispositivo separato. Halborn ha guardato come vengono generate le chiavi, come vengono memorizzate, e come vengono combinate nelle firme. Il protocollo è all'altezza dell'affermazione.
- Un threat model pubblico. I report descrivono cosa è stato testato, non solo cosa è stato trovato. Se stai valutando SSP per l'auto-custodia, puoi leggere gli stessi documenti di scope da cui Halborn ha lavorato.
- Un'asticella di manutenzione. Le future release di SSP saranno misurate contro la baseline post-audit. Se qualcosa regredisce, il diff è visibile.
Come verificare da te
Non devi credere a questo post per nulla di tutto questo. I PDF completi sono linkati sopra sul sito di Halborn, e il team SSP li replica nel repository di documentazione del progetto — incluso l'indice riassuntivo degli audit in ssp-docs. Ogni PDF include la metodologia, la lista completa dei finding, le classificazioni di severità, e lo stato della remediation. Sono scritti per un lettore ingegnere di sicurezza, ma sono accessibili.
Se preferisci partire dal protocollo stesso prima dell'audit, l'introduzione al multisig 2-di-2 è il punto d'ingresso giusto.