AWS Nitro Enclavesを使用してCubist CubeSignerを構築：Ethereumバリデーターなどのための安全で高信頼性の鍵管理プラットフォーム

バリデーターは、Ethereum のようなProof of Stake (PoS) ブロックチェーンプロトコルの基本的な構成要素です。バリデーターはチェーンの履歴を維持し、分散型金融アプリケーションから NFT コレクティブルまで、複雑な分散型アプリケーションを可能にするコンセンサスプロトコルを実行します。
プロトコルに参加するために、バリデーターは担保として資産を提供します。これにより、コンセンサスを形成する際に正しく動作することが保証されます。残念ながら、プロトコルは悪意のあるバリデーターと単なる過失を区別できないため、運用上のミスやバリデーターのクライアントソフトウェアのバグにより資産がリスクにさらされています。最良のケースでは小さな経済的なペナルティに、最悪の場合は資金全額が失われることにつながります。

このポストでは、Ethereum バリデータオペレーターを内部の脅威、バリデーターへの侵害、運用上のミス、クライアントのバグから守るために設計されたセキュアな鍵管理プラットフォームのハイレベルなアーキテクチャについて説明します。

以下のトピックについても扱います。

Ethereum のバリデーターを実行する際の課題と、関連するセキュリティおよびスラッシングリスク。
※スラッシングとは、バリデーターの不正行為に対する罰金のことです。
リモート鍵管理ソリューションを使ってこれらの課題に取り組む考え方と、リスクを実質的に軽減するためにキーマネージャーが構築される必要がある根本的な目標。
Cubist の CubeSigner のハイレベル設計。CubeSigner は AWS Nitro Enclaves 上に構築された、セキュアな鍵管理プラットフォームで、エンドユーザーのウォレットからトレーディング、チームや運用のための鍵管理まで、ステーキングやその他のアプリケーションをサポートしています。

Ethereum バリデーターを実行する際の運用上の落とし穴

Ethereum の PoS プロトコルは、数十万のバリデーターにより実行されるコンセンサスプロトコルです。数秒おきにバリデーターは Ethereum のトランザクションを実行し、無作為に選ばれたバリデーターが提案した状態の変化と結果が一致する場合、これらのトランザクションをブロックチェーンに追加し、バリデーションメッセージに署名することでそれを証明します。バリデーターに、正直にチェーンの状態を報告するインセンティブを与えるため、このプロトコルではバリデーターに 32 ETH のステーキングを求めています。バリデーターが期待どおり振る舞う (トランザクションを改ざんしたりチェーンの状態を偽ったりしない) と、ステークされた資産に対して報酬が得られます。そうでない場合、ステークの一部が失われます。

バリデーターがチェーンの状態を改ざんしていた場合、ネットワークの安全性を損なったとしてスラッシュと呼ばれるペナルティが課されます。スラッシュされるとかなりの金銭的ペナルティを受け、プロトコルから締め出されます。また、オフラインになったり、署名が非常に遅くなったバリデーターにも、プロトコルの可用性を危険にさらしているので、軽い制裁が課されます。

残念ながら、検証ノード (ノード運営者) のミスと故意の不正行為を区別することはできません。検証ノードがブロックチェーンの状態に関して 2 つの矛盾するレポートを提出した場合、その矛盾が意図的な不正行為に起因するものなのか、検証ノードソフトウェアのバグによるものなのかを判別するのは不可能です。その結果、セキュリティ、正確性、またはパフォーマンスに関する様々な種類のミスをしたオペレーターは、スラッシング (ペナルティ) によって直接的に金銭的損失を被ることになります。これらのミスを防ぐには、深刻な課題があります。

セキュリティ – 1 つのバリデーターのステーキングキーは通常 32 ETH (執筆時点で約 8 万米ドル) を保護します。ただし、このような貴重なバリデーターのステーキングキーは、数分ごとに検証メッセージに署名する必要があるため、コールドストレージに保管できません。そのため、ノード運用者はホットキーをシステム侵入から保護する必要があります。オープンソースのバリデータークライアント、ノードを 24 時間 365 日稼働させる運用要件、不正な運用者やソーシャルエンジニアリングなどの内部の脅威ベクトルがある複雑な環境において、これは特に困難です。
- 目標 – 攻撃者や悪意のある内部者から秘密の署名キーを盗まれたり、悪用されるのを防ぐキーマネージャーを作成する。
正確性 – 2 つの異なる競合するメッセージに署名したバリデーターは、競合する署名が誤りでも不正とみなされ、罰金 (スラッシング) が科されます。過去には、正直な運用者がバグのあるバリデータークライアントソフトウェア、マシン間でのバリデーターの移行エラー、バリデーターソフトウェアの更新ミスなどによって罰金を科されたこともあります。
- 目標 – 運用者がスラッシングから守られ、Beacon チェーンプロトコル仕様に従った正しい動作が保証されるキーマネージャーを作成する。
可用性 – 署名しなかったり遅れて署名した (たとえば 12 秒のスロット時間に応答しなかった) バリデーターは、報酬が減額されるか支払われません。そのため、ノード運用者は高可用性と信頼性のあるソリューションを設計し、低レイテンシー (通常は署名時の上限を 500 ミリ秒に設定) で応答する必要があります。
- 目標 – このようなレイテンシー、信頼性、可用性の目標を達成するのに役立つキーマネージャーを作成する。

リモートでの署名は、バグや運用ミスによるリスクを軽減

Ethereum の PoS Beacon チェーンに参加するために、ノードオペレーターは Lighthouse や Prysm などのバリデータークライアントを使用します。バリデータークライアントは、任意の数のバリデーターキーペアを含みます。各ペアは 1 つのバリデーターに対応しており、公開鍵がバリデーターの識別子、秘密鍵がバリデータークライアントがそのバリデーターに代わってメッセージに署名するために使用されます。バリデータークライアントはその後、これらの署名済みメッセージをビーコンチェーンネットワークに放送し、本質的にバリデーターのチェーン状態の見解を主張します。

Validator クライアントは、所有のマシン上で Validator キーを保持してローカルに署名することができます。または、リモートサイナーを使用することができます。リモートサイナーは、キーをリモートに保持し、Validator クライアントに対して署名 API を公開します。各エポックで、Validator クライアントは署名リクエストをリモートサイナーに送信し、サイナーから署名済みの Validation メッセージを受け取ります。ネットワーク経由のリモート署名はローカル署名より遅くなります。しかし、以下の理由から、オペレーターはリモートサイナーを使用しています。

セキュリティ– リモートサイナーを使用することで、バリデーター鍵を以下から隔離できます。
- バリデーターのクライアント – これは外部の不信な環境 (他のビーコンチェーンノード) と対話し、信頼されない Ethereum Virtual Machine (EVM) コードを実行します。
- インサイダー脅威 – ここにはノードの稼働状態を維持する運用者が含まれますが、彼らにはバリデーターの秘密鍵へのアクセスは不要です。
正確性– リモートサイナーを使用することで、参照モニター (アンチスラッシングデータベースと連携したサイナー) を実装し、鍵がスラッシングを引き起こすようなメッセージに署名することを回避できます。
可用性– すべてのバリデーター鍵を処理するリモートサイナーを使用することで、ノード運用者がバリデーターのクライアントを自動的にスケールし、クラッシュ時に新たにスピンアップできるようになります。

リモートサイナーは、これらの特性を考慮して設計される必要があります。Web3Signer のような一般的なサイナーを単純に使用しただけでは、これらの特性を得られません。例えば、リモートサイナーは、キーにアクセスできるユーザーを制限する必要があります。つまり、承認されたユーザー (およびバリデータクライアント) のみにアクセスを制限し、キーをサイナー自体に封印します。そして、キーで何ができるのかを制限する必要があります。そうしないと、侵害やインサイダー脅威がキーの盗難につながる可能性があります。

リモートサイナー自体は、高可用性で耐障害性がある必要があり、グローバルで高可用性のスラッシング防止データベースを使用する必要があります。そうしないと、サイナーや OS の更新、マシン障害、ネットワーク障害がスラッシングイベントの原因となる可能性があります。

最後に、リモートサイナーはローカル (安全ではない) 署名ほど高速である必要はありませんが、バリデータの待機時間は重要です。遅すぎる (一般的に 1 秒以上) と、バリデータがメッセージ署名が遅れ、オペレーターに金銭的損失が発生します。

以下のセクションでは、Nitro Enclaves ベースの CubeSigner リモート署名ソリューションを実装することで、セキュリティ、正確性、および可用性のゴールを達成した方法について詳しく説明します。

Cubist CubeSigner – Architecture overview

前述の、正確性、セキュリティ、パフォーマンスと信頼性の課題に対処するために、私たちは AWS Key Management Service (AWS KMS)、Amazon DynamoDB、そして Nitro Enclaves を利用した、新しいリモート署名サービス CubeSigner を構築しました。

検証クライアントからのメッセージを処理するためにサイナーが実行する手順は次のとおりです。

Amazon API Gateway 上の HTTP インターフェース経由で、検証メッセージを受け入れます。
DynamoDB に保存された署名履歴を使用して、そのメッセージがスラッシングするかどうかを確認します。
スラッシングしない場合は、AWS KMS とセキュアなキーを使用して署名します。

次の図は、このソリューションアーキテクチャを示しています。

次のセクションでは、これらの 3 つのステップを詳しく説明します。

認証されたハイレベルの署名 API

署名者は、Lighthouse や Prysm などの検証クライアントがそのまま使える API を公開する必要があります。シンプルながら低レベルの署名エンドポイントを公開する AWS KMS API とは異なり、この API はイーサリアム Beacon チェーン特有のハイレベルのバリデーターメッセージを処理する必要があります。このハイレベル API は必須です。なぜなら、メッセージの内容に基づいて、バリデーターメッセージに対してスラッシング防止ポリシーを適用できるからです。代わりにメッセージの生ハッシュを受け取って署名するだけでは、特定のメッセージがスラッシングの対象となる可能性があるかどうかを判断することはできません。

スラッシングを防ぐだけでなく、このハイレベルの API は、検証要求が認証済みの検証ノードから来たものであることも保証する必要があります。そうしないと、単一のクライアントが侵害されれば、すべての検証ノードとすべてのキーが侵害されてしまいます。CubeSigner はさらに進んで、細かい権限範囲による認証を使用しています。権限範囲は認証セッションを制限して、特定のアクション (例えば検証) のみを実行できるようにします。検証ノードに検証の権限範囲のみを与えることで、ノードオペレーターはそれらの検証ノードが、例えば Exit メッセージに署名したり、検証プロトコルから出ることを防ぐことができます。これにより、オペレーターが誤って検証ノードを出ることを防ぎ、代わりに出ようとする攻撃者からオペレーターが報酬を失うのを防ぎます。

CubeSigner は、発信者のアイデンティティを判別するためのカスタム認証スキームを実装した AWS Lambda authorizersと API Gateway を利用しています。各許可された署名リクエストは、CubeSigner の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに送信され、まず許可されたスコープがリクエストを許可しているかを確認します。次に、署名者がメッセージの署名ルートハッシュを計算し、そのハッシュの署名がスラッシングを引き起こさないようにアンチスラッシングポリシーを適用して署名を行い、署名をバリデータークライアントに返します。次に、アンチスラッシングと署名そのものについて説明します。

スラッシング対策

CubeSigner はポリシーエンジンであり、アンチスラッシングを実装しています。署名要求を承認した後、CubeSigner は Ethereum の組み込みアンチスラッシングを含む複数のポリシーを適用します。アンチスラッシングポリシーは EIP-3076 に従い、バリデーターがすでにコミットした Chain 履歴と矛盾するメッセージに署名しないことを保証します。つまり、ポリシーには状態を保存する必要があります。CubeSigner は DynamoDB をデータベースとしてこのポリシーを適用します。すべてのバリデーター鍵に対して、署名したメッセージを原子的かつ条件付きで記録し、ある特定のスロット番号に対して複数の署名が生成されないことを保証します。

DynamoDB は、あらゆるスケールのハイパフォーマンスアプリケーションを実行するために設計された、フルマネージド、サーバーレスのキーバリューの NoSQL データベースです。DynamoDB には、組み込みのセキュリティ、継続的なバックアップ、自動マルチリージョンレプリケーション、インメモリキャッシュ、そしてデータのインポートおよびエクスポートツールが備わっています。可用性と一貫したパフォーマンスは、ブロックチェーンバリデーターの実行時に特に重要です。これらが停止したり、レイテンシーやデータ不整合が発生すると、直接的な金銭的損失につながる可能性があるためです。これらの要件を踏まえると、DynamoDB は、単一ミリ秒で一貫したパフォーマンスと 99.999 % の可用性を備えている点で適しています。DynamoDB のパフォーマンス、コスト、スケーラビリティ機能の詳細については、Amazon DynamoDB 機能を参照してください。

安全な署名

3 つ目の層は、CubeSigner 仮想ハードウェアセキュリティモジュール (vHSM) です。この層は、キーを攻撃者から守るために、ハードウェアセキュリティモジュール(HSM)内で AWS KMS を利用してバリデーションメッセージに署名を付けます。

HSM と AWS KMS

銀行業務やドメイン証明書の管理など、セキュリティが重要な業務分野では、鍵管理に関するタスク (キーの保管や署名など) を HSM に外部委託することが一般的です。HSM は、暗号化の秘密鍵を物理的ハードウェアに紐付けた専用のデバイスです。このため、非常に盗難が難しくなっています。たとえば標準的な HSM では鍵の抽出攻撃を行うには電子顕微鏡のある研究室が必要です。そうしない場合、盗難を検知すると自己破壊します。

ただし、HSM 単独での利用は比較的難しくなります。高水準言語で記述されたアプリケーション内から HSM にアクセスするには、通常、ベンダー固有の SDK が必要となり、アプリケーション自体が PKCS11 API 標準に準拠している必要があります。AWS では、アクセス可能な HSM ベースの鍵管理サービスである AWS KMS を提供しています。AWS KMS は、FIPS 140-2 セキュリティレベル 3 に分類される HSM で保護された暗号化キーを作成/管理できるフルマネージドサービスです。さらに、標準の AWS SDK (例えば、Rust 向けの aws-sdk-kms)から利用できます。

AWS KMS を単独で使用しない理由

AWS KMS だけでは、バリデーターに対して安全な鍵管理ソリューションを構築するには不十分です。1つ目の課題は技術的なものです。

Ethereum バリデーターは Boneh-Lynn-Shacham (BLS) 署名スキームを使用して署名する必要がありますが、HSM はまだ National Institute of Standards and Technology (NIST) との規制の整合性の課題により、BLS をサポートしていません。HSM は主に、ブロックチェーン業界外で普及している RSA や Elliptic Curve Digital Signature Algorithm (ECDSA) などの暗号化署名スキームの提供に重点を置いています。新しい署名スキームのサポートを拡張するには、通常、HSM 自体のローレベルのファームウェアアップグレードが必要になります。

たとえ HSM が BLS 署名を生成できたとしても、次のような課題に直面するでしょう。待ち時間と処理能力です。Ethereum ノードオペレーターは数百から数千の承認者を実行していますが、すべての承認者が約 1 秒 (暗号化処理とネットワーク往復を含む) で署名を生成する必要があります。ほとんどの HSM はパブリックキー暗号化処理のバッチ処理に最適化されていません (例えば、KMS での 100 件の ECDSA 署名処理のレイテンシ合計では、1 秒制限を超えてしまいます)。さらに、HSM は一般的に処理能力に制限があります (デフォルトでは、AWS KMS は 1 秒間に 300 件の楕円曲線非対称暗号化処理しかできません)。AWS KMS HSM と Nitro Enclave を組み合わせることで、セキュリティを確保したまま、これらの問題を解決できる vHSM を実装できます。

Nitro Enclaves は分離された、堅牢な制約のある仮想化コンピューティング環境です。AWS Nitro Systemは専用ハードウェアと軽量のハイパーバイザによって、強固な分離、Nitro Security Moduleによるハードウェア生成エントロピー、暗号認証といった機能を提供します。これにより、Enclaves の信頼性を検証し、許可されたコードのみが実行されることを確認できます。

Nitro Enclavesと AWS KMS を利用する CubeSigner の仕組み

CubeSigner vHSM は、BLS などの主要な署名方式をソフトウェアで実装し、このコードを Nitro Enclave 上で実行します。これにより、任意の署名スキームをサポートでき、HSM よりもはるかに高速に署名を行うことができます。

vHSM はすべての署名キーを AWS KMS ベースのラッピングキーを使って暗号化します。トランザクションの署名要求を受けると、暗号化された署名キーとラッピングキーをEnclaves に取り込み、署名キーを復号化し、トランザクションに署名して、ユーザーに返します。vHSM での署名処理は、検証に十分な速度で行われ、パフォーマンスに影響を与えることはありません。その理由はネットワーク遅延を含めても 500ms 以下の時間しかかからないためです。

メッセージの署名には単一の署名キーの復号化が必要ですが、HSM は対称暗号化操作に最適化されています。例えば、AWS KMS では、デフォルトで毎秒 50,000 回の対称暗号化/復号化操作を実行できます。Nitro Enclave は、高速で非対称暗号操作 (例えば、署名の生成) を行えます。CubeSigner は、すべての暗号化された署名鍵 (この例では BLS バリデーター鍵ですが、一般的には任意の署名スキームの鍵) を DynamoDB に保存します。これにより、鍵のレプリケーション、バックアップ、DynamoDB のスケーラビリティとパフォーマンスの活用が可能になります。

ラッピングキーは AWS KMS を使用して保存および管理され、ノードオペレーターごとに 1 つのラッピングキーがあります。この鍵はEnclaves 内の vHSM にシールされ、AWS ルートユーザーからはアクセスできなくなっています。つまり、誰もラッピングキーを使用または抽出できません。KMS キーをEnclaves にシールすることは極めて強力な基本操作です。これにより、vHSM がオペレーターの署名キーを復号化できる唯一のコンポーネントであることが保証され、ソフトウェア上で HSM のようなハードウェア抽象化を実装することが可能になります。

Enclaves 内のコードだけがシークレットキーにアクセスできるため、キーを安全に保つには、Enclaves 内のコードを安全に保つことに尽きます。この目的で、コードは次の機能を備えています。

Rust で実装 – コードが秘密情報をメモリやサイドチャネルから漏洩しないように、低レベルで秘密情報の扱い方を制御できるため、Rust で開発しました。また、Rust を使用すれば、Enclaves 内で実行されるコードの安全性を証明する検証技術を簡単に使えます。
少ない依存関係 – cargo vet を使って依存関係を管理し、Rust の使用により、マッシブな実行時システム (JVM など)、複雑な Just-In-Time コンパイラ (JavaScript エンジンなど)、そして、それらに付随する大規模なサプライチェーンから解放されます。
最小権限 – Enclaves 内で実行されるコードのインターフェースが攻撃対象の表面積となります。当社の vHSM は、vsock 通信チャネルを使い、小さくタイプ安全なインターフェースを実装しています。これは、他のサイナーとは異なり、Enclaves の境界を越えて任意のネットワーク要求をプロキシするようなものではありません。
接続先の制限 – vHSM から外部に通信できるのは、AWS KMS への安全な通信経路のみです。詳細については、How AWS Nitro Enclaves uses AWS KMSを参照してください。しかし、ここでもサイナーはチャネルが侵害される可能性があると想定し、特定のEnclavesに関連付けられた一時的な秘密鍵と公開鍵を使用して、AWS KMS からの結果を証明書内の公開鍵で暗号化します。このようにすれば、AWS KMS の復号要求が発せられたEnclaves内でのみ、その復号結果を読み取ることができます。

おわりに

このポストでは、Ethereum のバリデーターノードを運用する際の運用上の落とし穴やトラップについて説明し、特にノードオペレーターが日々直面する安全性、正確性、可用性の課題のバランスについて取り上げました。ノードにローカルでキーを管理することに対し、リモートに署名することにより、これらの課題に対処できます。しかし、リモートサイナーの設計が重要です。そのため、Nitro Enclave に基づくリモートシグニングソリューション CubeSigner の設計を詳しく説明し、CubeSigner がオペレーターが直面する安全性とペナルティの課題に対処するだけでなく、運用コストを大幅に削減でき、高可用性のバリデータークラスターを実行するのにも役立つことを示しました。

Cubist のCubeSigner サンドボックスアカウントに登録し、AWS Blockchain Node Runners テンプレートを使用してイーサリアムのバリデーターを起動し、独自のイーサリアムのバリデーターノードを実行することをお勧めします。

本記事は、Use AWS Nitro Enclaves to build Cubist CubeSigner, a secure and highly reliable key management platform for Ethereum validators and beyond を翻訳したものです。翻訳は Blockchain Prototyping Engineer の深津颯騎が担当しました。

著者について

フレイザー・ブラウンは、Cubistの共同創設者兼最高技術責任者（CTO）です。また、カーネギーメロン大学コンピューターサイエンス学部の助教授でもあります。彼女の研究は、セキュリティとプログラムの正確性に焦点を当てており、実運用システムの（一部の）検証から、実際のコードベースにおける悪用可能なバグの自動検出まで幅広く取り組んでいます。例えば、彼女が開発したツールは、人気のあるChromeやFirefoxブラウザにおいて、多くのゼロデイ脆弱性や報奨金対象のバグ、そしてCVE（共通脆弱性識別子）を発見しています。

デイアン・ステファンは、Cubistの共同創設者兼チーフサイエンティストです。また、カリフォルニア大学サンディエゴ校のコンピューターサイエンス・エンジニアリング学科の准教授でもあります。彼の研究は、セキュリティとプログラミング言語の交差点に位置し、特に実運用環境で展開される安全なシステムの構築に重点を置いています。2019年にVMwareに買収された、ランタイムセキュリティのスタートアップ企業Intrinsicの共同創設者でもありました。

デイビッド-ポール・ドーンザイファーは、AWSのブロックチェーン開発アーキテクトです。彼は顧客がエンドツーエンドのブロックチェーンソリューションを設計、開発、スケーリングするのを支援することに注力しています。彼の主な専門分野はデジタル資産のカストディと鍵管理ソリューションです。

Amazon Web Services ブログ