Google Cloud Key Vault Service

Kami menggambarkan cloud sebagai layanan yang menggunakan hardware aman untuk menyimpan kunci kriptografik dengan dilindungi oleh faktor pengetahuan entropi rendah (mis., PIN layar kunci) untuk mengaksesnya. Hardware aman dirancang untuk mencegah serangan brute-force, dengan membuat kunci kriptografik tersimpan tidak dapat diambil lagi untuk selamanya setelah terlalu sering gagal mencoba memasukkan faktor pengetahuan yang benar.

Penulis: Shabsi Walfish
Tanggal Versi: 2018-03-06

Catatan: Dokumen ini masih dalam pengerjaan, dan detail implementasi sedang dituntaskan. Begitu sistem telah stabil dan dokumentasi selengkapnya bisa dibuat, kami akan memperbarui dokumen resmi ini dengan informasi lebih detail (khususnya bersama dengan rilis open source yang relevan).

Ringkasan

Biasanya, enkripsi (yang digunakan untuk menjaga privasi data) mengharuskan penggunaan rahasia yang memiliki entropi tinggi dari perspektif penyerang. Entropi tinggi diperlukan karena skema enkripsi harus mampu menahan serangan brute-force yang mengeksplorasi ruang yang mungkin berisi rahasia hingga ditemukan rahasia sebenarnya. Mengingat ketersediaan kemampuan komputasi zaman sekarang, kebutuhan entropi minimum yang layak untuk rahasia kriptografik mungkin sekitar 70 hingga 80 bit. Sayangnya, kita sangat sulit menghapalnya dan mengingat sandi atau rahasia lain dengan entropi sebesar itu¹, khususnya jika jarang menggunakannya (tetapi sering menggunakan sandi dengan entropi tinggi merupakan hal yang sulit dan membosankan). Hal ini menyisakan masalah yang menantang pada kita: bagaimana kita bisa melindungi data pribadi dengan teknologi enkripsi, jika kita ingin rahasia itu menjadi "faktor pengetahuan" yang kemungkinan besar harus diingat oleh pengguna? Karena berbagai alasan, masalah ini sulit dipecahkan sehingga layanan penyimpanan Cloud biasanya hanya mengenkripsi data dengan rahasia yang ditangani oleh penyedia penyimpanan Cloud itu sendiri, bukan mengandalkan pengguna untuk mengingat rahasia mereka sendiri.

Satu pendekatan untuk menjembatani kesenjangan antara kebutuhan akan rahasia kriptografik dan rahasia yang dapat diingat manusia adalah menggunakan Cloud Key Vault (CKV) service untuk menyimpan "kunci pemulihan" entropi tinggi, yang dilindungi oleh rahasia yang dapat diingat manusia dengan entropi rendah. CKV service akan merilis kunci pemulihan hanya kepada pihak yang terbukti mengetahui dengan benar rahasia yang dapat diingat manusia. Serangan brute-force terhadap rahasia yang dapat diingat manusia bisa dirintangi oleh CKV service, yang akan memberlakukan batas mutlak atas jumlah upaya gagal untuk membuktikan pengetahuan atas rahasia tersebut. Kunci pemulihan itu sendiri adalah kunci simetris kriptografik standar, cocok untuk digunakan bersama skema enkripsi (terautentikasi) yang bisa dengan mudah mengenkripsi volume data yang besar (seperti backup disk) yang bisa dengan aman disimpan di mana saja – data dienkripsi tersebut tidak berguna bagi orang yang tidak bisa memperoleh kunci pemulihan.

Dokumen resmi ini menjelaskan pendekatan kami dalam membangun Cloud Key Vault service dengan menggunakan Trusted Hardware Module (THM). Implementasi pertama kami untuk CKV service dirancang untuk melindungi kunci pemulihan dengan Lock Screen Knowledge Factor (LSKF) pengguna – PIN rahasia, sandi, atau pola geser yang digunakan untuk membuka kunci smartphone. Manusia diyakini bisa mengingat LSKF mereka. Pada saat yang sama, rahasia LSKF demikian biasanya memiliki entropi yang cukup untuk menahan penyerang yang mencoba dalam jumlah upaya sangat terbatas, sehingga membuatnya cocok untuk CKV service.

Aplikasi pertama dari Cloud Key Vault service adalah untuk memungkinkan backup Android yang dienkripsi pada sisi klien. Sebelumnya, file yang dienkripsi secara lokal pada perangkat Android menggunakan kunci yang dilindungi dengan Lock Screen Knowledge Factor pengguna, tetapi backup file itu yang disimpan (dan dienkripsi) di Cloud tidak dilindungi oleh layar kunci. Untuk pertama kali, Cloud Key Vault juga memungkinkan perlindungan layar kunci untuk backup Android yang disimpan di Cloud. Ini berarti server Google tidak mampu mengakses atau memulihkan isi backup dienkripsi – hanya perangkat dengan LSKF pengguna yang bisa mendekripsi backup tersebut.

Konsep Inti

Sebagai awal, hanya platform klien yang didukung untuk Cloud Key Vault service yang akan menjadi sistem operasi Android P mendatang, dan bila kami menyebut klien dalam dokumen resmi ini berarti yang kami maksud adalah perangkat yang menjalankan sistem operasi Android P bersama Layanan Seluler Google. Implementasi pada sisi server kami berjalan pada server Google yang dirancang khusus dengan chip Titan ekstra² terinstal di dalamnya. Chip Titan rancangan Google berfungsi sebagai komponen hardware dalam Trusted Hardware Module, dan secara khusus kami menyediakannya bersama bootloader dan firmware khusus yang mengimplementasikan protokol serta mekanisme pemberlakuan keamanan kami (seperti dijelaskan di sini). Kami menggunakan teknik pembuktian hardware dalam rangka mendapatkan kepastian bahwa protokol kami benar-benar berjalan pada hardware Titan.

CKV service harus diskalakan untuk menangani traffic dari miliaran³ perangkat Android, tanpa kehilangan data pengguna dalam jumlah signifikan akibat kegagalan hardware (mis., chip hangus) atau mengalami pemutusan listrik yang lama akibat pemeliharaan pusat data. Karena alasan ini, server yang menggunakan chip Titan disusun dalam beberapa kelompok, masing-masing kelompok terdiri dari sejumlah THM independen yang masing-masing berisi copy material kunci yang sama. Kelompok yang diberikan akan didistribusikan ke semua bagian pusat data yang terpisah secara fisik dalam beberapa zona pemeliharaan berbeda, dalam rangka memastikan sistem bisa memenuhi sasaran ketersediaan dan keandalannya. Untuk skalabilitas, klien akan dipecah menjadi beberapa kelompok berbeda, sehingga kami bisa menyesuaikan kapasitas layanan cukup dengan menambahkan server lebih banyak untuk menambah jumlah kelompok yang tersedia.

Kami sekarang siap menyebutkan berbagai komponen utama arsitektur Cloud Key Vault service.

Komponen Arsitektural / Glosarium

Lock Screen Knowledge Factor (LSKF): Rahasia yang dapat diingat manusia, misalnya PIN yang pendek, pola geser di atas petak 3 x 3 titik, atau sandi. Rahasia ini digunakan untuk melindungi kemampuan membuka kunci perangkat secara lokal, dan dianggap sebagai faktor autentikasi utama (atau "kuat") bagi kunci layar perangkat lokal pengguna.

Klien: Perangkat pengguna akhir yang menjalankan sistem operasi Android P dan Layanan Seluler Google, atau software yang sama-sama didukung.

Android Framework: kami menggunakan istilah umum ini untuk menyebut API dalam sistem operasi Android rilis berikutnya (penerus rilis Oreo, yang masih tidak bernama sejak penulisannya) atau setelahnya, dan tidak dimaksudkan untuk merujuk rilis terdahulu

Layanan Seluler Google: Kumpulan layanan dan aplikasi yang berjalan pada perangkat pengguna akhir, yang memungkinkannya digunakan bersama sistem akun dan API server khusus Google.

Agen Pemulihan: Aplikasi sistem yang berjalan sebagai bagian dari Google Play Services di ruang pengguna pada perangkat Android P (atau yang serupa). Agen Pemulihan bertanggung jawab mengeksekusi sisi Klien dari beragam protokol, dan berantarmuka dengan Sistem Operasi Android bila diperlukan untuk membuat pesan protokol yang melibatkan LSKF.

Klaim Pemulihan: Bila pengguna ingin mengambil Kunci Pemulihan, mereka harus membuat Klaim Pemulihan, yang memiliki copy LSKF dienkripsi yang diklaim diketahui oleh pengguna. Biasanya, pengguna akan diminta memasukkan LSKF perangkat lama mereka pada perangkat baru yang mencoba mengakses Kunci Pemulihan pada perangkat lama.

Kunci Pemulihan: Kunci rahasia kriptografik yang dilindungi dengan Cloud Key Vault service, dan digunakan untuk mengenkripsi (serta mengautentikasi) data pada perangkat Klien. Setelah Kunci Pemulihan dimasukkan ke dalam Vault (lihat di bawah) copy lokal bisa dihapus begitu Klien selesai menggunakannya untuk mengenkripsi data.

Cloud Key Vault (CKV) Service: Layanan internet yang memungkinkan perangkat Klien menyimpan kunci kriptografik yang dilindungi dengan LSKF yang bisa diingat oleh manusia.

Kelompok: Kumpulan Server Vault/THM yang satu sama lain dapat berfungsi sebagai replika redundant.

Kunci Umum Kelompok: Kunci umum dari pasangan kunci yang dihasilkan oleh Kelompok THM tertentu. Kunci pribadi yang bersangkutan hanya tersedia di dalam THM yang ada di Kelompok tersebut pada waktu pembuatan kunci.

Trusted Hardware Module (THM): Modul keamanan khusus (pengontrol mikro) dirancang untuk menyediakan lingkungan komputasi minimal dan tepercaya. Minimum, elemen aman harus bisa menghasilkan dan/atau menyimpan kunci rahasia, dan mempertahankan semacam keadaan yang berkembang secara tidak volatil (sehingga bisa mencegah serangan yang melibatkan setel ulang ke keadaan sebelumnya).

Vault: Entri khusus di database CKV Service, berisi LSKF satu perangkat yang dilindungi Kunci Pemulihan. Pengguna akhir mungkin memiliki beberapa Vault pada file, masing-masing menyatakan perangkat atau LSKF berbeda. Hanya THM di Server Vault yang bisa memeriksa atau mengekstrak isi suatu Vault.

Server Vault: Mesin serba guna yang beroperasi di pusat data Google yang telah dirombak secara khusus untuk menambahkan Trusted Hardware Module (THM)

Desain Protokol

Protokol CKV terdiri dari sejumlah fase, seperti berikut:

Inisialisasi

Untuk melakukan inisialiasi sistem, Google akan memasukkan kunci umum bagi "akar kepercayaan" yang akan digunakan Android Framework untuk memverifikasi pembuktian hardware Google. Kunci penandatanganan untuk akar kepercayaan ini disimpan secara offline secara hati-hati diamankan sedemikian rupa sehingga diperlukan partisipasi banyak karyawan untuk menandatangani dengan menggunakannya. Kunci umum untuk akar kepercayaan ini telah diintegrasikan ke dalam Android OS, dan hanya bisa diubah melalui update OS.

Secara berkala Google juga memublikasikan daftar kunci umum untuk setiap Kelompok THM, bersama pembuktian pada daftar. Pembuktian pada daftar menggunakan tanda tangan yang dirantai kembali ke akar kepercayaan. Setiap update daftar yang dipublikasikan juga berisi nomor urut, sehingga rollback bisa dicegah. Agen Pemulihan akan mengambil daftar publikasi terbaru kunci umum Kelompok dan memasukkannya ke Android Framework. Android Framework kemudian memverifikasi pembuktian dan secara acak memilih Kunci Umum Kelompok dari daftar yang akan digunakan dalam fase Pembuatan Vault.

Pembuatan Vault

Setelah membantu Framework menyelesaikan Inisialisasi dengan mengambil daftar Kunci Umum Kelompok, Agen Pemulihan akan meminta Android Framework membuat Vault baru. Bila LSKF kemudian dimasukkan oleh pengguna, Framework akan menghasilkan Kunci Pemulihan baru dan mengenkripsinya lebih dahulu dengan kunci yang diperoleh dari hash LSKF, kemudian dengan Kunci Umum Kelompok yang dipilih oleh Framework selama Inisialisasi. Blob dienkripsi yang dihasilkan adalah Vault yang akan disalurkan kembali oleh Framework ke Agen Pemulihan, yang kemudian menguploadnya ke CKV service milik Google.

Pembukaan Vault

Bila Agen Pemulihan pada perangkat baru perlu mendapatkan akses ke Kunci Pemulihan yang tersimpan di Vault tertentu, terlebih dahulu ia akan meminta pengguna memasukkan LSKF perangkat asal yang telah membuat Vault. Agen Pemulihan kemudian akan meminta Framework membuat Klaim Pemulihan dengan menggunakan LSKF itu. Framework akan membuat Kunci Claimant baru, dan mengenkripsi Kunci Claimant itu beserta hash LSKF yang diklaim, dengan Kunci Umum Kelompok yang sama dengan yang digunakan untuk mengenkripsi Vault. Blob dienkripsi yang dihasilkan disebut Klaim Pemulihan, dan Framework menyalurkannya ke Agen Pemulihan, yang kemudian memberikannya ke CKV service.

CKV merutekan Klaim Pemulihan (dan Vault-nya) ke Server Vault yang merupakan bagian dari Kelompok yang benar. THM di Server Vault kemudian mendekripsi Klaim Pemulihan dan berupaya mengekstrak Klaim Pemulihan dari Vault semula dengan menggunakan hash LSKF yang diklaim (untuk memperoleh kunci enkripsi dalam). Jika hash LSKF asal dan hash LSKF yang diklaim ternyata sama, THM akan mengekstrak Kunci Pemulihan dari Vault dan mengenkripsinya kembali dengan Kunci Claimant yang ada dalam Klaim Pemulihan. Jika tidak, THM akan memicu penghitung upaya gagal. Setelah penghitung upaya gagal mencapai batasnya, THM akan menolak memproses Klaim Pemulihan selanjutnya untuk Vault ini.

Terakhir, jika semua berjalan dengan baik, Kunci Pemulihan yang dienkripsi ulang (yang kini dienkripsi pada Kunci Claimant) dikirim kembali dari Server Vault langsung ke Framework. Framework menggunakan copy Kunci Claimant-nya untuk mendekripsi Kunci Pemulihan, dan protokol kini lengkap.

Tindakan Keamanan

Sistem Cloud Key Vault bertujuan menyediakan "pertahanan yang menyeluruh" dengan menyertakan perlindungan keamanan pada beberapa level tumpukan kami. Untuk memberikan gambaran mengenai cara kerja perlindungan ini, kami akan mulai dengan menjelaskan Klien dan cara kerja kami hingga tumpukan ke Cloud Key Vault Service.

Keamanan Klien

Bergantung pada OEM dan perangkat tertentu, Lock Screen Knowledge Factor (LSKF) biasanya disimpan dan dilindungi pada perangkat dengan menggunakan beragam metode yang berbeda-beda menurut OEM. Misalnya, perangkat Pixel 2 dari Google memanfaatkan modul keamanan hardware tahan-perusakan untuk menyimpan LSKF, dan memberlakukan batas nilai berbasis hardware pada validasi LSKF. Framework API baru yang akan diperkenalkan untuk memungkinkan penggunaan Cloud Key Vault dirancang untuk mempertahankan jaminan keamanan yang ada sebisa mungkin, bahkan bila perangkat menggunakan modul keamanan hardware untuk melindungi penyimpanan LSKF.

Kami akan memfokuskan bagian ini secara khusus pada masalah keamanan dan perlindungan yang relevan, yang memengaruhi fitur Cloud Key Vault baru, bukan berupaya memberikan gambaran lengkap dari semua mekanisme keamanan yang berkaitan dengan LSKF.

Mengamankan Framework API

Framework API baru yang telah ditambahkan untuk mendukung CKV service ditandai sebagai @SystemApi dan memerlukan izin khusus, yang memastikannya hanya akan tersedia untuk aplikasi sistem yang disetujui OEM, misalnya Google Play Services. Hal ini banyak menghilangkan bidang serangan langsung yang mungkin ditemui aplikasi yang diinstal pengguna pada perangkat.

API Framework juga memastikan bahwa Vault hanya dibuat untuk Kunci Umum Kelompok yang telah dibuktikan melalui akar kepercayaan. Akar kepercayaan telah diintegrasikan ke dalam Framework oleh OEM saat mengirimkannya, dan tidak bisa diubah tanpa update OS. Hal ini memberikan keyakinan bahwa LSKF hanya akan digunakan untuk membuat Vault yang akan memberlakukan perlindungan brute-force berbasis hardware dengan benar. Dengan mengandalkan THM di Cloud Key Vault service untuk perlindungan brute-force bagi LSKF, kami bisa mencapai keamanan yang sebanding dengan menggunakan hardware aman pada perangkat untuk hal yang sama (seperti pada perangkat Google Pixel 2).

Karena kami tidak beranggapan bahwa LSKF akan disimpan pada perangkat di luar hardware aman, Vault baru hanya bisa langsung dibuat setelah membuka kunci perangkat. Pada waktu pengguna memasukkan LSKF untuk membuka kunci perangkat, LSKF segera tersedia untuk Framework di RAM. Pada saat itulah API baru menggunakannya untuk membuat Vault. Tidak mungkin membuat Vault yang dilindungi LSKF baru selagi perangkat terkunci, karena LSKF tidak tersedia.

Mengamankan Agen Pemulihan

Perlindungan keamanan utama yang kami berikan pada Agen Pemulihan adalah bahwa protokol ini dirancang untuk mencegah Agen Pemulihan melihat LSKF perangkat saat ini atau Kunci Pemulihan apa pun. Hanya Framework yang bisa melihat semua itu pada sisi Klien, sehingga semakin sulit mengeksploitasi bug yang potensial atau kerentanan keamanan di Agen Pemulihan. Agen Pemulihan kebanyakan digunakan untuk mengelola event daur hidup dan penerusan data bolak-balik antara Cloud dan Framework. Satu-satunya pengecualian untuk hal ini terjadi selama pemulihan persis sebelum protokol Pembukaan Vault, saat pengguna harus memasukkan LSKF perangkat lama – UI yang mengumpulkan LSKF yang diklaim untuk perangkat lama diimplementasikan di Agen Pemulihan⁴. Akan tetapi, implementasi Recovery Agent tidak "melupakan" LSKF yang diklaim begitu Framework mengambil alih konstruksi Klaim Pemulihan.

Fitur Keamanan Protokol

Walaupun analisis lengkap atas protokol berada di cakupan dokumen ini, kami ingin menyoroti beberapa perlindungan yang diintegrasikan dalam protokol. Secara khusus, protokol hanya menggunakan hash LSKF seluruhnya. Berarti, jika LSKF memiliki entropi tinggi (mis., jika berupa sandi entropi tinggi yang baik) maka menyimpan Vault lebih baik daripada menyimpan hash sandi, dan dalam hal ini hash sandi bisa memberikan tindakan keamanan yang tidak bergantung pada keamanan THM. Karena alasan ini, kami tidak mendukung hashing "memory hard" yang salt untuk LSKF sebagai bagian dari protokol. Kami juga secara kriptografik mengikat Vault ke ID untuk perangkat yang membuatnya, dan mengikat Klaim Pemulihan pada waktu ini saja yang digunakan sebagai tantangan selama protokol Pembukaan Vault untuk memastikan Klaim Pemulihan dalam keadaan baru.

Berhubung Kunci Pemulihan dihasilkan dalam keadaan baru pada setiap pembuatan Vault, kami mengimplementasikan rotasi kunci dengan menimpa entri Vault yang ada dengan Vault yang baru dibuat. Alamat untuk penghitung upaya gagal yang digunakan oleh Vault dipilih selama pembuatan Vault, dan Android Framework memastikan bahwa alamat penghitung yang digunakan untuk Vault selanjutnya tidak akan berubah kecuali jika LSKF telah berubah atau ada daftar pembuktian baru dari Kunci Umum Kelompok. Sehingga, rotasi Kunci Pemulihan bisa dilakukan tanpa merusak perlindungan brute-force untuk LSKF.

Keamanan Server untuk Cloud Key Vault Service

Server diimplementasikan menggunakan kombinasi software yang berjalan pada hardware server biasa, dan firmware yang berjalan pada hardware khusus (chip Titan). Kami akan menjelaskan perlindungan yang ditawarkan pada setiap layer.

Perlindungan hardware

Perlindungan keamanan utama yang diimplementasikan pada sisi server CKV service adalah Trusted Hardware Module (THM) yang dibangun menggunakan chip Titan yang dirancang khusus oleh Google sendiri. Chip ini menjalankan firmware yang mengekspos API yang dibutuhkan untuk mengimplementasikan protokol CKV. Khususnya, mereka bisa menghasilkan dan berbagi pasangan kunci secara aman dengan anggota lain dari Kelompoknya misalnya logika firmware melindungi kunci pribadi agar tidak bocor keluar dari chip Titan di Kelompok. Mereka juga bisa melakukan operasi Pembukaan Vault, dan menjaga penghitung upaya gagal per-Vault yang bertahap secara ketat (counter didukung oleh keadaan yang disimpan di dalam chip Titan). Deskripsi lebih detail mengenai protokol yang dieksekusi oleh firmware chip CKV Titan akan diberikan dalam rilis mendatang dokumen ini.

Dengan anggapan keamanan server didapat dari logika firmware dalam chip Titan, kita harus memastikan bahwa logika tidak berubah dengan cara yang memungkinkan chip membocorkan rahasia atau mengabaikan batas penghitung. Untuk mencapai sasaran ini, kami juga mengubah boot-loader Titan untuk memastikan data yang disimpan di chip (seperti kunci pribadi untuk Kelompok) di-wipe sepenuhnya sebelum update diterapkan. Kelemahan dari perlindungan ini adalah karena kita tidak bisa melakukan patch bug di firmware tanpa mengalami kehilangan data–memperbarui firmware secara fungsional setara dengan menghancurkan hardware yang ada dan menggantinya dengan chip baru. Seandainya diperlukan patch firmware penting, Google perlu membuat dan memublikasikan daftar yang sepenuhnya baru untuk Kunci Umum Kelompok yang telah dibuktikan dan secara bertahap memigrasikan semua pengguna ke daftar baru itu. Untuk meminimalkan risiko ini, kami mencoba mempertahankan basis kode firmware dengan benar-benar minimal, dan mengauditnya secara cermat untuk masalah keamanan yang potensial.

Perlindungan software

Di samping batas kegagalan hard-per-Vault yang dikenakan oleh THM, CKV service juga mengimplementasikan pembatasan nilai berbasis software. Pembatasan nilai dirancang untuk mencegah pembajak masuk ke dalam akun pengguna dan secara cepat menghabiskan batas upaya pemulihan gagal mereka, yang secara efektif mengunci akses pengguna sungguhan ke Kunci Pemulihan. Serupa dengan tundaan waktu yang dikenakan oleh perangkat pengguna bila sudah terlalu banyak upaya gagal untuk membuka kunci layar, CKV service akan memberlakukan tundaan waktu yang meningkat setiap kali permintaan Pembukaan Vault selanjutnya yang gagal.

Kami juga mengimplementasikan tindakan keamanan standar bagi Cloud service yang menjadi host data pengguna, termasuk kontrol akses yang ketat, pemantauan, dan audit.

Spesifikasi Protokol Detail

Spesifikasi protokol detail masih dalam proses, dan dokumen ini akan diupdate untuk menyertakan semua detail itu bersama publikasi kode klien di Proyek Open Source Android nanti tahun ini.

Catatan