Enkripsi Berbasis File

Android 7.0 dan lebih tinggi mendukung enkripsi berbasis file (FBE). Enkripsi berbasis file memungkinkan file yang berbeda dienkripsi dengan kunci berbeda yang dapat dibuka secara mandiri.

Artikel ini menjelaskan cara mengaktifkan enkripsi berbasis file pada perangkat baru dan bagaimana aplikasi sistem dapat menggunakan API Direct Boot untuk menawarkan pengalaman terbaik dan paling aman kepada pengguna.

Semua perangkat yang diluncurkan dengan Android 10 dan lebih tinggi harus menggunakan enkripsi berbasis file.

Boot Langsung

Enkripsi berbasis file mengaktifkan fitur baru yang diperkenalkan di Android 7.0 yang disebut Direct Boot . Direct Boot memungkinkan perangkat terenkripsi untuk boot langsung ke layar kunci. Sebelumnya, pada perangkat terenkripsi yang menggunakan enkripsi disk penuh (FDE), pengguna perlu memberikan kredensial sebelum data apa pun dapat diakses, mencegah ponsel melakukan semua operasi kecuali yang paling dasar. Misalnya, alarm tidak dapat beroperasi, layanan aksesibilitas tidak tersedia, dan telepon tidak dapat menerima panggilan tetapi hanya terbatas pada operasi dialer darurat dasar.

Dengan diperkenalkannya enkripsi berbasis file (FBE) dan API baru untuk membuat aplikasi mengetahui enkripsi, aplikasi ini mungkin beroperasi dalam konteks terbatas. Ini dapat terjadi sebelum pengguna memberikan kredensial mereka sambil tetap melindungi informasi pribadi pengguna.

Pada perangkat yang mendukung FBE, setiap pengguna perangkat memiliki dua lokasi penyimpanan yang tersedia untuk aplikasi:

• Penyimpanan Credential Encrypted (CE), yang merupakan lokasi penyimpanan default dan hanya tersedia setelah pengguna membuka kunci perangkat.
• Penyimpanan Perangkat Terenkripsi (DE), yang merupakan lokasi penyimpanan yang tersedia selama mode Direct Boot dan setelah pengguna membuka kunci perangkat.

Pemisahan ini membuat profil kerja lebih aman karena memungkinkan lebih dari satu pengguna dilindungi sekaligus karena enkripsi tidak lagi hanya berdasarkan kata sandi saat boot.

Direct Boot API memungkinkan aplikasi yang sadar enkripsi untuk mengakses setiap area ini. Ada perubahan pada siklus hidup aplikasi untuk mengakomodasi kebutuhan untuk memberi tahu aplikasi saat penyimpanan CE pengguna dibuka sebagai respons terhadap kredensial yang pertama kali dimasukkan di layar kunci, atau dalam kasus profil kerja yang memberikan tantangan kerja . Perangkat yang menjalankan Android 7.0 harus mendukung API dan siklus hidup baru ini terlepas dari apakah mereka menerapkan FBE atau tidak. Meskipun, tanpa FBE, penyimpanan DE dan CE akan selalu dalam keadaan tidak terkunci.

Implementasi lengkap enkripsi berbasis file pada sistem file Ext4 dan F2FS disediakan dalam Android Open Source Project (AOSP) dan hanya perlu diaktifkan pada perangkat yang memenuhi persyaratan. Produsen yang memilih untuk menggunakan FBE mungkin ingin mencari cara mengoptimalkan fitur berdasarkan sistem pada chip (SoC) yang digunakan.

Semua paket yang diperlukan di AOSP telah diperbarui agar sadar booting langsung. Namun, jika produsen perangkat menggunakan versi yang disesuaikan dari aplikasi ini, mereka ingin memastikan setidaknya ada paket sadar boot langsung yang menyediakan layanan berikut:

• Layanan telepon dan Dialer
• Metode input untuk memasukkan kata sandi ke layar kunci

Contoh dan sumber

Android menyediakan implementasi referensi enkripsi berbasis file, di mana vold ( system/vold ) menyediakan fungsionalitas untuk mengelola perangkat penyimpanan dan volume di Android. Penambahan FBE menyediakan vold dengan beberapa perintah baru untuk mendukung manajemen kunci untuk kunci CE dan DE dari banyak pengguna. Selain perubahan inti untuk menggunakan kemampuan enkripsi berbasis file di kernel , banyak paket sistem termasuk lockscreen dan SystemUI telah dimodifikasi untuk mendukung fitur FBE dan Direct Boot. Ini termasuk:

• AOSP Dialer (paket/aplikasi/Dialer)
• Jam Meja (paket/aplikasi/Jam Meja)
• LatinIME (paket/metode masukan/LatinIME)*
• Aplikasi Pengaturan (paket/aplikasi/Pengaturan)*
• SystemUI (frameworks/base/packages/SystemUI)*

* Aplikasi sistem yang menggunakan atribut manifes defaultToDeviceProtectedStorage

Lebih banyak contoh aplikasi dan layanan yang peka terhadap enkripsi dapat ditemukan dengan menjalankan perintah mangrep directBootAware di direktori kerangka kerja atau paket dari pohon sumber AOSP.

Ketergantungan

Untuk menggunakan implementasi AOSP FBE dengan aman, perangkat harus memenuhi dependensi berikut:

• Dukungan Kernel untuk enkripsi Ext4 atau enkripsi F2FS.
• Dukungan Keymaster dengan HAL versi 1.0 atau lebih tinggi. Tidak ada dukungan untuk Keymaster 0.3 karena tidak memberikan kemampuan yang diperlukan atau menjamin perlindungan yang memadai untuk kunci enkripsi.
• Keymaster/ Keystore dan Gatekeeper harus diimplementasikan dalam Trusted Execution Environment (TEE) untuk memberikan perlindungan bagi kunci DE sehingga OS yang tidak sah (OS kustom di-flash ke perangkat) tidak dapat meminta kunci DE begitu saja.
• Perangkat Keras Root of Trust dan Verified Boot yang terikat pada inisialisasi Keymaster diperlukan untuk memastikan bahwa kunci DE tidak dapat diakses oleh sistem operasi yang tidak sah.

Penerapan

Pertama dan terpenting, aplikasi seperti jam alarm, ponsel, dan fitur aksesibilitas harus dibuat android:directBootAware sesuai dengan dokumentasi pengembang Direct Boot .

Dukungan kernel

Dukungan kernel untuk enkripsi Ext4 dan F2FS tersedia di kernel umum Android, versi 3.18 dan lebih tinggi. Untuk mengaktifkannya di kernel versi 5.1 atau lebih tinggi, gunakan:

CONFIG_FS_ENCRYPTION=y

Untuk kernel lama, gunakan CONFIG_EXT4_ENCRYPTION=y jika sistem file userdata perangkat Anda adalah Ext4, atau gunakan CONFIG_F2FS_FS_ENCRYPTION=y jika sistem file userdata perangkat Anda adalah F2FS.

Jika perangkat Anda akan mendukung penyimpanan yang dapat diadopsi atau akan menggunakan enkripsi metadata pada penyimpanan internal, aktifkan juga opsi konfigurasi kernel yang diperlukan untuk enkripsi metadata seperti yang dijelaskan dalam dokumentasi enkripsi metadata .

Selain dukungan fungsional untuk enkripsi Ext4 atau F2FS, produsen perangkat juga harus mengaktifkan akselerasi kriptografi untuk mempercepat enkripsi berbasis file dan meningkatkan pengalaman pengguna. Misalnya, pada perangkat berbasis ARM64, akselerasi ARMv8 CE (Ekstensi Kriptografi) dapat diaktifkan dengan menyetel opsi konfigurasi kernel berikut:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Untuk lebih meningkatkan kinerja dan mengurangi penggunaan daya, produsen perangkat juga dapat mempertimbangkan penerapan perangkat keras enkripsi inline , yang mengenkripsi/mendekripsi data saat dalam perjalanan ke/dari perangkat penyimpanan. Kernel umum Android (versi 4.14 dan yang lebih tinggi) berisi kerangka kerja yang memungkinkan enkripsi inline untuk digunakan saat perangkat keras dan dukungan driver vendor tersedia. Kerangka kerja enkripsi inline dapat diaktifkan dengan menyetel opsi konfigurasi kernel berikut:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Jika perangkat Anda menggunakan penyimpanan berbasis UFS, aktifkan juga:

CONFIG_SCSI_UFS_CRYPTO=y

Jika perangkat Anda menggunakan penyimpanan berbasis eMMC, aktifkan juga:

CONFIG_MMC_CRYPTO=y

Mengaktifkan enkripsi berbasis file

Mengaktifkan FBE pada perangkat memerlukan pengaktifan pada penyimpanan internal ( userdata ). Ini juga secara otomatis mengaktifkan FBE pada penyimpanan yang dapat diadopsi; namun, format enkripsi pada penyimpanan yang dapat diadopsi dapat diganti jika perlu.

Penyimpanan internal

FBE diaktifkan dengan menambahkan opsi fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] ke kolom fs_mgr_flags dari baris fstab untuk userdata . Opsi ini menentukan format enkripsi pada penyimpanan internal. Ini berisi hingga tiga parameter yang dipisahkan titik dua:

• Parameter contents_encryption_mode menentukan algoritma kriptografi mana yang digunakan untuk mengenkripsi konten file. Itu bisa berupa aes-256-xts atau adiantum . Karena Android 11 juga dapat dibiarkan kosong untuk menentukan algoritme default, yaitu aes-256-xts .
• Parameter filenames_encryption_mode menentukan algoritma kriptografi mana yang digunakan untuk mengenkripsi nama file. Itu bisa berupa aes-256-cts , aes-256-heh , adiantum , atau aes-256-hctr2 . Jika tidak ditentukan, defaultnya adalah aes-256-cts jika contents_encryption_mode adalah aes-256-xts , atau adiantum jika contents_encryption_mode adalah adiantum .
• Parameter flags , baru di Android 11, adalah daftar flag yang dipisahkan oleh karakter + . Bendera berikut ini didukung:
  • Bendera v1 memilih kebijakan enkripsi versi 1; bendera v2 memilih kebijakan enkripsi versi 2. Kebijakan enkripsi versi 2 menggunakan fungsi penurunan kunci yang lebih aman dan fleksibel . Standarnya adalah v2 jika perangkat diluncurkan pada Android 11 atau lebih tinggi (sebagaimana ditentukan oleh ro.product.first_api_level ), atau v1 jika perangkat diluncurkan pada Android 10 atau lebih rendah.
  • Bendera inlinecrypt_optimized memilih format enkripsi yang dioptimalkan untuk perangkat keras enkripsi inline yang tidak menangani sejumlah besar kunci secara efisien. Ini dilakukan dengan menurunkan hanya satu kunci enkripsi konten file per kunci CE atau DE, bukan satu per file. Pembuatan IV (vektor inisialisasi) disesuaikan.
  • Bendera emmc_optimized mirip dengan inlinecrypt_optimized , tetapi juga memilih metode pembuatan IV yang membatasi IV hingga 32 bit. Tanda ini hanya boleh digunakan pada perangkat keras enkripsi inline yang sesuai dengan spesifikasi JEDEC eMMC v5.2 dan karenanya hanya mendukung IV 32-bit. Pada perangkat keras enkripsi inline lainnya, gunakan inlinecrypt_optimized sebagai gantinya. Tanda ini tidak boleh digunakan pada penyimpanan berbasis UFS; spesifikasi UFS memungkinkan penggunaan infus 64-bit.
  • Pada perangkat yang mendukung kunci yang dibungkus perangkat keras , flag wrappedkey_v0 mengaktifkan penggunaan kunci yang dibungkus perangkat keras untuk FBE. Ini hanya dapat digunakan dalam kombinasi dengan opsi mount inlinecrypt , dan flag inlinecrypt_optimized atau emmc_optimized .

Jika Anda tidak menggunakan perangkat keras enkripsi inline, pengaturan yang disarankan untuk sebagian besar perangkat adalah fileencryption=aes-256-xts . Jika Anda menggunakan perangkat keras enkripsi inline, pengaturan yang disarankan untuk sebagian besar perangkat adalah fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (atau setara dengan fileencryption=::inlinecrypt_optimized ). Pada perangkat tanpa bentuk akselerasi AES apa pun, Adiantum dapat digunakan sebagai pengganti AES dengan menyetel fileencryption=adiantum .

Sejak Android 14 (eksperimen AOSP), AES-HCTR2 adalah mode enkripsi nama file yang lebih disukai untuk perangkat dengan instruksi kriptografi yang dipercepat. Namun, hanya kernel Android yang lebih baru yang mendukung AES-HCTR2. Dalam rilis Android mendatang, ini direncanakan menjadi mode default untuk enkripsi nama file. Jika kernel Anda memiliki dukungan AES-HCTR2, itu dapat diaktifkan untuk enkripsi nama file dengan menyetel filenames_encryption_mode ke aes-256-hctr2 . Dalam kasus paling sederhana ini akan dilakukan dengan fileencryption=aes-256-xts:aes-256-hctr2 .

Pada perangkat yang diluncurkan dengan Android 10 atau lebih rendah, fileencryption=ice juga diterima untuk menentukan penggunaan mode enkripsi konten file FSCRYPT_MODE_PRIVATE . Mode ini tidak diimplementasikan oleh kernel umum Android, tetapi dapat diimplementasikan oleh vendor menggunakan tambalan kernel khusus. Format pada disk yang dihasilkan oleh mode ini khusus untuk vendor. Pada perangkat yang diluncurkan dengan Android 11 atau lebih tinggi, mode ini tidak lagi diizinkan dan format enkripsi standar harus digunakan.

Secara default, enkripsi konten file dilakukan menggunakan API kriptografi kernel Linux. Jika Anda ingin menggunakan perangkat keras enkripsi inline, tambahkan juga opsi mount inlinecrypt . Misalnya, baris fstab lengkap mungkin terlihat seperti:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Penyimpanan yang dapat diadopsi

Sejak Android 9, FBE dan penyimpanan yang dapat diadopsi dapat digunakan bersama.

Menentukan opsi fstab fileencryption untuk userdata juga secara otomatis mengaktifkan enkripsi FBE dan metadata pada penyimpanan yang dapat diadopsi. Namun, Anda dapat mengganti format enkripsi FBE dan/atau metadata pada penyimpanan yang dapat diadopsi dengan menyetel properti di PRODUCT_PROPERTY_OVERRIDES .

Di perangkat yang diluncurkan dengan Android 11 atau lebih tinggi, gunakan properti berikut:

• ro.crypto.volume.options (baru di Android 11) memilih format enkripsi FBE pada penyimpanan yang dapat diadopsi. Ini memiliki sintaks yang sama dengan argumen untuk opsi fstab fileencryption , dan menggunakan default yang sama. Lihat rekomendasi untuk fileencryption di atas untuk apa yang digunakan di sini.
• ro.crypto.volume.metadata.encryption memilih format enkripsi metadata pada penyimpanan yang dapat diadopsi. Lihat dokumentasi enkripsi metadata .

Di perangkat yang diluncurkan dengan Android 10 atau lebih rendah, gunakan properti berikut:

• ro.crypto.volume.contents_mode memilih mode enkripsi konten. Ini setara dengan kolom pertama yang dipisahkan titik dua dari ro.crypto.volume.options .
• ro.crypto.volume.filenames_mode memilih mode enkripsi nama file. Ini sama dengan kolom kedua yang dipisahkan titik dua dari ro.crypto.volume.options , kecuali bahwa default pada perangkat yang diluncurkan dengan Android 10 atau lebih rendah adalah aes-256-heh . Pada sebagian besar perangkat, ini perlu diganti secara eksplisit menjadi aes-256-cts .
• ro.crypto.fde_algorithm dan ro.crypto.fde_sector_size pilih format enkripsi metadata pada penyimpanan yang dapat diadopsi. Lihat dokumentasi enkripsi metadata .

Mengintegrasikan dengan Keymaster

Keymaster HAL harus dimulai sebagai bagian dari kelas early_hal . Ini karena FBE mengharuskan Keymaster siap untuk menangani permintaan pada fase boot post-fs-data , yaitu saat vold menyiapkan kunci awal.

Tidak termasuk direktori

init menerapkan kunci DE sistem ke semua direktori tingkat atas /data , kecuali untuk direktori yang harus tidak dienkripsi: direktori yang berisi kunci DE sistem itu sendiri, dan direktori yang berisi direktori CE atau DE pengguna. Kunci enkripsi berlaku secara rekursif dan tidak dapat diganti oleh subdirektori.

Di Android 11 dan yang lebih tinggi, kunci yang diterapkan init ke direktori dapat dikontrol oleh argumen encryption=<action> ke perintah mkdir di skrip init. Nilai yang mungkin dari <action> didokumentasikan dalam README untuk bahasa init Android .

Di Android 10, tindakan enkripsi init di-hardcode ke lokasi berikut:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Di Android 9 dan sebelumnya, lokasinya adalah:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Dimungkinkan untuk menambahkan pengecualian untuk mencegah direktori tertentu dienkripsi sama sekali. Jika modifikasi semacam ini dilakukan maka pembuat perangkat harus menyertakan kebijakan SELinux yang hanya memberikan akses ke aplikasi yang perlu menggunakan direktori yang tidak dienkripsi. Ini harus mengecualikan semua aplikasi yang tidak tepercaya.

Satu-satunya kasus penggunaan yang dapat diterima untuk ini adalah untuk mendukung kemampuan OTA lama.

Mendukung Direct Boot dalam aplikasi sistem

Membuat aplikasi Direct Boot sadar

Untuk memfasilitasi migrasi aplikasi sistem yang cepat, ada dua atribut baru yang dapat diatur di level aplikasi. Atribut defaultToDeviceProtectedStorage hanya tersedia untuk aplikasi sistem. Atribut directBootAware tersedia untuk semua.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

Atribut directBootAware pada level aplikasi adalah singkatan untuk menandai semua komponen dalam aplikasi sebagai sadar enkripsi.

Atribut defaultToDeviceProtectedStorage mengalihkan lokasi penyimpanan aplikasi default ke penyimpanan DE alih-alih menunjuk ke penyimpanan CE. Aplikasi sistem yang menggunakan tanda ini harus mengaudit semua data yang disimpan di lokasi default dengan hati-hati, dan mengubah jalur data sensitif untuk menggunakan penyimpanan CE. Manufaktur perangkat yang menggunakan opsi ini harus hati-hati memeriksa data yang mereka simpan untuk memastikan tidak ada informasi pribadi.

Saat berjalan dalam mode ini, API Sistem berikut tersedia untuk secara eksplisit mengelola Konteks yang didukung oleh penyimpanan CE bila diperlukan, yang setara dengan mitra yang Dilindungi Perangkat.

• Context.createCredentialProtectedStorageContext()
• Context.isCredentialProtectedStorage()

Mendukung banyak pengguna

Setiap pengguna di lingkungan multi-pengguna mendapat kunci enkripsi terpisah. Setiap pengguna mendapatkan dua kunci: kunci DE dan kunci CE. Pengguna 0 harus masuk ke perangkat terlebih dahulu karena merupakan pengguna khusus. Ini relevan untuk penggunaan Administrasi Perangkat .

Aplikasi yang menyadari kripto berinteraksi antar pengguna dengan cara ini: INTERACT_ACROSS_USERS dan INTERACT_ACROSS_USERS_FULL memungkinkan aplikasi bertindak terhadap semua pengguna di perangkat. Namun, aplikasi tersebut hanya dapat mengakses direktori terenkripsi CE untuk pengguna yang sudah tidak terkunci.

Sebuah aplikasi mungkin dapat berinteraksi secara bebas di seluruh area DE, tetapi satu pengguna yang tidak terkunci tidak berarti bahwa semua pengguna di perangkat tersebut tidak terkunci. Aplikasi harus memeriksa status ini sebelum mencoba mengakses area ini.

Setiap ID pengguna profil kerja juga mendapatkan dua kunci: DE dan CE. Saat tantangan kerja terpenuhi, pengguna profil dibuka kuncinya dan Keymaster (di TEE) dapat memberikan kunci TEE profil.

Menangani pembaruan

Partisi pemulihan tidak dapat mengakses penyimpanan yang dilindungi DE pada partisi data pengguna. Perangkat yang mengimplementasikan FBE sangat disarankan untuk mendukung OTA menggunakan pembaruan sistem A/B . Karena OTA dapat diterapkan selama operasi normal, pemulihan tidak diperlukan untuk mengakses data pada drive terenkripsi.

Saat menggunakan solusi OTA lawas, yang memerlukan pemulihan untuk mengakses file OTA di partisi userdata :

1. Buat direktori tingkat atas (misalnya misc_ne ) di partisi userdata .
2. Konfigurasikan direktori tingkat atas ini agar tidak terenkripsi (lihat Tidak termasuk direktori ).
3. Buat direktori di dalam direktori tingkat atas untuk menyimpan paket OTA.
4. Tambahkan aturan SELinux dan konteks file untuk mengontrol akses ke direktori ini dan isinya. Hanya proses atau aplikasi yang menerima pembaruan OTA yang dapat membaca dan menulis ke direktori ini. Tidak ada aplikasi atau proses lain yang memiliki akses ke direktori ini.

Validasi

Untuk memastikan versi fitur yang diimplementasikan berfungsi sebagaimana mestinya, pertama-tama jalankan banyak pengujian enkripsi CTS, seperti DirectBootHostTest dan EncryptionTest .

Jika perangkat menjalankan Android 11 atau lebih tinggi, jalankan juga vts_kernel_encryption_test :

atest vts_kernel_encryption_test

atau:

vts-tradefed run vts -m vts_kernel_encryption_test

Selain itu, produsen perangkat dapat melakukan pengujian manual berikut. Di perangkat dengan FBE aktif:

• Periksa apakah ro.crypto.state ada
  • Pastikan ro.crypto.state dienkripsi
• Periksa apakah ro.crypto.type ada
  • Pastikan ro.crypto.type diatur ke file

Selain itu, penguji dapat mem-boot instance userdebug dengan set layar kunci pada pengguna utama. Kemudian adb shell ke dalam perangkat dan gunakan su untuk menjadi root. Pastikan /data/data berisi nama file terenkripsi; jika tidak, ada sesuatu yang salah.

Produsen perangkat juga didorong untuk mengeksplorasi menjalankan pengujian Linux upstream untuk fscrypt pada perangkat atau kernel mereka. Tes ini adalah bagian dari rangkaian pengujian sistem file xfstests. Namun, pengujian upstream ini tidak didukung secara resmi oleh Android.

Detail implementasi AOSP

Bagian ini memberikan detail tentang implementasi AOSP dan menjelaskan cara kerja enkripsi berbasis file. Produsen perangkat tidak perlu melakukan perubahan apa pun di sini untuk menggunakan FBE dan Direct Boot di perangkat mereka.

enkripsi fscrypt

Implementasi AOSP menggunakan enkripsi "fscrypt" (didukung oleh ext4 dan f2fs) di kernel dan biasanya dikonfigurasi untuk:

• Enkripsi konten file dengan AES-256 dalam mode XTS
• Enkripsi nama file dengan AES-256 dalam mode CBC-CTS

Enkripsi Adiantum juga didukung. Saat enkripsi Adiantum diaktifkan, isi file dan nama file dienkripsi dengan Adiantum.

fscrypt mendukung dua versi kebijakan enkripsi: versi 1 dan versi 2. Versi 1 sudah tidak digunakan lagi, dan persyaratan CDD untuk perangkat yang diluncurkan dengan Android 11 dan lebih tinggi hanya kompatibel dengan versi 2. Kebijakan enkripsi versi 2 menggunakan HKDF-SHA512 untuk memperoleh kunci enkripsi dari kunci yang disediakan oleh ruang pengguna.

Untuk informasi lebih lanjut tentang fscrypt, lihat dokumentasi kernel upstream .

Kelas penyimpanan

Tabel berikut mencantumkan kunci FBE dan direktori yang dilindungi secara lebih rinci:

Penyimpanan dan perlindungan kunci

Semua kunci FBE dikelola oleh vold dan disimpan dalam disk terenkripsi, kecuali kunci per-boot yang tidak disimpan sama sekali. Tabel berikut mencantumkan lokasi penyimpanan berbagai kunci FBE:

Seperti yang ditunjukkan pada tabel sebelumnya, sebagian besar kunci FBE disimpan di direktori yang dienkripsi dengan kunci FBE lainnya. Kunci tidak dapat dibuka kuncinya hingga kelas penyimpanan yang memuatnya dibuka kuncinya.

vold juga menerapkan lapisan enkripsi untuk semua kunci FBE. Setiap kunci selain kunci CE untuk penyimpanan internal dienkripsi dengan AES-256-GCM menggunakan kunci Keystore -nya sendiri yang tidak diekspos di luar TEE. Ini memastikan bahwa kunci FBE tidak dapat dibuka kecuali sistem operasi terpercaya telah melakukan booting, seperti yang diberlakukan oleh Verified Boot . Resistansi rollback juga diminta pada kunci Keystore, yang memungkinkan kunci FBE dihapus dengan aman pada perangkat yang didukung Keymaster untuk resistansi rollback. Sebagai fallback upaya terbaik saat resistensi rollback tidak tersedia, hash SHA-512 dari 16384 byte acak yang disimpan dalam file secdiscardable yang disimpan di samping kunci digunakan sebagai tag ID aplikasi dari kunci Keystore. Semua byte ini perlu dipulihkan untuk memulihkan kunci FBE.

Kunci CE untuk penyimpanan internal menerima tingkat perlindungan yang lebih kuat yang memastikan kunci tidak dapat dibuka tanpa mengetahui Faktor Pengetahuan Layar Kunci (LSKF) pengguna (PIN, pola, atau kata sandi), token reset kode sandi yang aman , atau kedua sisi klien dan kunci sisi server untuk operasi Resume-on-Reboot . Token penyetelan ulang kode sandi hanya boleh dibuat untuk profil kerja dan perangkat yang dikelola sepenuhnya .

Untuk mencapai hal ini, vold mengenkripsi setiap kunci CE untuk penyimpanan internal menggunakan kunci AES-256-GCM yang berasal dari kata sandi sintetik pengguna. Kata sandi sintetik adalah rahasia kriptografi entropi tinggi yang tidak dapat diubah yang dihasilkan secara acak untuk setiap pengguna. LockSettingsService di system_server mengelola kata sandi sintetis dan cara perlindungannya.

Untuk melindungi kata sandi sintetik dengan LSKF, LockSettingsService pertama-tama merentangkan LSKF dengan meneruskannya scrypt , menargetkan waktu sekitar 25 ms dan penggunaan memori sekitar 2 MiB. Karena LSKF biasanya pendek, langkah ini biasanya tidak memberikan banyak keamanan. Lapisan keamanan utama adalah Elemen Aman (SE) atau pembatasan tarif yang diberlakukan TEE yang dijelaskan di bawah ini.

Jika perangkat memiliki Elemen Aman (SE), maka LockSettingsService memetakan LSKF yang diregangkan ke rahasia acak entropi tinggi yang disimpan di SE menggunakan Weaver HAL . LockSettingsService kemudian mengenkripsi kata sandi sintetik dua kali: pertama dengan kunci perangkat lunak yang diturunkan dari LSKF yang diregangkan dan rahasia Weaver, dan kedua dengan kunci Keystore yang tidak terikat autentikasi. Hal ini memberikan pembatasan nilai tebakan LSKF yang diberlakukan oleh SE.

Jika perangkat tidak memiliki SE, maka LockSettingsService malah menggunakan LSKF yang diregangkan sebagai kata sandi Gatekeeper . LockSettingsService kemudian mengenkripsi kata sandi sintetik dua kali: pertama dengan kunci perangkat lunak yang berasal dari LSKF yang direntangkan dan hash dari file yang dapat dibuang, dan kedua dengan kunci Keystore yang terikat autentikasi ke pendaftaran Gatekeeper. Hal ini memberikan pembatasan nilai tebakan LSKF yang diberlakukan TEE.

Saat LSKF diubah, LockSettingsService menghapus semua informasi yang terkait dengan pengikatan kata sandi sintetik ke LSKF lama. Pada perangkat yang mendukung kunci Keystore yang tahan Weaver atau rollback, ini menjamin penghapusan pengikatan lama dengan aman. Untuk alasan ini, perlindungan yang dijelaskan di sini diterapkan meskipun pengguna tidak memiliki LSKF.