Konten yang terkandung dalam dokumen ini berlaku mulai Desember 2017. Laporan resmi ini menampilkan status quo pada saat penulisan. Kebijakan dan sistem keamanan Google Cloud dapat berubah pada masa mendatang, seiring upaya kami untuk terus meningkatkan perlindungan bagi pelanggan.
Ringkasan level-CIO
- Application Layer Transport Security (ALTS) Google adalah sistem enkripsi transpor dan autentikasi timbal balik yang dikembangkan oleh Google dan biasanya digunakan untuk mengamankan komunikasi Remote Procedure Call (RPC) dalam infrastruktur Google. ALTS memiliki konsep yang mirip dengan TLS yang diautentikasi secara bersama, tetapi telah dirancang dan dioptimalkan untuk memenuhi kebutuhan lingkungan pusat data Google.
- Model kepercayaan ALTS telah disesuaikan untuk aplikasi yang di-container dan mirip cloud. Identitas terikat dengan entitas, bukan ke nama server atau host tertentu. Model kepercayaan ini memfasilitasi replikasi microservice, load balancing, dan penjadwalan ulang yang lancar di seluruh host.
- ALTS mengandalkan dua protokol: protokol Handshake (dengan kelanjutan sesi) dan protokol Record. Protokol ini mengatur cara sesi dibuat, diautentikasi, dienkripsi, dan dilanjutkan.
- ALTS adalah solusi keamanan lapisan transport kustom yang kami gunakan di Google. Kami telah menyesuaikan ALTS dengan lingkungan produksi kami, sehingga ada beberapa perbedaan antara ALTS dan standar industri, TLS. Detail selengkapnya dapat ditemukan di bagian Tradeoff.
Pengantar
Sistem produksi di Google terdiri dari konstelasi microservice1 yang secara kolektif mengeluarkan O(1010) Remote Procedure Call (RPC) per detik. Saat engineer Google menjadwalkan workload produksi2, RPC yang dikeluarkan atau diterima oleh workload tersebut dilindungi dengan ALTS secara default. Perlindungan otomatis tanpa konfigurasi ini disediakan oleh Application Layer Transport Security (ALTS) Google. Selain perlindungan otomatis yang diberikan pada RPC, ALTS juga memfasilitasi replikasi layanan, load balancing, dan penjadwalan ulang yang mudah di seluruh mesin produksi. Dokumen ini menjelaskan ALTS dan membahas deployment-nya di infrastruktur produksi Google.
Audiens: Dokumen ini ditujukan untuk profesional keamanan infrastruktur yang ingin tahu cara autentikasi dan keamanan transportasi dilakukan dalam skala besar di Google.
Prasyarat: Selain pengantar ini, kami berasumsi sudah ada pemahaman dasar tentang pengelolaan cluster di Google.
Keamanan Tingkat Aplikasi dan ALTS
Banyak aplikasi, mulai dari browser web hingga VPN, mengandalkan protokol komunikasi yang aman, seperti TLS (Transport Layer Security) dan IPSec, untuk melindungi data dalam pengiriman3. Di Google, kami menggunakan ALTS, sistem enkripsi transpor dan autentikasi timbal balik yang berjalan di lapisan aplikasi, untuk melindungi komunikasi RPC. Dengan menggunakan keamanan tingkat aplikasi, aplikasi dapat memiliki identitas pembanding jarak jauh yang diautentikasi, yang dapat digunakan untuk menerapkan kebijakan otorisasi terperinci.
Mengapa Bukan TLS?
Mungkin tampak tidak biasa bagi Google untuk menggunakan solusi keamanan kustom seperti ALTS, padahal sebagian besar traffic Internet saat ini dienkripsi menggunakan TLS. ALTS mulai dikembangkan di Google pada tahun 2007. Pada saat itu, TLS dibundel dengan dukungan untuk banyak protokol lama yang tidak memenuhi standar keamanan minimum kami. Kami dapat mendesain solusi keamanan dengan mengadopsi komponen TLS yang diperlukan dan menerapkan komponen yang diinginkan; namun, keuntungan membangun sistem yang lebih sesuai dengan Google dari awal lebih besar daripada manfaat membuat patch pada sistem yang ada. Selain itu, ALTS lebih sesuai untuk kebutuhan kami, dan secara historis lebih aman daripada TLS lama. Di bawah ini tercantum perbedaan utama antara TLS dan ALTS.
- Ada perbedaan signifikan antara model kepercayaan4 TLS dengan semantik HTTPS dan ALTS. Pada yang pertama, identitas server terikat ke nama tertentu dan skema penamaan yang sesuai. Di ALTS, identitas yang sama dapat digunakan dengan beberapa skema penamaan. Tingkat tidak langsung ini memberikan lebih banyak fleksibilitas dan sangat menyederhanakan proses replikasi, load balancing, dan penjadwalan ulang microservice antar-host.
- Dibandingkan dengan TLS, ALTS lebih sederhana dalam desain dan implementasinya. Oleh karena itu, lebih mudah untuk memantau bug dan kerentanan keamanan menggunakan inspeksi manual kode sumber atau fuzzing ekstensif.
- ALTS menggunakan Protocol Buffer untuk melakukan serialisasi sertifikat dan pesan protokolnya, sedangkan TLS menggunakan sertifikat X.509 yang dienkode dengan ASN.1. Sebagian besar layanan produksi kami menggunakan buffer protokol untuk komunikasi (dan terkadang penyimpanan), sehingga ALTS lebih cocok untuk lingkungan Google.
Desain ALTS
ALTS didesain sebagai sistem tepercaya yang sangat andal yang memungkinkan autentikasi dan keamanan service-to-service dengan keterlibatan pengguna yang minimal. Untuk mencapai hal ini, properti yang tercantum di bawah adalah bagian dari desain ALTS:
- Transparansi: Konfigurasi ALTS transparan untuk lapisan aplikasi. Secara default, RPC layanan diamankan menggunakan ALTS. Hal ini memungkinkan developer aplikasi untuk berfokus pada logika fungsional layanan mereka tanpa harus mengkhawatirkan pengelolaan kredensial atau konfigurasi keamanan. Selama pembentukan koneksi layanan-ke-layanan, ALTS menyediakan identitas peer jarak jauh yang diautentikasi kepada aplikasi yang dapat digunakan untuk pemeriksaan otorisasi dan audit yang terperinci.
- Kriptografi canggih: Primitif dan protokol kriptografi yang digunakan oleh ALTS selalu diupdate untuk mengatasi serangan yang diketahui saat ini. ALTS berjalan di mesin yang dikontrol Google, yang berarti protokol kriptografi yang didukung dapat diupgrade dengan mudah dan di-deploy dengan cepat.
- Model identitas: ALTS melakukan autentikasi terutama berdasarkan identitas, bukan nama host. Di Google, setiap entitas jaringan (misalnya, pengguna perusahaan, mesin fisik, atau layanan atau workload produksi) memiliki identitas terkait. Komunikasi antarlayanan diautentikasi bersama.
- Distribusi kunci: ALTS mengandalkan setiap beban kerja yang memiliki identitas, yang dinyatakan sebagai serangkaian kredensial. Kredensial ini di-deploy di setiap beban kerja selama inisialisasi, tanpa keterlibatan pengguna. Secara paralel, root of trust dan rantai kepercayaan untuk kredensial ini dibuat untuk mesin dan workload. Sistem memungkinkan rotasi dan pencabutan sertifikat otomatis tanpa keterlibatan developer aplikasi.
- Skalabilitas: ALTS dirancang agar sangat skalabel untuk mendukung skala besar infrastruktur Google. Persyaratan ini menghasilkan pengembangan Lanjutan Sesi yang efisien.
- Koneksi yang aktif dalam waktu lama: Operasi kriptografi pertukaran kunci yang diautentikasi memerlukan banyak komputasi. Untuk mengakomodasi skala infrastruktur Google, setelah handshake ALTS awal, koneksi dapat dipertahankan untuk waktu yang lebih lama guna meningkatkan performa sistem secara keseluruhan.
- Kesederhanaan: TLS secara default dilengkapi dengan dukungan untuk versi protokol lama dan kompatibilitas mundur. ALTS jauh lebih sederhana karena Google mengontrol klien dan server, yang kami desain untuk mendukung ALTS secara native.
Model Kepercayaan ALTS
ALTS melakukan autentikasi terutama berdasarkan identitas, bukan host. Di Google, setiap entitas jaringan (misalnya, pengguna perusahaan, mesin fisik, atau layanan produksi) memiliki identitas terkait. Identitas ini disematkan dalam sertifikat ALTS dan digunakan untuk autentikasi peer selama pembuatan koneksi yang aman. Model yang kami kejar adalah layanan produksi kami berjalan sebagai entitas produksi yang dapat dikelola oleh Site Reliability Engineer (SRE)5 kami. Versi pengembangan layanan produksi ini berjalan sebagai entitas pengujian yang dapat dikelola oleh SRE dan developer.
Misalnya, kita memiliki produk dengan dua layanan: service-frontend dan service-backend. SRE dapat meluncurkan versi produksi layanan ini: service-frontend-prod dan service-backend-prod. Developer dapat mem-build dan meluncurkan versi pengembangan layanan ini, service-frontend-dev dan service-backend-dev, untuk tujuan pengujian. Konfigurasi otorisasi di layanan produksi akan dikonfigurasi agar tidak memercayai versi pengembangan layanan.
Kredensial ALTS
Ada tiga jenis kredensial ALTS, yang semuanya dinyatakan dalam format pesan Protocol Buffer.
- Sertifikat utama: ditandatangani oleh Layanan Penandatanganan jarak jauh dan digunakan untuk memverifikasi sertifikat handshake. Sertifikat utama berisi kunci publik yang terkait dengan kunci pribadi utama, misalnya, Pasangan kunci RSA. Kunci pribadi ini digunakan untuk menandatangani sertifikat handshake. Sertifikat ini, jika digunakan bersama dengan kebijakan ALTS yang dibahas di bawah, pada dasarnya adalah sertifikat Certificate Authority (CA) perantara yang dibatasi. Sertifikat master biasanya dikeluarkan untuk mesin produksi dan penjadwal workload dalam container seperti Borgmaster6.
- Sertifikat handshake: dibuat dan ditandatangani secara lokal oleh kunci pribadi master. Sertifikat ini berisi parameter yang digunakan selama handshake ALTS (pembuatan koneksi aman), misalnya, parameter Diffie-Hellman (DH) statis dan sandi handshake. Selain itu, sertifikat handshake berisi sertifikat utama yang berasal darinya, yaitu sertifikat yang dikaitkan dengan kunci pribadi utama yang menandatangani sertifikat handshake.
- Kunci kelanjutan: adalah rahasia yang digunakan untuk mengenkripsi tiket kelanjutan. Kunci ini diidentifikasi oleh ID Pengidentifikasi LanjutanR yang unik untuk, dan dibagikan di antara, workload produksi yang berjalan dengan identitas yang sama dan di sel datacenter yang sama. Untuk mengetahui detail selengkapnya tentang kelanjutan sesi di ALTS, lihat Kelanjutan Sesi.
Gambar 1 menunjukkan rantai sertifikat ALTS, yang terdiri dari kunci verifikasi Layanan Penandatanganan, sertifikat master, dan sertifikat handshake. Kunci verifikasi Layanan Penandatanganan adalah root of trust di ALTS dan diinstal di semua mesin Google di jaringan produksi dan perusahaan kami.
Gambar 1: Rantai sertifikat ALTS
Di ALTS, Layanan Penandatanganan mensertifikasi sertifikat utama yang pada gilirannya mensertifikasi sertifikat Handshake. Karena sertifikat Handshake dibuat lebih sering daripada sertifikat master, arsitektur ini mengurangi beban pada layanan Penandatanganan. Rotasi sertifikat sering terjadi di Google, terutama untuk sertifikat handshake 7. Rotasi yang sering ini mengompensasi pasangan pertukaran kunci statis yang dibawa oleh sertifikat handshake8.
Penerbitan Sertifikat
Untuk berpartisipasi dalam handshake aman ALTS, entitas di jaringan harus disediakan dengan sertifikat handshake. Pertama, penerbit mendapatkan sertifikat utama yang ditandatangani oleh Layanan Penandatanganan dan secara opsional meneruskannya ke entitas. Kemudian, sertifikat handshake dibuat dan ditandatangani oleh kunci pribadi utama terkait.
Biasanya, penerbitnya adalah Otoritas Sertifikat (CA) internal kami saat menerbitkan sertifikat ke mesin dan manusia, atau Borgmaster saat menerbitkan sertifikat ke beban kerja. Namun, dapat berupa entitas lain, misalnya, Borgmaster yang dibatasi untuk sel pusat data pengujian.
Gambar 2 menunjukkan cara layanan Penandatanganan digunakan untuk membuat sertifikat utama. Proses ini terdiri dari langkah-langkah berikut.
Gambar 2: Penerbitan Sertifikat
- Penerbit Sertifikat mengirimkan Permintaan Penandatanganan Sertifikat (CSR) ke Layanan Penandatanganan. Permintaan ini meminta Layanan Penandatanganan untuk membuat sertifikat untuk identitas A. Misalnya, identitas ini dapat berupa pengguna perusahaan atau identitas layanan produksi Google.
- Layanan Penandatanganan menetapkan penerbit sertifikat (termasuk dalam CSR) ke pemohon (Penerbit Sertifikat dalam hal ini) dan menandatanganinya. Ingatlah bahwa kunci publik (verifikasi) Layanan Penandatanganan yang sesuai diinstal di semua mesin Google.
- Layanan Penandatanganan mengirimkan kembali sertifikat yang ditandatangani.
- Sertifikat handshake dibuat untuk identitas A dan ditandatangani oleh kunci pribadi terkait sertifikat utama
Seperti yang ditunjukkan dalam proses di atas, dengan ALTS, penerbit dan penanda tangan sertifikat adalah dua entity logis yang berbeda. Dalam hal ini, penerbitnya adalah entitas Penerbit Sertifikat, sedangkan penandatangannya adalah Layanan Penandatanganan.
Ada tiga kategori umum sertifikat di ALTS, yaitu: Human, Machine, dan Workload. Bagian berikut menguraikan cara pembuatan dan penggunaan setiap sertifikat ini di ALTS.
Sertifikat Manusia
Di Google, kami menggunakan ALTS untuk mengamankan RPC yang dikeluarkan oleh pengguna manusia ke layanan produksi. Untuk mengeluarkan RPC, pengguna harus memberikan sertifikat handshake yang valid. Misalnya, jika Alice ingin menggunakan aplikasi untuk mengeluarkan RPC yang diamankan dengan ALTS, dia dapat mengautentikasi ke CA internal kami. Alice melakukan autentikasi ke CA menggunakan nama pengguna, sandi, dan autentikasi 2 langkah. Operasi ini akan menghasilkan Alice mendapatkan sertifikat handshake yang valid selama 20 jam.
Sertifikat Mesin
Setiap mesin produksi di pusat data Google memiliki sertifikat master mesin. Sertifikat ini digunakan untuk membuat sertifikat handshake untuk aplikasi inti di mesin tersebut, misalnya daemon pengelolaan mesin. Identitas utama yang disematkan dalam sertifikat mesin mengacu pada tujuan umum mesin. Misalnya, mesin yang digunakan untuk menjalankan berbagai jenis beban kerja produksi dan pengembangan dapat memiliki identitas yang berbeda. Sertifikat utama hanya dapat digunakan oleh mesin yang menjalankan stack software terverifikasi; dalam beberapa kasus, kepercayaan ini berakar pada hardware keamanan kustom9. Sertifikat master mesin produksi dikeluarkan oleh CA dan dirotasi setiap beberapa bulan. Selain itu, semua sertifikat handshake dirotasi setiap beberapa jam.
Sertifikat Workload
Keuntungan utama ALTS adalah bahwa ALTS beroperasi berdasarkan ide identitas beban kerja, yang memfasilitasi replikasi layanan, load balancing, dan penjadwalan ulang yang mudah di seluruh mesin. Di jaringan produksi kami, kami menggunakan sistem yang disebut Borg10 untuk pengelolaan cluster dan alokasi resource mesin dalam skala besar. Cara Borg menerbitkan sertifikat adalah bagian dari penerapan identitas beban kerja independen mesin ALTS.
Setiap beban kerja di jaringan produksi kami berjalan di sel Borg. Setiap sel berisi pengontrol yang terpusat secara logis yang disebut Borgmaster, dan beberapa proses agen yang disebut Borglet yang berjalan di setiap mesin dalam sel tersebut. Workload diinisialisasi dengan Sertifikat Negosiasi Workload terkait yang dikeluarkan oleh Borgmaster. Gambar 3 menunjukkan proses sertifikasi workload di ALTS dengan Borg.
Gambar 3: Pembuatan Sertifikat Handshake di Jaringan Produksi Google
Borgmaster kini siap menjadwalkan workload yang perlu menggunakan ALTS. Langkah-langkah di bawah terjadi saat klien menjadwalkan workload untuk dijalankan di Borg sebagai identitas tertentu.
- Setiap Borgmaster telah diinstal sebelumnya dengan Machine Master Certificate dan kunci pribadi terkait (tidak ditampilkan dalam diagram).
- ALTSd11 membuat Sertifikat Handshake Borgmaster dan menandatanganinya menggunakan kunci pribadi Machine Master. Sertifikat Handshake ini memungkinkan Borgmaster mengeluarkan RPC yang diamankan ALTS.
- Borgmaster membuat Sertifikat Master Workload Dasar, dan kunci pribadi yang sesuai. Borgmaster memulai permintaan (RPC yang diamankan ALTS) untuk mendapatkan Sertifikat Master Workload Dasar ini yang ditandatangani oleh Layanan Penandatanganan. Akibatnya, Layanan Penandatanganan mencantumkan Borgmaster sebagai penerbit pada sertifikat ini.
- Borgmaster memverifikasi bahwa klien diberi otorisasi untuk menjalankan workload sebagai identitas yang ditentukan dalam konfigurasi workload. Jika ya, Borgmaster akan menjadwalkan beban kerja Borg di Borglet, dan menerbitkan Sertifikat Pengesahan Beban Kerja dan kunci pribadinya yang sesuai. Sertifikat ini dirantai dari Sertifikat Master Workload Dasar. Sertifikat dan kunci pribadinya untuk handshake beban kerja kemudian dikirimkan dengan aman ke Borglet (melalui saluran yang dilindungi ALTS dengan autentikasi bersama antara Borgmaster dan Borglet). Borgmaster merotasi Base Workload Master Certificate dan menerbitkan ulang Handshake Certificate untuk semua beban kerja yang berjalan kira-kira setiap dua hari. Selain itu, setiap workload yang berjalan sebagai pengguna yang sama di sel yang sama menerima kunci dan ID kelanjutan yang sama (IDR) yang disediakan oleh Borgmaster.
- Saat workload perlu membuat RPC yang diamankan dengan ALTS, workload tersebut menggunakan Sertifikat Handshake Workload dalam protokol handshake. IDR juga digunakan sebagai bagian dari handshake untuk memulai kelanjutan sesi. Untuk mengetahui informasi selengkapnya tentang kelanjutan sesi di ALTS, lihat Kelanjutan Sesi.
Penegakan Kebijakan ALTS
Kebijakan ALTS adalah dokumen yang mencantumkan penerbit mana yang berwenang untuk menerbitkan kategori sertifikat tertentu untuk identitas tertentu. File ini didistribusikan ke setiap mesin di jaringan produksi kami. Misalnya, kebijakan ALTS memungkinkan CA menerbitkan sertifikat untuk mesin dan manusia. Hal ini juga memungkinkan Borgmaster mengeluarkan sertifikat ke workload.
Kami mendapati bahwa penegakan kebijakan selama verifikasi sertifikat, dibandingkan dengan penerbitan sertifikat, adalah pendekatan yang lebih fleksibel karena memungkinkan berbagai kebijakan diterapkan pada berbagai jenis deployment. Misalnya, kita mungkin ingin kebijakan di cluster pengujian lebih permisif daripada kebijakan di cluster produksi.
Selama handshake ALTS, validasi sertifikat mencakup pemeriksaan kebijakan ALTS. Kebijakan ini memastikan bahwa penerbit yang tercantum dalam sertifikat yang divalidasi diberi otorisasi untuk menerbitkan sertifikat tersebut. Jika tidak, sertifikat akan ditolak dan proses handshake akan gagal. Gambar 4 mengilustrasikan cara kerja penegakan kebijakan di ALTS. Mengikuti skenario pada Gambar 2, asumsikan bahwa Mallory (pengguna perusahaan yang ingin meningkatkan hak istimewanya) ingin mengeluarkan sertifikat utama kepada Admin Jaringan, yang merupakan identitas berkemampuan tinggi yang dapat mengonfigurasi ulang jaringan. Tentu saja, Mallory tidak diizinkan dalam kebijakan ALTS untuk melakukan operasi ini.
Gambar 4: Penerbitan dan Penggunaan Sertifikat
- Mallory menerbitkan sertifikat utama untuk identitas Admin Jaringan dan meminta sertifikat tersebut ditandatangani oleh Layanan Penandatanganan. Hal ini mirip dengan tiga langkah pertama pada Gambar 2.
- Mallory membuat dan menandatangani sertifikat handshake secara lokal untuk Admin Jaringan, menggunakan kunci pribadi utama yang terkait dengan sertifikat utama yang dibuat.
- Jika Mallory mencoba meniru identitas Admin Jaringan dengan menggunakan sertifikat handshake yang dibuat, penguat kebijakan ALTS, di peer yang coba diajak berkomunikasi oleh Mallory, akan memblokir operasi tersebut.
Pencabutan Sertifikat
Di Google, sertifikat akan dibatalkan jika masa berlakunya berakhir atau sertifikat tersebut tercantum dalam Daftar Pencabutan Sertifikat (CRL) kami. Bagian ini menjelaskan desain mekanisme pencabutan sertifikat internal Google.
Semua sertifikat yang dikeluarkan untuk pengguna perusahaan manusia memiliki stempel waktu habis masa berlaku harian yang mewajibkan pengguna untuk melakukan autentikasi ulang setiap hari. Banyak sertifikat yang dikeluarkan untuk mesin produksi tidak menggunakan stempel waktu habis masa berlaku. Kami menghindari penggunaan stempel waktu untuk mengakhiri masa berlaku sertifikat produksi karena dapat menyebabkan gangguan yang disebabkan oleh masalah sinkronisasi jam. Sebagai gantinya, kami menggunakan CRL sebagai sumber tepercaya untuk penanganan rotasi dan respons insiden sertifikat. Gambar 5 menunjukkan cara kerja CRL.
Gambar 5: Pembuatan Sertifikat Master dengan RevocationID
- Saat instance CA kami diinisialisasi12, instance tersebut akan menghubungi Layanan CRL dan meminta rentang ID pencabutan. ID pencabutan adalah ID panjang 64-bit dengan dua komponen, kategori sertifikat 8-bit (misalnya, sertifikat manusia atau mesin), dan ID sertifikat 56-bit. Layanan CRL memilih rentang ID ini dan menampilkannya ke CA.
- Saat menerima permintaan sertifikat utama, CA akan membuat sertifikat dan menyematkan ID pencabutan yang dipilihnya dari rentang.
- Secara paralel, CA memetakan sertifikat baru ke ID pencabutan dan mengirimkan informasi ini ke Layanan CRL.
- CA menerbitkan sertifikat master.
ID pencabutan yang ditetapkan ke sertifikat handshake bergantung pada cara sertifikat digunakan. Misalnya, sertifikat handshake yang dikeluarkan untuk pengguna korporat manusia mewarisi ID pencabutan sertifikat utama pengguna. Untuk sertifikat handshake yang dikeluarkan ke beban kerja Borg, ID pencabutan ditetapkan oleh rentang ID pencabutan Borgmaster. Rentang ID ini ditetapkan ke Borgmaster oleh Layanan CRL dalam proses yang mirip dengan yang ditunjukkan pada Gambar 5. Setiap kali peer terlibat dalam handshake ALTS, peer tersebut akan memeriksa salinan lokal file CRL untuk memastikan bahwa sertifikat peer jarak jauh belum dicabut
Layanan CRL mengompilasi semua ID pencabutan ke dalam satu file yang dapat dikirim ke mesin Google yang menggunakan ALTS. Meskipun database CRL berukuran beberapa ratus megabyte, file CRL yang dihasilkan hanya berukuran beberapa megabyte karena berbagai teknik kompresi.
Protokol ALTS
ALTS mengandalkan dua protokol: protokol Handshake (dengan kelanjutan sesi) dan protokol Record. Bagian ini memberikan ringkasan umum tentang setiap protokol. Ringkasan ini tidak boleh ditafsirkan sebagai spesifikasi protokol yang mendetail.
Protokol Handshake
Protokol handshake ALTS adalah protokol pertukaran kunci yang diautentikasi berbasis Diffie-Hellman yang mendukung Perfect Forward Secrecy (PFS) dan kelanjutan sesi. Infrastruktur ALTS memastikan bahwa setiap klien dan server memiliki sertifikat dengan identitas masing-masing dan kunci Elliptic Curve Diffie-Hellman (ECDH) yang terhubung ke kunci verifikasi Layanan Penandatanganan tepercaya. Di ALTS, PFS tidak diaktifkan secara default karena kunci ECDH statis ini sering diupdate untuk memperbarui kerahasiaan ke depan meskipun PFS tidak digunakan pada handshake. Selama handshake, klien dan server bernegosiasi dengan aman untuk mendapatkan kunci enkripsi transit bersama, dan protokol Record kunci enkripsi akan digunakan untuk melindungi. Misalnya, klien dan server dapat menyetujui kunci 128-bit yang akan digunakan untuk melindungi sesi RPC menggunakan AES-GCM. Proses handshake terdiri dari empat pesan Protocol Buffer yang diserialisasi, yang ringkasannya dapat dilihat pada Gambar 6.
Gambar 6: Pesan Protokol Handshake ALTS
- Klien memulai handshake dengan mengirim pesan ClientInit. Pesan ini berisi sertifikat handshake klien, dan daftar sandi terkait handshake dan protokol rekaman yang didukung klien. Jika klien mencoba melanjutkan sesi yang dihentikan, klien akan menyertakan ID kelanjutan dan tiket kelanjutan server yang dienkripsi.
Setelah menerima pesan ClientInit, server akan memverifikasi sertifikat klien. Jika valid, server memilih sandi handshake dan protokol rekaman dari daftar yang disediakan oleh klien. Server menggunakan kombinasi informasi yang ada dalam pesan ClientInit dan informasi lokalnya sendiri untuk menghitung hasil pertukaran DH. Hasil ini digunakan sebagai input ke Fungsi Turunan Kunci13 bersama dengan transkrip protokol untuk menghasilkan rahasia sesi berikut:
- Kunci rahasia record protocol M yang digunakan untuk mengenkripsi dan mengautentikasi pesan payload.
- R rahasia melanjutkan yang akan digunakan dalam tiket melanjutkan di sesi mendatang.
- Rahasia pengautentikasi A.
Server mengirim pesan ServerInit yang berisi sertifikatnya, sandi handshake yang dipilih, protokol rekaman, dan tiket kelanjutan terenkripsi opsional.
Server mengirim pesan ServerFinished yang berisi pengautentikasi handshake14. Nilai untuk pengautentikasi ini dihitung menggunakan Hash-based Message Authentication Code (HMAC) yang dihitung melalui string bit yang telah ditentukan sebelumnya dan secret pengautentikasi A.
Setelah menerima ServerInit, klien akan memverifikasi sertifikat server, menghitung hasil pertukaran DH yang serupa dengan server, dan mendapatkan rahasia M, R, dan A yang sama. Klien menggunakan A yang diturunkan untuk memverifikasi nilai pengautentikasi dalam pesan ServerFinished yang diterima. Pada tahap ini dalam proses handshake, klien dapat mulai menggunakan M untuk mengenkripsi pesan. Karena klien kini dapat mengirim pesan terenkripsi, kita dapat mengatakan bahwa ALTS memiliki protokol handshake satu RTT.
Di akhir handshake, klien mengirimkan pesan ClientFinished dengan nilai pengautentikasi serupa (lihat langkah 3) yang dihitung melalui string bit yang telah ditentukan sebelumnya lainnya. Jika perlu, klien dapat menyertakan tiket lanjutan terenkripsi untuk sesi mendatang. Setelah pesan ini diterima dan diverifikasi oleh server, protokol handshake ALTS selesai dan server dapat mulai menggunakan M untuk mengenkripsi dan mengautentikasi pesan payload lebih lanjut.
Protokol Rekaman
Bagian Protokol Handshake menjelaskan cara kami menggunakan protokol Handshake untuk menegosiasikan rahasia protokol Record. Rahasia protokol ini digunakan untuk mengenkripsi dan mengautentikasi traffic jaringan. Lapisan stack yang melakukan operasi ini disebut ALTS Record Protocol (ALTSRP).
ALTSRP berisi serangkaian skema enkripsi dengan berbagai ukuran kunci dan fitur keamanan. Selama handshake, klien mengirimkan daftar skema pilihannya, yang diurutkan berdasarkan preferensi. Server memilih protokol pertama dalam daftar klien yang cocok dengan konfigurasi lokal server. Metode pemilihan skema ini memungkinkan klien dan server memiliki preferensi enkripsi yang berbeda dan memungkinkan kita menerapkan (atau menghapus) skema enkripsi secara bertahap.
Bingkai
Frame adalah unit data terkecil di ALTS. Bergantung pada ukurannya, setiap pesan ALTSRP dapat terdiri dari satu atau beberapa frame. Setiap frame berisi kolom berikut:
- Panjang: nilai 32-bit yang tidak bertanda yang menunjukkan panjang frame, dalam byte. Kolom panjang 4 byte ini tidak disertakan sebagai bagian dari total panjang frame.
- Jenis: nilai 32-bit yang menentukan jenis frame, misalnya, frame data.
- Payload: data terautentikasi yang sebenarnya dan dienkripsi secara opsional yang sedang dikirim.
Panjang maksimum frame adalah 1 MB ditambah 4 byte panjang. Untuk protokol RPC saat ini, kami lebih membatasi panjang frame karena frame yang lebih pendek memerlukan lebih sedikit memori untuk buffering. Frame yang lebih besar juga dapat dieksploitasi oleh calon penyerang selama serangan Denial of Service (DoS) dalam upaya untuk membuat server kehabisan sumber daya. Selain membatasi panjang frame, kami juga membatasi jumlah frame yang dapat dienkripsi menggunakan M rahasia protokol rekaman yang sama. Batasnya bervariasi, bergantung pada skema enkripsi yang digunakan untuk mengenkripsi dan mendekripsi payload frame. Setelah batas ini tercapai, koneksi harus ditutup.
Payload
Di ALTS, setiap frame berisi payload yang dilindungi integritasnya dan secara opsional dienkripsi15. Pada saat publikasi dokumen ini, ALTS mendukung mode berikut:
- AES-128-GCM, AES-128-VCM: Mode AES-GCM dan AES-VCM, masing-masing, dengan kunci 128-bit. Mode ini melindungi kerahasiaan dan integritas payload menggunakan skema GCM dan VCM16.
- AES-128-GMAC, AES-128-VMAC: mode ini mendukung perlindungan khusus integritas menggunakan GMAC dan VMAC, masing-masing, untuk komputasi tag. Payload ditransfer dalam teks biasa dengan tag kriptografi yang melindungi integritasnya.
Di Google, kami menggunakan berbagai mode perlindungan, bergantung pada model ancaman dan persyaratan performa. Jika entitas yang berkomunikasi berada dalam batas fisik yang sama yang dikontrol oleh atau atas nama Google, perlindungan khusus integritas akan digunakan. Entitas ini tetap dapat memilih untuk mengupgrade ke enkripsi terautentikasi berdasarkan sensitivitas data mereka. Jika entitas yang berkomunikasi berada di batas fisik yang berbeda yang dikontrol oleh atau atas nama Google, dan komunikasi tersebut melewati Wide Area Network, kami akan otomatis mengupgrade keamanan koneksi ke enkripsi yang diautentikasi, terlepas dari mode yang dipilih. Google menerapkan perlindungan yang berbeda untuk data dalam pengiriman saat data dikirimkan ke luar batas fisik yang dikontrol oleh atau atas nama Google, karena langkah-langkah keamanan ketat yang sama tidak dapat diterapkan.
Setiap frame dilindungi integritasnya secara terpisah dan dienkripsi secara opsional. Kedua peer mempertahankan penghitung permintaan dan respons, yang disinkronkan selama operasi normal. Jika server menerima permintaan yang tidak berurutan, atau berulang, verifikasi integritas kriptografi akan gagal, sehingga permintaan dibatalkan. Demikian pula, klien akan membatalkan respons yang berulang atau tidak berurutan. Selain itu, dengan kedua peer mempertahankan penghitung (daripada menyertakan nilainya di header frame), byte tambahan di jaringan dapat dihemat.
Melanjutkan Sesi
ALTS memungkinkan penggunanya melanjutkan sesi sebelumnya tanpa perlu melakukan operasi kriptografi asimetris yang berat. Lanjutan sesi adalah fitur yang dibuat ke dalam protokol Handshake ALTS.
Handshake ALTS memungkinkan klien dan server bertukar (dan menyimpan dalam cache) tiket kelanjutan sesi secara aman yang dapat digunakan untuk melanjutkan koneksi di masa mendatang17. Setiap tiket melanjutkan yang di-cache diindeks oleh ID Lanjutan (IDR) yang unik untuk workload yang berjalan dengan identitas yang sama dan di sel pusat data yang sama. Tiket ini dienkripsi menggunakan kunci simetris yang terkait dengan ID yang sesuai.
ALTS mendukung dua jenis kelanjutan sesi:
Lanjutan sesi sisi server: klien membuat dan mengenkripsi tiket lanjutan yang berisi identitas server dan lanjutan rahasia R yang diturunkan. Tiket kelanjutan dikirim ke server di akhir handshake, dalam pesan ClientFinished. Pada sesi mendatang, server dapat memilih untuk melanjutkan sesi dengan mengirimkan tiket kembali ke klien dalam pesan ServerInit. Setelah menerima tiket, klien dapat memulihkan rahasia kelanjutan R dan identitas server. Klien dapat menggunakan informasi ini untuk melanjutkan sesi.
IDR dikaitkan dengan identitas dan bukan dengan koneksi tertentu. Di ALTS, beberapa klien dapat menggunakan identitas yang sama di pusat data yang sama. Hal ini memungkinkan klien melanjutkan sesi dengan server yang mungkin belum pernah berkomunikasi sebelumnya, misalnya jika load balancer mengirim klien ke server lain yang menjalankan aplikasi yang sama.
Lanjutan sesi sisi klien: di akhir handshake, server mengirim tiket lanjutan terenkripsi ke klien dalam pesan ServerFinished. Tiket ini mencakup rahasia kelanjutan R dan identitas klien. Klien dapat menggunakan tiket ini untuk melanjutkan koneksi dengan server mana pun yang memiliki IDR yang sama.
Saat sesi dilanjutkan, secret kelanjutan R digunakan untuk mendapatkan secret sesi baru M′, R′, dan A′. M′ digunakan untuk mengenkripsi dan mengautentikasi pesan payload, A′ digunakan untuk mengautentikasi pesan ServerFinished dan ClientFinished, dan R′ dienkapsulasi dalam tiket kelanjutan baru. Perhatikan bahwa R rahasia melanjutkan yang sama tidak digunakan lebih dari sekali.
Kompromi
Serangan Peniruan Identitas Akibat Kunci yang Dicuri
Menurut desainnya, protokol handshake ALTS rentan terhadap serangan Peniruan Identitas Akibat Pencurian Kunci (KCI). Jika penyerang membobol kunci pribadi DH, atau kunci pelanjutan, dari workload, mereka dapat menggunakan kunci tersebut untuk meniru identitas workload lain ke workload ini18. Hal ini secara eksplisit ada dalam model ancaman kelanjutan kami, karena kami ingin tiket kelanjutan yang dikeluarkan oleh satu instance identitas dapat digunakan oleh instance identitas lainnya.
Ada varian protokol handshake ALTS yang melindungi dari serangan KCI, tetapi hanya layak digunakan di lingkungan yang tidak menginginkan kelanjutan.
Privasi untuk Pesan Handshake
ALTS tidak dirancang untuk menyamarkan identitas internal yang berkomunikasi, sehingga ALTS tidak mengenkripsi pesan handshake apa pun untuk menyembunyikan identitas peer.
Kerahasiaan Penerusan Sempurna
Perfect Forward Secrecy (PFS) didukung, tetapi tidak diaktifkan secara default, di ALTS. Sebagai gantinya, kami menggunakan rotasi sertifikat yang sering untuk membuat kerahasiaan sempurna untuk sebagian besar aplikasi. Dengan TLS 1.2 (dan versi sebelumnya), kelanjutan sesi tidak dilindungi dengan PFS. Jika PFS diaktifkan dengan ALTS, PFS juga diaktifkan untuk sesi yang dilanjutkan.
Lanjutan Zero-Roundtrip
TLS 1.3 menyediakan kelanjutan sesi yang tidak memerlukan perjalanan pulang pergi (0-RTT), namun hal ini memiliki properti keamanan yang lebih lemah19. Kami memutuskan untuk tidak menyertakan opsi 0-RTT di ALTS karena koneksi RPC di Google umumnya berjangka panjang. Oleh karena itu, mengurangi latensi penyiapan saluran bukanlah pertukaran yang baik untuk kompleksitas tambahan dan/atau keamanan yang berkurang yang diperlukan oleh handshake 0-RTT.
Referensi lebih lanjut
- Untuk mengetahui informasi tentang cara Google mengenkripsi data dalam pengiriman, lihat laporan resmi Enkripsi dalam Pengiriman di Google Cloud kami.
- Untuk ringkasan tentang bagaimana keamanan dirancang dalam infrastruktur teknis Google, lihat Ringkasan Desain Keamanan Infrastruktur Google kami.