概要

​

埋め込みウォレットアーキテクチャ

Sequence Embedded Wallets は、ネイティブなスマートコントラクト型マルチシグウォレットです。マルチシグの構成は 2/2 で、両者の署名が揃わないとトランザクションを送信できません。

従来の MPC アーキテクチャでは鍵を一緒に生成してから分離しますが、Sequence WaaS の鍵は常に分離されており、署名のために結合されることはありません。

このコアセキュリティ層に加え、Sequence WaaS アーキテクチャは追加の保護機能も提供します：

• Sequence Auth: 暗号化された AWS Nitro Enclave 上で稼働し、Sequence Auth は最初の署名者として機能します。これは Quantstamp による最新の公開監査済みバージョンにロックされており、Quantstamp の承認なしに Sequence がエンクレーブへアクセスしたりアップデートを適用したりすることはできません。
• Sequence Guard: Sequence Auth とは独立して稼働し、Guard はトランザクション署名前にユーザーの本人確認やインテントの確認を行うことができます。
• OpenID Connect 互換: Sequence WaaS は Google や Apple など、OpenID Connect プロトコルに準拠した既存のプロバイダーを活用します。他のソリューションと異なり、WaaS ではこれらのサービスと連携して独自の OIDC 識別子も利用可能です。

​

Sequence Auth

Sequence Auth は AWS Nitro Enclaves プラットフォーム上で動作する API サービスで、ユーザーウォレットごとに 2/2 マルチシグ構成に貢献する認証署名者を提供します。Sequence Auth を利用することで、アカウント作成・ログイン・セッション管理・ウォレットサポートを簡単にアプリへ追加でき、従来の Web 体験（ソーシャルログインやメールログインなど）を提供しつつ、スマートコントラクトと連携する暗号資産ウォレットへのアクセスも実現します。

​

WaaS 設定キー

新しいインスタンスごとに、WaaS構成キーがアプリやゲームクライアントを認証します。これにより、生成されたインテントがSequence Authに送信され、WaaS SDKを通じてブロックチェーンへアクセスできます。1つの構成キー内には複数のログインプロバイダーのクライアントIDを登録でき、それぞれがプロバイダーごとに生成されるウォレットアドレスを決定します。つまり、ログインプロバイダー（例：GoogleやApple）のクライアントIDが複数のインスタンスで共有されている場合、同じ認証情報を使って同じログインプロバイダーでログインしたユーザーは、同じアドレスが生成されます。

​

ウォレット秘密鍵

ウォレットの秘密鍵は、SequenceとQuantstampによる責任分担方式で暗号化されて保存されています：

1. Sequenceは、データベースに保存された暗号化済みデータ（blob）にのみアクセスでき、復号する手段は持ちません。
2. Quantstampは、ウォレットキーのデータを暗号化するために使用されるKMS（AWSハードウェアセキュリティモジュール）を所有・運用しています。彼らはキーの素材をエクスポートすることはできず、暗号化されたデータ自体にもアクセスできません。

​

WaaSエンクレーブ

WaaSエンクレーブは、暗号化されたウォレットデータを利用できる唯一の存在です。そのセキュリティは以下によって保証されています：

1. AWS Nitroハイパーバイザーが、実際に稼働しているエンクレーブコードに基づいて暗号学的なアテステーションを生成・署名します。このドキュメントには、Amazonの公開鍵基盤で署名されたPCR0（エンクレーブコードのハッシュ値）が含まれます。
2. 信頼できる第三者が運用するKMSは、アテステーションが有効であり、エンクレーブのPCR0ハッシュが期待値と一致する場合のみ暗号操作を許可するポリシーを指定します。つまり、エンクレーブにごくわずかな変更が加えられた場合でも、異なるアテステーションおよびPCR0ハッシュとなり、これらは事実上無効となります。
3. エンクレーブのコードはオープンソースであり、誰でも監査でき、サービスが監査済みのソースコードと完全に一致していることを確認できます。検証について詳しくはこちら。

Sequence Authのソースコードは公開されており、独立した監査も受けています。上記のセーフガードにより、いかなる関係者による改ざんも防止されています。

​

Sequence Guard

Sequence GuardはSequenceがホストするサービスで、ウォレットごとに2/2構成となるもう一つの鍵を担います。これは追加の防御ラインとして設計されており、ユーザーの「本人確認」だけでなく「意図の確認」も行います。これを2つの方法で実現しています：

1 - 制限と許可リスト：開発ダッシュボードから許可するアクションの種類を設定できます。これにより、ガードはその制約内のトランザクションのみ署名します。例えば、特定のNFTコントラクトXのみ呼び出し可能と定義すれば、それ以外のトランザクションは実行できません。

2 - ユーザー認証：Sequence GuardはSequence Authとは独立してユーザーを認証します。これは、MetaやGoogle、XなどのサードパーティOAuth 2.0のIDトークンを利用するか、またはメールや電話番号を使ったOTPコードによる直接コミュニケーションで行います。直接のやり取りは常に必要ではなく、発生する場合もシームレスで、プロジェクトのブランド情報が反映されます。

​

脅威モデル

これらのセーフガードにより、ウォレットは以下のシナリオに対して安全です：

1. Sequence.appのバックエンドが侵害された場合やガードキーが漏洩した場合：この場合でも、ユーザーの本人確認はSequence Authで必須です。

2. Sequence Authが侵害された場合：この場合はSequence Guardがウォレットを保護します。なぜなら、ユーザー認証を独立して行うため、攻撃者はウォレットへアクセスできません。

また、以下のシナリオにも部分的に対応しています： 3. パートナーのフロントエンドが侵害された場合、またはパートナー側でMITM攻撃が発生した場合：攻撃者がパートナーのフロントエンドを脆弱にした場合、ログイン時にはウォレットへアクセスできる可能性がありますが、現在非アクティブなユーザーのウォレットにはアクセスできません。つまり、このような事態でも被害を限定しつつ復旧が可能です。

​

データフローの簡易図

以下は、埋め込みウォレットを使ったトランザクション署名など、一般的なユースケースのデータフローを示しています。

​

1. インテントの生成

ユーザーがクライアントを操作し、ウォレットによるアクション（例：USDCの送金やコントラクトメソッドの呼び出し）が必要な操作を行います。

クライアントはWaaS SDKに対し、そのアクションのインテント生成を依頼します。このインテントはクライアントのセッションキーで署名されます。このセッションキーは、OAuthセッションが有効な間のみ有効な一時的なキーです。WaaSバックエンドへ送信されるすべてのインテントは、まずこのセッションキーで署名され、ユーザー側で認証済みのアクティブなセッションであることを検証します。

​

2. SDKがインテントをSequence Authへ転送

インテントと対応する署名が、AWS Nitro Enclave上で稼働するSequence Authサービスへ送信されます。 Sequence AuthはWaaS APIにインテントに基づくトランザクションの構築を依頼し、そのトランザクションが元のインテントから逸脱していないかを検証します。検証が成功すると、Sequence Authはトランザクションに署名し、トランザクション・インテント・署名をWaaS APIへ転送します。

​

4. WaaS APIがSequence Guardから署名を収集

WaaS APIは「半分署名された」トランザクションリクエストと、クライアントが署名したインテントを受け取ります。トランザクションを中継するにはもう1つ署名が必要なため、Sequence Guardを呼び出します。

​

5. Sequence Guardがユーザーを認証

Sequence Guardは、指定されたウォレットへの署名リクエストを受け取ります。インテントが存在し、トランザクションと一致し、有効なセッションで署名されていることを確認します。すべて正しければ、トランザクションに署名します。

​

6. 中継とトランザクションレシート

WaaS APIはトランザクションを中継し、レシートを待ちます。得られたtxHashはクライアントに返されます。