Entre o final de dezembro de 2024 e o final de janeiro de 2025, o SSP passou por três auditorias de segurança independentes com a Halborn, a empresa por trás de revisões de segurança para projetos em todo o ecossistema Web3. As revisões cobriram os três pilares do SSP — os apps de wallet e key, os smart contracts por trás do multisig ERC-4337, e o SDK contra o qual outros desenvolvedores podem integrar. Os três relatórios são públicos.
Este post é uma breve recapitulação: o que entrou no escopo, em que datas cada auditoria correu, o que a Halborn encontrou e onde você pode ler os relatórios por conta própria.
Resumo
- Três auditorias em uma única janela (23 de dezembro de 2024 – 22 de janeiro de 2025).
- Escopo: a extensão de navegador SSP Wallet e o app móvel SSP Key, o servidor relay que comunica os dois, os smart contracts ERC-4337 + Schnorr na Ethereum, e o SDK público.
- Achados: nenhum problema crítico ou alto. Um pequeno número de achados de severidade baixa e informativos — a maioria em caminhos de código não usados ou mortos — todos resolvidos.
- Os relatórios são públicos no site da Halborn e espelhados nos repositórios do SSP.
Três auditorias, uma janela
As auditorias rodaram em paralelo em vez de uma após a outra, o que é incomum para um projeto do tamanho do SSP. A razão é estrutural: os três componentes que a Halborn revisou conversam entre si constantemente, e o threat model de cada um assume garantias específicas dos outros dois. Auditá-los na mesma janela deu à Halborn uma visão completa de como uma transação real do SSP flui do navegador, através do relay, para dentro do smart contract, e de volta — em vez de uma fatia por vez.
1. SSP Wallet, SSP Key e SSP Relay
Datas: 30 de dezembro de 2024 – 22 de janeiro de 2025 Relatório público: halborn.com — SSP Wallet, Relay & Key
Esta foi a maior contratação. A Halborn olhou para:
- O cliente de extensão de navegador (geração de chaves, criptografia em repouso, fluxos de assinatura).
- O app móvel companheiro (Android e iOS) que detém a segunda chave no esquema multisig 2-de-2 do SSP.
- O servidor relay que intermedeia mensagens entre os dois — incluindo o formato do protocolo e como ele se comporta sob tráfego malicioso ou malformado.
- As primitivas criptográficas usadas de ponta a ponta: como sementes são geradas, como AES-GCM é aplicado, como assinaturas são produzidas e verificadas.
- Os mecanismos de 2FA sobrepostos.
Se você já usou o SSP, quase tudo que toca diretamente está dentro do escopo desta auditoria.
2. Smart contracts: ERC-4337 + Schnorr
Datas: 23 de dezembro de 2024 – 3 de janeiro de 2025 Relatório público: halborn.com — Account Abstraction Schnorr MultiSig
O lado on-chain do SSP — sua implementação de account abstraction na Ethereum e em cadeias compatíveis com EVM — é uma base de código separada com um threat model diferente. Bugs em smart contracts são implacáveis: uma vez que um contrato está implantado e custodiando valor, você não pode simplesmente corrigi-lo silenciosamente.
O escopo da Halborn aqui:
- A integração com o EntryPoint do ERC-4337 e os account contracts específicos do SSP.
- Agregação de assinaturas Schnorr e verificação on-chain.
- Controle de acesso, ownership e procedimentos de upgrade.
- Padrões de otimização de gás (incluindo se alguma otimização abriu um footgun).
- Cada chamada externa que os contratos fazem.
3. O SDK
Datas: 2 de janeiro – 14 de janeiro de 2025 Relatório público: halborn.com — Schnorr Signatures SDK
Terceiros não consomem o SSP apenas pela UI do wallet — eles também podem integrar as primitivas subjacentes de account abstraction diretamente via o SDK. Isso torna o SDK sua própria superfície a fortalecer: qualquer default desleixado que ele entrega vira problema-de-todos-que-importam.
A Halborn olhou para a ergonomia da API por um ângulo de segurança, validação de input, práticas de logging seguro, e se a documentação do SDK orienta integradores em direção a padrões de uso seguros em vez das armadilhas comuns.
O que a Halborn encontrou
Através das três auditorias combinadas, o número-manchete é zero achados críticos e zero de severidade alta. Os relatórios contêm sim um pequeno conjunto de itens de severidade baixa e informativos — a maioria em ramos não usados ou caminhos de código morto que já estavam marcados para remoção. Cada item sinalizado foi resolvido antes de os relatórios serem publicados.
Essa última cláusula importa. "Auditado" por si só é uma alegação fraca se os achados ficam sem correção. A versão do SSP que você pode instalar hoje é a que inclui as correções pós-auditoria.
O que isso significa para você
Uma auditoria limpa é uma fotografia, não uma promessa eterna. Código novo aterrissa, dependências mudam e threat models evoluem. Mas as revisões de 2025 te dão três coisas que você não tinha antes:
- Confirmação independente da criptografia. A alegação de segurança do SSP repousa em multisig 2-de-2 real com cada chave em um dispositivo separado. A Halborn olhou para como as chaves são geradas, como são armazenadas e como são combinadas em assinaturas. O protocolo bate com a alegação.
- Um threat model público. Os relatórios descrevem o que foi testado, não apenas o que foi encontrado. Se você está avaliando o SSP para autocustódia, você pode ler os mesmos documentos de escopo a partir dos quais a Halborn trabalhou.
- Uma régua de manutenção. Releases futuras do SSP serão medidas contra a linha de base pós-auditoria. Se algo regredir, o diff fica visível.
Como verificar você mesmo
Você não precisa acreditar nas palavras deste post sobre nada disso. Os PDFs completos estão linkados acima no site da Halborn, e o time do SSP os espelha no repositório de documentação do projeto — incluindo o índice resumido de auditorias em ssp-docs. Cada PDF inclui a metodologia, a lista completa de achados, as classificações de severidade e o status de remediação. Eles foram escritos para um leitor engenheiro de segurança, mas são acessíveis.
Se você prefere começar pelo protocolo em si antes da auditoria, a introdução ao multisig 2-de-2 é o ponto de entrada certo.