2024 年 12 月末から 2025 年 1 月末にかけて、SSP は Halborn と共に 3 件の独立したセキュリティ監査を実施しました。Halborn は Web3 スタック全体のプロジェクトに対するセキュリティレビューを手がけている企業です。レビューは SSP の 3 本の柱を対象としました — wallet と key のアプリ、ERC-4337 multisig の背後にあるスマートコントラクト、そして他の開発者が連携できる SDK です。3 本の報告書はすべて公開されています。
本稿はその短いまとめです — 何がスコープに入ったのか、各監査がいつ実施されたのか、Halborn は何を見つけたのか、そしてどこで報告書を自分で読めるのか。
要約
- 同一の期間内に 3 件の監査（2024 年 12 月 23 日 – 2025 年 1 月 22 日）。
- スコープ： SSP Wallet ブラウザ拡張、SSP Key モバイルアプリ、両者を仲介する relay サーバー、Ethereum 上の ERC-4337 + Schnorr スマートコントラクト、そして公開 SDK。
- 発見事項： critical 級・high 級の問題はゼロ。少数の low 級および informational 級の発見 — そのほとんどは未使用または死んだコードパス内 — はすべて対応済み。
- 報告書は公開されており、 Halborn のサイトに掲載され、SSP のリポジトリにもミラーされています。
3 件の監査、ひとつの期間
監査は順次ではなく並行で進行しました。SSP の規模のプロジェクトとしては珍しいやり方です。理由は構造的で、Halborn がレビューした 3 つのコンポーネントは互いに常時通信しており、それぞれの threat model は他の 2 つから特定の保証が成立していることを前提にしています。同じ期間内にまとめて監査することで、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 構成において 2 つ目の鍵を保持するモバイル連携アプリ（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 contract。
- Schnorr 署名の集約と on-chain 検証。
- アクセス制御、ownership、upgrade 手続き。
- gas 最適化のパターン（最適化が footgun を開けていないかも含む）。
- コントラクトが行うすべての外部呼び出し。
3. SDK
実施日： 2025 年 1 月 2 日 – 1 月 14 日 公開報告書： halborn.com — Schnorr Signatures SDK
サードパーティは wallet UI 経由でしか SSP を利用できないわけではなく、基盤となる account abstraction プリミティブを SDK 経由で直接統合することもできます。そのため SDK はそれ自体がハードニング対象の表面となります — そこで雑な default が出荷されてしまうと、import するすべての人の問題になります。
Halborn はセキュリティの観点から API の使い勝手、入力検証、安全なログ運用、そして SDK のドキュメントが統合者を一般的な落とし穴ではなく安全な利用パターンへ導いているかを確認しました。
Halborn が見つけたもの
3 件の監査をまとめた見出し数値は critical ゼロ、high ゼロ です。報告書には少数の low 級・informational 級の項目 — そのほとんどは未使用のブランチや、もともと削除予定だった死んだコードパス内のもの — が含まれています。指摘されたすべての項目は、報告書が公開される前に対応されました。
最後の一文が重要です。「監査済み」という言葉だけでは、発見が未対応のまま残っていれば弱い主張に過ぎません。今日あなたがインストールできる SSP のバージョンは、監査後の修正を含んだバージョンです。
あなたにとっての意味
きれいな監査はスナップショットであり、永遠の約束ではありません。新しいコードが入り、依存関係は動き、threat model も進化します。しかし 2025 年のレビューはあなたにこれまでなかった 3 つのものを与えてくれます：
- 暗号方式の独立した確認。 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 の入門 が正しい入口です。