Entre fin décembre 2024 et fin janvier 2025, SSP a traversé trois audits de sécurité indépendants avec Halborn, le cabinet derrière des revues de sécurité pour des projets dans tout l'écosystème Web3. Les revues ont couvert les trois piliers de SSP : les applications wallet et key, les smart contracts derrière le multisig ERC-4337, et le SDK contre lequel d'autres développeurs peuvent intégrer. Les trois rapports sont publics.
Ce post est un bref récapitulatif : ce qui était dans le périmètre, à quelles dates chaque audit s'est déroulé, ce que Halborn a trouvé, et où vous pouvez lire les rapports vous-même.
En bref
- Trois audits dans la même fenêtre (23 décembre 2024 – 22 janvier 2025).
- Périmètre : l'extension de navigateur SSP Wallet et l'application mobile SSP Key, le serveur relay qui les fait communiquer, les smart contracts ERC-4337 + Schnorr sur Ethereum, et le SDK public.
- Résultats : aucun problème critique ni élevé. Un petit nombre de findings de gravité faible et informationnels — la plupart dans des chemins de code inutilisés ou morts — tous traités.
- Les rapports sont publics sur le site de Halborn et reproduits dans les dépôts SSP.
Trois audits, une seule fenêtre
Les audits ont été menés en parallèle plutôt qu'à la file, ce qui est inhabituel pour un projet de la taille de SSP. La raison est structurelle : les trois composants que Halborn a revus se parlent constamment, et le threat model de chacun suppose des garanties spécifiques des deux autres. Les auditer dans la même fenêtre a donné à Halborn une vue complète de la façon dont une vraie transaction SSP circule depuis le navigateur, à travers le relay, jusque dans le smart contract, puis revient — au lieu d'une tranche à la fois.
1. SSP Wallet, SSP Key et SSP Relay
Dates : 30 décembre 2024 – 22 janvier 2025 Rapport public : halborn.com — SSP Wallet, Relay & Key
Ce fut l'engagement le plus large. Halborn a regardé :
- Le client extension de navigateur (génération de clés, chiffrement au repos, flux de signature).
- L'application mobile compagnon (Android et iOS) qui détient la deuxième clé dans le schéma multisig 2-sur-2 de SSP.
- Le serveur relay qui fait l'intermédiaire entre les deux — y compris la forme du protocole et comment il tient face à du trafic malveillant ou malformé.
- Les primitives cryptographiques utilisées de bout en bout : comment les seeds sont générés, comment AES-GCM est appliqué, comment les signatures sont produites et vérifiées.
- Les mécanismes 2FA ajoutés par-dessus.
Si vous avez utilisé SSP, presque tout ce que vous touchez directement est dans le périmètre de cet audit.
2. Smart contracts : ERC-4337 + Schnorr
Dates : 23 décembre 2024 – 3 janvier 2025 Rapport public : halborn.com — Account Abstraction Schnorr MultiSig
Le côté on-chain de SSP — son implémentation d'account abstraction sur Ethereum et les chaînes EVM-compatibles — est une base de code séparée avec un threat model différent. Les bugs de smart contracts sont impitoyables : une fois qu'un contrat est déployé et garde de la valeur, vous ne pouvez pas le patcher discrètement.
Le périmètre de Halborn ici :
- L'intégration avec l'EntryPoint d'ERC-4337 et les account contracts spécifiques à SSP.
- L'agrégation de signatures Schnorr et la vérification on-chain.
- Le contrôle d'accès, l'ownership et les procédures d'upgrade.
- Les patterns d'optimisation de gaz (y compris si une optimisation a ouvert un footgun).
- Chaque appel externe que les contrats font.
3. Le SDK
Dates : 2 janvier – 14 janvier 2025 Rapport public : halborn.com — Schnorr Signatures SDK
Les tiers ne consomment pas SSP uniquement via l'UI du wallet — ils peuvent aussi intégrer les primitives sous-jacentes d'account abstraction directement via le SDK. Cela fait du SDK une surface à durcir à part entière : tout default négligé qu'il livre devient le problème de tous-ceux-qui-l'importent.
Halborn a examiné l'ergonomie de l'API sous un angle de sécurité, la validation des entrées, les pratiques de logging sécurisé, et si la documentation du SDK oriente les intégrateurs vers des patterns d'utilisation sûrs au lieu des pièges courants.
Ce que Halborn a trouvé
Sur les trois audits combinés, le chiffre titre est zéro finding critique et zéro de gravité élevée. Les rapports contiennent bien un petit ensemble d'éléments de gravité faible et informationnels — la plupart dans des branches inutilisées ou des chemins de code mort déjà prévus pour suppression. Chaque item signalé a été traité avant que les rapports ne soient publiés.
Cette dernière clause compte. « Audité » tout seul est une affirmation faible si les findings restent sans correction. La version de SSP que vous pouvez installer aujourd'hui est celle qui inclut les corrections post-audit.
Ce que cela signifie pour vous
Un audit propre est un instantané, pas une promesse éternelle. Du nouveau code arrive, les dépendances bougent et les threat models évoluent. Mais les revues de 2025 vous donnent trois choses que vous n'aviez pas avant :
- Une confirmation indépendante de la cryptographie. L'affirmation de sécurité de SSP repose sur du multisig 2-sur-2 réel, avec chaque clé sur un appareil séparé. Halborn a regardé comment les clés sont générées, comment elles sont stockées, et comment elles sont combinées en signatures. Le protocole correspond à l'affirmation.
- Un threat model public. Les rapports décrivent ce qui a été testé, pas seulement ce qui a été trouvé. Si vous évaluez SSP pour de l'auto-conservation, vous pouvez lire les mêmes documents de périmètre à partir desquels Halborn a travaillé.
- Une référence d'entretien. Les futures releases de SSP seront mesurées contre la baseline post-audit. Si quelque chose régresse, le diff est visible.
Comment vérifier vous-même
Vous n'avez pas besoin de croire ce post sur parole pour quoi que ce soit. Les PDFs complets sont liés ci-dessus sur le site de Halborn, et l'équipe SSP les reproduit dans le dépôt de documentation du projet — y compris l'index résumé des audits dans ssp-docs. Chaque PDF inclut la méthodologie, la liste complète des findings, les classements de gravité, et le statut de remédiation. Ils sont écrits pour un lecteur ingénieur sécurité, mais ils restent accessibles.
Si vous préférez commencer par le protocole lui-même avant l'audit, l'introduction au multisig 2-sur-2 est le bon point d'entrée.