Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

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 dienkripsi menggunakan enkripsi full-disk (FDE), pengguna diperlukan untuk memberikan mandat sebelum data dapat diakses, mencegah telepon dari melakukan semua tapi yang paling dasar dari operasi. 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 berdasarkan 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 memberitahu aplikasi ketika penyimpanan CE pengguna dibuka dalam menanggapi kredensial masuk pertama di layar kunci, atau dalam kasus profil kerja memberikan tantangan kerja . Perangkat yang menjalankan Android 7.0 harus mendukung API dan siklus hidup baru ini terlepas dari apakah perangkat tersebut 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 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 ( sistem / vold ) menyediakan fungsionalitas untuk mengelola perangkat penyimpanan dan volume pada Android. Penambahan FBE menyediakan vold dengan beberapa perintah baru untuk mendukung manajemen kunci untuk kunci CE dan DE dari banyak pengguna. Selain inti perubahan untuk menggunakan enkripsi file berbasis kemampuan dalam kernel, banyak paket sistem termasuk lockscreen dan SystemUI telah dimodifikasi untuk mendukung FBE dan langsung Boot fitur. 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)*

* Sistem aplikasi yang menggunakan defaultToDeviceProtectedStorage atribut manifest

Lebih banyak contoh aplikasi dan layanan yang enkripsi menyadari dapat ditemukan dengan menjalankan perintah mangrep directBootAware dalam kerangka atau paket direktori 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.
  • Keymaster Dukungan dengan HAL versi 1.0 atau 2.0. Tidak ada dukungan untuk Keymaster 0.3 karena tidak menyediakan kemampuan yang diperlukan atau menjamin perlindungan yang memadai untuk kunci enkripsi.
  • Keymaster / Keystore dan Gatekeeper harus dilaksanakan dalam Trusted Execution Environment (TEE) untuk memberikan perlindungan untuk tombol DE sehingga OS tidak sah (custom OS melintas ke perangkat) tidak bisa hanya meminta kunci DE.
  • Hardware Akar Trust dan Boot Verified 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 subfolder. 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 Langsung Boot dokumentasi pengembang.

Dukungan Kernel

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

CONFIG_FS_ENCRYPTION=y

Untuk kernel yang lebih tua, penggunaan CONFIG_EXT4_ENCRYPTION=y jika perangkat Anda userdata filesystem Ext4, atau penggunaan CONFIG_F2FS_FS_ENCRYPTION=y jika perangkat Anda userdata filesystem adalah F2FS.

Jika perangkat Anda akan mendukung penyimpanan adoptable atau akan menggunakan enkripsi metadata pada penyimpanan internal, juga memungkinkan pilihan 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 inline hardware enkripsi, yang mengenkripsi / mendekripsi data saat itu 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 memungkinkan 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 fstab baris untuk userdata . Opsi ini menentukan format enkripsi pada penyimpanan internal. Ini berisi hingga tiga parameter yang dipisahkan titik dua:

  • The contents_encryption_mode mendefinisikan parameter yang algoritma kriptografi digunakan untuk isi file mengenkripsi. Hal ini dapat berupa aes-256-xts atau adiantum . Sejak Android 11 itu juga dapat dibiarkan kosong untuk menentukan algoritma default, yang aes-256-xts .
  • The filenames_encryption_mode mendefinisikan parameter yang algoritma kriptografi digunakan untuk nama file mengenkripsi. Hal ini dapat berupa aes-256-cts , aes-256-heh , atau adiantum . Jika tidak ditentukan, standarnya ke aes-256-cts jika contents_encryption_mode adalah aes-256-xts , atau untuk adiantum jika contents_encryption_mode adalah adiantum .
  • The flags parameter, baru di Android 11, adalah daftar bendera dipisahkan oleh + karakter. Bendera berikut didukung:
    • The v1 kebijakan versi 1 enkripsi bendera menyeleksi; yang v2 bendera menyeleksi versi 2 kebijakan enkripsi. Versi 2 kebijakan enkripsi menggunakan lebih aman dan fleksibel fungsi derivasi kunci . 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 menurunkan.
    • The inlinecrypt_optimized bendera memilih format enkripsi yang dioptimalkan untuk inline hardware enkripsi 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.
    • The emmc_optimized bendera mirip dengan inlinecrypt_optimized , tetapi juga memilih metode generasi IV yang batas infus untuk 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 inline lainnya, menggunakan 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 hardware-dibungkus , yang wrappedkey_v0 bendera memungkinkan penggunaan kunci hardware-dibungkus untuk FBE. Ini hanya dapat digunakan dalam kombinasi dengan inlinecrypt opsi mount, dan baik inlinecrypt_optimized atau emmc_optimized bendera.

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

Pada perangkat yang diluncurkan dengan Android 10 atau lebih rendah, fileencryption=ice juga diterima untuk menentukan penggunaan FSCRYPT_MODE_PRIVATE berkas mode enkripsi isi. 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 hardware enkripsi inline sebaliknya, juga menambahkan inlinecrypt pilihan me-mount. Misalnya, penuh fstab baris akan 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 adoptable dapat digunakan bersama-sama.

Menentukan fileencryption pilihan fstab untuk userdata juga secara otomatis memungkinkan kedua FBE dan enkripsi metadata pada penyimpanan adoptable. Namun, Anda mungkin menimpa FBE dan / atau format enkripsi metadata pada penyimpanan adoptable dengan menetapkan 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 FBE Format enkripsi pada penyimpanan adoptable. Ini memiliki sintaks yang sama sebagai argumen ke fileencryption pilihan fstab, dan menggunakan default yang sama. Lihat rekomendasi untuk fileencryption atas untuk apa yang akan digunakan di sini.
  • ro.crypto.volume.metadata.encryption memilih metadata Format enkripsi pada penyimpanan adoptable. 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 isi. Ini setara dengan bidang dipisahkan oleh titik dua pertama ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode memilih mode enkripsi nama file. Ini setara dengan bidang dipisahkan oleh titik dua kedua 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 secara eksplisit diganti untuk aes-256-cts .
  • ro.crypto.fde_algorithm dan ro.crypto.fde_sector_size pilih format enkripsi metadata pada penyimpanan adoptable. Lihat dokumentasi enkripsi metadata .

Mengintegrasikan dengan Keymaster

Generasi 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 dipasang di awal proses boot. Pada saat on-post-fs fase init selesai, Keymaster harus siap untuk menangani permintaan. Pada perangkat Pixel, ini ditangani dengan memiliki blok naskah memastikan Keymaster dimulai sebelum /data sudah terpasang.

Kebijakan enkripsi

Enkripsi berbasis file menerapkan kebijakan enkripsi di tingkat direktori. Ketika perangkat userdata partisi pertama kali diciptakan, struktur dan kebijakan dasar yang diterapkan oleh init script. 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 lebih tinggi, kebijakan enkripsi tidak lagi hardcoded ke lokasi terpusat, melainkan ditentukan oleh argumen untuk mkdir perintah dalam skrip init. Direktori dienkripsi dengan sistem DE penggunaan kunci encryption=Require , sedangkan direktori tidak terenkripsi (atau direktori yang subdirektori dienkripsi dengan kunci per-user) 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 ini semacam dibuat maka produsen perangkat harus mencakup kebijakan SELinux yang hanya memberikan akses ke aplikasi yang perlu menggunakan direktori 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. The defaultToDeviceProtectedStorage atribut hanya tersedia untuk aplikasi sistem. The directBootAware atribut tersedia untuk semua.

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

The directBootAware atribut di tingkat aplikasi adalah istilah untuk menandai semua komponen di dalam aplikasi sebagai enkripsi sadar.

The defaultToDeviceProtectedStorage atribut pengalihan lokasi penyimpanan aplikasi default ke titik di penyimpanan DE bukannya menunjuk 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 memeriksa dengan cermat 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. Hal ini terkait untuk Administrasi Perangkat kegunaan.

Aplikasi kripto-sadar berinteraksi di pengguna dengan cara ini: INTERACT_ACROSS_USERS dan INTERACT_ACROSS_USERS_FULL memungkinkan aplikasi untuk bertindak di semua pengguna pada 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 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 menerapkan FBE sangat dianjurkan untuk dukungan OTA menggunakan pembaruan sistem A / B . Karena OTA dapat diterapkan selama operasi normal, pemulihan tidak diperlukan untuk mengakses data pada drive terenkripsi.

Bila menggunakan warisan solusi OTA, yang membutuhkan pemulihan untuk mengakses file OTA pada userdata partisi:

  1. Buat direktori tingkat atas (misalnya misc_ne ) di userdata partisi.
  2. Menambahkan direktori tingkat atas ini untuk pengecualian kebijakan enkripsi (lihat kebijakan Enkripsi 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 dilaksanakan karya fitur sebagaimana dimaksud, pertama menjalankan banyak tes enkripsi CTS, seperti DirectBootHostTest dan EncryptionTest .

Jika perangkat menjalankan Android 11 atau lebih tinggi, juga menjalankan 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 tes manual berikut. Pada perangkat dengan FBE diaktifkan:

  • Periksa bahwa ro.crypto.state ada
    • Pastikan ro.crypto.state dienkripsi
  • Periksa bahwa ro.crypto.type ada
    • Pastikan ro.crypto.type diatur untuk file

Selain itu, penguji dapat boot userdebug misalnya dengan seperangkat lockscreen pada pengguna utama. Kemudian adb shell ke dalam perangkat dan penggunaan su untuk menjadi root. Pastikan /data/data berisi nama file dienkripsi; jika tidak, ada sesuatu yang salah.

Produsen perangkat juga didorong untuk mengeksplorasi menjalankan tes Linux hulu 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 hulu .

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"

Auth Token adalah cryptographically dikonfirmasi tanda yang dihasilkan oleh Gatekeeper ketika pengguna berhasil login. TEE akan menolak untuk menggunakan kunci kecuali token otentikasi yang benar diberikan. Jika pengguna tidak memiliki kredensial, maka tidak ada token autentikasi yang digunakan atau diperlukan.

Credential yang membentang adalah credential pengguna setelah pengasinan dan peregangan dengan scrypt algoritma. Credential sebenarnya hash sekali dalam layanan kunci pengaturan sebelum dilewatkan ke vold untuk melewati ke scrypt . Ini cryptographically terikat pada kunci dalam TEE dengan semua jaminan yang berlaku untuk KM_TAG_APPLICATION_ID . Jika pengguna tidak memiliki kredensial, maka kredensial yang diregangkan tidak digunakan atau diperlukan.

The secdiscardable hash adalah hash 512-bit dari file 16 KB acak disimpan di samping informasi lain yang digunakan untuk merekonstruksi kunci, seperti benih. 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 cryptographically terikat pada kunci dalam 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.