# [ERC6662] ERC4337を拡張した認証データ管理の仕組みを理解しよう！

> ERC4337は、Ethereumのアカウント抽象化に関する提案であり、ユーザーがウォレットアカウントのセキュリティや使用性をカスタマイズできるようにするスマートコントラクトウォレットの標準を提供します。

- URL: https://cardene.dev/articles/2a28b56522466bf993f5
- 公開日: 2024-03-08
- 更新日: 2024-03-08
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

初めまして。
**CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

https://cryptogames.co.jp/

代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。

https://cryptospells.jp/

今回は、**ERC4337**の**IAccount**インターフェースを拡張し、ユーザーが一度の公開で認証データをチェーン上に保存できる新しい**IAccountMetadata**インターフェースを提案している**ERC6662**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-6662

他にも様々なEIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ERC4337**は、Ethereumのアカウント抽象化に関する提案であり、ユーザーがウォレットアカウントのセキュリティや使用性をカスタマイズできるようにするスマートコントラクトウォレットの標準を提供します。
この提案は、ユーザーがトランザクション署名に使う鍵をより柔軟に管理できるようにすることで、セキュリティの向上やユーザビリティの改善を目指しています。

提案された**IAccountMetadata**インターフェースは、**ERC4337**の拡張として、認証データをオンチェーンに保存する機能を提供します。
これは、よりユーザーフレンドリーな認証モデルのサポートを目的としています。
このインターフェースを利用することで、ウォレットやアプリケーションは、ユーザーがログインする時に使用する様々な認証方法（例えば、パスワード、バイオメトリクス、ハードウェアトークンなど）に関するデータをブロックチェーン上に保管することが可能になります。

**IAccountMetadata**インターフェースを使用することの主な利点は次のとおりです。

- **セキュリティの向上**
    - 認証データをオンチェーンに保存することで、データの不変性と透明性が保証され、不正アクセスやデータ改ざんのリスクを軽減できます。
- **利便性の向上**
    - ユーザーは異なるプラットフォームやサービス間で一貫した認証方法を利用できるようになります。
    - また、従来のパスワードベースの認証ではなく、よりセキュアで使いやすい認証方法の導入が促進される可能性があります。
- **カスタマイズ性**
    - **ERC4337**に基づくスマートコントラクトウォレットの柔軟性により、開発者は特定のアプリケーションやユーザー群に最適化された認証フローを設計できます。

この拡張は、ブロックチェーン技術の進化において、ユーザーエクスペリエンスを重視する方向性を示しています。
ユーザーフレンドリーな認証モデルを実現するために、セキュリティと使いやすさのバランスを取りながら、認証データを効果的に管理することが重要です。

:::message
**ERC4337**については以下の記事を参考にしてください。
:::

[\[ERC4337\] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！](/articles/8c97ca7c93c4557ebfc2)

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58/-qoixMc413uT4FFM61uhXYUiL05Hw-wahq9hV_JtjJs

## 動機

この提案における新しい**IAccountMetadata**インターフェースは、**ERC4337**の**IAccount**インターフェースを拡張したものです。
**IAccountMetadata**インターフェースを使用すると、ユーザーは認証データを一度だけ公開することでブロックチェーン上に保存できるようになります。
これにより、分散型アプリケーション（dApps）は、ユーザーがウォレットにログインするたびに、あらかじめウォレットを接続してアカウント関連情報をdAppにプッシュする現在の認証モデルの代わりに、チェーンから認証データを取得してより柔軟でユーザーフレンドリーな認証モデルをサポートできます。

### 背景
**ERC4337**は、ユーザーエクスペリエンスを向上させるためのアカウント抽象化を提案しますが、認証は依然としてウォレットを介して行われ、dAppとのやり取りにはウォレットの接続が必要です。
これにより、ユーザビリティが低下し、特に新規または非技術的なユーザーにとっては障壁になり得ます。

### IAccountMetadataインターフェースの提案
**IAccountMetadata**インターフェースを通じて、ユーザーは自身の認証情報（例えば、公開鍵、バイオメトリックス、OTP秘密鍵など）を一度ブロックチェーン上に公開することができます。
この情報は、ユーザーがdAppを使用する時に、dAppが自動的に取得して認証プロセスに利用できるようになります。

### 利点

#### ユーザーフレンドリー
ユーザーは一度認証情報を設定するだけで、その後は複数のdAppsで簡単にログインできるようになります。
これにより、ログインプロセスが大幅に簡素化されます。

#### 柔軟性
dAppsは、ユーザーから直接情報を受け取る代わりに、ブロックチェーンから認証データを取得することで、より柔軟な認証方法を実装できます。
これにより、セキュリティやユーザビリティの向上が期待できます。

#### セキュリティの向上
認証情報がブロックチェーン上に保存されるため、データの不変性と透明性が保証されます。
また、dAppは必要な情報のみを取得することができ、プライバシーの保護が強化されます。

### 実装上の考慮事項

#### プライバシー
認証データは公開情報となるため、ユーザーのプライバシーに配慮した設計が必要です。
適切な暗号化やアクセス制御メカニズムの導入が求められます。

#### インターフェースの標準化
**IAccountMetadata**インターフェースの機能やメソッドは、広く受け入れられるよう標準化される必要があります。
これにより、異なるdApps間での互換性と再利用性が確保されます。

#### 更新と管理
ユーザーが自分の認証データを更新または撤回するためのメカニズムが必要です。
これには、ユーザーが自身のデータに対する完全なコントロールを持つことが含まれます。

この提案は、Ethereumの認証モデルを大きく前進させるものであり、ユーザーエクスペリエンスの向上、セキュリティの強化、dApp開発の柔軟性向上に寄与する可能性があります。

## 仕様

### 認証フロー

![auth-flow.png](/images/qiita-db3ddf3f-ed81-95a4-1502-7c03d73d74a8.webp)
引用: https://eips.ethereum.org/EIPS/eip-6662

新しい認証ワークフローでは、ユーザーはAA（アカウント抽象化）に対応したスマートコントラクトアカウントを自分のウォレットアドレスとして使用します。
このシステムにおける「**認証者（Authenticator）**」は、ユーザーの操作を署名するための秘密鍵を保持するものである必要がありますが、その形態は何でも構いません。
例えば、オフラインの認証者モバイルアプリやオンラインのクラウドサービスなどが考えられます。
一方、「**リレー（Relay）**」は、dAppsからのリクエストを認証者に転送する責任を持つオンラインサービスです。認証者がオンラインであれば、リレーサービスの役割を果たし、直接dAppsからのリクエストを受け取ることができます。

#### AAに対応したスマートコントラクトアカウント
AA（Account Abstraction）は、Ethereumのアカウントモデルを拡張するコンセプトで、ユーザーが標準的なEOA（Externally Owned Account）ではなく、スマートコントラクトを通じてアクションを実行することを可能にします。
これにより、複雑なロジックやセキュリティ機能をアカウントレベルで実装できるようになります。

#### 認証者（Authenticator）
認証者は、ユーザーの命令（トランザクション署名など）を実行するための秘密鍵を保持します。
認証者は物理デバイス（例：スマートフォン）、ソフトウェアアプリケーション、またはクラウドベースのサービスである可能性があります。
オフライン認証者（モバイルアプリなど）は、物理的に分離された環境で秘密鍵を保持し、高いセキュリティレベルを提供します。
オンライン認証者（クラウドサービスなど）はアクセスが容易ですが、セキュリティ対策が十分に施されている必要があります。

#### リレー（Relay）
リレーサービスの主な役割は、dAppsからのリクエストを認証者に転送することです。
このプロセスは、ユーザーがdAppsを使用する時に透明な認証と操作の実行を可能にします。
認証者がオンラインの場合、リレーサービスの役割を自ら果たし、dAppsからのリクエストを直接受信することができます。
これにより、中間者の介在を最小限に抑え、より速やかで効率的な通信が実現します。

#### 新しい認証ワークフローのメリット
- **セキュリティ**
    - スマートコントラクトアカウントにより、秘密鍵の管理方法や認証プロセスに追加のセキュリティ層が導入されます。
- **柔軟性**
    - 認証者の形態が多様であるため、ユーザーは自分のニーズに最適なセキュリティと利便性のバランスを選択できます。
- **ユーザビリティ**
    - リレーサービスを介することで、ユーザーはdAppsとのやり取りをよりスムーズに行えるようになります。

この新しい認証ワークフローは、ブロックチェーン技術とデジタルアイデンティティの未来において、より安全でユーザーフレンドリーなアプローチを提供することを目指しています。

### インターフェース

このERC提案は、**ERC4337**によって定義された**IAccount**インターフェースを拡張する新しい**IAccountMetadata**インターフェースを導入しています。
この拡張は、新しい認証ワークフローをサポートするために設計されており、スマートコントラクトアカウントを使用して、より安全で柔軟、かつユーザーフレンドリーな認証システムを提供します。

#### IAccountMetadataインターフェースの構成

```ts
interface IAccountMetadata {
  struct AuthenticatorInfo {
    // a list of service URIs to relay message from dApps to authenticators
    string[] relayURI;
    // a JSON string or URI pointing to a JSON file describing the
    // schema of AuthenticationRequest. The URI should follow ERC-4804
    // if the schema file is stored on-chain
    string schema;
  }

  function getAuthenticationInfo() external view returns(AuthenticatorInfo[] memory);
}
```

##### AuthenticatorInfo構造体

認証情報を含む構造体で、以下のフィールドがあります。

- **relayURI**
    - dAppsから認証者にメッセージをリレーするためのサービスURIのリスト。
- **schema**
    - 認証リクエストのスキーマを記述するJSON文字列、またはJSONファイルを指すURI。
    - スキーマファイルがチェーン上に格納されている場合、URIは**ERC4804**に従うべきです。

:::message
**ERC4804**については以下の記事を参考にしてください。
:::

[\[ERC4804\] HTTP形式のWeb3 URLからコントラクトを呼び出すことができる仕組みを理解しよう！](/articles/837931ce60ca844aee13)

##### getAuthenticationInfo関数
この関数は外部から呼び出し可能で、認証情報（`AuthenticatorInfo`構造体の配列）を返します。

#### 認証リクエストのスキーマ

提案された認証システムでは、`AuthenticationRequest`オブジェクトの形式が、`AuthenticatorInfo`の`schema`フィールドによって定義されます。
スキーマは、エンドツーエンドの暗号化をサポートする例として提示され、`encryptedData`フィールドにすべての暗号化されたフィールドをパッケージングします。
基本フィールドに加え、スキーマ定義に従ってさらに多くのフィールドが存在する可能性があります。
特別な記号（例：`$e2ee`）が、フィールドが暗号化されていることを示すために使用されることもあります。

#### スキーマ例の詳細

```json
{
    "title": "AuthenticationRequest",
    "type": "object",
    "properties": {
        "entrypoint": {
            "type": "string",
            "description": "the entrypoint contract address",
        },
        "chainId": {
            "type": "string",
            "description": "the chain id represented as hex string, e.g. 0x5 for goerli testnet",
        },
        "userOp": {
            "type": "object",
            "description": "UserOp struct defined by ERC-4337 without signature",
        },
        "encryptedData": {
            "type": "string",
            "description": "contains all encrypted fields"
        },
    }
}
```

- **entrypoint**
    - エントリポイントのコントラクトアドレスを示します。
- **chainId**
    - チェーンIDを表す16進数文字列です。
    - 例えば、goerliテストネットは`0x5`と表されます。
- **userOp**
    - **ERC4337**によって定義された`UserOp`構造体を、署名なしで含みます。
- **encryptedData**
    - すべての暗号化されたフィールドを含む文字列です。

#### 重要性と影響
この提案により、dAppsはリレーサービスを通じて認証者から認証情報を効率的に取得できるようになり、認証プロセスをより安全かつスムーズに行えるようになります。
スキーマを使用することで、認証リクエストの形式を標準化し、エンドツーエンドの暗号化を通じてユーザーデータのセキュリティを確保することが可能です。
これにより、ブロックチェーンエコシステム全体での認証プロセスの透明性とセキュリティが向上します。


## 補足

提案された新しい認証ワークフローを実現するために、dAppは以下の二つの情報を知る必要があります。

#### 認証者はどこか？
これは`AuthenticationInfo`構造体内の`relayURI`フィールドによって解決されます。
ユーザーはこのURIをアカウントのメタデータとして公開し、dAppはこのURIを使用してサービスディスカバリーを行い、認証者にアクセスします。

#### `AuthenticationRequest`の形式は何か？
これは`AuthenticationInfo`構造体内の`schema`フィールドによって解決されます。
このスキーマは`AuthenticationRequest`オブジェクトの構造を定義し、認証者が消費します。
また、リレーサービスのための追加フィールドを定義し、柔軟なアクセス制御を可能にするためにも使用されます。

### リレーサービスの選択
各認証者は複数のリレーサービスのリストを提供できます。
dAppはリスト内のリレーサービスを通じて最初に機能するものを見つけるべきです。
各認証者の下にあるすべてのリレーサービスは同じスキーマに従う必要があります。

### 署名の集約
複数の`AuthenticatorInfo`が各スマートコントラクトアカウントの下で提供される場合、マルチシグ認証が可能になります。
各認証者は独立して署名されたユーザーオペレーションを署名し、バンドラーに提出できます。
これらの署名は**ERC4337**で定義されたアグリゲーターによって集約されます。

### 将来の拡張
**IAccountMetadata**インターフェースは、異なる要件に応じて拡張される可能性があります。
例えば、プロファイル表示用に新しいエイリアスやアバターフィールドが定義されるかもしれません。

:::message
この新しい認証ワークフローは、dAppとユーザー間のセキュリティと利便性を高めることを目指しています。
`relayURI`と`schema`フィールドにより、dAppは認証者の場所を特定し、必要な認証情報の形式を理解できるようになります。
リレーサービスの選択と署名の集約機能は、このシステムの柔軟性とセキュリティをさらに高める要素です。
将来的には、**IAccountMetadata**インターフェースの拡張により、さらに多くの機能が追加される可能性があります。
これにより、ブロックチェーン上での認証プロセスがより進化し、ユーザーエクスペリエンスが向上することが期待されます。
:::

## 互換性

新しいインターフェースは**ERC4337**と完全な互換性があります。

## セキュリティ

エンドツーエンド暗号化（End to End Encryption, E2EE）は、ユーザーのプライバシーを保護し、フロントランニング攻撃などのセキュリティリスクを防ぐための重要な技術です。
このコンテキストでは、dAppsから認証者へのデータ伝送中にデータを暗号化することで、第三者によるデータの閲覧や改ざんを防ぎます。

JWE（JSON Web Encryption, RFC-7516）は、このような状況でデータを暗号化するために採用される方法の一つです。

#### JWEを使用したプロセス

1. **CEK（Content Encryption Key）の生成**
    - まず、対称暗号化キーであるCEKを生成します。
    - このキーは、エンドツーエンド暗号化が有効になっているフィールドを暗号化するために使用されます。

2. **CEKの公開鍵による暗号化**
    - 次に、認証者（サインを行う人）の公開鍵を使用してCEK自体を暗号化します。
    - これにより、CEKを安全に送信することができ、唯一、対応する秘密鍵を持つ認証者のみがCEKを復号できるようになります。

3. **JWEオブジェクトの作成**
    - dAppは、`AuthenticationRequest`をJWEオブジェクトにパッケージングします。
    - このオブジェクトには、暗号化されたCEKとともに、エンドツーエンドで暗号化されたデータが含まれます。

4. **リレーサービスを通じた送信**
    - このJWEオブジェクトは、リレーサービスを介して認証者に送信されます。
    - リレーサービスはJWEオブジェクトを転送することはできますが、CEKを復号できないため、エンドツーエンドで暗号化されたデータにアクセスすることはできません。

#### セキュリティとプライバシー

- **ユーザープライバシーの保護**
    - E2EEは、ユーザーの認証情報やその他の機密データが、送信中に第三者によって読み取られることを防ぎます。
  
- **フロントランニング攻撃の防止**
    - トランザクションがブロックチェーンに記録される前に、その内容を知り、不正に利益を得ることを目的とした攻撃を防ぐことができます。

- **データの完全性と認証**
    - JWEは、データの完全性を保証し、送信者の認証も可能にします。
    - これにより、データが改ざんされたり、偽の送信者によって送られたりするリスクを軽減できます。

このように、JWEを使用したエンドツーエンド暗号化は、ブロックチェーンベースの認証プロセスにおいて、セキュリティとプライバシーを大幅に向上させることができます。

:::message
#### CKE

CEK（Content Encryption Key）は、コンテンツ暗号化キーのことで、データや情報を直接暗号化するために使用されるキーです。
具体的には、メッセージやファイルなどのデジタルコンテンツを暗号化する時に、そのコンテンツを暗号化するために使用されます。
CEKの概念は、特にエンドツーエンド暗号化（E2EE）の文脈で重要となります。
以下、CEKについてわかりやすく説明します。

#### CEKの役割

- **直接暗号化**
    - CEKは、対象となるデータ（例えばメールの本文やファイルの内容）を直接暗号化する役割を持ちます。
    - これにより、データのプライバシーとセキュリティが保たれます。

- **高速な処理**
    - 対象となるデータの直接暗号化に使われるため、CEKを使うことで、効率的かつ高速にデータの暗号化・復号が行えます。

#### エンドツーエンド暗号化におけるCEK

エンドツーエンド暗号化の文脈では、CEKは以下のようなプロセスで利用されます。

1. **CEKの生成**
    - 送信者は、対象となるデータを暗号化するためにCEKを生成します。

2. **データの暗号化**
    - 生成されたCEKを使用して、送信するデータを暗号化します。

3. **CEKの暗号化**
    - CEK自体を、受信者の公開鍵で暗号化します。
    - これにより、CEKは安全に受信者に送信され、受信者のみがCEKを復号して利用できるようになります。

4. **データの送信**
    - 暗号化されたデータと暗号化されたCEKを受信者に送信します。

5. **データの復号**
    - 受信者は、自分の秘密鍵を使用してCEKを復号し、そのCEKを使ってデータを復号します。

このプロセスにより、データは送信者から受信者まで安全に暗号化された状態で転送され、受信者のみがデータを読むことができるようになります。
これがエンドツーエンド暗号化の基本的な流れです。

#### CEKのメリット

- **セキュリティ**
    - CEKと公開鍵暗号化の組み合わせにより、非常に高いセキュリティレベルを実現できます。

- **柔軟性**
    - CEKを使うことで、さまざまなタイプのデータを効率的に暗号化・復号できます。

CEKは、データの安全な暗号化と転送に不可欠な要素であり、プライバシー保護とセキュリティ強化に大きく貢献します。
:::

:::message
#### JWE

JWE（JSON Web Encryption）は、JSON形式のデータを安全に暗号化するための規格です。
**RFC7516**に定義されており、データを暗号化し、その暗号化されたデータをJSONオブジェクトとして表現することができます。
JWEは、ウェブ上で情報を安全に送受信する必要がある場合に使用されます。
ここでは、JWEの基本的な概念と機能についてわかりやすく説明します。

#### JWEの構成要素

JWEは主に以下の5つの部分から構成されます。

- **Header（ヘッダー）**
    - 暗号化に使用されるアルゴリズムや、その他のメタデータを含みます。
    - このヘッダーはBase64URLエンコードされます。

- **Encrypted Key（暗号化されたキー）**
    - コンテンツを暗号化するために使用されたキー（CEK）を、受信者の公開鍵で暗号化したものです。
    - この部分もBase64URLエンコードされます。

- **Initialization Vector (IV)（初期化ベクトル）**
    - 暗号化プロセスにおいてランダム性を提供し、同じデータを暗号化する時に異なる結果を得るために使用される値です。
    - Base64URLエンコードされています。

- **Ciphertext（暗号文）**
    - 実際に暗号化されたデータ本体です。
    - データの内容がこの部分に含まれ、Base64URLエンコードされます。

- **Authentication Tag（認証タグ）**
    - 暗号化されたデータの完全性を保証するために使用される値です。
    - これもBase64URLエンコードされています。

#### JWEのプロセス

1. **暗号化**
    - 送信者はデータを暗号化するためにCEKを生成し、そのCEKを受信者の公開鍵で暗号化します。
    - 次に、実際のデータをCEKを使用して暗号化し、初期化ベクトル（IV）を用いてプロセスのランダム性を確保します。
    - 最後に、暗号化されたデータの完全性を確認するために認証タグを生成します。

2. **データの送信**
    - 暗号化されたキー、暗号文、初期化ベクトル、認証タグを含むJWEオブジェクトを生成し、これを受信者に送信します。

3. **復号**
    - 受信者は自分の秘密鍵を使用して暗号化されたキーを復号し、得られたCEKで暗号文を復号します。
    - その後、認証タグを使用してデータの完全性を確認します。

#### JWEのメリット

- **セキュリティ**
    - JWEはデータの機密性を保護し、送信中のデータの改ざんを防ぎます。
- **柔軟性**
    - さまざまな暗号化アルゴリズムとキーマネジメントスキームをサポートしており、用途に応じて最適なセキュリティレベルを選択できます。
- **互換性**
    - JSON形式でデータを扱うため、ウェブアプリケーションやAPI間でのデータの送受信に適しています。

JWEは、特にセンシティブな情報を含むデータを安全にウェブ上で交換する必要がある場合に重要な技術です。プライバシーを守りながらデータの完全性を保証するための効果的な手段として広く使用されています。
:::

## 引用

Shu Dong (@dongshu2013), Zihao Chen (@zihaoccc), Peter Chen (@pette1999), "ERC-6662: AA Account Metadata For Authentication [DRAFT]," Ethereum Improvement Proposals, no. 6662, March 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6662.

## 最後に

今回は「**ERC4337**の**IAccount**インターフェースを拡張し、ユーザーが一度の公開で認証データをチェーン上に保存できる新しい**IAccountMetadata**インターフェースを提案している**ERC6662**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4