すべての Confidential VM インスタンスのファームウェアは UEFI であり、Open Virtual Machine Firmware プロジェクトに基づいています。ファームウェアは、セキュリティ、パフォーマンス、安定性を維持するために Google によって管理されます。
Google が管理するファームウェアは、Confidential VM インスタンスの信頼のルートの測定レジスタに保存される値の一貫性も確保します。これにより、Confidential VM インスタンスのファームウェアが更新されたときに、構成証明の検証によって Confidential Computing ワークロードがブロックされるのを防ぐことができます。
Confidential VM インスタンスが Google が管理する正規のファームウェアで実行されていることを確認するには、次のタスクを実行します。
AMD SEV-SNP または Intel TDX が有効になっている Confidential VM インスタンスで、Google 署名のリリース認証を取得します。リリース認証には、ファームウェアに関連する事前計算済みの署名付き測定値が含まれています。
アーキテクチャ固有の測定値と比較して、リリースの承認を確認します。
リモート構成証明に加えて、Confidential VM インスタンスが保護されたリソースにアクセスする必要があるかどうかを決定するセキュリティ ポリシーの一部として、ファームウェア検証を含めることができます。
リリースのエンドースメントを取得する
リリースの推奨事項は、Google のツールまたは独自のツールを使用して取得できます。
Google ツールを使用してリリース エンドースメントを取得する
Google ツールを使用して AMD SEV-SNP または Intel TDX Confidential VM インスタンスからリリース承認を取得するには:
Go-TPM-Tools（AMD SEV-SNP または Intel TDX）または SEV Guest（AMD SEV-SNP）を使用して、構成証明レポートと関連する証明書を取得します。
gcetcbendorsementを使用して、構成証明から UEFI エンドーサメントを抽出し、ファイルに保存します。その後、構成証明が Google にルートされていることを確認し、構成証明レポートの測定値が署名付き測定値に含まれていることを確認できます。
独自のツールでリリースの推奨事項を取得する
独自のツールを使用してリリース承認を取得する手順は次のとおりです。
AMD SEV-SNP
AMD Secure Processor に拡張ゲスト リクエストを送信して、構成証明レポートを取得します。
オフセット
90hに保存されているレポートの 384 ビットの測定値を抽出します。詳細については、SEV セキュア ネストされたページング ファームウェア ABI 仕様の第 7.3 章、表 22 をご覧ください。384 ビットの測定値を使用して、次の Cloud Storage バケットからシリアル化された参照リリースのエンドーサメントをダウンロードします。
gs://gce_tcb_integrity/ovmf_x64_csm/sevsnp/384_BIT_MEASUREMENT.binarypbVMLaunchEndorsementメッセージ定義を使用して、protoc などのツールで BINARYPB ファイルをデコードします。message VMLaunchEndorsement { bytes serialized_uefi_golden = 1; bytes signature = 2; }
その他のリリース エンドーサーの場所
リリース承認は、AMD SEV-SNP 証明書配信メカニズムの GUID テーブルでも利用できます。次の GUID が割り当てられています。
9f4116cd-c503-4f5a-8f6f-fb68882f4ce2
GUID テーブルについては、AMD ゲスト / ハイパーバイザ通信ブロック仕様の SNP 拡張ゲスト リクエスト セクションをご覧ください。
Trusted Computing Group PC クライアント イベントログには、TCG PC クライアント プラットフォーム ファームウェア プロファイル仕様バージョン 1.06 リビジョン 52 に記載されている SP800-155 イベントで、リリース認証のローカル ロケーションとリモート ロケーションへの参照も含まれている場合があります。
インテル TDX
configfs-tsm レポートのエントリを作成します。
name=/sys/kernel/config/tsm/report/report0 mkdir "${name}" cat "${your_nonce_file}" > "${name}/inblob" cat "${name}/outblob" > "${your_quote_destination}"オフセット
b8hに保存されている引用の 384 ビットの信頼ドメイン測定 MRTD を抽出します（TDX モジュール 1.5 の場合）。詳細については、TDX DCAP 引用ライブラリをご覧ください。384 ビットの測定値を使用して、次の Cloud Storage バケットからシリアル化された参照リリースのエンドーサメントをダウンロードします。
gs://gce_tcb_integrity/ovmf_x64_csm/tdx/384_BIT_MEASUREMENT.binarypbprotoc などのツールで、
VMLaunchEndorsementメッセージ定義を使用してリリース承認をデコードします。message VMLaunchEndorsement { bytes serialized_uefi_golden = 1; bytes signature = 2; }
リリースの承認の例
リリース承認は次の例のようになります。
VMLaunchEndorsement:
serialized_uefi_golden: "SERIALIZED_BYTES"
signature: "LAUNCH_ENDORSEMENT_SIGNATURE_BYTES"
UEFI ゴールデン測定値
serialized_uefi_golden フィールドには、次のプロトコル バッファで定義されているように、複数の値のシリアル化されたバージョンが含まれます。
message VMGoldenMeasurement {
google.protobuf.Timestamp timestamp = 1;
// The changelist number this UEFI was built from.
uint64 cl_spec = 2;
// DER format certificate of the key that signed this document.
bytes cert = 4;
// SHA-384 digest of the UEFI binary without TEE-specifics about launch.
bytes digest = 5;
// A sequence of PEM-encoded certificates of keys used in cert in Root ...
// final intermediate order. The last certificate will have a signed cert.
bytes ca_bundle = 6;
VMSevSnp sev_snp = 7;
VMTdx tdx = 8;
}
VMGoldenMeasurement メッセージの VMSevSnp フィールドは、次のプロトコル バッファで定義されます。
message VMSevSnp {
// The Google-reported security version number of this UEFI on SEV-SNP.
uint32 svn = 1;
// Expected MEASUREMENT report field values given [key]-many VMSAs at launch.
map<uint32, bytes> measurements = 2; // bytes size 48
// A UUID that Google uses for its CVM UEFIs
bytes family_id = 3; // size 16
// A UUID to name this specific release of the UEFI image. This is randomly
// generated with each build.
bytes image_id = 4; // size 16
// The launch policy that verifiers should expect with this UEFI.
uint64 policy = 5;
// Optional. PEM-encoded certs for Identity..Author..Root. If a singleton,
// only an Id-key is used.
bytes ca_bundle = 6;
}
VMGoldenMeasurement メッセージの VMTdx フィールドは、次のプロトコル バッファで定義されます。
message VMTdx {
message Measurement {
// The amount of RAM in GiB provided to the VM. This is relevant to the
// construction of the measured TDHOB page that includes memory region
// resource attributes.
uint32 ram_gib = 1;
// If true, EFI_UNACCEPTED_MEMORY not presented to guest.
// All memory is accepted by the firmware. Relevant to the TDHOB page
// since the resource attribute will include
// EFI_RESOURCE_ATTRIBUTE_NEEDS_EARLY_ACCEPT.
bool early_accept = 2;
// The SHA-384 digest of the measurement operations for the VM at launch.
bytes mrtd = 3;
}
// The Google-reported security version number of this UEFI on TDX.
uint32 svn = 1;
// Expected MRTD report field values given legal configurations.
repeated Measurement measurements = 2;
}
独自のツールを使用して serialized_uefi_golden field からこれらの値を解凍してデコードするには、次の手順を完了します。
新しい
VMGoldenMeasurementメッセージを割り当てます。serialized_uefi_goldenをメッセージに Unmarshal します。
または、gcetcbendorsement inspect コマンドを使用することもできます。
リリースの推奨事項を確認する
リリース承認を取得したら、そのシグネチャを検証し、必要に応じてその測定値をセキュリティ ポリシーに統合します。
リリースの承認署名を確認する
信頼アンカーに Compute Engine Confidential Computing の信頼できるコンピューティング ベースのルートキー証明書を含めることで、リリース認証の署名を確認できます。
リリース エンドーサメントの VMGoldenMeasurement の cert フィールドには、エンドーサメント署名鍵の公開鍵の DER でエンコードされた X.509v3 証明書が含まれています。証明書がルートキーによって署名されている。
gcetcbendorsement を使用すると、署名の検証に実行する openssl コマンドを表示できます。たとえば、次のコマンドを実行します。
gcetcbendorsement verify --show LAUNCH_ENDORSEMENT_FILENAME.binarypb
次の例のようなレスポンスが返されます。
openssl verify -CAfile <(openssl x509 -outform pem -in <(curl https://pki.goog/cloud_integrity/GCE-cc-tcb-root_1.crt)) \
<(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert) \
&& \
openssl pkeyutl -verify -pkeyopt rsa_padding_mode:pss \
-pkeyopt rsa_pss_saltlen:32 -pkeyopt digest:sha256 -pkeyopt rsa_mgf1_md:sha256 -pubin \
-inkey <(openssl x509 -pubkey -nocert -outform pem -in <(gcetcbendorsement inspect mask "LAUNCH_ENDORSEMENT_FILENAME.binarypb" --path=cert)) \
-sigfile <(gcetcbendorsement inspect signature "LAUNCH_ENDORSEMENT_FILENAME.binarypb") -keyform PEM \
-in <(openssl dgst -sha256 -binary <(gcetcbendorsement inspect payload "LAUNCH_ENDORSEMENT_FILENAME.binarypb")
独自のツールを使用する場合は、レスポンスで使用される gcetcbendorsement inspect コマンドを、逆シリアル化された VMGoldenMeasurement メッセージの名前付きフィールドの独自のプロトコル バッファ抽出ロジックに置き換えることができます。
リリースの承認測定値を確認する
リリース承認を作成する方法のサンプルコードは、gce-tcb-verifier GitHub リポジトリで入手できます。これを使用して、Google が UEFI から測定値を導き出した方法を理解し、関連する測定値をセキュリティ ポリシーに組み込むことができます。
たとえば、ファームウェアがファームウェア ベンダーによって署名されていることを確認したり、アーキテクチャ固有の測定値を、VMLaunchEndorsement メッセージで提供される事前計算済みの署名付き値と比較したりできます。
リセット時に Compute Engine 仮想ファームウェアはアップグレードされますが、PCR0 の値は変更されません。このため、署名付き測定のファームウェアの svn 値が PCR0 で測定された EV_S_CRTM_VERSION と異なる場合があり、ファームウェア ブロッブ ダイジェストの EV_POST_CODE イベントがスキップされます。
Confidential VM インスタンスの UEFI バイナリを確認する
リリース承認から、
serialized_uefi_golden値をVMGoldenMeasurementに展開します。例については、Go での実装、またはプロトコル バッファをサポートする別の言語のendorsement.protoの protoc コンパイルを参照してください。VMGoldenMeasurementからダイジェストの値を取得します。これは、Confidential VM インスタンスが実行されている UEFI バイナリの SHA-384 ダイジェストです。SHA-384 ダイジェストを使用して、次の Cloud Storage バケットからファームウェア バイナリをダウンロードします。
gs://gce_tcb_integrity/ovmf_x64_csm/UEFI_BINARY_DIGEST.fd有効な URL でファームウェアがダウンロードされた場合は、ファームウェア バイナリに対して SHA-384 ハッシュを実行します。ゴールド測定のダイジェストと一致する場合、Confidential VM インスタンスで実行されているファームウェアは変更されていない状態です。