Google Cloud Key Vault Service

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Kami menjelaskan layanan cloud yang menggunakan hardware aman untuk menyimpan kunci kriptografis 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 disimpan tidak dapat diambil secara permanen setelah terlalu banyak upaya yang gagal untuk memberikan faktor pengetahuan yang benar.

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

Catatan: Dokumen ini masih dalam proses, dan detail penerapannya masih dalam tahap penyelesaian. Seiring sistem menjadi stabil dan lebih banyak dokumentasi dapat dibuat, kami akan memperbarui whitepaper ini dengan informasi yang lebih mendetail (terutama sehubungan dengan rilis open source yang relevan).

Ringkasan

Secara tradisional, enkripsi (yang digunakan untuk memastikan privasi data) memerlukan penggunaan secret yang memiliki entropi tinggi dari perspektif penyerang. Entropi tinggi diperlukan karena skema enkripsi harus menahan serangan brute force yang menjelajahi ruang semua kemungkinan secret hingga yang benar ditemukan. Mengingat ketersediaan daya komputasi saat ini, persyaratan entropi minimum yang wajar untuk secret kriptografis mungkin berada di sekitar 70 hingga 80 bit. Sayangnya, manusia sangat kesulitan untuk mengingat dan mengingat dengan andal sandi atau rahasia lainnya dengan jumlah entropi sebesar itu¹, terutama jika jarang digunakan (tetapi sering menggunakan sandi dengan entropi tinggi itu sulit dan merepotkan). Hal ini menimbulkan masalah yang menantang: bagaimana kita dapat melindungi data pribadi dengan teknologi enkripsi, jika kita ingin secret menjadi "faktor pengetahuan" yang sangat mungkin 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 secret mereka sendiri.

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

Whitepaper ini menjelaskan pendekatan kami untuk membuat layanan Cloud Key Vault menggunakan Modul Hardware Tepercaya (THM). Implementasi pertama kami atas layanan CKV 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 dapat mengingat LSKF mereka dengan andal. Pada saat yang sama, secret LSKF tersebut biasanya memiliki entropi yang cukup untuk melawan penyerang yang memiliki jumlah percobaan yang sangat terbatas, sehingga cocok untuk layanan CKV.

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

Konsep Inti

Awalnya, satu-satunya platform klien yang didukung untuk layanan Cloud Key Vault adalah sistem operasi Android 9 Pie, dan saat kami merujuk pada klien di seluruh whitepaper ini, kami merujuk pada perangkat yang menjalankan sistem operasi Android 9 Pie dengan layanan Google Play. Penerapan sisi server kami berjalan di server Google yang ditetapkan secara khusus dan memiliki chip Titan tambahan² yang diinstal di dalamnya. Chip Titan yang dirancang Google berfungsi sebagai komponen hardware di Modul Hardware Tepercaya kami, dan kami menyediakannya secara khusus dengan bootloader dan firmware kustom yang menerapkan protokol dan mekanisme penegakan keamanan kami (seperti yang dijelaskan di sini). Kami menggunakan teknik pengesahan hardware untuk mendapatkan jaminan bahwa protokol kami benar-benar berjalan di hardware Titan.

Layanan CKV harus diskalakan untuk menangani traffic dari miliaran³ perangkat Android, tanpa kehilangan data pengguna dalam jumlah yang signifikan karena kegagalan hardware (misalnya, chip yang terbakar) atau mengalami pemadaman layanan yang berkepanjangan karena pemeliharaan pusat data. Oleh karena itu, server dengan chip Titan diatur ke dalam kelompok, dengan setiap kelompok terdiri dari beberapa THM independen yang masing-masing berisi salinan materi kunci yang sama. Kohor tertentu akan didistribusikan di seluruh pusat data yang secara fisik berbeda di zona pemeliharaan yang berbeda, untuk memastikan bahwa sistem dapat memenuhi sasaran ketersediaan dan keandalannya. Untuk skalabilitas, klien akan di-shard ke sejumlah kohor 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 mudah diingat manusia, seperti PIN singkat, pola geser pada petak titik 3x3, 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 secara 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.

Recovery Agent: 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 untuk berinteraksi dengan Sistem Operasi Android sesuai kebutuhan untuk membuat pesan protokol apa pun yang melibatkan LSKF.

Klaim Pemulihan: Jika pengguna ingin mengambil Kunci Pemulihan, mereka harus membuat Klaim Pemulihan, yang memiliki salinan terenkripsi LSKF yang diklaim pengguna ketahui. Biasanya, pengguna akan diminta untuk memasukkan LSKF perangkat lama mereka di perangkat baru yang mencoba mengakses Kunci Pemulihan perangkat lama.

Kunci Pemulihan: Kunci rahasia kriptografis yang dilindungi oleh layanan Cloud Key Vault, dan digunakan untuk mengenkripsi (dan mengautentikasi) data di perangkat Klien. Setelah Kunci Pemulihan dimasukkan ke 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 mudah diingat manusia.

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

Kunci Publik Kohor: Kunci publik dari pasangan kunci yang dihasilkan oleh Kohor THM tertentu. Kunci pribadi yang sesuai hanya tersedia di dalam THM yang berada dalam Kohor pada waktu pembuatan kunci.

Trusted Hardware Module (THM): Modul keamanan khusus (mikrokontroler) yang dirancang untuk menyediakan lingkungan komputasi yang minimal dan tepercaya. Setidaknya, elemen aman harus dapat membuat dan/atau menyimpan kunci rahasia, serta mempertahankan beberapa status evolusi non-volatil (sehingga dapat mencegah serangan yang melibatkan reset ke status sebelumnya).

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

Server Vault: Mesin tujuan umum yang beroperasi di pusat data Google yang telah dimodifikasi secara khusus untuk menambahkan Trusted Hardware Module (THM).

Desain Protokol

Protokol CKV terdiri dari sejumlah fase, seperti berikut:

Inisialisasi

Untuk melakukan inisialisasi sistem, Google akan menyediakan kunci publik untuk "root of trust" yang akan digunakan Framework untuk memverifikasi pengesahan hardware Google. Kunci penandatanganan untuk root trust ini disimpan secara offline dan diamankan dengan cermat sehingga memerlukan partisipasi beberapa karyawan untuk menandatanganinya. Kunci publik untuk root of trust ini di-bake ke dalam Android OS, dan hanya dapat diubah melalui update OS.

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

Pembuatan Vault

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

Pembukaan Vault

Jika Recovery Agent di perangkat baru perlu mendapatkan akses ke Recovery Key yang disimpan di Vault tertentu, pertama-tama pengguna akan diminta untuk memasukkan LSKF perangkat asli yang membuat Vault. Recovery Agent kemudian akan meminta Framework untuk membuat Recovery Claim menggunakan LSKF tersebut. Framework akan membuat Kunci Penggugat baru, dan mengenkripsi Kunci Penggugat tersebut serta hash LSKF yang diklaim, dengan Kunci Publik Kohor yang sama dengan yang digunakan untuk mengenkripsi Vault. Blob terenkripsi yang dihasilkan disebut Klaim Pemulihan, dan Framework meneruskannya ke Agen Pemulihan, yang kemudian menampilkannya ke layanan CKV.

CKV merutekan Klaim Pemulihan (dan Vault yang sesuai) ke Server Vault yang merupakan bagian dari Kohor 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 ulang dengan Kunci Penggugat yang ada di Klaim Pemulihan. Jika tidak, THM akan memicu penghitung upaya gagal. Setelah penghitung upaya 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 bawah Kunci Penggugat) akan dikirim kembali dari Server Vault ke Framework. Framework menggunakan salinan Kunci Penggugat untuk mendekripsi Kunci Pemulihan, dan protokol kini sudah selesai.

Tindakan Keamanan

Sistem Cloud Key Vault bertujuan untuk memberikan "pertahanan mendalam" dengan menyertakan perlindungan keamanan di beberapa tingkat stack kami. Untuk memberikan gambaran tentang cara kerja perlindungan ini, kita akan mulai dengan menjelaskan Klien dan melanjutkan ke 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 menggunakan modul keamanan hardware yang tahan modifikasi tidak sah untuk menyimpan LSKF dalam penyimpanan, dan untuk menerapkan batas kapasitas berbasis hardware pada validasi LSKF. Framework API baru yang diperkenalkan untuk memungkinkan penggunaan Cloud Key Vault dirancang untuk mempertahankan jaminan keamanan yang ada sebanyak mungkin, meskipun perangkat menggunakan modul keamanan hardware tersebut untuk melindungi penyimpanan LSKF.

Kami akan memfokuskan bagian ini secara khusus pada masalah dan perlindungan keamanan yang relevan yang memengaruhi fitur Cloud Key Vault baru, bukan mencoba 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 memastikan API tersebut hanya tersedia untuk aplikasi sistem yang disetujui OEM seperti layanan Google Play. Hal ini sebagian besar menghilangkan platform serangan langsung yang mungkin terekspos ke aplikasi yang diinstal pengguna di perangkat.

Framework API juga memastikan bahwa Vault hanya dibuat untuk Kunci Publik Kohor yang diautentikasi oleh root of trust. Root of trust diintegrasikan ke dalam Framework oleh OEM saat dikirim, dan tidak dapat diubah tanpa update OS. Hal ini memberikan keyakinan bahwa LSKF hanya digunakan untuk membuat Vault yang akan menerapkan perlindungan brute force berbasis hardware dengan benar. Dengan mengandalkan THM di layanan Cloud Key Vault untuk perlindungan brute force bagi LSKF, kita dapat mencapai keamanan yang sebanding dengan menggunakan hardware aman di perangkat untuk hal yang sama (seperti yang dilakukan perangkat Google Pixel 2).

Karena kita tidak berasumsi bahwa LSKF akan disimpan di mana pun di perangkat di luar hardware yang aman, Vault baru hanya dapat dibuat segera setelah perangkat dibuka kuncinya. Pada saat pengguna memasukkan LSKF untuk membuka kunci perangkat, LSKF akan tersedia untuk Framework dalam RAM untuk sementara. Pada saat itulah API baru menggunakannya untuk membuat Vault. Anda 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 yang dirancang untuk mencegah Agen Pemulihan melihat LSKF perangkat saat ini atau Kunci Pemulihan apa pun. Hanya Framework yang akan melihat hal-hal tersebut di sisi Klien, sehingga lebih sulit untuk mengeksploitasi potensi bug atau kerentanan keamanan di Recovery Agent. Agen Pemulihan sebagian besar digunakan untuk mengelola peristiwa siklus proses dan penerusan data secara 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 Pemulihan⁴. Namun, penerapan Agen Pemulihan "melupakan" LSKF yang diklaim segera setelah Framework mengambil alih konstruksi Klaim Pemulihan.

Fitur Keamanan Protokol

Meskipun analisis lengkap protokol berada di luar cakupan dokumen ini, kami ingin menyoroti beberapa perlindungan bawaan dalam protokol. Secara khusus, protokol hanya menggunakan hash LSKF di seluruh bagian. Artinya, jika LSKF memiliki entropi tinggi (misalnya, jika merupakan sandi entropi tinggi yang baik), menyimpan Vault jauh lebih baik daripada menyimpan hash sandi, dan dalam hal ini, hash sandi dapat memberikan ukuran keamanan yang tidak bergantung pada keamanan THM. Oleh karena itu, kami mendukung hashing "memory hard" dengan garam LSKF sebagai bagian dari protokol. Kami juga secara kriptografis mengikat Vault 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 dibuat baru pada setiap pembuatan Vault, kami menerapkan 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 jika LSKF telah diubah atau ada daftar Kunci Publik Kohor baru yang dibuktikan. Dengan demikian, rotasi Kunci Pemulihan dapat dilakukan tanpa membahayakan perlindungan brute force untuk LSKF.

Keamanan Server untuk Cloud Key Vault Service

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

Perlindungan hardware

Perlindungan keamanan utama yang diterapkan di sisi server layanan CKV adalah Modul Hardware Tepercaya (THM) yang dibuat menggunakan chip Titan yang dirancang khusus oleh Google. Chip menjalankan firmware yang mengekspos API yang diperlukan untuk menerapkan protokol CKV. Secara khusus, mereka dapat membuat dan membagikan pasangan kunci dengan aman kepada anggota lain dalam Kohor mereka sehingga logika firmware melindungi kunci pribadi agar tidak bocor ke luar chip Titan di Kohor. Chip ini juga dapat melakukan operasi Pembukaan Vault, dan mempertahankan penghitungan per Vault yang gagal dengan sangat ketat (dengan penghitung yang didukung oleh status yang disimpan di dalam chip Titan). Deskripsi yang lebih mendetail tentang protokol yang dijalankan oleh firmware chip CKV Titan akan diberikan dalam rilis mendatang dari dokumen ini.

Mengingat bahwa keamanan server berasal dari logika firmware di chip Titan, kita harus memastikan bahwa logika tidak berubah dengan cara yang memungkinkan chip membocorkan rahasia atau mengabaikan batas penghitung. Untuk mencapai tujuan ini, kami juga mengubah bootloader Titan untuk memastikan bahwa data yang disimpan chip (seperti kunci pribadi untuk Kohor) dihapus sepenuhnya sebelum update diterapkan. Kelemahan dari perlindungan ini adalah kita tidak dapat memperbaiki bug di firmware tanpa mengalami beberapa kehilangan data. Mengupdate firmware secara fungsional setara dengan menghancurkan hardware yang ada dan menggantinya dengan chip baru. Jika patch firmware kritis diperlukan, Google harus membuat dan memublikasikan daftar Kunci Publik Kohor yang diautentikasi sepenuhnya dan secara bertahap memigrasikan semua pengguna ke daftar baru. Untuk mengurangi risiko ini, kami mencoba menjaga codebase firmware agar tetap minimal, dan mengauditnya dengan cermat untuk menemukan potensi masalah keamanan.

Perlindungan software

Selain batas kegagalan per Vault yang ketat yang diberlakukan oleh THM, layanan CKV juga menerapkan pembatasan kapasitas berbasis software. Pembatasan kapasitas dirancang untuk mencegah pembajak masuk ke akun pengguna dan dengan cepat menghabiskan batas upaya pemulihan yang gagal, sehingga secara efektif mengunci akses pengguna sebenarnya ke Kunci Pemulihan mereka. Serupa dengan penundaan waktu yang diberlakukan oleh perangkat pengguna setelah terlalu banyak upaya membuka kunci layar yang gagal, layanan CKV 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 beserta publikasi kode klien di Project Open Source Android nanti pada tahun ini.

Catatan