2024년 12월 말부터 2025년 1월 말까지, SSP는 Halborn과 함께 세 차례의 독립 보안 감사를 거쳤습니다. Halborn은 Web3 스택 전반의 프로젝트에 대한 보안 검토를 수행하는 회사입니다. 이번 검토는 SSP의 세 기둥을 다루었습니다 — wallet과 key 앱, ERC-4337 multisig를 떠받치는 스마트 컨트랙트, 그리고 다른 개발자들이 통합할 수 있는 SDK입니다. 세 보고서 모두 공개되어 있습니다.
이 글은 짧은 정리입니다 — 무엇이 범위에 들어왔는지, 각 감사가 언제 진행되었는지, Halborn이 무엇을 발견했는지, 그리고 보고서를 직접 어디서 읽을 수 있는지.
요약
- 같은 기간 내에 세 건의 감사 (2024년 12월 23일 – 2025년 1월 22일).
- 범위: SSP Wallet 브라우저 확장과 SSP Key 모바일 앱, 둘 사이를 중계하는 relay 서버, Ethereum 위의 ERC-4337 + Schnorr 스마트 컨트랙트, 그리고 공개 SDK.
- 발견 사항: critical 또는 high 수준 문제 없음. 소수의 low와 informational 수준 발견 — 대부분은 사용되지 않거나 죽은 코드 경로에 있었음 — 모두 처리됨.
- 보고서는 공개되어 있으며 Halborn 사이트에 게시되고 SSP 저장소에 미러되어 있습니다.
세 건의 감사, 한 기간
감사는 순차가 아닌 병렬로 진행되었으며, 이는 SSP 규모의 프로젝트에서는 흔치 않은 방식입니다. 이유는 구조적입니다: Halborn이 검토한 세 컴포넌트는 끊임없이 서로 통신하며, 각각의 threat model은 다른 둘로부터의 특정 보장을 가정합니다. 같은 기간에 함께 감사함으로써 Halborn은 실제 SSP 트랜잭션이 브라우저에서 시작해 relay를 거쳐 스마트 컨트랙트로 들어갔다가 돌아오는 흐름을 한 조각씩이 아니라 통째로 살펴볼 수 있었습니다.
1. SSP Wallet, SSP Key 그리고 SSP Relay
날짜: 2024년 12월 30일 – 2025년 1월 22일 공개 보고서: halborn.com — SSP Wallet, Relay & Key
이번이 가장 폭넓은 작업이었습니다. Halborn이 살펴본 것:
- 브라우저 확장 클라이언트 (키 생성, at rest 암호화, 서명 흐름).
- SSP의 2-of-2 multisig 구성에서 두 번째 키를 보관하는 모바일 동반 앱 (Android와 iOS).
- 둘 사이의 메시지를 중개하는 relay 서버 — 프로토콜 모양과 악의적이거나 기형 트래픽에 대한 견고성 포함.
- end-to-end로 사용되는 암호 프리미티브: seed가 어떻게 생성되는지, AES-GCM이 어떻게 적용되는지, 서명이 어떻게 생성되고 검증되는지.
- 그 위에 얹힌 2FA 메커니즘.
SSP를 사용해 본 적이 있다면, 직접 만지는 거의 모든 것이 이 감사 범위 안에 있습니다.
2. 스마트 컨트랙트: ERC-4337 + Schnorr
날짜: 2024년 12월 23일 – 2025년 1월 3일 공개 보고서: halborn.com — Account Abstraction Schnorr MultiSig
SSP의 on-chain 측 — Ethereum과 EVM 호환 체인에서의 account abstraction 구현 — 은 다른 threat model을 가진 별도의 코드베이스입니다. 스마트 컨트랙트 버그는 가차 없습니다: 컨트랙트가 일단 배포되어 가치를 보관하기 시작하면, 조용히 패치할 수 없습니다.
여기서 Halborn의 범위:
- ERC-4337 EntryPoint 통합과 SSP 고유의 account 컨트랙트.
- Schnorr 서명 집계와 on-chain 검증.
- 접근 제어, ownership, upgrade 절차.
- 가스 최적화 패턴 (어떤 최적화가 footgun을 열어두지는 않았는지 포함).
- 컨트랙트가 수행하는 모든 외부 호출.
3. SDK
날짜: 2025년 1월 2일 – 1월 14일 공개 보고서: halborn.com — Schnorr Signatures SDK
서드파티가 SSP를 사용하는 통로는 wallet UI만이 아닙니다 — 그들은 또한 기반이 되는 account abstraction 프리미티브를 SDK를 통해 직접 통합할 수 있습니다. 이 때문에 SDK는 그 자체로 강화되어야 할 표면이 됩니다: 거기서 출하되는 어떤 허술한 default라도 그것을 import 하는 모든 사람의 문제가 됩니다.
Halborn은 보안 관점에서 API의 사용감, 입력 검증, 안전한 로깅 관행, 그리고 SDK 문서가 통합자를 흔한 함정 대신 안전한 사용 패턴으로 이끄는지 살펴보았습니다.
Halborn이 발견한 것
세 건의 감사를 합산했을 때 헤드라인 숫자는 critical 0건, high 수준 0건입니다. 보고서들에는 분명히 소수의 low 수준과 informational 수준 항목이 들어 있습니다 — 대부분은 어차피 제거가 예정되어 있던 사용되지 않는 분기나 죽은 코드 경로에 있었습니다. 표시된 모든 항목은 보고서가 공개되기 전에 처리되었습니다.
마지막 절이 중요합니다. 발견이 그대로 미해결로 남는다면 "감사 완료"는 그 자체로 약한 주장입니다. 오늘 여러분이 설치할 수 있는 SSP 버전은 감사 이후 수정이 포함된 버전입니다.
이것이 여러분에게 의미하는 바
깨끗한 감사는 스냅샷이지 영원한 약속이 아닙니다. 새 코드가 들어오고, 의존성은 움직이며, threat model은 진화합니다. 그러나 2025년 검토는 여러분에게 이전에 갖지 못했던 세 가지를 줍니다:
- 암호 방식에 대한 독립적인 확인. SSP의 보안 주장은 각 키를 별개의 기기에 두는 진짜 2-of-2 multisig에 기댑니다. Halborn은 키가 어떻게 생성되고, 어떻게 저장되며, 어떻게 서명으로 결합되는지 살펴보았습니다. 프로토콜은 주장과 일치합니다.
- 공개된 threat model. 보고서는 무엇이 발견되었는지뿐 아니라 무엇이 테스트되었는지를 기술합니다. 여러분이 self-custody를 위해 SSP를 평가하고 있다면, Halborn이 작업한 것과 동일한 범위 문서를 읽을 수 있습니다.
- 유지 보수 기준선. 향후 SSP 릴리스는 감사 이후 기준선에 비추어 측정될 것입니다. 무언가가 회귀하면 diff가 보입니다.
직접 검증하는 방법
이 글의 어떤 말도 액면 그대로 받아들일 필요는 없습니다. 전체 PDF는 위에서 Halborn 사이트로 링크되어 있고, SSP 팀은 그것을 프로젝트 문서 저장소에도 미러합니다 — 감사 요약 인덱스도 ssp-docs에 있습니다. 각 PDF는 방법론, 전체 발견 목록, severity 등급, remediation 상태를 포함합니다. 보안 엔지니어 독자를 상정해 쓰여 있지만, 다가가기 어렵지는 않습니다.
감사 이전에 프로토콜 자체부터 시작하고 싶다면, 2-of-2 multisig 소개가 올바른 시작점입니다.
