Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Enkripsi Berbasis File

Android 7.0 dan lebih tinggi mendukung enkripsi berbasis file (FBE). Enkripsi berbasis file memungkinkan file yang berbeda untuk 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 seaman mungkin kepada pengguna.

Booting Langsung

Enkripsi berbasis file memungkinkan fitur baru yang diperkenalkan di Android 7.0 yang disebut Direct Boot . Direct Boot memungkinkan perangkat terenkripsi untuk melakukan 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 kecuali operasi yang paling dasar. Misalnya, alarm tidak dapat beroperasi, layanan aksesibilitas tidak tersedia, dan telepon tidak dapat menerima panggilan tetapi dibatasi hanya untuk pengoperasian dialer darurat dasar.

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

Pada perangkat berkemampuan 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 Device Encrypted (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 sekaligus karena enkripsi tidak lagi hanya didasarkan pada kata sandi waktu booting.

Direct Boot API memungkinkan aplikasi yang peka enkripsi untuk mengakses setiap area ini. Ada perubahan pada siklus hidup aplikasi untuk mengakomodasi kebutuhan untuk memberi tahu aplikasi ketika penyimpanan CE pengguna dibuka sebagai respons untuk memasukkan kredensial pertama kali di layar kunci, atau dalam kasus profil kerja yang memberikan tantangan kerja . Perangkat yang menjalankan Android 7.0 harus mendukung API dan siklus proses baru ini terlepas dari apakah mereka mengimplementasikan 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 di 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 menjadi sadar boot langsung. Namun, jika produsen perangkat menggunakan versi yang disesuaikan dari aplikasi ini, mereka akan ingin memastikan setidaknya ada paket yang sadar boot langsung yang menyediakan layanan berikut:

  • Layanan Teleponi dan Dialer
  • Metode masukan untuk memasukkan kata sandi ke layar kunci

Contoh dan sumber

Android menyediakan implementasi referensi dari enkripsi berbasis file, di mana vold ( system / vold ) menyediakan fungsionalitas untuk mengelola perangkat dan volume penyimpanan di Android. Penambahan FBE memberi vold 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 / Pemanggil)
  • Jam Meja (paket / aplikasi / DeskClock)
  • LatinIME (paket / metode input / LatinIME) *
  • Aplikasi Pengaturan (paket / aplikasi / Pengaturan) *
  • SystemUI (kerangka kerja / 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 kerangka atau direktori paket dari pohon sumber AOSP.

Dependensi

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 2.0. Tidak ada dukungan untuk Keymaster 0.3 karena itu 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 khusus yang di-flash ke perangkat) tidak bisa begitu saja meminta kunci DE.
  • Akar Perangkat Keras Kepercayaan dan Boot Terverifikasi yang terikat ke 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 yang dienkripsi dengan kredensial daripada penyimpanan yang dienkripsi dengan perangkat.

Penerapan

Pertama dan terpenting, aplikasi seperti jam alarm, ponsel, 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 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 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 (Cryptography Extensions) 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 dalam perjalanan ke / dari perangkat penyimpanan. Kernel umum Android (versi 4.14 dan yang lebih tinggi) berisi kerangka kerja yang memungkinkan enkripsi inline digunakan saat dukungan driver hardware dan vendor tersedia. Kerangka kerja enkripsi sebaris dapat diaktifkan dengan mengatur 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. Ini bisa berupa aes-256-xts atau adiantum . Sejak Android 11, ini juga dapat dikosongkan untuk menentukan algoritme default, yaitu aes-256-xts .
  • Parameter filenames_encryption_mode menentukan algoritma kriptografi mana yang digunakan untuk mengenkripsi nama file. Ini bisa 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 .
  • 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 derivasi kunci yang lebih aman dan fleksibel. Default-nya 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 sebaris yang tidak menangani kunci dalam jumlah besar secara efisien. Hal ini dilakukan dengan mendapatkan hanya satu kunci enkripsi konten file per kunci CE atau DE, bukan satu per file. Pembangkitan IV (vektor inisialisasi) disesuaikan.
    • Flag 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 IV 32-bit. Pada perangkat keras enkripsi sebaris lainnya, gunakan inlinecrypt_optimized sebagai gantinya. Bendera ini tidak boleh digunakan di penyimpanan berbasis UFS; spesifikasi UFS memungkinkan penggunaan IV 64-bit.
    • Bendera yang wrappedkey_v0 memungkinkan penggunaan kunci yang dibungkus perangkat keras. Saat diaktifkan, kunci FBE tidak dibuat oleh perangkat lunak, melainkan dibuat oleh Keymaster menggunakan tag STORAGE_KEY . Kemudian, setiap kunci FBE yang sebenarnya disediakan ke kernel adalah kunci STORAGE_KEY diekspor dari Keymaster, yang menyebabkan kunci tersebut dibungkus dengan kunci efemeral per boot. Kernel kemudian menyediakan kunci yang dibungkus langsung ke perangkat keras enkripsi sebaris. Jika diterapkan dengan benar, kunci yang tidak dibungkus tidak pernah ada dalam memori sistem, dan kunci terbungkus yang disusupi tidak dapat digunakan setelah reboot. inlinecrypt ini memerlukan dukungan perangkat keras, dukungan Keymaster untuk STORAGE_KEY , dukungan driver kernel, opsi pemasangan inlinecrypt , dan tanda 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 sebaris pengaturan yang disarankan untuk sebagian besar perangkat adalah fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (atau yang 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 bisa diterapkan oleh vendor yang menggunakan tambalan kernel khusus. Format di disk yang dihasilkan oleh mode ini 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, baris fstab lengkap mungkin terlihat seperti ini:

/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 fileencryption pilihan fstab untuk userdata juga secara otomatis memungkinkan kedua FBE dan enkripsi metadata pada penyimpanan adoptable. 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 ke opsi fstab fileencryption , dan menggunakan default yang sama. Lihat rekomendasi untuk fileencryption atas untuk mengetahui apa yang harus 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 sama dengan kolom pertama ro.crypto.volume.options dipisahkan oleh ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode memilih mode enkripsi nama file. Ini sama dengan kolom ro.crypto.volume.options dipisahkan titik dua, kecuali default pada perangkat yang diluncurkan dengan Android 10 atau lebih rendah adalah aes-256-heh . Di 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 .

Berintegrasi dengan Keymaster

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

Pada boot pertama, kunci pengguna 0 dibuat dan dipasang di awal proses boot. Pada saat fase on-post-fs dari init selesai, Keymaster harus siap untuk 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 pada 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 mereka 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 sistem DE key use 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

Anda dapat menambahkan pengecualian untuk mencegah direktori tertentu dienkripsi sama sekali. Jika modifikasi semacam ini dilakukan maka produsen perangkat harus menyertakan 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 kapabilitas OTA lama.

Mendukung Direct Boot dalam aplikasi sistem

Menyadari aplikasi Direct Boot

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

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

Atribut directBootAware di tingkat aplikasi adalah singkatan untuk menandai semua komponen dalam aplikasi sebagai peka enkripsi.

Atribut defaultToDeviceProtectedStorage mengarahkan ulang 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. Produsen perangkat yang menggunakan opsi ini harus memeriksa dengan cermat data yang mereka simpan untuk memastikan tidak ada informasi pribadi.

Saat menjalankan mode ini, API Sistem berikut tersedia untuk secara eksplisit mengelola Konteks yang didukung oleh penyimpanan CE saat diperlukan, yang setara dengan perangkat 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 ini adalah pengguna khusus. Ini relevan untuk penggunaan Administrasi Perangkat .

Aplikasi peka-kripto berinteraksi di seluruh 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 yang dienkripsi CE untuk pengguna yang sudah dibuka kuncinya.

Sebuah aplikasi mungkin dapat berinteraksi dengan bebas di seluruh area DE, tetapi satu pengguna yang 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 mendapat dua kunci: DE dan CE. Ketika tantangan kerja terpenuhi, pengguna profil tidak terkunci dan Keymaster (dalam TEE) dapat memberikan kunci TEE profil.

Menangani pembaruan

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

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. 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 diimplementasikan berfungsi sebagaimana mestinya, 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. Di 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 disetel ke file

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

Produsen perangkat juga didorong untuk mengeksplorasi menjalankan tes Linux hulu untuk fscrypt pada perangkat atau kernel mereka. Pengujian 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, konten file dan nama file dienkripsi dengan Adiantum.

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

Derivasi kunci

Kunci enkripsi berbasis file, yaitu 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 autentikasi
  • Kredensial yang direntangkan
  • "Hash yang dapat dipisahkan"

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

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

secdiscardable hash adalah 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 kuncinya 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 secara kriptografis terikat 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 sebenarnya digunakan untuk melakukan enkripsi, misalnya kunci per-file atau per-mode. Untuk kebijakan enkripsi versi 2, HKDF-SHA512 digunakan untuk ini.