Azure Confidential Ledger ノードの認証
Azure confidential ledger ノードは、コード サンプルとユーザーによって認証できます。
コード サンプル
初期化時に、コード サンプルでは、ID Service にクエリを実行してノード証明書を取得します。 コード サンプルは、ノード証明書を取得した後、台帳のクエリを実行して見積もりを取得し、その後、ホスト検証バイナリを使用して検証します。 検証が成功すると、コード サンプルは台帳操作に進みます。
Users
ユーザーは、Azure confidential ledger ノードの信頼性を検証して、それらが実際に台帳のエンクレーブとやり取りしていることを確認できます。 Azure Confidential Ledger ノードの信頼度はいくつかの方法で構築できます。それを相互に積み重ねることで、全体的な信頼度レベルを高めることができます。 そのため、手順 1 と 2 は、機能ワークフロー内の最初の TLS ハンドシェイクと認証の一部として、Azure confidential ledger エンクレーブのユーザーにとって重要な信頼構築メカニズムです。 さらに、ユーザーのクライアントと confidential ledger の間に永続的なクライアント接続が維持されます。
confidential ledger ノードの検証: confidential ledger は、Microsoft によってホストされている ID サービスのクエリを実行することで検証されます。これにより、サービス証明書が提供されるため、台帳ノードが、その特定のインスタンスのサービス証明書によって保証または署名された証明書を提示しているのを確認できます。 既知の証明機関 (CA) または中間 CA は、PKI ベースの HTTPS を使用してサーバーの証明書に署名します。 Azure confidential ledger の場合、CA 証明書はサービス証明書の形式で ID サービスによって返されます。 このノード証明書が返されたサービス証明書によって署名されていない場合、(サンプル コードに実装されているように) クライアント接続は失敗します。
confidential ledger エンクレーブの検証: confidential ledger は、そのエンクレーブ内で生成されたデータ BLOB であるリモート構成証明レポート (または見積もり) で表される Intel® SGX エンクレーブで実行されます。 これは、他のエンティティが、Intel® SGX 保護を使用して実行されているアプリケーションからその見積もりが生成されたことを確認するために使用できます。 見積もりには、エンクレーブとそれが実行されているアプリケーションのさまざまなプロパティを識別するためのクレームが含まれています。 具体的には、confidential ledger ノードの証明書に含まれる公開キーの SHA-256 ハッシュが含まれています。 confidential ledger ノードの見積もりは、機能ワークフロー API を呼び出すことによって取得できます。 取得した見積もりは、こちらで説明されている手順に従って検証できます。