企業におけるWeb3テクノロジー導入の最大の課題を克服するために

by ブルーノ・マルティンス（アルゴランド財団プリンシパル・アーキテクト）とロブ・ムーア（MakerX、CTO兼共同設立者）

ブロックチェーン革命は、分散化とトラストレスなトランザクションの新時代を切り開き、比類のないセキュリティと透明性を約束しました。しかし、企業がブロックチェーン技術を採用する機会が増えるにつれ、分散型台帳技術（DLT）内の鍵管理システム（KMS）の未成熟さに対する懸念が浮上しています。この記事では、企業がDLTのための堅牢なKMSソリューションを導入する際に直面する課題について、ベストプラクティス、落とし穴、代替アプローチ、安全でシームレスな未来のビジョンを、Hashicorpの洞察、Hashicorp Vaultを使用する際の課題、MakerXのケーススタディを通して紹介します。

鍵管理システムのベストプラクティス

‍

KMSとは、暗号鍵を保護し、暗号化、復号化、署名、検証などの暗号セキュア・オペレーションを実行するために使用されるシステムです。伝統的な意味において、鍵管理の実践は長い間、我々のシステムに根付いており、そのベスト・プラクティスの原則はよく理解されています。

‍

その原則は次のようにまとめられます：

• 分離：鍵は、それを使用するシステムから隔離すべきである。これは、システムが危殆化した場合に、鍵が危殆化するのを防ぐためである。

• アクセス制御：許可された利用者のみが鍵にアクセスできるよう、厳格なアクセス制御が必須である。

• 耐タンパー性：KMSは改ざんされにくいものでなければならない。これは、システムが改ざんされても暗号鍵が損なわれないようにするためである。

• 監査：KMSは監査可能でなければならない。これは、鍵の使用を包括的に監視し、鍵が正しく使用されていることを確認し、潜在的な侵害を調査する際に鍵がどのように使用されたかをフォレンジック的に判断できるようにするためである。

• 相互運用可能な統合API：KMSは、容易で一貫性のあるセキュアな統合を促進するために、統合のための標準的で合意されたプロトコルを採用すべきである。これはまた、コンプライアンスやセキュリティの規制要件にも役立つ。

• ハードウェア・セキュリティ：ハードウェア・ベースのソリューションがより安全であるのに対し、メモリのランタイム空間を参照する鍵は漏洩しやすいため、ソリューションはハードウェア・セキュリティ・モジュール（HSM）を含むべきである。

Web3におけるKMSの現状

シームレスさと安全性の欠如

‍

伝統的なKMSがその使用コンテキストから切り離されているのとは対照的に、Web3における現在のユーザー体験は、シームレスで安全なトランザクション署名に欠けています。WhatsAppのメッセージ送信のような日常的なアプリケーションでは、ユーザーは暗号化スキームとデジタル署名がシームレスに統合された裏側の恩恵を受けています。Web3は、残念ながら、同様の直感的で透明性のあるエクスペリエンスを提供するのに苦戦しています。

さらに、エンドユーザー向けWeb3ウォレットの現在のパラダイムでは、ユーザーが災難に強い状態を保つために「リカバリ・フレーズ」（本質的には秘密鍵）を見てバックアップする必要があります。ユーザが自分の秘密鍵をエクスポートできるという事実と、秘密鍵が安全な（理想的には）ハードウェア・エンクレーブに保管されることがほとんどないという事実が相まって、現在のエクスペリエンスは分離、改ざん防止、ハードウェア・セキュリティの原則に反していることになります。

‍「コピーペースト」地獄

‍

Web3業界では、技術や標準に対する 「コピーペースト 」的なアプローチが多い。さらに、Bitcoinの初期には、secp256k1のような暗号の選択により、カスタマイズされたインメモリ方式で多くの鍵管理を行う必要がありました。当時、従来のデバイス、ハードウェア、KMSは、選択された楕円曲線をサポートしてませんでした。

このため、カスタム鍵管理ソリューションが急増し、従来の鍵管理とハードウェア・ベースのセキュリティの原則を採用せずに登場したWeb3ハードウェア・ベンダーが出現しました。

‍

オープンなハードウェア・ウォレットの欠如

‍

ビジネスやウォレットが、ISO、FIPS、PCIなどの標準のコンプライアンスやセキュリティに対応するための、相互運用可能な方法でハードウェア・セキュリティ・デバイスと統合するための共通標準を欠いている場合、Web3業界の未成熟さは明らかなものになります。

‍現在、各ベンダーは独自のソフトウェア開発キット（SDK）、API、オペレーティング・システム固有のライブラリを使用しています。この断片化は、特にベンダーにとらわれないソリューションの開発を目指す企業や開発者にとって、コストと時間の面で大きな負担となっています。

‍

伝統的に、ハードウェア・メーカー（HSM、セキュリティ・キー、携帯電話など）は、PKCS#11、KMIPなどのオープン・スタンダードに準拠しています。この遵守により、これらの標準をサポートするデバイスは、同じAPIとSDKを使用してシームレスに統合できることが保証されます。ブロックチェーンに標準ベースのアプローチを取り入れることは、業界の成熟と技術的進歩に不可欠です。企業がブロックチェーンを採用することは、このような標準化された手法を確立するための自然な推進力となります。

‍

KMSの分離なし

‍

Web3ウォレットで広く見られるセキュリティ上の懸念は、KMSの基本的なセキュリティ原則である隔離の違反にあります。多くの場合、インメモリ・ウォレットはアプリケーション／ウォレットと同じランタイム空間内で秘密鍵情報を保存し、暗号化操作を実行するため、鍵のマテリアルを適切に分離することなくウォレットが運用されています。鍵を扱うコンポーネント間のメモリ、プロセス、パーミッションが論理的に分離されていないため、セキュリティ上のリスクが大きくなっています。より堅牢なアプローチには、Web3ウォレットの全体的なセキュリティ体制を強化するための論理的分離の実装が必要です。

したがって、現在の状況は、望ましいユーザー体験や必要不可欠なセキュリティ態勢を満たしていません。企業のニーズを満たすためには、何かを変えなければなりません。

‍

提案：エンタープライズ・ブロックチェーンKMSのあるべき姿

‍

KMSの原則に根ざした代替アプローチ

‍

アルゴランドのようなDLTを採用する真剣なビジネスや企業を効果的に支援するためには、以下の原則に沿った鍵管理アプローチを導入することが極めて重要です：‍

• マルチ・テナンシー：一般的なWeb3のSDKやウォレットがシングル・ユーザー向けであるのとは異なり、エンタープライズ・グレードのソリューションでは、複数のユーザーの認証や、自動化された暗号処理を実行するような無人システムサービスにも対応する必要がある。

• 分離：実行中のアプリケーションから秘密鍵のマテリアルを明確に分離してシステムを設計することは、漏洩のリスクを大幅に低減するために不可欠である。Web3では、Web3.js、ethersjs、algosdkなどのSDKがアプリケーションと同じランタイム空間で直接使用されるため、この原則はしばしば破られる。

• 回復力：鍵管理システムは、高いアップタイムを維持し、エンタープライズ標準に準拠した信頼性を持つ必要がある。さらに、データ損失を防ぐために、鍵資料の復旧を含むディザスター・リカバリ（DR）のための堅牢なメカニズムが整備されていなければならない。

• セキュリティ：KMSの全体的なセキュリティ体制を強化するためには、多層防御（Defense in depth）、最小権限、アクセス制御、転送時および静止時の暗号化、監査など、企業の標準的なセキュリティ慣行を導入することが不可欠である。

• コンプライアンス：KMSは、ISO、FIPSなど（ただし、これらに限定されない）、要求されるコンプライアンス標準を遵守し、業界で認知されたベンチマークに適合していることを保証する必要がある。

• オープンであること： オープン・スタンダードに基づく実装を選択することで、統合プロセスが合理化され、さまざまなアプリケーションや環境に対してよりアクセスしやすく、適応しやすくなる。

‍エンタープライズ・ブロックチェーン・シナリオのためのHashiCorp Vault

‍

これらの原則に従うため、エンタープライズ・ブロックチェーン・シナリオでは、特注のアプローチを選択するのではなく、実績のある既製のKMSを利用することをお勧めします。

すなわち、ハードウェア・セキュリティ・モジュール（HSM）、Fireblocks、CloudHSM、Azure Key Vault、またはHashiCorp Vaultのような実績のあるソフトウェア・ソリューションなどのソリューションです。ハードウェア・エンクレーブを使用することは理想的ですが、コスト、弾力性、広範な署名アルゴリズムのサポート不足などを考慮すると、トランザクション署名にHSMを使用しないことがよくあります。HSMが署名アルゴリズムにネイティブに対応していない場合、秘密鍵のマテリアルがエンクレーブから出なければならなくなるため、HSMを使用する目的が失われることに注意することが重要です。

これらの点を考慮して、HashiCorp Vaultを、適切に構成・設計されたエンタープライズ・ブロックチェーン署名シナリオの理想的なソリューションとしてお勧めします。その理由は以下の通りです：

• 実証済みの実績：HashiCorp Vaultは、従来の暗号化シナリオで長年にわたりその有効性を実証しており、文書化されたケーススタディにより業界をリードするソリューションとしての地位を確立しています。

• オープンソース／監査済み：HashiCorp Vaultは、オープンソースであり、厳重な監査を受けており、多くのセキュリティ標準に準拠しています。また監査装置とテレメトリーを内蔵しています。

• 業界標準の暗号化技術：HashiCorp Vaultは、業界暗号標準に大きく依存し、これらの標準の上に一貫したインターフェースを提供しています。

• 改ざん防止セキュリティモデル：HashiCorp Vaultは、改ざん防止セキュリティモデルを提供し、全体的な信頼性とセキュリティを強化しています。

• 幅広い暗号アルゴリズムをサポート：HashiCorp Vaultは、幅広い暗号アルゴリズムと暗号エンジンをネイティブにサポートしています。そのため、鍵のマテリアルはVaultエンクレーブから出る必要がありません。

• 弾力的な展開：HashiCorp Vaultは、高可用性と暗号化されたバックアップ/リストア・プロセスのメカニズムにより、弾力的な展開を容易にします。

• 鍵の隔離：HashiCorp Vaultの鍵はVault内に隔離されており、Vault内で鍵の作成が可能です。適切な設定により、管理者は秘密鍵にアクセスできず、厳格なアクセスポリシーにより、秘密鍵の使用/エクスポートが制限されます。

• 高度な機能：HashiCorp Vaultは、IDベースのアクセス管理により、鍵へのセキュアなユーザーアクセスを可能にする高度な機能を提供します。さらに、FIPS準拠のHSMですべての秘密マテリアルをラッピングすることも可能です。‍

Hashicorp Vaultの仕組み

Hashicorp Vaultは、多くの企業で利用されているオープンソースのKMSです。幅広い暗号アルゴリズムをサポートし、多くのセキュリティ標準に準拠しています。

秘密管理とローテーション、暗号化/復号化と関連鍵管理、署名機能、IDベースのアクセス管理、包括的な監査ログ、クラウド・サービスやHSMとの統合、マルチ・テナント、高可用性、高度なリカバリ・メカニズムなど、すぐに利用できる機能のリストは実に印象的です。

シャミアの秘密分散

暗号アルゴリズムであるシャミアの秘密分散は、秘密をシェアに分割することを容易にします。これらのシェアは異なる個人間で分配することができ、指定された閾値（2/3存在、3/5存在など）を満たすことで、元の秘密を再構築することができます。

Vaultの初期化

‍

Vaultの初期化とは、ルート鍵が生成され、シャミアの秘密分散を用いて定義された閾値に基づいてシェアに分割されるプロセスです。これらのシェアは次に、別個の個人または信頼できる組織であるべき開封者に配布されます。これは、一人の管理者が秘密鍵マテリアルにアクセスできないようにする鍵の仕組みです。

Vaultの封印と封印解除

‍

静止状態では、Vaultは密閉（暗号化）されており、使用の際には密閉を解除する必要があります。これは、初期化時に生成されたシャミアの秘密シェアの閾値を提供することで達成されます。このプロセスは、複数の人間が手動で実行することも、複数のAPIコールによって自動的に実行することもできます。

アクセス・ポリシーとロール

‍

Vaultは、ポリシーとロールの定義が可能な非常にきめ細かいアクセス制御システムを備えています。これを使用して、秘密や操作へのアクセスを制限したり、Vaultからの秘密マテリアルの不正なエクスポートを禁止したりすることができます。‍

‍

トランジット・エンジン

Vaultプラグインであるトランジット・エンジンは、暗号化、復号化、署名、検証などの暗号処理をトランジット中のデータ（保存されていない、例えば署名されていないブロックチェーン・トランザクション）に対して実行できるようにする必要があります。主要なブロックチェーン署名アルゴリズムのほとんどを含む幅広いアルゴリズムをサポートし、多くのセキュリティ標準に準拠しています。すぐにサポートされるアルゴリズムには、AES-GCM、ECDSA、ED25519、RSA、SHA2があり、追加オプションのためのプラグイン・エコシステムもあります。

Hashicorp Vaultを利用する上での課題と注意点

‍

Hashicorp Vaultには多くの優れた機能がありますが、軽い気持ちで導入できるソリューションではありません。Hashicorp Vaultは高度に設定可能で柔軟なソリューションであるため、正しく設定し、セキュアな運用を行うには、それなりの専門知識が必要となります。

これは、HCP Vault（ホスト型）またはエンタープライズ層のいずれかに料金を支払うことで、部分的に相殺することができます。HCP Vault層はコアVaultの信頼できるホスティングを保証し、エンタープライズ層はホスティングに加え、エンタープライズ・グレードのクラスタを簡単にセットアップできる便利なプラグインを利用できます。

これにより、信頼性の高いVaultクラスタを構築することができますが、正しく設定するためには追加の作業が必要になります。さらに、ホスティング層やエンタープライズ層の価格構造は、中小企業やプロトタイプのユースケースにコスト上の課題をもたらす可能性があります。HashiCorp Vaultはオープンソースであるため、ライセンス料を支払うことなく独自のクラスタを構築することも可能です。しかし、自動化された可用性の高いクラスタを構築するためには、かなりの労力がかかることに注意する必要があります。このアプローチでは、HashiCorp Vaultクラスタの設定と操作に習熟していることを強く推奨します。‍

ベースとなるVaultクラスターを利用し、ブロックチェーン・トランザクションに署名するための信頼性の高いエンタープライズ・グレードのソリューションを構築するには、以下の追加ステップを踏む必要があります：

• 署名の前に秘密鍵の再構築を行うための秘密のシェアを単一のノード上でアセンブルする必要があり、一人の管理者が秘密鍵にアクセスできないようにするため、シャミアの秘密鍵の取り扱い方法を検討。

• 自動アンシール（最初のポイントを損なうことなく）、回復力のあるクラスタ・リーダーの処理、効果的なアベイラビリティ・ゾーンの処理など、データ・センターの停止に耐える高い信頼性を確保するための自動化。

• 管理アカウントと設定アカウント、およびエンドユーザーIDプロバイダーの設定（理想的には自動化）。

• ブロックチェーン・トランザクション署名用のトランジット・キーの作成と設定、およびこれらのキーに対する（理想的には自動化された）アクセス・ポリシーの策定を行い、不正使用やエクスポートを防止。

• テレメトリー、監査、ディザスター・リカバリ（バックアップ/リストア）のための運用プロセスと統合を実装し、システムの監視とデータの整合性に対する包括的なアプローチを確保。

• APIを使用してエンドユーザー識別情報を適切に伝播し、符号化されたトランザクションを署名のために正しく渡し、署名されたトランザクションをブロックチェーンに渡す前に結果の署名を使用。‍

‍

アルゴランド・トランザクション構築

‍

アルゴランドのKMSとしてHashiCorpを統合する場合、従来のSDKを使用しないため、適切なモデルを作成し、エンコーディングを行い、適切な署名スキームを選択する方法を理解する必要があります。

モデル

‍

アルゴランド・トランザクションを構築する最初のステップは、最終的にエンコードされ署名されるモデルを作成することです。これらをどのような構造で構築すべきかを探すと、ほとんどの文書に次のような形式があります：‍

{

"txn": {

"amt": 5000000,

"fee": 1000,

"fv": 6000000,

"gen": "mainnet-v1.0",

"gh": "wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=",

"lv": 6001000,

"note": "SGVsbG8gV29ybGQ=",

"rcv": "GD64YIY3TWGDMCNPP553DZPPR6LDUSFQOIJVFDPPXWEG3FVOJCCDBBHU5A",

"snd": "EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4",

"type": "pay"

}

}

しかし、このモデルはalgosdkとgoalに特有なもので、プロトコルに特有なものではありません。このトランザクションの未署名バージョンを直接エンコードしてKMSで署名しようとしても、ノードによって検証されないことが判明しました。これは、期待されるモデルと実際に署名されるモデルとの間にある以下の主な違いに起因します：

• txnの内容だけがエンコードされる必要がある。

• プロパティはアルファベット順にソートする必要がある。

• JS Algorand SDKでは、エンコーディングは標準のmsgpackをフォークしたmsgpackで行う。こちらにあります：https://www.npmjs.com/package/algorand-msgpack

• 「snd」と「rcv」はエンコードされたアドレスとして表現されますが、対応するバイナリ公開鍵として署名する必要がある。

• 「gh」はgenesisハッシュですが、base64からデコードし、バイト配列としてエンコードする必要がある。

エンコーディング

txnの内容をエンコードする前に、amt、fee、fv、gen、gh、lv、note、rcv、snd、typeの各フィールドをアルファベット順に並べる必要があります。

アルゴランド暗号

アルゴランドでは、トランザクションの署名と検証に標準的なEd25519署名スキームを使用します。下の図は、通常のEd25519署名スキームと、生成と署名に必要な手順を示しています。

SDKの代わりに通常のKMSやHSMを統合して署名を実行しようとすると、Hashicorp Vaultのように署名プロセスの一部として使用するハッシュ関数を指定するよう求められる場合があります。選択するハッシュ関数としてSHA512を指定する必要があります。

‍

algosdkには、署名が必要な生のバイトを出力するbytesToSign関数があります。しかし、この方法では、先に説明したようにトランザクションを構築し、必要な依存関係をすべてインポートする必要があります。このメソッドには、生成されたバイトの正しさを検証したり、デコードに関するガイダンスを提供したりするメカニズムが欠けています。

このようなSDKの欠陥は、アルゴランド・エコシステムのツールに限ったことではありません。カスタムAPIとプロトコルが摩擦点となるような、より確立されたKMSとインターフェイスする場合、Web3業界には一定のレベルの未熟さがあります。

さらに、大規模なSDKをインポートしてその一部だけを使用することは、アプリケーション・パッケージの肥大化、不要なサードレベルの依存関係、未監査のパッケージ、操作や統合に対するきめ細かなコントロールの欠如など、エンタープライズ・レベルのアプリケーションにとって問題を引き起こします。

‍

これらの課題に対処するため、専用パッケージや専用ツールが、このような統合のためにますます魅力的になってきています。その一例が algo-modelsです。algo-modelsは、正しいモデリング、スキーマ検証、およびKMSで利用可能な形式でのエンコーディングを実行するための軽量パッケージです。このアプローチは有望であり、業界内でより広く普及することを期待します。

ケーススタディ：MakerXエンタープライズ署名プラットフォーム

AlgoKitの実装パートナーであるアルゴランド財団パートナーMakerXは、最近Hashicorp Vaultとトランザクションを作成しエンコードするためのalgo-modelsに基づいて、完全に自動化されたエンタープライズ・グレードの鍵管理プラットフォームを構築しました。このプラットフォームは、セキュアなアルゴランド・トランザクション署名を促進することを目的としています。

このシステムを設計するきっかけとなったのは、MakerXのクライアントの特定のニーズでした。そのクライアントは、金融サービス分野のアプリケーションのために、規制に準拠したカストディアル・アカウントを求めていました。このケースでは、アプリケーションはオーストラリア証券投資委員会（ASIC）から付与されたカストディアル・ライセンスによって管理されています。秘密鍵は、エンドユーザーに代わって数百万ドル相当の資産を保護する可能性があります。

プラットフォームの設計は、3つの主要なアーキテクチャ原則によって導かれ、安全なカストディアル・ソリューションの厳しい要件を満たすことを保証しました：

1. (半）分散型の鍵アクセス：一個人や管理者が秘密鍵にアクセスすることはない。異なる（半信頼）組織から複数の関係者が集まってアクセスする必要がある。

2. 回復の弾力性：鍵が相当額の資産に責任を持つことを考えると、ソリューションは障害に強くなければならず、ディザスタ・リカバリのシナリオでは、鍵は第1の原則に適合しながらも回復可能でなければならない。

3. 現存ユーザー鍵使用：鍵は、エンドユーザーが証明可能な形で存在する場合にのみ使用される。IDプロバイダーから提供され、特定のユーザーのみがアクセス可能な短命のアクセストークンが、鍵への唯一のアクセスポイントとして機能する。鍵のマテリアル自体はエンクレーブから出ることが制限され、鍵の使用を可聴化することができる。

MakerXのプラットフォームのハイレベルなアーキテクチャはこのようになっています：

最終的にMakerXは、これらの原則に準拠しながら、完全に自動化された印象的なプロダクション・グレードのプラットフォームを構築しました。これは、ブロックチェーン・システムのエンタープライズ鍵管理が正しく行われた素晴らしい例です。同様のプラットフォームを特定のユースケースに導入することを検討しているのであれば、MakerX社に連絡し、さらなる情報やディスカッションを得る価値があるかもしれません。

結論

MakerXとHashiCorp Vaultを使用して規制に準拠したカストディアル・アカウントを実装したように、Web3環境において従来のKMSの原則を遵守するKMS統合は成功しています。これは、厳格なコンプライアンスを必要とするエンタープライズ・グレードのアプリケーションによって、アルゴランドの技術スタックの統合が初めて成功したことを意味します。この統合は、ビジネスが規制要件を満たす上で明らかに役立っています。我々としては、統合、鍵管理、セキュリティに関して、長年にわたってこれまでのパターン、標準、テクニックを無視するのが普通であったWeb3が、新たな成熟レベルに達したことを意味すると考えています。

元記事：https://www.algorand.foundation/news/key-management-systems-and-enterprise-adoption-in-web3