Ringkasan pengesahan jarak jauh

Pengesahan jarak jauh adalah proses memverifikasi bahwa identitas instance Confidential VM sah, dan bahwa instance tersebut beroperasi dalam status yang diharapkan. Pengesahan dapat membantu Anda menilai kredibilitas sistem sebelum Anda memberikan akses ke resource yang dilindungi.

Pihak dan model pengesahan

Biasanya ada tiga pihak dalam proses pengesahan:

• Pengesah. Di Google Cloud, ini adalah workload pada instance VM Rahasia yang memerlukan akses ke resource yang dilindungi. Untuk meningkatkan kepercayaan bahwa instance Confidential VM tidak disusupi dan bukan penipu, VM dan hostnya mengambil pengukuran status hardware dan software virtual VM selama proses booting.

• Verifikator. Verifier adalah sistem eksternal yang memvalidasi bukti dari instance Confidential VM, dan memeriksanya berdasarkan kebijakan pengesahannya untuk memastikan bahwa konfigurasi VM sesuai yang diharapkan. Jika bukti lulus pemeriksaan yang diperlukan, pemverifikasi akan menampilkan bukti versi bertanda tangan yang dikenal sebagai hasil pengesahan.

  Verifier dapat berupa layanan yang sudah ada sebelumnya seperti Pengesahan Google Cloud atau Intel Trust Authority, atau sesuatu yang Anda buat sendiri.

• Pihak yang mengandalkan. Pihak tepercaya mengontrol akses ke resource yang dilindungi yang dibutuhkan pengesah. Setelah menerima hasil pengesahan, pihak tepercaya akan memeriksa nilai dalam bukti berdasarkan kebijakan aksesnya. Jika nilai cocok, pengesah diizinkan mengakses resource.

  Pihak tepercaya sering kali berupa workload identity pool, dengan verifier ditambahkan sebagai penyedia OpenID Connect (OIDC). Google Cloud

Cara pihak berinteraksi bergantung pada model pengesahan yang diikuti oleh arsitektur Anda. RFC Arsitektur Prosedur ATestasi Jarak Jauh (RATS) menentukan dua model pengesahan utama: model paspor dan model pemeriksaan latar belakang. Perbedaan utama antara keduanya adalah pihak yang memiliki identitas terverifikasi pengesah: pengesah atau pihak tepercaya.

Model paspor

Model paspor menggunakan proses berikut untuk mengonfirmasi identitas pengesah dan memberikan akses ke resource yang diminta:

1. Pengesah mengirimkan bukti identitasnya kepada verifier.

2. Jika bukti dianggap dapat dipercaya, pemverifikasi akan mengirimkan hasil pengesahan kepada pengesah, yang mungkin berupa token pengesahan.

3. Pengesah mengirimkan hasil pengesahan ke pihak tepercaya.

4. Pihak tepercaya memeriksa bahwa hasil pengesahan memenuhi kondisi tertentu. Jika hasilnya sesuai harapan, pihak tepercaya akan mengizinkan pengesah untuk mengakses resource yang diminta.

Dalam model paspor, pengesah dan pihak tepercaya harus menyetujui tampilan hasil pengesahan, yang berarti mereka harus menyetujui verifier.

Model pemeriksaan latar belakang

Model pemeriksaan latar belakang menggunakan proses berikut untuk mengonfirmasi identitas pengesah dan memberikan akses ke resource yang diminta:

1. Pengesah mengirimkan bukti identitasnya kepada pihak pengikat.

2. Pihak tepercaya meneruskan bukti ke verifikator.

3. Jika bukti dianggap tepercaya, pemverifikasi akan mengirimkan hasil pengesahan kepada pihak tepercaya, sering kali sebagai token pengesahan.

4. Pihak tepercaya memeriksa bahwa hasil pengesahan memenuhi kondisi tertentu. Jika hasilnya sesuai harapan, pihak tepercaya akan mengizinkan pengesah untuk mengakses resource yang diminta.

Dengan model pemeriksaan latar belakang, pihak tepercaya menentukan bukti pengesahan yang diperlukan, dan memilih verifikator.

Arsitektur dan bukti pengesah

Bagian ini membahas cara instance Confidential VM sebagai pengesah memberikan bukti identitasnya yang tahan terhadap gangguan.

Root of trust

Dalam trusted execution environment (TEE) seperti instance Confidential VM, root of trust adalah komponen keamanan mendasar yang menjadi dasar pembentukan kepercayaan lainnya. Root of trust menyediakan fungsi kriptografi, tahan terhadap gangguan, dan tidak dapat diubah oleh sistem operasi host.

Root of trust berada di dalam batas kepercayaan dalam TEE yang dikenal sebagai Trusted Computing Base (TCB). TCB adalah kumpulan hardware dan software di seluruh VM tamu dan hostnya yang bertanggung jawab atas tugas-tugas seperti isolasi lingkungan (melalui mekanisme seperti enkripsi memori dan isolasi hypervisor) serta mengambil pengukuran untuk menjaga integritas lingkungan.

TEE mendukung akar tepercaya untuk fungsi pengukuran, penyimpanan, dan pelaporan:

• Root of trust untuk pengukuran adalah kode yang memulai pengukuran proses booting TEE.

• Root of trust untuk penyimpanan menyediakan memori terlindung untuk pengukuran dalam bentuk register pengukuran.

• Root of trust untuk pelaporan memberikan perlindungan integritas dan keaslian untuk rantai pengukuran. Layanan ini mengambil pengukuran dari root tepercaya untuk penyimpanan dan menggabungkannya ke dalam paket bukti bertanda tangan yang disebut laporan kutipan atau pengesahan. Paket ini ditandatangani dengan kunci pengesahan yang berada di TEE, dan dapat menyertakan nonce kriptografi untuk memastikan bukti masih baru dan terlindungi dari serangan replay.

  Istilah Utama: Serangan replay terjadi saat pihak tidak bertanggung jawab menyalin bukti yang memverifikasi identitas, dan menggunakan bukti tersebut untuk mendapatkan akses ke resource secara tidak sah. Salah satu cara untuk mengatasi serangan replay adalah dengan nonce: angka acak sekali pakai yang berumur pendek yang diberikan oleh salah satu pihak yang melindungi resource—dalam kasus Confidential Computing, yaitu verifier. Entitas yang membuktikan identitasnya harus menyertakan nonce ke dalam buktinya sebelum bukti tersebut dikirim. Jika pihak tidak bertanggung jawab mencoba menggunakan bukti yang dicuri untuk mengakses resource, kemungkinan akan gagal karena nonce yang disertakan dalam bukti telah digunakan atau telah habis masa berlakunya.

Informasi berikut menjelaskan berbagai pendekatan terhadap akar tepercaya untuk berbagai teknologi Confidential Computing.

AMD SEV

Instance Confidential VM dengan AMD SEV membuktikan lingkungan dan konfigurasinya menggunakan pengukuran berbasis vTPM Shielded VM. AMD Secure Processor dan AMD SEV digunakan semata-mata untuk enkripsi memori.

Root of trust adalah sebagai berikut:

• Root of trust untuk pengukuran: Firmware instance VM

• Root of trust untuk penyimpanan: vTPM Shielded VM

• Root of trust untuk pelaporan: vTPM Shielded VM, yang menggunakan kunci pengesahan pribadi untuk menandatangani laporan pengesahan

Untuk mempelajari pengukuran apa yang dicatat di mana dalam vTPM Shielded VM, lihat register konfigurasi platform vTPM.

AMD SEV-SNP

Instance Confidential VM dengan AMD SEV-SNP terutama membuktikan lingkungan dan konfigurasinya melalui AMD Secure Processor, yang menangani pengukuran peluncuran awal.

Untuk pengukuran bootloader, kernel, dan ruang pengguna, pengukuran berbasis vTPM Shielded VM dapat digunakan.

Root of trust adalah sebagai berikut:

• Akar tepercaya untuk pengukuran: AMD Secure Processor + firmware instance VM

• Root of trust untuk penyimpanan: AMD Secure Processor + vTPM Shielded VM

• Root of trust untuk pelaporan:

  • Pengukuran peluncuran awal: AMD Secure Processor, yang menggunakan Version Chip Endorsement Key (VCEK) yang berada di chip untuk menandatangani laporan pengesahan

  • Pengukuran bootloader, kernel, dan ruang pengguna: vTPM Shielded VM

Untuk mempelajari pengukuran yang dicatat di AMD Secure Processor, lihat AMD SEV-SNP measurement register.

Untuk mempelajari pengukuran apa yang dicatat di mana dalam vTPM Shielded VM, lihat register konfigurasi platform vTPM.

Intel TDX

Instance Confidential VM dengan Intel TDX membuktikan lingkungan dan konfigurasinya melalui modul Intel TDX. Modul Intel TDX mengukur firmware tamu VM dalam domain tepercaya yang terisolasi, dan menyimpan pengukuran tersebut dalam Pengukuran Domain Tepercaya (MRTD). Pengukuran berikutnya dalam rantai booting diukur ke dalam Run-Time Measurement Registers (RTMR).

Root of trust adalah sebagai berikut:

• Root of trust untuk pengukuran: Modul Intel TDX

• Root of trust untuk penyimpanan: Pengukuran Domain Tepercaya (MRTD) dan Run-Time Measurement Registers (RTMR)

• Akar tepercaya untuk pelaporan: Trust Domain Quoting Enclave (TDQE) di dalam modul Intel TDX, yang menghasilkan kunci pengesahan untuk menandatangani kutipan pengesahan

Untuk mempelajari pengukuran yang dicatat di mana dalam register pengukuran TDX, lihat Register pengukuran Intel TDX.

Pengesahan software dan hardware

Teknologi Confidential Computing di Google Cloud dapat dianggap sebagai software atau hardware yang di-attestasi, bergantung pada akar kepercayaannya.

Dibuktikan oleh software berarti bahwa root of trust didasarkan pada software: firmware virtual adalah root of trust untuk pengukuran, dan root of trust untuk penyimpanan adalah vTPM Shielded VM. vTPM dikelola oleh hypervisor host, sedangkan firmware dikelola oleh VM tamu. Di On Google Cloud, kedua komponen ini dikontrol oleh Google.

Dibuktikan oleh hardware berarti pengukuran dikelola dan dilindungi oleh hardware khusus di luar kontrol penyedia layanan Anda. Di Google Cloud, hardware ini mencakup AMD Secure Processor untuk AMD SEV-SNP (hanya untuk pengukuran peluncuran), dan Intel TDX Module untuk Intel TDX.

Pengesahan hardware menghapus hypervisor penyedia layanan dari root kepercayaan untuk pengukuran dan penyimpanan, serta mengisolasi pengukuran dalam hardware khusus. Meskipun pihak tidak bertanggung jawab mendapatkan kontrol atas hypervisor host, mereka tidak dapat memalsukan laporan atau kutipan pengesahan karena mereka tidak memiliki akses untuk mengubah register hardware khusus.

Teknologi Confidential Computing yang disediakan oleh Google Cloud dikategorikan sebagai berikut:

• AMD SEV: Software yang dibuktikan. Firmware virtual mengukur dirinya sendiri, dan pengukuran disimpan di vTPM Shielded VM.

• AMD SEV-SNP: Hardware dan software hybrid yang telah di-attestasi. Pengukuran peluncuran, termasuk pengukuran firmware virtual, direkam dan disimpan di AMD Secure Processor, sehingga menjadikannya terbukti hardware. Pengukuran bootloader, kernel, dan userspace disimpan di vTPM Shielded VM, sehingga dapat dibuktikan secara software. Anda dapat memilih untuk hanya menggunakan pengukuran yang dibuktikan hardware, pengukuran yang dibuktikan software, atau keduanya.

• Intel TDX: Hardware yang dibuktikan. Modul TDX mengukur firmware virtual, dan semua pengukuran disimpan dalam modul Intel TDX. vTPM Shielded VM masih menjadi bagian dari sistem, tetapi bukan bagian dari TCB kecuali Anda menjalankan software yang memerlukan antarmuka TPM.

Daftar pengukuran

Akar kepercayaan untuk Confidential VM menyediakan penyimpanan terlindung dan tahan gangguan untuk pengukuran dalam bentuk register pengukuran (MR). Nama register pengukuran tersebut berubah bergantung pada teknologi Confidential Computing yang digunakan:

• AMD SEV: Daftar konfigurasi platform (PCR). Kunci ini berada di dalam vTPM Shielded VM.

  vTPM VM Terlindungi menggunakan tiga bank PCR yang menyimpan pengukuran yang sama, tetapi di-hash dengan algoritma yang berbeda: SHA-1, SHA-256, dan SHA-384.

• AMD SEV-SNP: Peluncuran MEASUREMENT pendaftaran. Bagian ini berada di dalam AMD Secure Processor.

  PCR di dalam vTPM Shielded VM juga digunakan untuk menyimpan pengukuran bootloader, kernel, dan ruang pengguna.

• Intel TDX: Pengukuran Domain Tepercaya (MRTD) waktu build dan Register Pengukuran Waktu Proses (RTMR).

  Pengukuran juga tersedia di PCR vTPM Shielded VM untuk software yang mengharapkan antarmuka TPM.

Hanya root of trust yang dapat mengubah nilai register. Pendaftaran pengukuran biasanya menyimpan satu ringkasan kriptografi, yang merepresentasikan satu peristiwa atau serangkaian peristiwa.

Untuk peristiwa tunggal, seperti pengukuran peluncuran atau pengukuran waktu build VM, root of trust biasanya menulis langsung ke register dan membuat register tidak dapat diubah selama masa aktif TEE.

Komponen yang dimuat lebih lambat dalam rantai booting seperti bootloader, kernel, dan userspace dapat merekam pengukuran untuk beberapa peristiwa ke dalam satu register. Untuk menyimpan pengukuran untuk kumpulan peristiwa, register pengukuran mengekspos perintah extend yang menggabungkan nilai register yang ada dengan ringkasan peristiwa baru, melakukan hashing pada nilai yang digabungkan, lalu menyimpan ringkasan yang dihasilkan. Proses ini diwakili oleh formula berikut:

\(MR_{new}=hash(MR_{old}\;∥\;hash(measured\;data))\)

Karena fungsi hash bersifat satu arah, mereplikasi nilai register pengukuran yang sama tanpa memberikan pengukuran yang sama dalam urutan yang sama akan sulit dilakukan. Meskipun properti ini membantu menentukan integritas VM, properti ini dapat membuat kebijakan berbasis nilai register pengukuran tertentu menjadi sulit. Hal ini karena perubahan kecil pada input pengukuran—seperti update software atau firmware, atau perubahan urutan pengukuran—menghasilkan nilai register yang berbeda, sehingga berpotensi menjadi kriteria yang tidak stabil untuk mendasarkan kebijakan dan meningkatkan beban pemeliharaan. Jika Anda perlu mendasarkan kebijakan pada nilai register pengukuran, coba pilih nilai register yang lebih stabil seperti PCR 0 atau PCR 7 di vTPM.

Tips: Untuk mendasarkan kebijakan pada pengukuran individual yang stabil, bukan nilai register pengukuran, Anda dapat menggunakan log peristiwa yang dihasilkan oleh TCB Anda. Verifikator harus melakukan pemutaran ulang log peristiwa terlebih dahulu untuk memverifikasi integritas log terhadap register pengukuran, dan setelah verifikasi berhasil, verifikator dapat mengurai peristiwa untuk mengekstrak pengukuran yang bermakna.

Log aktivitas

Saat pengukuran ditulis atau diperluas ke dalam register pengukuran, satu atau beberapa log ditulis ke sistem file sistem operasi tamu yang mencatat peristiwa pengukuran yang terjadi.

Log peristiwa ini memiliki tujuan berikut:

• Verifier dapat memutar ulang log peristiwa untuk menelusuri proses pengukuran instance Confidential VM menggunakan register pengukuran tersimulasi. Jika ringkasan akhir yang dihitung oleh verifier cocok dengan ringkasan akhir yang dilaporkan oleh attester, hal ini dapat meningkatkan keyakinan bahwa log peristiwa dan proses booting instance VM Konfidensial tidak dirusak.

• Setelah diputar ulang, verifier dapat mengurai log peristiwa untuk membandingkan bukti dengan kebijakan pengesahan. Verifier dapat mewajibkan pengirim pengesahan untuk memenuhi kriteria tertentu seperti mengaktifkan booting aman, atau menggunakan teknologi Confidential Computing tertentu sebelum hasil pengesahan yang berhasil ditampilkan.

Log peristiwa disimpan dalam sistem file sistem operasi tamu di lokasi berikut:

Teknologi Confidential Computing	MR untuk diverifikasi	Jenis log	Jalur OS tamu untuk pemutaran ulang log peristiwa
AMD SEV, AMD SEV-SNP, Intel TDX	Daftar konfigurasi platform vTPM (PCR)	Log Aktivitas Trusted Computing Group (TCG)	/sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX	RTMR[0], RTMR[1], RTMR[2]	Log Peristiwa Confidential Computing (CCEL)	/sys/firmware/acpi/tables/data/CCEL

Pelajari lebih lanjut pemutaran ulang dan penguraian log peristiwa.

Kutipan dan laporan pengesahan

Root of trust untuk pelaporan memberikan perlindungan integritas dan keaslian untuk ringkasan yang disimpan dalam register pengukuran dengan menandatangani pengukuran menggunakan kunci pengesahan. Blob biner yang dihasilkan dikenal sebagai kutipan PCR untuk vTPM, laporan pengesahan untuk AMD SEV-SNP, dan kutipan untuk Intel TDX.

Yang ada di blob biner berbeda untuk berbagai teknologi Confidential Computing:

• AMD SEV: vTPM Shielded VM membaca nilai dari salah satu bank PCR-nya (SHA-1, SHA-256, atau SHA-384), menggabungkan nilai tersebut dalam urutan numerik, lalu melakukan hashing pada hasilnya dengan algoritma hashing yang sama seperti yang digunakan untuk bank PCR guna membuat ringkasan digest. Ringkasan digest ini, bersama dengan nonce opsional yang diberikan oleh verifier, ditempatkan ke dalam struktur TPMS_ATTEST dan ditandatangani oleh kunci pengesahan pribadi vTPM untuk membuat kutipan PCR.

  Untuk mengetahui detail tentang struktur TPMS_ATTEST, lihat Trusted Platform Module Library, Part 2: Structures (PDF).

• AMD SEV-SNP: AMD Secure Processor membuat ringkasan SHA-384, berdasarkan pengukuran peluncuran awalnya yang dilakukan sebelum UEFI instance Confidential VM dieksekusi.

  Ringkasan ini, data VM lainnya, dan nonce opsional yang disediakan oleh verifier ditempatkan ke dalam struktur ATTESTATION_REPORT yang ditandatangani oleh Kunci Pengesahan Chip Versi (VCEK) Prosesor Aman AMD untuk membuat laporan pengesahan.

  Untuk mengetahui detail tentang struktur ATTESTATION_REPORT, lihat SEV Secure Nested Paging Firmware ABI Specification (PDF).

• Intel TDX: Modul TDX menempatkan nilai MRTD dan RTMR, data VM lainnya, dan nonce opsional yang disediakan oleh verifier ke dalam struktur TDREPORT_STRUCT.

  Membuat penawaran harga adalah proses multi-langkah. Pertama, Enclave Sertifikasi Penyediaan di dalam CPU mendapatkan kunci sertifikasi penyediaan (PCK) dari rahasia kriptografi yang digabungkan ke dalam CPU. Kemudian, Quoting Enclave di dalam CPU membuat kunci pengesahan pribadi, yang ditandatangani dengan kunci sertifikasi penyediaan. TDREPORT_STRUCT kemudian ditandatangani dengan kunci pengesahan pribadi untuk membuat penawaran.

  Untuk mengetahui detail tentang struktur TDREPORT_STRUCT, lihat Spesifikasi Arsitektur Dasar Modul Intel Trust Domain Extensions (Intel TDX) (PDF).

Endorsement

Berbagai jenis pengesahan digunakan sebagai bukti bahwa instance Confidential VM berjalan pada konfigurasi hardware, vTPM, dan firmware yang diharapkan.

Sertifikat

Sertifikat X.509 v3 digunakan sebagai bukti bahwa hardware AMD atau Intel asli digunakan di host, atau bahwa instance Confidential VM menggunakan vTPM Shielded VM.

Nama sertifikat berbeda untuk setiap teknologi Confidential Computing:

• AMD SEV: Sertifikat kunci pengesahan (AK)

• AMD SEV-SNP: Sertifikat Version Chip Endorsement Key (VCEK)

• Intel TDX: Menyediakan sertifikat Kunci Sertifikasi (PCK)

Untuk AMD SEV, sertifikat memverifikasi vTPM Shielded VM. Host membuat permintaan ke server otoritas sertifikat Google, dan menyediakan sertifikat secara otomatis langsung ke penyimpanan non-volatile vTPM instance VM Rahasia. Tamu dapat mengambil sertifikat ini satu per satu dengan memintanya dari vTPM dengan software seperti go-tpm-tools.

Untuk AMD SEV-SNP dan Intel TDX, host mengekstrak bukti hardware dari CPU dan menampilkannya ke cache yang dikelola Google. Cache ini menyimpan sertifikat yang sebelumnya ditarik dari layanan distribusi kunci AMD dan layanan sertifikat penyediaan Intel. Setelah berhasil menyajikan bukti hardware, sertifikat di-cache ke disk host, dan dibagikan kepada tamu. Tamu dapat mengambil sertifikat ini satu per satu untuk memvalidasi hardware dengan software seperti go-sev-guest dan go-tdx-guest.

Sertifikat berisi informasi berikut:

• Identitas penerbit sertifikat, baik AMD, Google, atau Intel.

• Kunci pengesahan publik, yang memverifikasi tanda tangan pada kutipan PCR (vTPM), laporan pengesahan (SEV-SNP), dan kutipan pengesahan (Intel TDX).

• Pengesahan hardware saja: versi TCB firmware dan mikrocode hardware yang dijalankan firmware host.

• Pengesahan hardware saja: bukti yang mengikat sertifikat ke prosesor fisik tertentu, yang telah ditandatangani dengan kunci pribadi di prosesor dan tidak dapat diekstraksi. Untuk AMD SEV-SNP, bukti ini adalah ID platform. Untuk Intel TDX, buktinya adalah manifes platform.

Firmware

Untuk pengesahan hardware, pengesahan peluncuran firmware tersedia langsung dari instance VM atau dapat didownload secara online. Pengesahan peluncuran adalah buffer protokol yang diserialisasi biner dan ditandatangani yang digunakan untuk mengonfirmasi bahwa firmware virtual instance Confidential VM belum dirusak.

Saat VM dimulai, modul AMD Secure Processor atau Intel TDX akan melakukan hashing pada biner firmware sebelum dieksekusi. Ringkasan SHA-384 ini disimpan di kolom MEASUREMENT untuk AMD SEV-SNP, dan di MRTD untuk Intel TDX.

Anda dapat menggunakan ringkasan tersebut untuk mendownload pengesahan peluncuran dari Google, memverifikasi bahwa tanda tangan berakar pada Google dengan alat seperti gcetcbendorsement, lalu memverifikasi bahwa ringkasan SHA-384 cocok antara pengukuran firmware dan yang tercatat dalam pengesahan.

Selain verifikasi firmware, Anda dapat menggunakan properti tertentu dalam pengesahan peluncuran untuk menerapkan kebijakan akses, seperti nomor versi keamanan (SVN) minimum, jumlah vCPU, konfigurasi memori, atau ID family UEFI.

Untuk mengetahui informasi selengkapnya, lihat Memverifikasi firmware instance Confidential VM.

Pemutaran ulang dan penguraian log peristiwa verifier

Selain memverifikasi secara langsung bukti yang diberikan oleh pengesah, verifier dapat memutar ulang log peristiwa yang diberikan oleh pengesah untuk memverifikasi integritasnya terhadap nilai register pengukurannya.

Untuk melakukannya, verifier membuat versi simulasi dari setiap register pengukuran yang perlu diperiksa sebagai bagian dari kebijakan pengesahannya. Kemudian, peristiwa dari log peristiwa akan mengisi register simulasi tersebut. Jika nilai akhir register yang disimulasikan cocok dengan nilai yang disimpan dalam register pengukuran nyata yang setara, hal ini akan meningkatkan keyakinan bahwa log peristiwa dan proses booting instance VM Rahasia tidak dirusak.

Setelah log diverifikasi dengan cara ini, log dapat diuraikan untuk mendapatkan pengukuran individual yang dapat digunakan oleh pihak yang memverifikasi atau pihak yang mengandalkan untuk mendasarkan kebijakan.

Membuat alat pemutaran ulang dan penguraian log peristiwa Anda sendiri

Meskipun Anda dapat membuat software sendiri untuk memutar ulang dan mengurai log peristiwa, sebaiknya Anda menggunakan software yang sudah mapan seperti go-eventlog untuk membantu Anda menghindari kesalahan umum seperti kerentanan EventType untuk format Log Peristiwa Trusted Computing Group dan Confidential Computing.

Jika Anda masih ingin membuat software pemutaran ulang dan parsing sendiri, contoh berbasis vTPM berikut dapat membantu pemahaman awal Anda, meskipun Anda harus mendasarkan penerapan pada log peristiwa yang dihasilkan oleh instance Confidential VM Anda sendiri.

Contoh berikut memiliki peristiwa tertentu dari log peristiwa vTPM Ubuntu 24.04, yang diukur ke dalam PCR 0. Log peristiwa telah dikonversi dari biner ke ASCII dengan tpm2_eventlog menggunakan perintah berikut:

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

Peristiwa PCR 0 dari log adalah sebagai berikut:

---
version: 1
events:
- EventNum: 0
  PCRIndex: 0
  EventType: EV_NO_ACTION
  Digest: "0000000000000000000000000000000000000000"
  EventSize: 41
  SpecID:
  - Signature: Spec ID Event03
    platformClass: 0
    specVersionMinor: 0
    specVersionMajor: 2
    specErrata: 0
    uintnSize: 2
    numberOfAlgorithms: 3
    Algorithms:
    - Algorithm[0]:
      algorithmId: sha1
      digestSize: 20
    - Algorithm[1]:
      algorithmId: sha256
      digestSize: 32
    - Algorithm[2]:
      algorithmId: sha384
      digestSize: 48
    vendorInfoSize: 0
- EventNum: 1
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 160
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e37000300000028000000468e85a27fa36a458c790c1fe48b65ff4600690072006d007700610072006500520049004d0000000000000000000000000000000000"
- EventNum: 2
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 288
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e370001000000a800000068747470733a2f2f73746f726167652e676f6f676c65617069732e636f6d2f6763655f7463625f696e746567726974792f6f766d665f7836345f63736d2f3834383939616564336339653837363735666638303966356665613365366638383733353533643166303130306464623961653333323639323832356163636537333866343562646563323738613430393864316332376534393533373134332e66642e7369676e65640000000000000000000000000000"
- EventNum: 3
  PCRIndex: 0
  EventType: EV_S_CRTM_VERSION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "4031fe1129fb826f12dcad169992cca9f4f56aa3"
  - AlgorithmId: sha256
    Digest: "fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d"
  - AlgorithmId: sha384
    Digest: "21d340a4a30bb8865486d150cd9ceb46100662b92f336d38b87d70b373ca15c4c60878336924baa818dc2aceaeb40ea6"
  EventSize: 48
  Event: "47004300450020005600690072007400750061006c0020004600690072006d0077006100720065002000760032000000"
- EventNum: 4
  PCRIndex: 0
  EventType: EV_NONHOST_INFO
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "2b106cedd1631981619790bbc1afaa80cc6ecd3e"
  - AlgorithmId: sha256
    Digest: "6ac9241348a80c5755a63bcd1865b9f6d5720f6e925dc869bb4694281c1510c5"
  - AlgorithmId: sha384
    Digest: "1167e32c3814259ea4809234cccfbd2785c32bde882833bb199d6df6bd989a49f45663e63ce11699fcd01250050f042c"
  EventSize: 32
  Event: "474345204e6f6e486f7374496e666f0001000000000000000000000000000000"
- EventNum: 19
  PCRIndex: 0
  EventType: EV_SEPARATOR
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "9069ca78e7450a285173431b3e52c5c25299e473"
  - AlgorithmId: sha256
    Digest: "df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119"
  - AlgorithmId: sha384
    Digest: "394341b7182cd227c5c6b07ef8000cdfd86136c4292b8e576573ad7ed9ae41019f5818b4b971c9effc60e1ad9f1289f0"
  EventSize: 4
  Event: "00000000"

Saat instance Confidential VM direset, PCR-nya diinisialisasi ke nol. Saat peristiwa terjadi, nilai di bank SHA-256 PCR 0 (PCRIndex: 0) berubah sebagai berikut (peristiwa EV_NO_ACTION tidak memperpanjang pendaftaran):

1. Nilai register digabungkan dengan digest SHA-256 dari peristiwa berikutnya yang ditetapkan ke PCR 0, EV_S_CRTM_VERSION. Hasil gabungan di-hash SHA-256 lagi, lalu disimpan dalam register. Hexdigest SHA-256 PCR 0 sekarang adalah 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

2. Proses yang sama digunakan untuk peristiwa EV_NONHOST_INFO. Hexdigest SHA-256 PCR 0 sekarang adalah 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.

3. Proses yang sama digunakan untuk peristiwa EV_SEPARATOR, yang menunjukkan bahwa ekstensi pengukuran ke dalam register tertentu telah selesai. EV_SEPARATOR adalah nilai nol 32-bit (\x00*4). Hal ini membuat hexdigest SHA-256 akhir PCR 0 a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

Kode Python berikut menunjukkan prosedur sebelumnya dengan membuat PCR 0 Compute Engine yang disimulasikan. Kode tersebut bukan pemutaran ulang log peristiwa, karena kode tersebut memperoleh ringkasan peristiwanya dari nilai yang diketahui. Saat membuat pemutaran ulang log peristiwa yang tepat, Anda harus membaca ringkasan dari log peristiwa instance VM Anda.

import hashlib

def CalculatePCR0(version_num: int, mem_encrypt_enum: int):
  """Calculates the expected SHA-256 PCR 0 value given the
  Compute Engine firmware version and Confidential Computing technology
  that's in use.

  This code uses derived values for events instead of reading digests from an
  event log. It's intended to demonstrate how to simulate the extend function
  used in measurement registers.

  While the code should provide correct values for PCR 0 in
  Compute Engine VM instances, for other PCRs and true event log replay
  you should read in digests from an event log instead of using derived values.

  PCR 0 measurements include:
    * EV_S_CRTM_VERSION: The firmware version string, in UTF-16 little-endian
      form. This value remains stable as long as the firmware version stays the
      same.
    * EV_NONHOST_INFO: This value changes based on the Confidential Computing
      technology that's in use.
    * EV_SEPARATOR: A 32-bit zero value to split UEFI and bootloader
      measurements.

  Args:
    version_num (int): The Compute Engine firmware version number. The
      value is 2.

    mem_encrypt_enum (int): The type of Confidential Computing technology used
      on the VM:

      0: None
      1: AMD SEV
      2: AMD SEV-ES
      3: Intel TDX
      4: AMD SEV-SNP

  Returns:
    A hexstring representing the expected PCR 0 digest.
  """
  # Create a hash object to act as PCR 0, and initialize it with zeroes.
  h = hashlib.sha256()
  h.update(b'\x00' * h.digest_size)

  # Update the hash object with the EV_S_CRTM_VERSION event, with a hard-coded
  # firmware version `version_num`.
  #
  # This code uses derived values for events. To use the digest supplied in an
  # event log for event log replay, you need to read in the event digest, and
  # then convert it to bytes before updating the hash object, similar to the
  # following:
  #
  # h.update(bytes.fromhex('fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d'))
  #
  h.update(
          hashlib.sha256(
              # The firmware uses UCS-2 encoding, so we match it by encoding to
              # the equivalent UTF-16 little-endian. An extra null byte is
              # needed to match the required byte length.
              f'GCE Virtual Firmware v{version_num}\x00'.encode('utf-16-le')).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h2 = hashlib.sha256()

  h2.update(h.digest())

  # Update the hash object with the EV_NONHOST_INFO event, which includes
  # `mem_encrypt_enum`, the Confidential Computing technology in use. Performing
  # this update completes the simulated EXTEND function.

  h2.update(
          hashlib.sha256(
              b'GCE NonHostInfo\x00'
              + (mem_encrypt_enum).to_bytes(1, byteorder='little')
              + (b'\x00' * 15)
              ).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h3 = hashlib.sha256()
  h3.update(h2.digest())

  # Update the hash object with the EV_SEPARATOR event. Performing this update
  # completes the simulated EXTEND function.
  h3.update(hashlib.sha256(b'\x00' * 4).digest())

  # There are more PCR 0 events, but they're all `EV_NO_ACTION` and don't
  # affect the register value. Return the final simulated register value.
  digest = h3.hexdigest()
  return digest

print('\nPCR 0 simulation')
print('\nConfidential Computing type\tDigest')
# Compute Engine firmware version 2, no Confidential Computing
# Expected hexdigest: d0c70a9310cd0b55767084333022ce53f42befbb69c059ee6c0a32766f160783
print(f'None\t\t\t\t{CalculatePCR0(2, 0)}')

# Compute Engine firmware version 2, AMD SEV
# Expected hexdigest: a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85
print(f'AMD SEV\t\t\t\t{CalculatePCR0(2, 1)}')

# Compute Engine firmware version 2, AMD SEV-SNP
# Expected hexdigest: 50597a27846e91d025eef597abbc89f72bff9af849094db97b0684d8bc4c515e
print(f'AMD SEV-SNP\t\t\t{CalculatePCR0(2, 4)}')

# Compute Engine firmware version 2, Intel TDX
# Expected hexdigest: 0cca9ec161b09288802e5a112255d21340ed5b797f5fe29cecccfd8f67b9f802
print(f'Intel TDX\t\t\t{CalculatePCR0(2, 3)}')

print()

Konfigurasi pihak tepercaya

Bergantung pada apakah model paspor atau model pemeriksaan latar belakang yang digunakan, pihak tepercaya menerima hasil pengesahan dari pengesah atau pemverifikasi.

Pihak tepercaya kemudian memverifikasi bahwa klaim yang telah diterimanya dalam hasil pengesahan cocok dengan nilai yang diharapkan. Jika nilai cocok, pihak tepercaya mengizinkan pengesah untuk mengakses resource sebagai identitas lokal.

Pola umum untuk mengonfigurasi pihak tepercaya di Google Cloud adalah menggunakan Workload Identity Federation, dan memperlakukan pengesah sebagai identitas gabungan:

1. Tambahkan verifier Anda sebagai penyedia OIDC ke workload identity pool. Setelah itu, akun layanan yang terlampir ke beban kerja instance Confidential VM Anda dapat bertindak sebagai identitas gabungan dan mengakses resource yang diperlukan.

2. Tentukan nilai yang diklaim oleh pengesahan verifier harus cocok agar pengesah diberi akses ke resource.

   Di Google Cloud, hal ini melibatkan pemetaan klaim pengesahan ke atribut sehingga Identity and Access Management (IAM) dapat memprosesnya sebagai kondisi yang harus dipenuhi oleh identitas gabungan untuk diautentikasi sebagai pokok keamanan.

   Kemudian, Anda dapat memberikan akses langsung ke resource kepada pengesah dengan menambahkan binding peran untuk akun utama federasinya ke kebijakan izinkan resource yang diperlukan. Untuk layanan yang tidak mendukung identitas gabungan, Anda dapat memberikan akses ke resource melalui peniruan identitas akun layanan.

Sebagai alternatif untuk Workload Identity Federation, Anda dapat menulis kode untuk mengurai klaim token pengesahan secara langsung. Sebagai contoh, lihat Pengesahan Jarak Jauh vTPM di Virtual Machine Rahasia.