Entre finales de diciembre de 2024 y finales de enero de 2025, SSP atravesó tres auditorías de seguridad independientes con Halborn, la firma detrás de revisiones de seguridad para proyectos en todo el ecosistema Web3. Las revisiones cubrieron los tres pilares de SSP: las aplicaciones de wallet y key, los smart contracts detrás del multisig ERC-4337, y el SDK con el que otros desarrolladores pueden integrarse. Los tres informes son públicos.
Este post es un breve resumen: qué entró en alcance, qué fechas duró cada auditoría, qué encontró Halborn y dónde puedes leer los informes por ti mismo.
Resumen
- Tres auditorías en una misma ventana (23 de diciembre de 2024 – 22 de enero de 2025).
- Alcance: la extensión de navegador SSP Wallet y la app móvil SSP Key, el servidor relay que las comunica, los smart contracts ERC-4337 + Schnorr en Ethereum, y el SDK público.
- Hallazgos: ningún problema crítico ni alto. Un pequeño número de hallazgos de severidad baja e informativos —la mayoría en rutas de código no usadas o muertas— todos resueltos.
- Los informes son públicos en el sitio de Halborn y replicados en los repositorios de SSP.
Tres auditorías, una sola ventana
Las auditorías corrieron en paralelo en lugar de una tras otra, lo cual es inusual para un proyecto del tamaño de SSP. La razón es estructural: los tres componentes que Halborn revisó se hablan constantemente entre sí, y el threat model de cada uno asume garantías específicas de los otros dos. Auditarlos en la misma ventana le dio a Halborn una visión completa de cómo fluye una transacción real de SSP desde el navegador, a través del relay, hasta el smart contract y de vuelta —en lugar de una porción a la vez.
1. SSP Wallet, SSP Key y SSP Relay
Fechas: 30 de diciembre de 2024 – 22 de enero de 2025 Informe público: halborn.com — SSP Wallet, Relay & Key
Esta fue la revisión más amplia. Halborn examinó:
- El cliente extensión de navegador (generación de llaves, cifrado en reposo, flujos de firma).
- La app móvil compañera (Android e iOS) que sostiene la segunda llave en el esquema multisig 2-de-2 de SSP.
- El servidor relay que intermedia los mensajes entre ambas —incluyendo la forma del protocolo y cómo se comporta ante tráfico malicioso o malformado.
- Las primitivas criptográficas usadas de extremo a extremo: cómo se generan las semillas, cómo se aplica AES-GCM, cómo se producen y verifican las firmas.
- Los mecanismos 2FA que se superponen encima.
Si has usado SSP, casi todo lo que tocas directamente está dentro del alcance de esta auditoría.
2. Smart contracts: ERC-4337 + Schnorr
Fechas: 23 de diciembre de 2024 – 3 de enero de 2025 Informe público: halborn.com — Account Abstraction Schnorr MultiSig
El lado on-chain de SSP —su implementación de account abstraction en Ethereum y cadenas EVM-compatibles— es una base de código separada con un threat model diferente. Los bugs en smart contracts son implacables: una vez que un contrato está desplegado y custodiando valor, no puedes parcharlo silenciosamente.
El alcance de Halborn aquí:
- La integración con el EntryPoint de ERC-4337 y los account contracts específicos de SSP.
- Agregación de firmas Schnorr y verificación on-chain.
- Control de acceso, ownership y procedimientos de upgrade.
- Patrones de optimización de gas (incluyendo si alguna optimización abrió un footgun).
- Cada llamada externa que hacen los contratos.
3. El SDK
Fechas: 2 de enero – 14 de enero de 2025 Informe público: halborn.com — Schnorr Signatures SDK
Los terceros no consumen SSP únicamente a través de la UI del wallet —también pueden integrar las primitivas subyacentes de account abstraction directamente vía el SDK. Eso convierte al SDK en su propia superficie a endurecer: cualquier valor por defecto descuidado que ship se vuelve problema-de-todo-quien-lo-importe.
Halborn revisó la ergonomía de la API desde un ángulo de seguridad, validación de inputs, prácticas de logging seguro, y si la documentación del SDK guía a los integradores hacia patrones de uso seguros en lugar de los errores comunes.
Qué encontró Halborn
A través de las tres auditorías combinadas, el número titular es cero hallazgos críticos y cero de severidad alta. Los informes sí contienen un pequeño conjunto de hallazgos de severidad baja e informativos —la mayoría en ramas no usadas o rutas de código muerto que ya estaban marcadas para eliminación. Cada elemento señalado fue resuelto antes de que los informes se publicaran.
Esa última cláusula importa. "Auditado" por sí solo es una afirmación débil si los hallazgos quedan sin resolver. La versión de SSP que puedes instalar hoy es la que incluye las correcciones post-auditoría.
Qué significa esto para ti
Una auditoría limpia es una instantánea, no una promesa eterna. Llega código nuevo, las dependencias cambian y los threat models evolucionan. Pero las revisiones de 2025 te dan tres cosas que antes no tenías:
- Confirmación independiente de la criptografía. La afirmación de seguridad de SSP descansa en multisig 2-de-2 real con cada llave en un dispositivo separado. Halborn revisó cómo se generan las llaves, cómo se almacenan y cómo se combinan en firmas. El protocolo cumple con la afirmación.
- Un threat model público. Los informes describen qué se probó, no solo qué se encontró. Si estás evaluando SSP para autocustodia, puedes leer los mismos documentos de alcance con los que trabajó Halborn.
- Una vara de mantenimiento. Las futuras releases de SSP se medirán contra la línea base post-auditoría. Si algo regresiona, el diff es visible.
Cómo verificarlo por ti mismo
No tienes que tomar las palabras de este post para nada de esto. Los PDFs completos están enlazados arriba en el sitio de Halborn, y el equipo de SSP los replica en el repositorio de documentación del proyecto —incluyendo el índice resumen de auditorías en ssp-docs. Cada PDF incluye la metodología, la lista completa de hallazgos, las clasificaciones de severidad y el estado de remediación. Están escritos para un lector ingeniero de seguridad, pero son accesibles.
Si prefieres empezar por el protocolo en sí antes que por la auditoría, la introducción al multisig 2-de-2 es el punto de entrada correcto.