Kami menjelaskan suatu layanan cloud yang menggunakan hardware aman untuk menyimpan kunci kriptografis sehingga aksesnya dilindungi oleh faktor pengetahuan entropi rendah (misalnya PIN layar kunci). Hardware aman didesain untuk mencegah serangan brute force, dengan membuat kunci kriptografis yang tersimpan tidak dapat diambil kembali secara permanen setelah terlalu banyak upaya gagal untuk memberikan faktor pengetahuan yang benar.
Penulis: Shabsi Walfish
Tanggal Versi: 06-03-2018
Catatan: Dokumen ini masih dalam proses, dan detail implementasinya masih dalam proses. Setelah sistem stabil 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 rahasia hingga yang benar ditemukan. Mengingat ketersediaan daya komputasi saat ini, persyaratan entropi minimum yang wajar untuk secret kriptografis mungkin sekitar 70 hingga 80 bit. Sayangnya, manusia sangat sulit untuk menghafal dan mengingat sandi atau rahasia lain yang memiliki entropi tersebut secara andal1, terutama jika jarang digunakan (tetapi sering menggunakan sandi dengan entropi tinggi adalah hal yang sulit dan membosankan). Hal ini menimbulkan masalah yang menantang: bagaimana cara melindungi data pribadi dengan teknologi enkripsi, jika kita ingin rahasia itu menjadi "faktor pengetahuan" yang sangat mungkin diingat oleh pengguna? Karena berbagai alasan, masalah ini sangat sulit diselesaikan 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 rahasia kriptografis 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 terbukti mengetahui 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 mutlak terhadap jumlah upaya yang 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 data dalam jumlah besar (seperti cadangan disk) dan dapat disimpan dengan aman di mana saja – data terenkripsi tersebut tidak berguna bagi siapa pun yang tidak dapat memperoleh kunci pemulihan.
Laporan resmi ini menjelaskan pendekatan kami dalam membangun Cloud Key Vault service menggunakan Trusted Hardware Module (THM). Implementasi pertama kami untuk 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, rahasia LSKF semacam itu biasanya memiliki entropi yang cukup untuk menahan penyerang yang memiliki jumlah upaya 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 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. Ini berarti bahwa 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 layanan Cloud Key Vault adalah sistem operasi Android 9 Pie. Saat kami merujuk kepada klien di seluruh laporan resmi ini, kami merujuk pada perangkat yang menjalankan sistem operasi Android 9 Pie dengan layanan Google Play. Implementasi sisi server kami berjalan di server Google yang ditetapkan secara khusus dengan chip Titan tambahan2 yang terinstal di dalamnya. Chip Titan rancangan Google berfungsi sebagai komponen hardware dalam Trusted Hardware Module, dan kami secara khusus menyediakannya dengan bootloader dan firmware kustom 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 hangus) atau mengalami pemadaman layanan yang berkepanjangan karena 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 ke berbagai pusat data secara fisik di zona pemeliharaan yang berbeda untuk memastikan bahwa sistem dapat memenuhi sasaran ketersediaan dan keandalannya. Untuk skalabilitas, klien akan di-sharding ke sejumlah kelompok yang berbeda, sehingga kami dapat menyesuaikan kapasitas layanan dengan hanya menambahkan lebih banyak server untuk meningkatkan 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, 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 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 istilah ini tidak merujuk pada 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 menjalankan sisi Klien dari berbagai protokol, dan berinteraksi dengan Sistem Operasi Android sebagaimana diperlukan untuk membuat pesan protokol yang melibatkan LSKF.
Klaim Pemulihan: Ketika ingin mengambil Kunci Pemulihan, pengguna harus membuat Klaim Pemulihan, yang memiliki salinan LSKF terenkripsi yang diklaim pengguna. Biasanya, pengguna akan diminta memasukkan LSKF perangkat lama mereka pada 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 (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 dibuat oleh Kelompok THM tertentu. Kunci pribadi yang terkait hanya tersedia di dalam THM yang ada di Kelompok pada waktu pembuatan kunci.
Trusted Hardware Module (THM): Modul keamanan khusus (pengontrol mikro) yang dirancang untuk menyediakan lingkungan komputasi minimal dan tepercaya. Setidaknya, elemen pengaman harus dapat menghasilkan dan/atau menyimpan kunci rahasia, dan mempertahankan beberapa status berkembang yang 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 satu perangkat. Pengguna akhir mungkin memiliki beberapa Vault pada file, masing-masing Vault terkait dengan perangkat atau LSKF 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 disesuaikan 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 kepercayaan" yang akan digunakan Framework untuk memverifikasi pengesahan hardware Google. Kunci penandatanganan untuk root kepercayaan ini disimpan secara offline dan diamankan dengan cermat sehingga diperlukan partisipasi beberapa karyawan untuk menandatanganinya. Kunci publik untuk root kepercayaan ini diintegrasikan ke dalam Android OS, dan hanya dapat diubah melalui update OS.
Google secara berkala juga memublikasikan daftar kunci publik untuk setiap Kelompok THM, bersama dengan 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 memberikannya ke Framework. Framework kemudian akan 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 selanjutnya dimasukkan oleh pengguna, Framework akan membuat Kunci Pemulihan baru dan mengenkripsinya terlebih dahulu dengan kunci yang berasal dari hash LSKF, kemudian 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 layanan CKV Google.
Pembukaan Vault
Jika Agen Pemulihan di perangkat baru perlu mendapatkan akses ke Kunci Pemulihan yang disimpan di Vault tertentu, aplikasi akan meminta pengguna memasukkan LSKF perangkat asli yang membuat Vault terlebih dahulu. Selanjutnya, Agen Pemulihan akan meminta Framework membuat Klaim Pemulihan menggunakan LSKF tersebut. Framework ini akan membuat Kunci Penggugat baru, dan mengenkripsi Kunci Penggugat tersebut serta hash LSKF yang diklaim, dengan Kunci Publik Kelompok yang sama dengan yang digunakan untuk mengenkripsi Vault. Blob terenkripsi yang dihasilkan disebut Klaim Pemulihan, dan Framework akan meneruskannya ke Agen Pemulihan, yang kemudian memberikannya 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 dalam). Jika hash LSKF asli dan hash LSKF yang diklaim cocok, THM akan mengekstrak Kunci Pemulihan dari Vault dan mengenkripsinya ulang dengan Kunci Klaimant yang ada di 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 semua berjalan lancar, Kunci Pemulihan yang dienkripsi ulang (yang kini dienkripsi dengan Kunci Klaimant) akan dikirim kembali dari Server Vault hingga ke Framework. Framework menggunakan salinan Kunci Claimsant-nya untuk mendekripsi Kunci Pemulihan, dan protokol sekarang sudah selesai.
Tindakan Keamanan
Sistem Cloud Key Vault bertujuan memberikan "pertahanan yang mendalam" dengan menyertakan perlindungan keamanan pada beberapa level stack kami. Untuk memberikan gambaran tentang cara kerja perlindungan ini, kami akan mulai dengan menjelaskan Klien dan melanjutkan 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 berdasarkan OEM. Misalnya, perangkat Pixel 2 Google menggunakan modul keamanan hardware yang tahan perusakan untuk menyimpan LSKF dalam penyimpanan, dan untuk 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 saat 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, daripada 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 terekspos ke aplikasi yang diinstal pengguna di perangkat.
Framework API juga memastikan bahwa Vault hanya dibuat untuk Kunci Publik Kelompok yang telah disahkan oleh root kepercayaan. Root kepercayaan telah disertakan ke dalam Framework oleh OEM saat diluncurkan, 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 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 di mana pun pada 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 sebentar untuk Framework di RAM. Pada saat itulah API baru menggunakannya untuk membuat Vault. Tidak dapat membuat Vault yang dilindungi LSKF baru 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. Hanya Framework yang akan melihat semua hal tersebut di sisi Klien, sehingga akan 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 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 Pemulihan4. Namun, implementasi Agen Pemulihan akan "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 bagus), penyimpanan Vault benar-benar lebih baik daripada menyimpan hash sandi, dan dalam hal ini, hash sandi dapat memberikan tingkat keamanan yang tidak bergantung pada 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 tetap baru.
Karena Kunci Pemulihan dihasilkan 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 pengesahan baru dari 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 pada setiap lapisan.
Perlindungan hardware
Perlindungan keamanan utama yang diimplementasikan di sisi server CKV service adalah Trusted Hardware Module (THM) yang dibangun menggunakan chip Titan yang dirancang khusus oleh Google. Chip ini menjalankan firmware yang mengekspos API yang diperlukan untuk mengimplementasikan protokol CKV. Secara khusus, mereka dapat membuat dan membagikan pasangan kunci dengan aman kepada anggota Kelompoknya lainnya sehingga logika firmware melindungi kunci pribadi agar tidak bocor ke luar chip Titan dalam Kelompok tersebut. Aplikasi juga dapat melakukan operasi Pembukaan Vault, dan mempertahankan penghitung upaya gagal per-Vault yang bertambah secara ketat (di mana penghitung didukung oleh status yang disimpan di dalam chip Titan). Deskripsi lebih detail tentang protokol yang dieksekusi oleh firmware chip CKV Titan akan disediakan dalam rilis mendatang dokumen ini.
Mengingat 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 bahwa data yang disimpan di chip (seperti kunci pribadi untuk Kelompok) benar-benar dihapus sebelum update apa pun diterapkan. Kelemahan dari perlindungan ini adalah kami tidak dapat mem-patch bug dalam 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 Kunci Publik Kelompok yang baru yang telah disahkan dan memigrasikan semua pengguna ke daftar baru secara bertahap. Untuk mengurangi risiko ini, kami mencoba untuk menjaga agar codebase firmware tetap minim, dan dengan cermat mengauditnya untuk menemukan potensi masalah keamanan.
Perlindungan software
Selain batas kegagalan hard per-Vault yang diberlakukan oleh THM, layanan CKV juga menerapkan pembatasan kapasitas berbasis software. Pembatasan kapasitas ini dirancang agar pembajak tidak dapat masuk ke akun pengguna dan segera menghabiskan batas upaya pemulihan yang gagal, yang secara efektif mengunci akses pengguna sebenarnya ke Kunci Pemulihan mereka. Serupa dengan tundaan waktu yang diberlakukan oleh perangkat pengguna setelah terlalu banyak upaya yang gagal untuk membuka kunci layar, CKV layanan akan menerapkan penundaan waktu yang meningkat setelah setiap permintaan Pembukaan Vault yang gagal berikutnya.
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 diupdate untuk menyertakan detail tersebut bersama dengan publikasi kode klien di Project Open Source Android nanti pada tahun ini.
Catatan
- "Menuju Penyimpanan Andal dari Rahasia 56-bit dalam Memori Manusia | USENIX." 1 Agustus 2014, https://www.usenix.org/node/184458. ↩
- "Blog Google Cloud Platform: Titan in depth: Security in simpletext." 24 Agu 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html. ↩
- "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. ↩
- 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. ↩