Google Cloud Key Vault Service

Kami menjelaskan bahwa layanan cloud yang menggunakan hardware aman untuk menyimpan kunci kriptografis sedemikian rupa, sehingga akses ke kunci tersebut dilindungi oleh faktor pengetahuan entropi rendah (misalnya PIN layar kunci). Hardware aman dirancang untuk mencegah serangan brute force, dengan membuat kunci kriptografis yang tersimpan tidak dapat diambil kembali secara permanen setelah terlalu banyak upaya yang gagal untuk memasok faktor pengetahuan yang benar.

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

Catatan: Dokumen ini masih dalam proses, dan detail penerapannya masih dalam proses. Seiring dengan stabilnya sistem dan dokumentasi lainnya dapat dibuat, kami akan memperbarui laporan resmi ini dengan informasi yang lebih mendetail (terutama bersama dengan rilis open source yang relevan).

Ringkasan

Secara tradisional, enkripsi (yang digunakan untuk memastikan privasi data) mengharuskan penggunaan secret yang memiliki entropi tinggi dari perspektif penyerang. Entropi tinggi diperlukan karena skema enkripsi harus menahan serangan brute force yang menjelajahi ruang dari semua kemungkinan secret sampai yang benar ditemukan. Mengingat ketersediaan daya komputasi saat ini, persyaratan entropi minimum yang wajar untuk rahasia kriptografis mungkin berkisar antara 70 hingga 80 bit. Sayangnya, manusia sangat sulit menghafal dan mengingat sandi atau rahasia lain dengan entropi sebanyak itu1, terutama jika jarang digunakan (tetapi sering menggunakan sandi entropi tinggi akan sulit dan membosankan). Hal ini menyisakan masalah yang menantang: bagaimana cara 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 sangat sulit dipecahkan sehingga layanan penyimpanan Cloud biasanya hanya mengenkripsi data dengan secret yang dikelola oleh penyedia penyimpanan Cloud itu sendiri, bukan mengandalkan pengguna untuk mengingat rahasia mereka sendiri.

Salah satu pendekatan untuk menjembatani kesenjangan antara persyaratan untuk rahasia kriptografi dan rahasia yang dapat diingat manusia adalah menggunakan layanan Cloud Key Vault (CKV) untuk menyimpan "kunci pemulihan" dengan entropi tinggi, yang dilindungi oleh rahasia yang dapat diingat manusia dengan entropi rendah. CKV service akan merilis kunci pemulihan hanya kepada pihak yang membuktikan pengetahuan tentang rahasia yang benar yang dapat diingat manusia. Serangan brute force terhadap rahasia yang dapat diingat manusia dapat digagalkan oleh CKV service, yang akan menerapkan batas absolut pada jumlah upaya gagal untuk membuktikan pengetahuan tentang rahasia tersebut. Kunci pemulihan itu sendiri adalah kunci simetris kriptografis standar, yang cocok untuk digunakan dengan skema enkripsi (terautentikasi) yang dapat dengan mudah mengenkripsi sejumlah besar data (misalnya cadangan disk) yang dapat disimpan dengan aman di mana saja. Data terenkripsi tersebut tidak berguna bagi siapa saja yang tidak dapat memperoleh kunci pemulihan.

Laporan resmi ini menjelaskan pendekatan kami dalam pembuatan Cloud Key Vault service menggunakan Trusted Hardware Module (THM). Implementasi pertama kami untuk CKV service dirancang untuk melindungi kunci pemulihan dengan Lock Screen Knowledge Factor (LSKF) pengguna, yaitu PIN rahasia, sandi, atau pola geser yang digunakan untuk membuka kunci smartphone. Manusia dapat mengingat LSKF mereka dengan andal. Pada saat yang sama, secret LSKF tersebut biasanya memiliki entropi yang cukup untuk menahan penyerang yang memiliki jumlah percobaan yang sangat terbatas, sehingga cocok untuk CKV service.

Aplikasi pertama dari layanan Cloud Key Vault kami adalah mengaktifkan pencadangan Android terenkripsi sisi klien. Sebelumnya, file yang dienkripsi secara lokal pada perangkat Android menggunakan kunci yang dilindungi dengan LSKF pengguna, tetapi cadangan file yang disimpan (dan dienkripsi) di Cloud tidak dilindungi oleh LSKF. Untuk pertama kalinya, Cloud Key Vault juga memungkinkan perlindungan layar kunci untuk cadangan Android yang disimpan di Cloud. Artinya, server Google tidak dapat mengakses atau memulihkan konten cadangan terenkripsi – hanya perangkat dengan LSKF pengguna yang dapat mendekripsi cadangan tersebut.

Konsep Inti

Awalnya, satu-satunya platform klien yang didukung untuk Cloud Key Vault service adalah sistem operasi Android 9 Pie, dan saat kami merujuk klien di seluruh laporan resmi ini, berarti kami mengacu pada perangkat yang menjalankan sistem operasi Android 9 Pie dengan layanan Google Play. Implementasi sisi server kami dijalankan pada server Google yang dirancang khusus dan memiliki chip Titan tambahan2 yang terinstal di dalamnya. Chip Titan rancangan Google berfungsi sebagai komponen hardware di Trusted Hardware Module, dan kami secara khusus menyediakannya bersama bootloader dan firmware khusus yang mengimplementasikan protokol serta mekanisme penegakan keamanan kami (seperti yang dijelaskan di sini). Kami menggunakan teknik pengesahan hardware untuk mendapatkan jaminan bahwa protokol kami benar-benar berjalan pada hardware Titan.

Layanan CKV harus diskalakan untuk menangani traffic dari miliaran3 perangkat Android, tanpa kehilangan sejumlah besar data pengguna karena kegagalan hardware (misalnya, chip burn-out) atau mengalami pemadaman layanan berkepanjangan akibat pemeliharaan pusat data. Oleh karena itu, server yang berisi chip Titan disusun ke dalam beberapa kelompok, dengan setiap kelompok terdiri dari beberapa THM independen yang masing-masing berisi salinan materi kunci yang sama. Kelompok tertentu akan didistribusikan di seluruh pusat data yang berbeda secara fisik dalam zona pemeliharaan yang berbeda, untuk memastikan bahwa sistem tersebut dapat memenuhi sasaran ketersediaan dan keandalannya. Untuk skalabilitas, klien akan di-sharding ke sejumlah kelompok yang berbeda, sehingga kami dapat menyesuaikan kapasitas layanan hanya dengan menambahkan lebih banyak server untuk meningkatkan jumlah kohor 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, seperti PIN pendek, pola geser pada 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") untuk kunci layar perangkat lokal pengguna.

Klien: Perangkat pengguna akhir yang menjalankan sistem operasi Android 9 Pie dan layanan Google Play, atau software yang didukung setara.

Framework Android: kami menggunakan istilah umum ini (atau hanya Framework) untuk merujuk ke API di Android 9 Pie atau yang lebih baru, dan tidak dimaksudkan untuk merujuk ke rilis sebelumnya.

Layanan Google Play: Kumpulan layanan dan aplikasi yang berjalan di perangkat pengguna akhir, yang memungkinkannya berfungsi dengan sistem akun Google dan API server kustom.

Agen Pemulihan: Aplikasi sistem yang berjalan sebagai bagian dari layanan Google Play di ruang pengguna pada perangkat Android 9 Pie (atau yang serupa). Agen Pemulihan bertanggung jawab untuk mengeksekusi sisi Klien dari berbagai protokol, dan berinteraksi dengan Sistem Operasi Android sesuai kebutuhan untuk membuat pesan protokol yang melibatkan LSKF.

Klaim Pemulihan: Saat ingin mengambil Kunci Pemulihan, pengguna harus membuat Klaim Pemulihan, yang memiliki salinan LSKF terenkripsi yang diklaim diketahui oleh pengguna. Biasanya, pengguna akan diminta untuk memasukkan LSKF perangkat lama pada perangkat baru yang mencoba mengakses Kunci Pemulihan pada perangkat lama.

Kunci Pemulihan: Kunci rahasia kriptografis yang dilindungi layanan Cloud Key Vault, serta digunakan untuk mengenkripsi (serta mengautentikasi) data di perangkat Klien. Setelah Kunci Pemulihan dimasukkan ke dalam Vault (lihat di bawah), salinan lokal dapat dihapus segera setelah Klien selesai menggunakannya untuk mengenkripsi data.

Layanan Cloud Key Vault (CKV): Layanan internet yang memungkinkan perangkat Klien menyimpan kunci kriptografis yang dilindungi oleh LSKF yang dapat diingat manusia.

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

Kunci Publik Kelompok: Kunci publik dari pasangan kunci yang dihasilkan oleh Kelompok THM tertentu. Kunci pribadi terkait hanya tersedia di dalam THM yang ada di Kelompok tersebut pada waktu pembuatan kunci.

Trusted Hardware Module (THM): Modul keamanan khusus (pengontrol mikro) yang dirancang untuk menyediakan lingkungan komputasi minimal dan tepercaya. Setidaknya, elemen aman harus dapat menghasilkan dan/atau menyimpan kunci rahasia, dan mempertahankan beberapa status yang berkembang tidak mudah berubah (sehingga dapat mencegah serangan yang melibatkan reset ke status sebelumnya).

Vault: Entri tertentu dalam database CKV Service, yang berisi Kunci Pemulihan yang dilindungi LSKF dari satu perangkat. Pengguna akhir mungkin memiliki beberapa Vault pada file, yang masing-masing berkaitan dengan perangkat atau LSKF yang berbeda. Hanya THM di Server Vault yang dapat memeriksa atau mengekstrak isi Vault.

Server Vault: Mesin tujuan umum 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 menginisialisasi sistem, Google akan menyediakan kunci publik untuk "root of trust" yang akan digunakan Framework untuk memverifikasi pengesahan hardware Google. Kunci penandatanganan untuk root kepercayaan ini disimpan secara offline dan diamankan dengan cermat sehingga memerlukan partisipasi banyak karyawan agar dapat menandatangani dengan kunci tersebut. Kunci publik untuk root kepercayaan ini telah diintegrasikan ke dalam Android OS, dan hanya dapat diubah melalui update OS.

Google juga memublikasikan daftar kunci publik secara berkala untuk setiap Kelompok THM, bersama pengesahan pada daftar. Pengesahan pada daftar menggunakan tanda tangan yang dirantai kembali ke root kepercayaan. Setiap pembaruan daftar yang dipublikasikan juga berisi nomor urut, sehingga rollback dapat dicegah. Agen Pemulihan akan mengambil daftar kunci publik Kelompok terbaru yang dipublikasikan dan menyediakannya ke Framework. Framework kemudian memverifikasi pengesahan dan secara acak memilih Kunci Publik Kelompok dari daftar untuk digunakan dalam fase Pembuatan Vault.

Pembuatan Vault

Setelah membantu Framework menyelesaikan Inisialisasi dengan mengambil daftar Kunci Publik Kelompok, Agen Pemulihan akan meminta Framework membuat Vault baru. Setiap kali LSKF dimasukkan lagi oleh pengguna, Framework akan membuat Kunci Pemulihan baru dan mengenkripsinya terlebih dahulu dengan kunci yang berasal dari hash LSKF, lalu dengan Kunci Publik Kelompok yang dipilih oleh Framework selama Inisialisasi. Blob terenkripsi yang dihasilkan adalah Vault yang diteruskan kembali oleh Framework ke Agen Pemulihan, yang kemudian menguploadnya ke CKV service Google.

Pembukaan Vault

Jika Agen Pemulihan di perangkat baru perlu mendapatkan akses ke Kunci Pemulihan yang disimpan di Vault tertentu, perangkat akan meminta pengguna memasukkan LSKF perangkat asli yang membuat Vault terlebih dahulu. Agen Pemulihan kemudian akan meminta Framework untuk membuat Klaim Pemulihan menggunakan LSKF tersebut. Framework akan membuat Kunci Penggugat baru, dan mengenkripsi Kunci Penggugat tersebut serta hash LSKF yang diklaim, dengan Kunci Publik Kelompok yang sama dengan Vault yang awalnya dienkripsi. Blob terenkripsi yang dihasilkan disebut Klaim Pemulihan, dan Framework meneruskannya ke Agen Pemulihan, yang kemudian menyajikannya ke layanan CKV.

CKV merutekan Klaim Pemulihan (dan Vault-nya) yang sesuai ke Server Vault yang merupakan bagian dari Kelompok yang benar. THM di Server Vault kemudian mendekripsi Klaim Pemulihan dan mencoba mengekstrak Kunci Pemulihan dari Vault asli menggunakan hash LSKF yang diklaim (untuk mendapatkan kunci enkripsi bagian dalam). Jika hash LSKF asli dan hash LSKF yang diklaim cocok, THM akan mengekstrak Kunci Pemulihan dari Vault dan mengenkripsinya kembali dengan KunciClaimant yang ada dalam Klaim Pemulihan. Jika tidak, THM akan memicu penghitung upaya gagal. Setelah penghitung upaya yang gagal mencapai batasnya, THM akan menolak untuk memproses Klaim Pemulihan berikutnya untuk Vault ini.

Terakhir, jika semuanya berjalan lancar, Kunci Pemulihan yang dienkripsi ulang (yang kini dienkripsi di Kunci Claimsant) akan dikirim kembali dari Server Vault hingga ke Framework. Framework menggunakan salinan Kunci Claimsant-nya untuk mendekripsi Kunci Pemulihan, dan protokol kini telah selesai.

Tindakan Keamanan

Sistem Cloud Key Vault bertujuan untuk menyediakan "pertahanan mendalam" dengan menyertakan perlindungan keamanan di berbagai level stack kami. Untuk memberikan gambaran tentang cara kerja perlindungan ini, kami akan mulai dengan menjelaskan Klien dan cara kerja kami hingga stack ke Cloud Key Vault Service.

Keamanan Klien

Bergantung pada OEM dan perangkat tertentu, Lock Screen Knowledge Factor (LSKF) biasanya disimpan dan dilindungi di perangkat menggunakan berbagai metode yang bervariasi menurut OEM. Misalnya, perangkat Pixel 2 Google memanfaatkan modul keamanan hardware anti-modifikasi untuk menyimpan LSKF dalam penyimpanan, dan menerapkan batas kapasitas berbasis hardware pada validasi LSKF. Framework API baru yang diperkenalkan untuk mengaktifkan penggunaan Cloud Key Vault dirancang untuk mempertahankan jaminan keamanan yang ada semaksimal mungkin, bahkan jika perangkat menggunakan modul keamanan hardware tersebut untuk melindungi penyimpanan LSKF.

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

Mengamankan Framework API

Framework API baru yang ditambahkan untuk mendukung layanan CKV ditandai sebagai @SystemApi dan memerlukan izin khusus, yang memastikannya hanya tersedia untuk aplikasi sistem yang disetujui OEM seperti layanan Google Play. Hal ini sebagian besar menghilangkan permukaan serangan langsung yang mungkin terpapar aplikasi yang diinstal pengguna di perangkat.

Framework API juga memastikan bahwa Vault hanya dibuat untuk Kunci Publik Kelompok yang telah dibuktikan oleh root kepercayaan. Akar kepercayaan telah ditanamkan ke dalam Framework oleh OEM saat dikirimkan, dan tidak dapat diubah tanpa update OS. Hal ini memberikan keyakinan bahwa LSKF hanya 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 dapat mencapai keamanan yang sebanding dengan menggunakan hardware aman pada perangkat untuk hal yang sama (seperti yang dilakukan perangkat Google Pixel 2).

Karena kami tidak berasumsi bahwa LSKF akan disimpan pada perangkat di luar hardware aman, Vault baru hanya dapat dibuat segera setelah perangkat dibuka kuncinya. Pada saat pengguna memasukkan LSKF untuk membuka kunci perangkat, LSKF akan tersedia sebentar lagi untuk Framework di RAM. Pada saat itulah API baru menggunakannya untuk membuat Vault. Tidak dapat membuat Vault baru yang dilindungi LSKF saat perangkat terkunci, karena LSKF tidak tersedia.

Mengamankan Agen Pemulihan

Perlindungan keamanan utama yang kami berikan di Agen Pemulihan adalah protokol ini dirancang untuk mencegah Agen Pemulihan melihat LSKF perangkat saat ini atau Kunci Pemulihan apa pun. Hanya Framework yang seharusnya melihat hal tersebut di sisi Klien, sehingga makin sulit untuk mengeksploitasi potensi bug atau kerentanan keamanan di Agen Pemulihan. Agen Pemulihan sebagian besar digunakan untuk mengelola peristiwa siklus proses dan penerusan data bolak-balik antara Cloud dan Framework. Satu-satunya pengecualian untuk hal ini terjadi selama pemulihan tepat sebelum protokol Pembukaan Vault, saat pengguna harus memasukkan LSKF perangkat lama – UI yang mengumpulkan LSKF yang diklaim untuk perangkat lama diterapkan di Agen Pemulihan4. Namun, implementasi Agen Pemulihan tidak "melupakan" LSKF yang diklaim segera setelah Framework mengambil alih konstruksi Klaim Pemulihan.

Fitur Keamanan Protokol

Meskipun analisis lengkap protokol ini berada di luar cakupan dokumen ini, kami ingin menyoroti beberapa perlindungan bawaan pada protokol. Secara khusus, protokol hanya menggunakan hash LSKF secara keseluruhan. Artinya, jika LSKF memiliki entropi tinggi (misalnya, jika sandi tersebut adalah sandi entropi tinggi yang baik), penyimpanan Vault akan lebih baik daripada menyimpan hash sandi, dan dalam hal ini hash sandi dapat memberikan langkah pengamanan yang terpisah dari keamanan THM. Karena alasan ini, kami mendukung hashing "memory hard" yang salt untuk LSKF sebagai bagian dari protokol. Kami juga mengikat Vault secara kriptografis ke ID untuk perangkat yang membuatnya, dan mengikat Klaim Pemulihan ke nonce yang digunakan sebagai tantangan selama protokol Pembukaan Vault untuk memastikan bahwa Klaim Pemulihan masih baru.

Karena Kunci Pemulihan dihasilkan 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 Framework memastikan bahwa alamat penghitung yang digunakan untuk Vault berikutnya tidak akan berubah kecuali LSKF telah diubah atau ada daftar baru yang disahkan untuk Kunci Publik Kelompok. Dengan demikian, rotasi Kunci Pemulihan dapat 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 di setiap lapisan.

Perlindungan hardware

Perlindungan keamanan utama yang diimplementasikan pada sisi server CKV service adalah Trusted Hardware Modules (THM) yang dibangun menggunakan chip Titan yang dirancang khusus milik Google. Chip ini menjalankan firmware yang mengekspos API yang diperlukan untuk mengimplementasikan protokol CKV. Secara khusus, mereka dapat membuat dan membagikan pasangan kunci secara aman dengan anggota lain dalam Kelompoknya, sehingga logika firmware melindungi kunci pribadi agar tidak bocor ke luar chip Titan di Kelompok. Mereka juga dapat melakukan operasi Pembukaan Vault, dan mempertahankan penghitung gagal per-Vault yang jumlahnya benar-benar bertambah (penghitung ini didukung oleh status yang disimpan di dalam chip Titan). Deskripsi lebih detail tentang protokol yang dijalankan oleh firmware chip CKV Titan akan diberikan dalam rilis mendatang dokumen ini.

Mengingat bahwa keamanan server berasal dari logika firmware dalam chip Titan, kita harus memastikan bahwa logika tidak berubah dengan cara yang memungkinkan chip membocorkan secret atau mengabaikan batas penghitung. Untuk mencapai tujuan ini, kami juga mengubah boot loader Titan untuk memastikan data yang disimpan di chip (seperti kunci pribadi untuk Kelompok) sepenuhnya dihapus total sebelum update diterapkan. Kelemahan dari perlindungan ini adalah kita tidak dapat mem-patch bug di firmware tanpa mengalami kehilangan data–mengupdate firmware secara fungsional setara dengan menghancurkan hardware yang ada dan menggantinya dengan chip baru. Jika patch firmware penting diperlukan, Google harus membuat dan memublikasikan daftar yang benar-benar baru untuk Kunci Publik Kelompok yang telah dibuktikan dan secara bertahap memigrasikan semua pengguna ke daftar baru tersebut. Untuk mengurangi risiko ini, kami mencoba meminimalkan codebase firmware, dan mengauditnya dengan cermat untuk menemukan setiap potensi masalah keamanan.

Perlindungan software

Selain batas kegagalan hard per-Vault yang diberlakukan oleh THM, CKV service juga mengimplementasikan pembatasan kapasitas berbasis software. Pembatasan kapasitas dirancang untuk mencegah pembajak masuk ke akun pengguna dan menghabiskan batas upaya pemulihan yang gagal dengan cepat, yang secara efektif mengunci akses pengguna sebenarnya ke Kunci Pemulihan. Serupa dengan penundaan waktu yang diterapkan oleh perangkat pengguna setelah terlalu banyak upaya yang gagal untuk membuka kunci layar, CKV service akan menerapkan penundaan waktu yang meningkat setelah setiap permintaan Pembukaan Vault berikutnya yang gagal.

Kami juga menerapkan langkah-langkah keamanan standar untuk layanan Cloud yang menghosting data pengguna, termasuk kontrol akses, pemantauan, dan pengauditan yang ketat.

Spesifikasi Protokol Detail

Spesifikasi protokol mendetail masih dalam proses, dan dokumen ini akan diperbarui untuk menyertakan detail tersebut bersama dengan publikasi kode klien dalam Project Open Source Android nanti pada tahun ini.

Catatan

  1. "Menuju Penyimpanan Andal 56-bit Secrets in Human Memory | USENIX." 1 Agustus 2014, https://www.usenix.org/node/184458.
  2. "Blog Google Cloud Platform: Mendalami Titan: Keamanan dalam teks biasa." 24 Agu 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html.
  3. "Google mengumumkan lebih dari 2 miliar perangkat aktif bulanan di Android ...." 17 Mei. 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users.
  4. Hal ini memungkinkan kami menyediakan UI yang fleksibel untuk memasukkan LSKF perangkat lain -- Framework perangkat saat ini mungkin tidak memiliki UI yang sesuai untuk memasukkan LSKF perangkat lama.