re:Invent 2024: AWSでのBlockchainウォレット実装 - KMSとNitro Enclaves活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Blockchain wallets on AWS: Secure, smart, and scalable (BLC403)
この動画では、AWSのBlockchain ArchitectのDavid Dornseiferが、CircleとFireblocksの専門家とともに、AWSにおけるBlockchainウォレットの実装について解説しています。Custodial、Non-custodial、Smart Walletなど様々なタイプのウォレットの特徴を説明した後、AWS KMSやAWS Nitro Enclavesを活用した実装方法を詳しく解説します。特にNitro Enclavesを用いたFireblocksのMPCウォレット実装は、EC2インスタンス上で強力な分離と保護を実現し、Private Keyの安全な管理を可能にしています。また、CircleのProgrammable Walletsは、Web2の開発者でも扱いやすい柔軟なウォレットインフラを提供し、ブロックチェーンの概念をエンドユーザーから抽象化することに成功しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
ブロックチェーンウォレットセッションの概要
皆様、本日のセッションBLC 403へようこそ。私はAWSのBlockchain ArchitectのDavid Dornseiferです。本日は、CircleのVP Security EngineeringのTamás Henning氏と、FireblocksのSystems ArchitectのMaayan Keshet氏をお迎えしています。今日は「AWSにおけるBlockchainウォレット：セキュア、スマート、そしてスケーラブル」についてお話しします。では、本日のアジェンダを見ていきましょう。
まず、様々な種類のBlockchainウォレットから始めます。 これらの違いやユースケースについて説明します。次に、AWS Key Management Servicesとコアサービスを使用してこれらをどのように実装できるかを見ていきます。その後、TamásがCircleが提供するスマートウォレットについて、そしてBlockchainウォレットに関連するUXの課題をどのように解決できるかについて説明します。続いて、AWS Nitro Enclavesの紹介と詳細な解説を行い、Confidential ComputeとNitro Enclavesの組み合わせがBlockchain分野でなぜ有効なのかを説明します。最後に、MaayanからFireblocksがAWSを使用してMPCとMPCウォレットをどのように構築したかについてお話しいただきます。
ブロックチェーンウォレットの基本と種類
まずは、Blockchainウォレットの基本的な仕組みについて、皆様と認識を共有しましょう。上部の図を見ると、ウォレットにはPrivate Keyが含まれており、これによってPublic Keyが決定されます。例えばEthereumの場合、これがパブリックアドレスに変換されます。Blockchainレイヤーやレジャー自体を見ると、ネイティブアセットやERC-20トークンなどの異なるアセットがあります。これらのトークンやネイティブアセットはパブリックアドレスを指しています。この関連付けを変更したい場合に重要となるのがPrivate Keyです。Private Keyは署名に使用され、その署名はレジャー上で検証され、特定のパブリックアドレスが有効で、十分なアセットがあるかどうかを確認します。その後、トランザクションが実行され、アセットが送信されるか、所有者が変更されます。この仕組みで重要なのは、Blockchainウォレットの核心となる原則、つまりPrivate Keyです。メタデータは追加的なものですが、核心となるのはPrivate Keyの保護です。なぜなら、誰かがPrivate Keyを入手したり署名を作成できたりすると、ウォレット全体を空にしたり、不正なトランザクションを送信したりすることができてしまうからです。
では、ユーザー基準でこれらのBlockchainウォレットを区別していきましょう。 まず、一般ユーザー向けの非常に人気のあるCustodialウォレットについて説明します。この実装では、BinanceやCoinbaseなどのサードパーティ企業があなたのキーを管理し、高度なセキュリティ、完全に管理されたリカバリー、その他の機能を提供します。ちなみに、会場の皆様の中で、Custodialウォレットをお持ちの方はどれくらいいらっしゃいますか？かなり多いですね。セキュリティは非常に重要な側面なので、通常MFA（多要素認証）が強制されます。Custodialウォレットの一般的なユースケースには、ステーキング、トレーディング、投資があり、時にはこれらの企業が面倒な作業を全て管理してくれるため、単なる実験的な利用もあります。
一方で、Non-custodialウォレットがあります。これらはMetaMaskのようなブラウザプラグイン、Ledgerのような専用のハードウェアセキュリティデバイス、Safe.globalのようなマルチシグネチャウォレットの形で非常に人気があります。Non-custodialウォレットは、ユーザーのコントロールと所有権を最適化することが目的です。ただし、エンドユーザーとしてキーの管理とリカバリーに責任を持つ必要があり、キーを失うと資金も失う可能性があるというデメリットがあります。
Private Keyの管理は非常に重要です。この概念に馴染みがあり、実際に経験がある方はどのくらいいらっしゃいますか？多くの方がご存じのようですね。Crypto-nativeなユーザーは通常、このタイプのウォレットから始めて、徐々に慣れていきます。私たちはこれらのウォレットを取引や投資、あるいはSafe.globalのようなDAOの資金管理に使用しています。DAOは分散型自治組織で、通常、資金の変更には定足数が必要となります。
Smart Walletとその特徴
ここ2、3年で、特にL2やL3ネットワークの登場に伴い、新しいタイプのウォレットが非常に人気を集めています。これらはSmart Walletと呼ばれ、Account Abstractionウォレットやプログラマブルウォレットとしても知られています。これらのウォレットは、後ほどTamásが詳しく説明しますが、企業によって管理されています。カスタマイズ可能なスマートコントラクトで、非カストディアルウォレットに関連するユーザー体験の多くの問題を解決します。ソーシャルログインやMFAなど、セキュリティを最適化できる機能があります。ブロックチェーンやスマートコントラクトベースの特徴を活かして、ゲーミングなど様々なアプリケーションに合わせてこれらの機能をカスタマイズできる点が素晴らしいところです。
では、機関投資家向けウォレットについて見ていきましょう。機関投資家向けでは、Hot Wallet、Warm Wallet、Cold Walletの3つのタイプに分類されます。Hot Walletはインターネットに接続されている、より具体的にはプログラムによるアクセスが可能なウォレットです。これらのウォレットには、キーを抽出できないHSMなどのセキュリティ対策が施されています。ただし、誰かがウォレットを操作してトランザクションに署名させることができた場合、それを防ぐことはできません。これらのウォレットは非常に効率的で高速であり、オンラインHSMがその実装例となります。ステーキング、決済、オンラインカストディなど、特定のユースケースではキーへの継続的なプログラムアクセスが必要です。
Warm Walletは、Hot Walletに似ていますが、人による確認など追加の承認が必要です。生体認証やアプリを通じてトランザクションを承認するという原則があります。これは、より高度な暗号アルゴリズムの文脈で見られ、通常はMPC/TSSの領域で、単一のキースキームを使用する代わりに異なる当事者が関与します。Tamásが後ほど、FireblocksでのWarm Walletの構築方法について詳しく説明します。このタイプのウォレットは、大量のデジタル資産を日々移動させる取引会社の間で特に人気があり、キーの高度なセキュリティ設定が必要とされています。
Cold Walletは最も古い標準的なウォレットタイプです。これらは通常、完全にオフラインであり、意図的にプログラムによるアクセスを持たないという点でWarm WalletやHot Walletとは異なります。署名やPrivate Keyの変更には人の介入が必要です。Cold Walletは、物理的な分離とプログラムアクセスの欠如により、極めて高いセキュリティを提供します。標準的な実装としては、オフラインHSM、つまりインターネットから切り離された専用のハードウェアセキュリティデバイスがあり、これは別の金庫に保管され、Chief Crypto Officerのみがアクセス可能です。この解決策は、数百または数千のBitcoinを保管する年金基金などのオフラインカストディに適しています。
AWS上でのブロックチェーンウォレット構築
Blockchainウォレットに必要な基本的な構成要素をまとめてみましょう。これまでさまざまなタイプのBlockchainウォレットを見てきましたが、最も重要な要素は、AWS KMS、Cloud HSM、あるいはSecrets Managerなどの、安全で堅牢なKey Management Serviceを持つことです。
ユースケースに応じて、AWS IAMによる細かなアクセス管理や、監査目的でのCloudTrailの利用が必要になります。これらのウォレットには、効率的なコンピュートレイヤーが必要不可欠です。LambdaやEC2インスタンスと組み合わせることができるサーバーレスなものもあります。Amazon CloudWatchは、統合可能な高度な監視・ログ記録システムです。トレーディングのユースケースでは、特定のAPIへの超低レイテンシーアクセスが必要なウォレットもあり、これはEC2インスタンスのクラスタープレイスメントグループやEnhanced Networkingで実現できます。
では、これらのウォレットを構築する2つの異なる実装方法を見ていきましょう。まず1つ目は、標準的な、比較的シンプルなウォレットです。これはKMSとLambdaをベースにしたHot Walletです。 完全にサーバーレスで、API Gatewayを通じてリクエストを処理できます。Lambdaがアクセスして署名を作成する、とてもシンプルな仕組みです。キーのインポートをサポートし、FIPS140-L2に準拠しており、このようにしてEVM互換のBlockchainウォレットを構築することができます。
もう1つ構築できるのがCold Walletです。先ほど説明したように、Cold Walletはオフラインのウォレットです。インターネットアクセスのない専用のプライベートサブネットでAWS CloudHSMを使用し、そこでキーを管理することができます。AWS CloudHSMは、シングルテナントのハードウェアセキュリティデバイスで、最高レベルのFIPS140-L3準拠を実現し、インポートとエクスポートをサポートしています。クラウドオペレーターやChief Security OfficerがEC2インスタンスを介してアクセスすることができます。
CircleのProgrammable Walletsソリューション
ここからはThomasにバトンタッチします。まずCircleについて簡単にご紹介させていただきます。当社は2013年に設立され、USDCとEURCの発行者として、約161兆ドルの取引量を誇る最大の規制対応かつMICA準拠のStablecoinを提供しています。私たちが提供する重要なサービスの1つが、エンタープライズグレードのStablecoinとインフラストラクチャで、これによりビジネスにBlockchainを組み込むことができます。 エンタープライズグレードのアプリケーションを構築するための完全なスタックプラットフォームを提供しています。EVMチェーンおよび非EVMチェーンを含む15のチェーンにわたるサービスを提供し、その上にUSDCとEURCを構築しました。また、Cross-Chain Transfer Protocolも構築しました。これは複数のチェーンにまたがる初のMint and Burnブリッジで、ブリッジに関連するセキュリティリスクを軽減します。
Web3サービスについてお話ししましょう。ここでは、Programmable Walletsのソリューションを構築しており、アプリケーションにセキュアなWalletを組み込む方法について詳しくご説明します。また、Smart Contract Platformによるデプロイメント、ブロックチェーンの手数料に関するすべてを抽象化できるGas Station、そしてCompliance Engineも提供しています。 Web3エコシステムに参入しようとする開発者との対話を通じて、私たちが発見した重要なポイントの1つは、暗号資産に精通してすべてを管理できる人から、Private Keyの扱い方を知らないWeb2の開発者まで、柔軟性が必要だということです。そのため、開発者が望む形で開発できるよう、システムに可能な限りの柔軟性を組み込みました。
私たちは、さまざまなUXオプションを用意しており、まずはDeveloper-controlled Walletsについてお話しします。これは、開発者の皆様がWallet内で起こることを完全にコントロールできるWalletです。EOAやエンドユーザーのWallet、またはSmart Contract Accountを自身で管理し、任意のモデルで好きな取引に署名することができ、エンドユーザーからブロックチェーンの概念を抽象化することができます。実際のアプリケーション体験を構築することができ、エンドユーザーにとってのブロックチェーンの概念は、単なるUSDやEURの送金のように、すべてがシームレスにバックグラウンドで処理されるような実装が可能です。
エンドユーザーは、ブロックチェーンを意識する必要がまったくありません。中央のオプションでは、MPCテクノロジー（Multi-party Computation）を利用して署名を行う、ユーザー自身がよりキーをコントロールできる方式です。これはエンドユーザーWalletとSmart Contract Walletで機能し、ユーザーは自身のモバイルデバイスで取引に署名し、PINコードや選択した認証方法を積極的に入力する必要があります。そのデバイスもMPCの計算に参加することになります。
これにより、APIのユーザーエクスペリエンスをカスタマイズできると同時に、開発者でさえも干渉できないように、ユーザーが望む通りにコントロールを維持することができます。右側では、Modular Walletsについて説明しましょう。これは最近オープンベータとしてリリースしたもので、Modular Smart Contract Walletsの実装を可能にします。各ステップで非常に柔軟な設定が可能で、独自のキーを持ち込んだり、開発者のキーを使用したり、ユーザーコントロールキーを使用したりして、望む方法でWalletを設定できます。素晴らしい点は、ERC-6900を使用して新しい機能を追加したり、必要に応じて機能を制限したりできる、完全な拡張性を持っていることです。
現在のAWSの活用方法を見てみましょう。左側から始めると、システムを通じたルーティングのためにAPI Gatewayを設定しています。上部には、この機能を実現するために構築したさまざまなシステムとプラットフォームが表示されています。その下には、異なるブロックチェーンとの通信方法や、取引の実行、ブロックチェーンの状態監視、異なるチェーン間での取引の認識などの複雑な処理を扱う方法が示されています。右側が魔法が起こる場所です - ここでKMSを利用し、MPCサーバーを実行し、ブロックチェーン内で起こっていることすべてを私たちの内部の世界の状態と照合するLedgerサービスを運用しています。
私たちは、このエコシステム全体を運用するために必要なすべてのキーや各種シークレットを保護するために、AWS KMSを広範に活用しています。また、お客様が独自のMPCノードを運用することを決めた場合、キー管理の観点からMPCシャーディングを完全にコントロールできるよう、お客様のMPCサーバーと相互接続することも可能です。 これが私たちの提供するキー管理の世界です。左側はSingle Sigで、1人の承認者が1つの固有のキーを持つ形式です。つまり、標準的なEOAトランザクションで、1つのキーですべてを制御できます。MPCサイドでは、MPCコンピュートによる一般的なThreshold Signatureを提供しています。最近ではPasskeysのサポートを開始し、さらに近々、複数の固有キーがポリシーやトランザクションを実行するためのしきい値に達することができるMulti-Sigを導入する予定です。
AWS Nitro Enclavesの概要と活用
では、先ほどのアーキテクチャで見た高度な暗号資産ウォレットの要件について説明しましょう。AWS Nitro Enclavesについて、そしてなぜこれが高度なブロックチェーンワークロードに適しているのかを説明したいと思います。まず、Nitro Enclavesとは何かを大まかに理解しましょう。 AWS Nitro Enclavesは、EC2インスタンスに追加レベルの分離と保護をもたらします。現状では、EC2インスタンス上の誰もが暗号化されたデータやプレーンテキスト、つまりEC2インスタンス上で使用中のデータにアクセスできます。EC2インスタンス上のRoot UserやAdministratorは、処理中のこのデータにアクセスする可能性があります。 AWS Nitro Enclavesを使用すると、専用のメモリ領域と専用CPUを切り出して、機密計算をそこに移動できます。これにより、非常に制限された安全なローカルチャネルを持つ、本質的に専用の仮想マシンであるEnclaveが実現します。
具体的には、親インスタンスへのvsock接続を持っています。この原理により、親インスタンスのLinuxボックス上のRoot Userでさえも、Nitro Enclave内で処理されているデータにアクセスすることはできません。では、Nitro Enclaveとは何か、そして何ではないのかを見ていきましょう。
Nitro Enclaveは、分離された、堅牢で、高度に制約された仮想マシンです。独自の独立したカーネルを持つ軽量なLinuxオペレーティングシステムであり、Enclaveの素晴らしい点は、独自の暗号化キーを実行できることです。Enclaveが「ではないもの」として：これはコンテナではなく、Enclaveに関連付けられた永続的なストレージはありません。EC2インスタンスのメモリ上で実行されるため、Enclave内のすべてが一時的です。Root User、Administrator、オペレーター、その他誰もが、EC2インスタンスからでさえも、この特定のEnclaveにアクセスすることはできません。そのため、メモリダンプを実行したりCPUレジスタにアクセスしたりすることはできません。さらに、デフォルトでは外部ネットワーキングがなく、親EC2インスタンスからのソケットだけという非常に制限された状態になっています。
これらの分離機能に加えて、暗号化アテステーションと呼ばれる興味深い機能があります。暗号化アテステーションとは、Enclaveが自身のアイデンティティを証明できることを意味します。Nitro Enclave内では、固定されたスキーマでアテステーションドキュメントを作成できます。オプションのデータフィールドを追加することはできますが、デフォルトでは、そのようなアテステーションドキュメントにさまざまなメジャーメントが含まれています。これらのメジャーメントは、基本的に状態に対するハッシュ値、またはEnclaveが作成されたときに取得されたハッシュ値です。例えば、Enclave全体に対するハッシュ値は、状態やカーネル設定に変更があれば、これらの値も異なるものになるため、そのアイデンティティとして機能します。
これらのオプションのデータフィールド（パブリックキーなど）と組み合わせることで、Enclave内で認証文書に署名することができます。この署名はNitro Hypervisorによって行われ、その文書はAWSのルート証明書で検証することができます。この検証により、その文書がEnclave内で作成され、Hypervisorによって署名されたものであることが確認でき、さらにPCR値を通じて正確な状態を把握することができます。
この認証機能を活用することで、AWS KMSのポリシーと組み合わせて、対称鍵の復号化などのKMSアクションをEnclaveのハッシュ値やIDと関連付けることができます。これは非常に強力な機能です。なぜなら、特定のEnclaveだけが特定の鍵を復号化できるようにすることができるからです。これはブロックチェーン分野で人気のある用途の1つです。Enclaveだけが復号化操作を実行でき、例えば秘密鍵の平文がEnclave内でのみ表示され、オペレーターや権限のない人が読み取ることができないことを保証できるからです。
主な特徴とメリットをまとめてみましょう。デフォルトではネットワークアクセスのない、強力な分離とセキュリティを備えています。EC2親インスタンスからのvsockという安全なローカルチャネルがあります。x86やARMプロセッサーで実行でき、このEnclaveに割り当てるCPUやメモリの量を決定できる柔軟性があります。Enclaveのアイデンティティをリモートで証明するための暗号化認証を利用できます。そして何より、追加コストなしでどのEC2インスタンスでも有効にできます。
では、これらの要素を組み合わせて、シンプルなブロックチェーンウォレットにNitro Enclaveをどのように活用できるか見てみましょう。 ここで見ているのは、VPCの中核にあるNitro Enclaveです。このユースケースでは...
...AWS KMSで暗号化されたブロックチェーンの秘密鍵があり、AWS Secrets Managerに保存することができます。暗号化されているため、これらの鍵の保存にDynamoDBやS3を使用することもできます。暗号化された鍵はAWS Nitro Enclaveにダウンロードされ、暗号化認証を使用してKMSに対してそのアイデンティティを証明します。その後、AWS Nitro Enclave内で秘密鍵の平文を取得することができます。
これらのEnclaveの素晴らしい点は、完全にソフトウェアで定義されているため、特定の楽円曲線のサポートに制限されないことです。私たちは望むあらゆる暗号化操作を実行し、署名済みトランザクションをユーザーに返すことができます。先ほど述べたように、アーキテクチャに関して完全な柔軟性があります。Gravitonとの互換性があり、x86上でも実行でき、その他多くのオプションがあります。これにより、大規模な鍵管理操作に対して非常にコスト効率の高いソリューションを実現できます。
FireblocksによるNitro Enclavesの実装と知見
では、FireblocksがNitro Enclavesをどのように活用しているかについて、Maayanにバトンを渡したいと思います。 皆さん、こんにちは。Fireblocksのマーヤンです。これからNitroと機密計算に関する私たちのユースケースについて詳しくお話ししたいと思います。 私たちは、Bank of New York MellonやANZのような機関投資家向けにブロックチェーンインフラストラクチャとウォレットインフラストラクチャを提供しています。ブロックチェーン分野には多くの可能性があります。これはブロックチェーンのセッションですからね。皆さんの多くがブロックチェーンウォレットを持っているとおっしゃっていましたので、私たちと同じように興奮していらっしゃると思います。そして機関投資家の方々もそれを理解しています。
トークンやCBDC、カーボンクレジット取引など、暗号資産でできることは多岐にわたります。暗号資産の世界は時として不安を感じるものですが、私たちはそのサポートをしています。新しいブロックチェーンをFireblocksに追加すると、突然そのチェーンの取引量の25%がFireblocksを通過するようになることがあります。これは、お客様とエコシステムの両方に対する大きな責任です。このような責任を負うことは身が引き締まる思いですが、同時に、これらの課題に対して見出した解決策には大きなエンジニアリングの誇りも感じています。
トランザクションの流れについて説明しましょう。トランザクションを開始するとどうなるのでしょうか？例えば、Davidが私に1ビットコインを送りたい場合を考えてみましょう。まずWeb UIかAPIを通じてトランザクションを作成します。そこからポリシーエンジンに進みます。ここでは、お客様それぞれが独自のルールを設定できます。例えば、1日の送金額を100万ドルまでに制限したり、特定のアドレスへの送金のみを許可したりといった、金融業界では一般的な制限を設けることができます。次にシリアライゼーションに進みます。Bitcoin、Ethereum、そしてその他のプロトコルにはそれぞれ異なるビットとバイトのプロトコルがあるため、トランザクションをシリアライズする必要があります。その後、秘密鍵による署名段階に進み、最後にネットワークにブロードキャストします。
このフローの中で、機密計算を重点的に活用すべき重要なフェーズをいくつか特定しました。例えば、攻撃者がポリシーエンジンを攻撃することに成功した場合、ルールを無視することができてしまいます - これは良くありません。また、もしシリアライゼーションフェーズが侵害された場合、私が会場の誰かに1ビットコインを送ろうとしても、攻撃者は送金先を自分のアドレスに変更できてしまいます - これも良くありません。あるいは、送金額を1億ビットコインに変更されてしまうかもしれません。どうなるかわかりませんね。
同様の理由で、署名のステージは非常に重要です。なぜなら、意図しないトランザクションに誤って署名してしまうと問題になるからです。これらすべてが非常に重要であり、今日は署名の部分に焦点を当てていきます。
先ほど述べたように、署名の部分は非常に重要で、暗号資産の世界では「Not your keys, not your crypto（あなたの鍵でなければ、あなたの暗号資産でもない）」や「Not your keys, not your wallet（あなたの鍵でなければ、あなたのウォレットでもない）」という言葉があるほどです。多くの方がこの言葉を聞いたことがあるでしょう。この問題に対してはさまざまな解決策があり、先ほどMPCについて触れましたが、これから詳しく見ていきます。
では、MPCつまりMulti-party computationとは何でしょうか？名前が示す通り、複数の関係者、あるいはCosignerと呼ばれる署名者が存在します。 各Cosignerは、他の署名者とは独立して、ランダムなビットとバイトのセットを生成します。これらのシャードが合わさって論理的な鍵を表現しますが、重要なのは、この論理的な鍵がどこにも保存されていないということです。トランザクションの送信時にどのように機能するかを後ほど見ていきますが、攻撃者が Private keyを盗むことができる単一の場所が存在しないという点で、非常に強力なシステムです。すべては仮想的で論理的なものなのです。
トランザクションに署名する際は、これらのCosignerすべてが通信を行って署名する必要があります。もし誰か一人でも不正を疑う理由がある場合、その人は単に署名を拒否すればよいのです。それだけです。数学的に見ても、それ以外のことはできません。誰か一人でも疑わしいと言えば、安全性が保たれ、合意も署名も行われません。MPCのもう一つの利点は、Blockchain-agnosticであることです。通常、Multi-signatureや他のスキームについて話す際、それはプロトコルに大きく依存します。BitcoinにはBitcoinのMultisigの方法があり、EthereumにはEthereumの方法があります。MPCを使用することで、新しいBlockchainを迅速にオンボードできる能力が得られ、また、すべてのBlockchainに対して、同じ実績のある検証済みのMPCインフラストラクチャを使用できます。このスキーマでは、通常、Fireblocksに2つのCosignerがあり、顧客のワークスペースにホストされる1つの顧客Cosignerがあります。
これがCosignerのアーキテクチャ図です。一度に理解するには多くの情報がありますが、順を追って説明していきましょう。まず、顧客はいくつかのセットアップを行う必要があります。先ほど説明したように、Nitroにはデフォルトで永続性がないため、Amazon S3 Bucketをセットアップする必要があります。Nitroが有効化されたEC2インスタンスをセットアップし、後ほど認証に使用するAWS KMSをセットアップする必要があります。その後、私たちが提供するイメージをそのEC2インスタンスにインストールします。
Cosignerが起動すると、MPCシャード（先ほど言及した一連のランダムなビット列とバイト列）が格納された暗号化データベースのあるS3バケットにアクセスします。これらは、お客様が設定したKMSキーを使用して暗号化されています。Enclaveを起動してこの暗号化データベースを取得すると、お客様に提供するイメージは、Davidが先ほど説明したプロセスを通じてKMSによる認証を受けます。認証が成功すると、データベースを復号化できますが、失敗した場合は、そのシャードに対して何もできず、その存在すら認識できません。これは非常に強力な機能です。なぜなら、誤ったイメージをインストールしたり、イメージが不正に改変されたり、誰かがコードを変更しようとした場合でも、そのシャード（秘密鍵の一部）にアクセスできず、署名プロセスに参加できないからです。すべてが正常に進んだ場合、Cosignerはネットワークに接続し、Fireblocksのサービスにアクセスして署名すべきトランザクションを取得し、このMPC通信に参加することができます。
アーキテクチャの詳細については、さらに多くの説明があります。完全な詳細については、ぜひ読んでいただきたい素晴らしいブログ記事を用意しています。興味がある方は、このQRコードからアクセスできます。AWSのブログに掲載されていますので、「AWS blog Nitro Fireblocks」でGoogle検索しても見つけることができます。
Fireblocksでは、様々な機密計算フレームワークを経験してきましたが、Nitroを使用する際に得られた重要な知見は非常に興味深いものでした。まず第一に、VM分離がより柔軟です。これはどういう意味でしょうか？Nitroでは、分離レベルはEnclave全体のレベルにあります。つまり、Enclave全体が分離された環境として機能し、その中で信頼できる、改ざんされていないことが保証されたコードを書くことができます。他のフレームワークでは、「インプロセス分離」と呼ばれる方式が採用されており、プロジェクトやコード内で、信頼できる部分と信頼できない部分を区分する必要があります。
実用面での影響として、他のフレームワークでは通常、そのフレームワークのベンダーとの密接な連携が必要になります。私たちの経験では、ファーストクラスのSDKは通常C++とRustでのみ提供されています。これは、これらのフレームワークがシステムエンジニアリングのバックグラウンドから来ているためです。ここには人材とベロシティに関する重要な考慮事項があります。C++とRustに精通したシステムエンジニアは少数かもしれませんが、機密計算を活用してシステムをより安全にしたいと考えるNode.jsエンジニアの方が多いかもしれません。これは私たちにとって大きなメリットであり、重要な発見でした。
その他の重要な知見として、このモデルにおいてもサプライチェーン攻撃の緩和が重要だということがあります。Enclaveを安全に起動し、コードを安全に実行する方法について多く議論してきましたが、もし10年前の脆弱性のあるNPMパッケージを使用して悪意のあるコードをEnclaveにダウンロードしてしまえば、それは良くありません。そのため、Enclaveに組み込まれるパッケージに対して、許可リストのような仕組みが必要です。私たちも、そして私たちのお客様も、このようなパッケージの脆弱性をスキャンするパイプラインを持っています。現在、市場にはDockerイメージで動作する多くの製品が存在します。私たちは、NitroのフォーマットであるEIF（Enclave Image Format）から同様のイメージを抽出するユーティリティを作成しました。このユーティリティを私たちのパイプラインに統合し、お客様にも使用していただくことで、私たちが構築して提供するイメージへの信頼性を高めることができています。
さて、セキュアなコードの実行について多くお話ししてきましたが、それだけで十分でしょうか？システムは本当に安全になったのでしょうか？システムのセキュリティは、最も信頼性の低い要素と同じくらいの強度しかない、言い換えれば、最も弱い部分と同じくらいの強度しかありません。ここ数年のソフトウェアプロジェクトへの攻撃、特に成功した攻撃を見てみると、その多くがソフトウェアエンジニアリングプロジェクトのCI/CD部分に焦点を当てています。そこで私たちは、この分野で何ができるかを検討し、Nitro Enclavesが私たちにとって良い構成要素になると考えました。
セキュアで信頼できるプロジェクトを構築する際には、3つの質問を考える必要があります：どこでビルドするのか、何をビルドするのか、そしてどのようなSecretsを使用するのか、です。例えばFireblocksでは、そのようなサービスを構築する方法の1つとして、オフラインマシンを使用しています。これらは安全で、オフラインであり、鍵も保管されており、誰もアクセスできません。しかし、使用するのは非常に困難です。毎日プロジェクトを開発して変更を加えたり、新しいセキュリティ脆弱性を修正したい場合など、この方法では迅速な開発が難しいのです。これが一つの方法です。では、何をビルドするのでしょうか？
攻撃者がGitリポジトリに侵入し、ビルドボタンをクリックする直前に悪意のあるコードを挿入することに成功した場合、重大なセキュリティ問題となります。セキュリティには完璧な数学的解決策はなく、常により多くの防御層を作ることを目指します。次に、Secretsをどこに保管するかを考える必要があります。これは後のアテステーションプロセスで使用される、イメージに署名するための鍵のことです。このプロセスによって、そのイメージがFireblocksによって作成され、信頼できるものであることを確認します。オフラインマシンの場合は簡単で、オフラインマシンに保存するだけです。
私たちはNitro Enclavesを使用して、オフラインマシンでビルダーイメージを作成するソリューションを開発しました。同じ方法で検証を行い、この新しいビルダーイメージを信頼します。オフラインマシンは信頼のルートとして機能します。なぜなら、私たちはオフラインマシンを信頼し、したがってその出力も信頼できるからです。ビルダーイメージのEnclaveが起動すると、ビルドする署名済みのコミットを受け取ります。組織内では、デプロイを決定できる指定された人々がいて、彼らはビルドしたい特定のハッシュに署名する必要があります。そして、それが本当にビルドを意図したコードであることを確認します。
その後、ビルダーイメージのアテステーションを行い、すべてが正しく、悪意のあるものでないことを確認してから、アテステーションの一部として受け取った鍵を使用してビルドと署名を行います。EIFをビルドし、署名し、成果物を公開してから、Enclaveを破棄します。これはNitro Enclavesを使用した非常に興味深い実装でした。なぜなら、信頼のルートをオフラインマシンから、より迅速で現代的なオンラインのビルドプロセスに昇格させることができ、開発の速度を大幅に向上させることができたからです。
ブロックチェーンウォレットソリューションの比較と結論
本日のレビューをしていきましょう。まず、Blockchainウォレットの概要から始めました。 私たちは、異なるユースケースを区別し、機関投資家向けと個人向けの様々なタイプのBlockchainウォレットについて見ていき、それらをAWS上でどのように安全に構築できるかを説明しました。最初に紹介したアーキテクチャは、KMSベースのHot Walletでした。KMSでは、キーのインポートは直接可能ですが、エクスポートはできません。EVMやその他のチェーンに必要なSECP256k1曲線という特定の楕円曲線の対応に関する問題があるため、非EVM互換のキーを実行することはできません。しかし、KMSはプログラム可能でインターネット経由でアクセスできるため、Smart Walletのサポートに使用できます。Tamásが説明したように、BLS署名がサポートされていないため、ステーキングのサポートは利用できません。複雑さの観点からは、Lambdaを使用して完全にサーバーレスな形で実装できますが、KMSはキーごとに課金されるため、コストが高くなります。
CloudHSMは、キーのインポートとエクスポートの両方をサポートしています。KMSと同様に、楕円曲線の制約により、非EVM互換の署名はまだサポートされていませんが、Smart Walletを実装することは可能です。CloudHSMはプログラムでアクセスできますが、シングルテナントのハードウェアセキュリティデバイスであるため、プライベートVPCでの特別なVPCセットアップとアクセスポイントが必要となり、より多くの実装作業が必要です。
コストの観点からは、専用のシングルテナントHSMであるため、より高価になりますが、最高レベルのコンプライアンスを表すFIPS 140レベル3準拠を提供します。
次に、AWS Nitro Enclavesについて、そしてそれが様々なタイプのBlockchainウォレットにどのように使用できるかについて説明しました。Nitro Enclavesは完全にソフトウェアで定義されているため、キーのインポート、エクスポート、そしてGoやRustなどの言語を使用して暗号アルゴリズムを定義できるため、非互換チェーンのサポートも提供します。コードを監査した後、安全なエンクレーブ処理を確保するためにエンクレーブに移行できます。これにより、あらゆるタイプのカスタムワークロードを実行できるため、Smart Walletに非常に人気があります。ステーキングのサポートについては、BLS楕円曲線機能も利用可能です。
これは、独自のソフトウェアを構築する必要がある完全なソフトウェア定義ソリューションであるため、複雑さの評価は3となります。Maayanが言及したように、ソフトウェアが適切に監査され、開発されていることを確認する必要があります。ただし、AWS Nitro EnclavesではEC2インスタンス自体以外の追加料金がないため、コスト効率の良いソリューションとなっています。
AWS Nitro EnclavesはEKSと組み合わせて使用することもでき、KubernetesとAWS Nitro Enclavesを一緒に活用することができます。これにより、Enclaveサイドでの鍵のインポートに関する機能をすべて維持しながら、水平スケーリングの機能も追加で利用できます。複雑さという観点では、Kubernetesはそれほど簡単ではなく、証明書管理のオーバーヘッドも必要となるため、より多くの複雑さに対処する必要があります。ただし、動的なスケールインとスケールアウトの機能を活用できます。コストの観点では、EKSのコストも考慮する必要があるため、若干高くなります。
本日のセッションは以上となります。ご質問がある方は、私たちはこの後も会場に残っておりますので、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion