Enkripsi Berbasis File

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

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

Boot Langsung

Enkripsi berbasis file memungkinkan 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 terbatas hanya pada pengoperasian telepon darurat dasar.

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

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

  • Penyimpanan Terenkripsi Kredensial (CE), yang merupakan lokasi penyimpanan default dan hanya tersedia setelah pengguna membuka kunci perangkat.
  • Penyimpanan Terenkripsi Perangkat (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 untuk dilindungi pada satu waktu karena enkripsi tidak lagi hanya didasarkan pada kata sandi waktu booting.

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 masuk di layar kunci, atau jika profil kerja 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 di Android Open Source Project (AOSP) dan hanya perlu diaktifkan pada perangkat yang memenuhi persyaratan. Produsen yang memilih untuk menggunakan FBE mungkin ingin mencari cara untuk mengoptimalkan fitur berdasarkan sistem pada chip (SoC) yang digunakan.

Semua paket yang diperlukan di AOSP telah diperbarui agar dapat melakukan booting langsung. Namun, di mana produsen perangkat menggunakan versi khusus dari aplikasi ini, mereka akan 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 layar kunci dan SystemUI telah dimodifikasi untuk mendukung fitur FBE dan Direct Boot. Ini termasuk:

  • AOSP Dialer (paket/aplikasi/Dialer)
  • Jam Meja (paket/aplikasi/DeskClock)
  • LatinIME (paket/metode masukan/LatinIME)*
  • Pengaturan Aplikasi (paket/aplikasi/Pengaturan)*
  • SystemUI (kerangka/basis/paket/SystemUI)*

* Aplikasi sistem yang menggunakan atribut manifes defaultToDeviceProtectedStorage

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

Ketergantungan

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

  • Dukungan Kernel untuk enkripsi Ext4 atau enkripsi F2FS.
  • Dukungan Keymaster dengan HAL versi 1.0 atau 2.0. 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 terhadap kunci DE sehingga OS yang tidak sah (OS kustom yang di-flash ke perangkat) tidak dapat begitu saja meminta kunci DE.
  • Akar Kepercayaan Perangkat Keras dan Boot Terverifikasi yang terikat pada inisialisasi keymaster diperlukan untuk memastikan bahwa kredensial Enkripsi Perangkat tidak dapat diakses oleh sistem operasi yang tidak sah.

Catatan : Kebijakan penyimpanan diterapkan ke folder dan semua subfoldernya. Produsen harus membatasi konten yang tidak terenkripsi ke folder OTA dan folder yang menyimpan kunci yang mendekripsi sistem. Sebagian besar konten harus berada di penyimpanan terenkripsi kredensial daripada penyimpanan terenkripsi perangkat.

Penerapan

Pertama dan terpenting, aplikasi seperti jam alarm, telepon, fitur aksesibilitas harus dibuat android:directBootAware menurut 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 data pengguna perangkat Anda adalah Ext4, atau gunakan userdata CONFIG_F2FS_FS_ENCRYPTION=y jika sistem file data pengguna perangkat Anda adalah userdata .

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 untuk menerapkan perangkat keras enkripsi inline , yang mengenkripsi/mendekripsi data saat sedang dalam perjalanan ke/dari perangkat penyimpanan. Kernel umum Android (versi 4.14 dan lebih tinggi) berisi kerangka kerja yang memungkinkan enkripsi sebaris digunakan saat dukungan perangkat keras dan driver vendor tersedia. Kerangka kerja enkripsi sebaris 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 pengguna ). 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 content_encryption_mode mendefinisikan algoritma kriptografi yang digunakan untuk mengenkripsi contents_encryption_mode file. Itu bisa berupa aes-256-xts atau adiantum . Sejak Android 11 juga dapat dibiarkan kosong untuk menentukan algoritme default, yaitu aes-256-xts .
  • Parameter filenames_encryption_mode mendefinisikan algoritma kriptografi yang digunakan untuk mengenkripsi nama file. Itu bisa berupa aes-256-cts , aes-256-heh , atau adiantum . Jika tidak ditentukan, defaultnya adalah aes-256-cts jika contents_encryption_mode adalah aes-256-xts , atau ke adiantum jika contents_encryption_mode adalah adiantum .
  • Parameter flags , baru di Android 11, adalah daftar flag yang dipisahkan oleh karakter + . Bendera berikut didukung:
    • Bendera v1 memilih kebijakan enkripsi versi 1; bendera v2 memilih kebijakan enkripsi versi 2. Kebijakan enkripsi versi 2 menggunakan fungsi derivasi kunci yang lebih aman dan fleksibel. Defaultnya 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. Generasi IV (vektor inisialisasi) disesuaikan.
    • Bendera emmc_optimized mirip dengan inlinecrypt_optimized , tetapi juga memilih metode pembuatan IV yang membatasi IV hingga 32 bit. Bendera ini hanya boleh digunakan pada perangkat keras enkripsi sebaris yang sesuai dengan spesifikasi JEDEC eMMC v5.2 dan oleh karena itu hanya mendukung infus 32-bit. Pada perangkat keras enkripsi sebaris lainnya, gunakan inlinecrypt_optimized sebagai gantinya. Bendera ini tidak boleh digunakan pada penyimpanan berbasis UFS; spesifikasi UFS memungkinkan penggunaan IV 64-bit.
    • Pada perangkat yang mendukung kunci yang dibungkus perangkat keras , tanda yang wrappedkey_v0 memungkinkan penggunaan kunci yang dibungkus perangkat keras untuk FBE. Ini hanya dapat digunakan dalam kombinasi dengan opsi pemasangan inlinecrypt , dan flag inlinecrypt_optimized atau emmc_optimized .

Jika Anda tidak menggunakan perangkat keras enkripsi sebaris, 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 akselerasi AES dalam bentuk apa pun, Adiantum dapat digunakan sebagai pengganti AES dengan menyetel fileencryption=adiantum .

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 diterapkan oleh kernel umum Android, tetapi dapat diterapkan oleh vendor menggunakan patch kernel kustom. Format pada disk yang dihasilkan oleh mode ini adalah khusus vendor. Pada perangkat yang diluncurkan dengan Android 11 atau lebih tinggi, mode ini tidak lagi diizinkan dan format enkripsi standar harus digunakan sebagai gantinya.

Secara default, enkripsi konten file dilakukan menggunakan API kriptografi kernel Linux. Jika Anda ingin menggunakan perangkat keras enkripsi inline, tambahkan juga opsi pemasangan inlinecrypt . Misalnya, garis 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 fileencryption untuk userdata pengguna 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 .

Pada 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 ke opsi fileencryption fstab, dan menggunakan default yang sama. Lihat rekomendasi untuk fileencryption di atas untuk apa yang harus digunakan di sini.
  • ro.crypto.volume.metadata.encryption memilih format enkripsi metadata pada penyimpanan yang dapat diadopsi. Lihat dokumentasi enkripsi metadata .

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

  • ro.crypto.volume.contents_mode memilih mode enkripsi konten. Ini setara dengan bidang pertama yang dipisahkan titik dua dari ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode memilih mode enkripsi nama file. Ini setara 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 ke 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

Pembuatan kunci dan pengelolaan keyring kernel ditangani oleh vold . Implementasi AOSP dari FBE mengharuskan perangkat mendukung Keymaster HAL versi 1.0 atau yang lebih baru. Tidak ada dukungan untuk versi sebelumnya dari Keymaster HAL.

Pada boot pertama, kunci 0 pengguna dibuat dan diinstal di awal proses boot. Pada saat fase on-post-fs init selesai, Keymaster harus siap menangani permintaan. Pada perangkat Pixel, ini ditangani dengan memiliki blok skrip yang memastikan Keymaster dimulai sebelum /data dipasang.

Kebijakan enkripsi

Enkripsi berbasis file menerapkan kebijakan enkripsi di tingkat direktori. userdata partisi data pengguna perangkat pertama kali dibuat, struktur dan kebijakan dasar diterapkan oleh skrip init . Skrip ini akan memicu pembuatan kunci CE dan DE pengguna pertama (pengguna 0) serta menentukan direktori mana yang akan dienkripsi dengan kunci ini. Saat pengguna dan profil tambahan dibuat, kunci tambahan yang diperlukan dibuat dan disimpan di keystore; kredensial dan lokasi penyimpanan perangkat dibuat dan kebijakan enkripsi menautkan kunci ini ke direktori tersebut.

Di Android 11 dan yang lebih tinggi, kebijakan enkripsi tidak lagi di-hardcode ke lokasi terpusat, melainkan ditentukan oleh argumen ke perintah mkdir dalam skrip init. Direktori yang dienkripsi dengan kunci DE sistem menggunakan encryption=Require , sedangkan direktori yang tidak terenkripsi (atau direktori yang subdirektorinya dienkripsi dengan kunci per pengguna) menggunakan encryption=None .

Di Android 10, kebijakan enkripsi di-hardcode ke lokasi ini:

/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 dibuat, maka produsen perangkat harus menyertakan kebijakan SELinux yang hanya memberikan akses ke aplikasi yang perlu menggunakan direktori yang tidak terenkripsi. Ini harus mengecualikan semua aplikasi yang tidak tepercaya.

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

Mendukung Direct Boot dalam aplikasi sistem

Membuat aplikasi menyadari Direct Boot

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

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

Atribut directBootAware pada tingkat 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 dengan hati-hati mengaudit semua data yang disimpan di lokasi default, dan mengubah jalur data sensitif untuk menggunakan penyimpanan CE. Pabrikan perangkat yang menggunakan opsi ini harus hati-hati memeriksa data yang mereka simpan untuk memastikan bahwa data tersebut tidak berisi 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 rekan yang Dilindungi Perangkat.

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

Mendukung banyak pengguna

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

Aplikasi sadar kripto berinteraksi antar pengguna dengan cara ini: INTERACT_ACROSS_USERS dan INTERACT_ACROSS_USERS_FULL memungkinkan aplikasi untuk bertindak di semua pengguna di perangkat. Namun, aplikasi tersebut hanya dapat mengakses direktori terenkripsi CE untuk pengguna yang telah dibuka kuncinya.

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

Setiap ID pengguna profil kerja juga mendapatkan dua kunci: DE dan CE. Ketika tantangan kerja terpenuhi, pengguna profil akan terbuka dan Keymaster (dalam TEE) dapat memberikan kunci TEE profil.

Menangani pembaruan

Partisi pemulihan tidak dapat mengakses penyimpanan yang dilindungi DE pada partisi data pengguna. Perangkat yang menerapkan 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 lama, yang memerlukan pemulihan untuk mengakses file userdata di partisi data pengguna:

  1. Buat direktori tingkat atas (misalnya misc_ne ) di partisi userdata .
  2. Tambahkan direktori tingkat atas ini ke pengecualian kebijakan enkripsi (lihat Kebijakan enkripsi di atas).
  3. Buat direktori di dalam direktori tingkat atas untuk menampung paket OTA.
  4. Tambahkan aturan SELinux dan konteks file untuk mengontrol akses ke folder ini dan isinya. Hanya proses atau aplikasi yang menerima pembaruan OTA yang dapat membaca dan menulis ke folder ini. Tidak ada aplikasi atau proses lain yang memiliki akses ke folder ini.

Validasi

Untuk memastikan versi fitur yang diterapkan berfungsi sebagaimana dimaksud, pertama-tama jalankan banyak tes 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. Pada perangkat dengan FBE diaktifkan:

  • 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 tes Linux upstream untuk fscrypt pada perangkat atau kernel mereka. Tes ini adalah bagian dari paket 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 seharusnya tidak perlu membuat 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, konten file dan nama file dienkripsi dengan Adiantum.

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

Derivasi kunci

Kunci enkripsi berbasis file, yang merupakan kunci 512-bit, disimpan dienkripsi oleh kunci lain (kunci AES-GCM 256-bit) yang disimpan di TEE. Untuk menggunakan kunci TEE ini, tiga persyaratan harus dipenuhi:

  • Token autentik
  • Kredensial yang terbentang
  • "Hash yang dapat dibuang"

Token autentikasi adalah token yang diautentikasi secara kriptografis yang dihasilkan oleh Gatekeeper ketika pengguna berhasil masuk. TEE akan menolak untuk menggunakan kunci kecuali jika token autentikasi yang benar diberikan. Jika pengguna tidak memiliki kredensial, maka tidak ada token autentikasi yang digunakan atau diperlukan.

Kredensial yang diregangkan adalah kredensial pengguna setelah pengasinan dan peregangan dengan algoritma scrypt . Kredensial sebenarnya di-hash sekali dalam layanan pengaturan kunci sebelum diteruskan ke vold untuk diteruskan ke scrypt . Ini terikat secara kriptografis ke kunci di TEE dengan semua jaminan yang berlaku untuk KM_TAG_APPLICATION_ID . Jika pengguna tidak memiliki kredensial, maka kredensial yang diregangkan tidak digunakan atau diperlukan.

secdiscardable hash 512-bit dari file 16 KB acak yang disimpan bersama informasi lain yang digunakan untuk merekonstruksi kunci, seperti seed. File ini dihapus dengan aman saat kunci dihapus, atau dienkripsi dengan cara baru; perlindungan tambahan ini memastikan penyerang harus memulihkan setiap bit dari file yang dihapus dengan aman ini untuk memulihkan kunci. Ini terikat secara kriptografis ke kunci di TEE dengan semua jaminan yang berlaku untuk KM_TAG_APPLICATION_ID .

Dalam kebanyakan kasus, kunci FBE juga menjalani langkah derivasi kunci tambahan di kernel untuk menghasilkan subkunci yang benar-benar digunakan untuk melakukan enkripsi, misalnya kunci per-file atau per-mode. Untuk kebijakan enkripsi versi 2, HKDF-SHA512 digunakan untuk ini.