Konten ini terakhir diperbarui pada Oktober 2023, dan menampilkan kondisi pada saat penulisan konten ini. Kebijakan dan sistem keamanan Google dapat berubah di masa mendatang, seiring upaya kami untuk terus meningkatkan perlindungan bagi pelanggan.
Dokumen ini menjelaskan kontrol infrastruktur yang digunakan Google untuk menerapkan integritas proses booting pada mesin produksi. Kontrol ini, yang dibuat di atas proses booting terukur, membantu memastikan bahwa Google dapat memulihkan mesin pusat datanya dari kerentanan di seluruh stack booting mereka dan mengembalikan mesin dari status booting arbitrer ke konfigurasi yang terkenal bagus.
Pengantar
Postur keamanan mesin pusat data ditetapkan saat booting. Proses booting mesin mengonfigurasi hardware mesin dan melakukan inisialisasi sistem operasinya, sekaligus menjaga agar mesin tetap aman untuk berjalan di lingkungan produksi Google.
Pada setiap langkah dalam proses booting, Google menerapkan kontrol yang terdepan di industri untuk membantu menerapkan status booting yang diharapkan dan membantu menjaga keamanan data pelanggan. Kontrol ini membantu memastikan bahwa mesin kami melakukan booting ke software yang diinginkan, memungkinkan kami menghapus kerentanan yang dapat membahayakan postur keamanan awal mesin.
Dokumen ini menjelaskan proses booting dan menunjukkan bagaimana kontrol kami beroperasi pada setiap langkah dalam alur booting.
Latar belakang
Bagian ini mendefinisikan dan memberikan konteks untuk istilah kredensial mesin, root of trust hardware, kredensial tersegel, dan penyegelan kriptografis.
Kredensial mesin
Salah satu komponen sentral dalam sistem pengelolaan mesin Google adalah infrastruktur kredensial kami, yang terdiri dari certificate authority (CA) internal dan elemen bidang kontrol lainnya yang bertanggung jawab untuk mengoordinasikan alur rotasi kredensial.
Mesin di fleet produksi Google melakukan autentikasi mutual saat membuat saluran aman. Untuk melakukan autentikasi mutual, setiap mesin memiliki kunci publik CA Google. Setiap mesin juga memiliki pasangan kunci umum/pribadinya sendiri, serta sertifikat untuk pasangan kunci tersebut.
Setiap pasangan kunci umum/pribadi mesin, bersama dengan sertifikat yang ditandatangani oleh CA, dikenal sebagai kredensial mesin, yang digunakan mesin untuk autentikasi dirinya sendiri ke mesin lain dalam fleet. Dalam jaringan produksi, mesin memeriksa apakah kunci publik mesin lain telah disertifikasi oleh CA Google sebelum bertukar traffic.
Root of trust hardware dan penyegelan kriptografis
Seiring perangkat komputasi menjadi semakin canggih, permukaan serangan setiap perangkat juga berkembang. Untuk menjelaskan hal ini, semakin banyak perangkat yang memiliki root of trust (RoT) hardware yang merupakan trusted execution environment kecil yang melindungi data sensitif mesin. RoT juga muncul di perangkat seluler seperti laptop atau ponsel, dan di perangkat yang lebih konvensional seperti PC desktop.
Mesin pusat data Google dilengkapi dengan root of trust hardware kustom yang dirancang Google, yang terintegrasi ke dalam lapisan terdalam setiap mesin, yang dikenal sebagai Titan. Kami menggunakan Titan, beserta mekanisme yang disebut penyegelan kriptografis, untuk memastikan bahwa setiap mesin menjalankan konfigurasi dan versi software yang kami harapkan.
Penyegelan kriptografis mirip dengan penyegelan dengan Trusted Platform Module (TPM), spesifikasi yang dipublikasikan oleh Grup Komputasi Tepercaya, tetapi penyegelan kriptografis memiliki beberapa keuntungan tambahan. Titan menghadirkan kemampuan yang lebih baik untuk mengukur dan mengesahkan firmware tingkat rendah.
Penyegelan kriptografis terdiri dari dua kontrol berikut:
- Enkripsi data sensitif
- Kebijakan yang harus dipenuhi sebelum data dapat didekripsi
Kredensial tersegel
Infrastruktur kredensial Google menggunakan penyegelan kriptografis untuk mengenkripsi kredensial mesin dalam penyimpanan dengan kunci yang dikontrol oleh root of trust hardware komputer. Kunci pribadi kredensial yang dienkripsi, dan sertifikat yang sesuai, disebut sebagai kredensial tersegel. Selain kredensial mesin, Google juga menggunakan mekanisme penyegelan ini untuk melindungi bagian data sensitif lainnya.
Setiap mesin dapat mendekripsi dan mengakses kredensial mesinnya hanya jika dapat memenuhi kebijakan dekripsi yang menentukan software apa yang harus di-booting oleh mesin. Misalnya, menyegel kredensial mesin ke kebijakan yang menentukan rilis kernel sistem operasi yang diinginkan akan memastikan bahwa mesin tidak dapat berpartisipasi dalam cluster mesinnya kecuali jika melakukan booting versi kernel yang diperlukan.
Kebijakan dekripsi diterapkan melalui proses yang disebut booting terukur. Setiap lapisan dalam stack booting mengukur lapisan berikutnya, dan mesin mengesahkan rantai pengukuran ini pada akhir booting. Pengukuran ini sering kali merupakan hash kriptografis.
Proses penyegelan kredensial
Bagian ini menjelaskan penyegelan kredensial dan proses booting terukur yang digunakan oleh mesin Google. Diagram berikut menggambarkan alur ini.
Untuk menyegel kredensial mesin pada kebijakan booting tertentu, langkah-langkah berikut akan terjadi:
- Infrastruktur otomatisasi mesin Google memulai update software di mesin. Hal ini meneruskan versi software yang dimaksud ke infrastruktur kredensial.
- Infrastruktur kredensial Google meminta kunci penyegelan dari Titan, yang terikat dengan kebijakan sehingga Titan hanya menggunakannya jika mesin melakukan booting ke software yang diinginkan.
- Infrastruktur kredensial membandingkan kebijakan kunci yang ditampilkan dengan intent yang disampaikan oleh infrastruktur otomatisasi mesin. Jika infrastruktur kredensial puas bahwa kebijakan sesuai dengan intent, infrastruktur tersebut akan menerbitkan kredensial mesin bersertifikasi ke mesin.
- Infrastruktur kredensial mengenkripsi kredensial ini menggunakan kunci penyegelan yang diperoleh pada langkah 2.
- Kredensial terenkripsi disimpan di disk untuk didekripsi oleh Titan pada booting berikutnya.
Proses booting terukur
Stack booting mesin Google terdiri dari empat lapisan, yang divisualisasikan dalam diagram berikut.
Lapisan tersebut adalah sebagai berikut:
- Userspace: aplikasi seperti daemon atau workload.
- Software sistem: hypervisor atau kernel. Tingkat terendah software yang menyediakan abstraksi atas fitur hardware seperti jaringan, sistem file, atau memori virtual ke userspace.
- Firmware booting: firmware yang melakukan inisialisasi kernel, seperti BIOS dan bootloader.
- Root of trust hardware: Di mesin Google, chip Titan yang mengukur firmware dan layanan CPU tingkat rendah lainnya secara kriptografis.
Selama booting, setiap lapisan mengukur lapisan berikutnya sebelum meneruskan kontrol ke lapisan tersebut. Kredensial tersegel mesin hanya tersedia untuk sistem operasi jika semua pengukuran yang diambil selama booting sesuai dengan kebijakan dekripsi kredensial tersegel, seperti yang ditentukan oleh infrastruktur kredensial Google. Oleh karena itu, jika mesin dapat menjalankan operasi dengan kredensial tersegel, hal tersebut menjadi bukti bahwa mesin tersebut memenuhi kebijakan booting terukurnya. Proses ini adalah bentuk pengesahan implisit.
Jika mesin mlakukan booting software yang menyimpang dari status yang diinginkan, mesin tidak dapat mendekripsi dan melakukan operasi dengan kredensial yang diperlukan untuk beroperasi dalam fleet. Mesin tersebut tidak dapat berpartisipasi dalam penjadwalan workload hingga infrastruktur pengelolaan mesin memicu tindakan perbaikan otomatis.
Memulihkan dari kerentanan di kernel
Misalkan sebuah mesin menjalankan kernel versi A, tetapi peneliti keamanan menemukan bahwa versi kernel ini memiliki kerentanan. Dalam skenario ini, Google akan mem-patch kerentanan dan meluncurkan versi kernel B terupdate ke fleet.
Selain mem-patch kerentanan, Google juga menerbitkan kredensial mesin baru ke setiap mesin dalam fleet. Seperti yang dijelaskan dalam Proses penyegelan kredensial, kredensial mesin baru terikat pada kebijakan dekripsi yang hanya dipenuhi jika versi kernel B melakukan booting di mesin. Setiap mesin yang tidak menjalankan kernel yang dimaksud tidak dapat mendekripsi kredensial mesin barunya, karena pengukuran firmware booting tidak akan memenuhi kebijakan booting mesin. Sebagai bagian dari proses ini, kredensial mesin lama juga dicabut.
Akibatnya, mesin-mesin ini tidak dapat berpartisipasi dalam cluster mesin tersebut sampai kernelnya diupdate agar sesuai dengan intent bidang kontrol. Kontrol ini membantu memastikan bahwa mesin yang menjalankan kernel versi A yang rentan tidak dapat menerima tugas atau data pengguna sebelum diupgrade ke kernel versi B.
Memulihkan dari kerentanan dalam firmware booting
Misalkan ada kerentanan dalam firmware booting, alih-alih kernel sistem operasi. Kontrol serupa yang dijelaskan dalam Memulihkan dari kerentanan dalam kernel membantu Google pulih dari kerentanan semacam itu.
Chip Titan Google mengukur firmware booting mesin sebelum dijalankan, sehingga Titan dapat mengetahui apakah firmware booting tersebut memenuhi kebijakan booting kredensial mesin. Setiap mesin yang tidak menjalankan firmware booting yang dimaksud tidak dapat memperoleh kredensial mesin baru, dan mesin tersebut tidak dapat berpartisipasi dalam cluster mesinnya hingga firmware booting-nya sesuai dengan intent bidang kontrol.
Memulihkan dari kerentanan dalam firmware root of trust
RoT tidak kebal terhadap kerentanan, tetapi kontrol booting Google memungkinkan pemulihan dari bug bahkan pada lapisan boot stack ini, dalam kode RoT yang dapat berubah.
Stack booting Titan mengimplementasikan sendiri alur booting yang aman dan terukur. Saat chip Titan menyala, hardware-nya secara kriptografis mengukur bootloader Titan, yang kemudian mengukur firmware Titan. Demikian pula dengan kernel dan firmware booting mesin, firmware Titan ditandatangani secara kriptografis dengan nomor versi. Bootloader Titan memvalidasi tanda tangan dan mengekstrak nomor versi firmware Titan, yang memasok nomor versi ke subsistem derivasi kunci berbasis hardware Titan.
Subsistem hardware Titan menerapkan skema derivasi kunci berversi, dengan firmware Titan yang berversi X dapat memperoleh kunci khusus chip yang terikat pada semua versi yang kurang dari atau sama dengan X. Hardware Titan memungkinkan firmware dengan versi X mengakses kunci yang terikat pada versi yang kurang dari atau sama dengan X, tetapi yang tidak lebih besar dari X. Semua rahasia yang tersegel pada Titan, termasuk kredensial mesin, dienkripsi menggunakan kunci berversi.
Kunci pengesahan dan penyegelan bersifat unik untuk setiap chip Titan. Kunci unik memungkinkan Google hanya memercayai chip Titan yang diharapkan berjalan dalam pusat data Google.
Diagram berikut menunjukkan Titan dengan kunci versi. Kunci Versi X+1 tidak dapat diakses oleh firmware versi X, tetapi semua kunci yang lebih lama dari itu dapat diakses.
Jika terjadi kerentanan yang parah pada firmware Titan, Google akan meluncurkan patch dengan nomor versi yang lebih besar, lalu menerbitkan kredensial mesin baru yang terikat dengan versi firmware Titan yang lebih tinggi. Setiap firmware Titan yang lebih lama dan rentan tidak dapat mendekripsi kredensial baru ini. Oleh karena itu, jika mesin melakukan operasi dengan kredensial barunya dalam produksi, Google dapat menyatakan dengan yakin bahwa chip Titan mesin tersebut menjalankan firmware Titan terbaru.
Memastikan keaslian root of trust
Semua kontrol yang dijelaskan dalam dokumen ini bergantung pada fungsionalitas RoT hardware itu sendiri. Infrastruktur kredensial Google bergantung pada tanda tangan yang dikeluarkan oleh RoT ini untuk mengetahui apakah mesin menjalankan software yang diinginkan.
Oleh karena itu, infrastruktur kredensial dapat menentukan apakah RoT hardware tersebut autentik dan apakah RoT menjalankan firmware terbaru.
Saat setiap chip Titan diproduksi, chip tersebut diprogram dengan entropi yang unik. Rutinitas booting tingkat rendah Titan mengubah entropi tersebut menjadi kunci khusus perangkat. Elemen pengaman di lini produksi Titan mendukung kunci khusus chip ini, sehingga Google akan mengenalinya sebagai chip Titan yang sah.
Diagram berikut menggambarkan proses dukungan ini.
Saat diproduksi, Titan menggunakan kunci khusus perangkatnya untuk mendukung setiap tanda tangan yang dikeluarkannya, menggunakan alur yang mirip dengan Device Identifier Composition Engine (DICE). Dukungan ini meliputi informasi versi firmware Titan. Pengesahan ini membantu mencegah penyerang meniru identitas tanda tangan yang dikeluarkan oleh chip Titan, serta melakukan roll back ke firmware Titan versi lama dan meniru firmware Titan yang lebih baru. Kontrol ini membantu Google memverifikasi bahwa tanda tangan yang diterima dari Titan dikeluarkan oleh hardware Titan autentik yang menjalankan firmware Titan autentik.
Membangun integritas saat booting
Makalah ini menjelaskan mekanisme untuk memastikan bahwa prosesor aplikasi mesin melakukan booting kode yang diinginkan. Mekanisme ini bergantung pada alur booting terukur, ditambah dengan chip root-of-trust hardware.
Model ancaman Google meliputi penyerang yang mungkin secara fisik berada di bus antara CPU dan RoT, dengan tujuan mendapatkan kredensial yang didekripsi mesin secara tidak tepat. Untuk membantu meminimalkan risiko ini, Google mendorong pengembangan pendekatan berbasis standar untuk mengalahkan interposer aktif, yang menyatukan TPM dan API DPE dari Trusted Computing Group serta root of trust terintegrasi Caliptra.
Langkah selanjutnya
- Untuk informasi tentang cara Google membantu memastikan integritas stack booting mesin yang terpisah dan kompleks, lihat Pengesahan jarak jauh untuk mesin terpisah.
- Untuk informasi ringkas tentang infrastruktur keamanan Google, lihat Ringkasan desain keamanan infrastruktur Google.
- Untuk informasi lebih lanjut tentang kontribusi Google dalam memberikan solusi keamanan Titan terhadap standar industri, lihat diskusi TPM yang Disahkan di Lingkungan Terdistribusi, Big, dan Distributed Environment di channel YouTube Trusted Computing Group.
- Untuk laporan resmi keamanan lainnya, lihat Laporan resmi keamanan.
Penulis: Jeff Andersen, Kevin Plybon