[ERC5437] コントラクトの脆弱性報告手段を定義する仕組みを理解しよう！

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、セキュリティについての連絡手段をコントラクトに暗号化して定義する仕組みを提案しているERC5437についてまとめていきます！

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

ERC-5437: Security Contact InterfaceAn interface for security notice using asymmetric encryptionEthereum Improvement Proposals

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

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

ERC5437では、非対称暗号を用いた「セキュリティ通知用インターフェース」を導入する提案をしています。具体的には、スマートコントラクトが公開鍵（非対称暗号の暗号鍵）と、セキュリティ通知の送付先（例えばメールアドレスやWebフォームURL）をインターフェース経由で公開します。

これにより、セキュリティ研究者は公開鍵を使って機密情報を暗号化し、安全な形で脆弱性の詳細を送信できるようになります。通知の送信先は、暗号化された情報を受け取って復号し、対応を行うコントラクトの管理者や開発チームになります。

動機

現在、スマートコントラクトの管理者に対して、セキュリティ問題を報告するための「公式的な連絡手段」は標準化されていません。そのため、脆弱性を発見したセキュリティ研究者がどこに、どのように報告すればよいか明確でなく、対応の遅れや情報漏洩のリスクが高まっています。

ERC5437で提案されているインターフェースを導入することで、開発者はセキュリティ報告専用の安全なチャネルを提供でき、研究者はそれを用いて暗号化された情報を安心して送信できます。 Ethereumや他のEVMベースのスマートコントラクト環境において、よりセキュアで信頼性の高いバグ報告の流れを構築することが目的です。

仕様

IEIP5437

IEIP5437.sol

interface IEIP5437 {

    /// REQUIRED
    function getSecurityContact(uint8 type, bytes memory data) public view
    returns (
        uint8 type,
        bytes memory publicKey,
        bytes memory extraData
    );

    /// OPTIONAL
    // TODO consider remove if not needed before finalized
    function setSecurityContact(
        uint8 type,
        bytes memory publicKey,
        bytes memory extraData) public;
    event SecurityContactChanged(uint8 type, bytes memory publicKeyForEncryption, bytes memory extraData);

    /// OPTIONAL
    function securityNotify(uint8 type, bytes memory data) public payable;
    /// OPTIONAL
    event OnSecurityNotification(uint8 type, bytes memory sourceData, uint256 value);

    /// OPTIONAL
    // TODO consider to make it a separate EIP
    function bountyPolicy(uint256 id) public view returns(string, bytes memory extraData);
}

イベント

SecurityContactChanged
- setSecurityContact 関数成功時に発行されるイベント。
OnSecurityNotification
- securityNotify 関数成功時に発行されるイベント。

関数

`getSecurityContact`

セキュリティ連絡先の情報を取得する関数。

function getSecurityContact(uint8 type, bytes memory data)
    public view
    returns (
        uint8 type,
        bytes memory publicKey,
        bytes memory extraData
    );

type
- 連絡先情報の形式を指定（[0x10, 0x7f] の範囲が有効）。
publicKey
- 指定された暗号方式の公開鍵。
extraData
- 電子メールアドレスなどの追加情報。

例： type = 0x10 は「GnuPG RSA/3072鍵＋RFC2822形式のメールアドレス」であることを意味します。

`setSecurityContact`

function setSecurityContact(
    uint8 type,
    bytes memory publicKey,
    bytes memory extraData
) public;

セキュリティ連絡先を設定・更新する関数。設定が成功した場合、SecurityContactChanged イベントを発行します。

`securityNotify`

function securityNotify(uint8 type, bytes memory data) public payable;

スマートコントラクトに対してオンチェーンでセキュリティ通知を送信する関数。成功した場合は OnSecurityNotification イベントを発行します。

`bountyPolicy`

function bountyPolicy(uint256 id) public view returns (string, bytes memory extraData);

セキュリティバグ報告に対する報酬ポリシー（バグバウンティ）の情報を取得する関数。

id = 0
- バウンティ全体の概要。
それ以外の数字
- 個別ポリシー（報告範囲や条件など）。

戻り値はURI文字列で、任意のフォーマットでバウンティ内容が掲載されます。

条件

getSecurityContact の実装は必要です。
ERC165（インターフェース識別標準）への対応が必要です。
type の値は [0x10, 0x7f] の範囲を使い、他は将来拡張用に予約されています。
publicKey のフォーマットは指定された暗号方式に準拠している必要があります。
setSecurityContact や securityNotify を実装する場合、それに対応するイベントの発行が必要です。

公開鍵の例

text

公開鍵の形式としてRFC 20（PGP ASCII Armor形式）を想定したRSA/3072ビット鍵の例が示されています。これはGnuPGで生成され、メール通知と連携するために使われます。

このようにして、スマートコントラクトがセキュリティ通報を正式かつ暗号的に安全な方法で受け取るインターフェースを提供することができます。

補足

ERC5437では、セキュリティ連絡先の情報を扱う方式として、シンプルなGPG（GNU Privacy Guard）ベースの暗号化方式と電子メールアドレスを採用しています。これは、実装や運用をできる限り簡易に保つことを目的としています。

将来的には、新しい暗号方式や通知手段を追加する提案（EIP）が登場することも見越されており、それに対応できるよう柔軟な設計が取られています。

また、以下のような理由からいくつかの補助的機能が導入されています。

setSecurityContact の追加は、暗号鍵の有効期限切れや運用変更などに応じて、連絡先を更新可能にするためです。
securityNotify を payable にしているのは、脆弱性報告に対してステーキングを伴う設計も可能にするためです。
- 例えば、報告の真剣度を担保する担保金のような用途です。
bountyPolicy と extraData フィールドを導入することで、今後の拡張（報酬体系や通知方法など）に柔軟に対応できる構造になっています。

互換性

現状、OpenZeppelinなどが採用している方法では、セキュリティ連絡先はソースコード内に平文で次のように記述されています。

/// @custom:security-contact some-user@some-domain.com

ERC5437は、既存の平文ベースの方法に加えて、暗号化された安全な報告チャネルを提供する新たな標準を導入する提案です。既存の方法と併用することが推奨されています。

セキュリティ

ERC5437を実装する際には、以下のような暗号通信のベストプラクティスに従う必要があります。

セキュリティ連絡先情報を常に最新に保つこと。
暗号鍵は推奨される期限内で定期的にローテーションすること。
通報チャネル（例：メールアドレスなど）は、通知を迅速に受け取れるよう定期的に監視すること。

これらの運用が適切に行われていない場合、セキュリティ報告手段が意味を成さず、脆弱性の発見や対応が遅れるリスクがあります。そのため、実装だけでなく継続的な運用管理も含めたセキュリティ対策が求められます。

引用

Zainan Zhou (@xinbenlv), "ERC-5437: Security Contact Interface [DRAFT]," Ethereum Improvement Proposals, no. 5437, August 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5437.

最後に

今回は「セキュリティについての連絡手段をコントラクトに暗号化して定義する仕組みを提案しているERC5437」についてまとめてきました！いかがだったでしょうか？

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

Twitter @cardene777

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

https://chaldene.net/

かるでねさんのプロフィールスマートコントラクトやAIを楽しんでいます。主にSolidityやSmart Contract、AIを使用した記事を書いてます。Zenn

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion