Enkripsi Berbasis File

Android 7.0 dan lebih tinggi mendukung enkripsi berbasis file (FBE). Enkripsi berbasis file memungkinkan file 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.

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

Booting Langsung

Enkripsi berbasis file mengaktifkan fitur baru yang diperkenalkan di Android 7.0 yang disebut Direct Boot . Direct Boot memungkinkan perangkat terenkripsi untuk melakukan booting langsung ke layar kunci. Sebelumnya, pada perangkat yang dienkripsi menggunakan enkripsi disk penuh (FDE), pengguna perlu memberikan kredensial sebelum data apa pun dapat diakses, sehingga 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 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. Hal 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 Terenkripsi Perangkat (DE), yaitu 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 terlindungi secara bersamaan karena enkripsi tidak lagi hanya didasarkan pada kata sandi waktu boot.

Direct Boot API memungkinkan aplikasi yang sadar enkripsi mengakses setiap area ini. Terdapat perubahan pada siklus hidup aplikasi untuk mengakomodasi kebutuhan memberi tahu aplikasi saat penyimpanan CE pengguna dibuka kuncinya sebagai respons saat kredensial pertama kali dimasukkan 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 perangkat tersebut 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 pada perangkat yang memenuhi persyaratan. Produsen yang memilih untuk menggunakan FBE mungkin ingin mencari cara untuk mengoptimalkan fitur berdasarkan system on chip (SoC) yang digunakan.

Semua paket yang diperlukan di AOSP telah diperbarui agar dapat melakukan boot langsung. Namun, jika produsen perangkat menggunakan versi khusus dari aplikasi ini, mereka ingin memastikan setidaknya ada paket yang mendukung 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 enkripsi berbasis file, di mana vold ( system/vold ) menyediakan fungsionalitas untuk mengelola perangkat penyimpanan dan volume 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 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)*
  • Pengaturan Aplikasi (paket/aplikasi/Pengaturan)*
  • SystemUI (kerangka/basis/paket/SystemUI)*

* Aplikasi sistem yang menggunakan atribut manifes defaultToDeviceProtectedStorage

Contoh lebih lanjut dari aplikasi dan layanan yang peka terhadap enkripsi dapat ditemukan dengan menjalankan perintah mangrep directBootAware di direktori kerangka kerja atau paket pada 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 khusus yang di-flash ke perangkat) tidak dapat meminta kunci DE begitu saja.
  • Root of Trust Perangkat Keras dan Boot Terverifikasi 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, telepon, 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 (Cryptography Extensions) dapat diaktifkan dengan mengatur 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 sedang dalam perjalanan ke/dari perangkat penyimpanan. Kernel umum Android (versi 4.14 dan lebih tinggi) berisi kerangka kerja yang memungkinkan enkripsi inline digunakan ketika dukungan perangkat keras dan driver vendor tersedia. Kerangka enkripsi inline 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 pengaktifannya di penyimpanan internal ( userdata ). Hal ini juga secara otomatis mengaktifkan FBE pada penyimpanan yang dapat diadopsi; namun, format enkripsi pada penyimpanan yang dapat diadopsi dapat diganti jika diperlukan.

Penyimpanan internal

FBE diaktifkan dengan menambahkan opsi fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] ke kolom fs_mgr_flags pada 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. Bisa berupa aes-256-xts atau adiantum . Sejak Android 11 juga dapat dikosongkan untuk menentukan algoritma default, yaitu aes-256-xts .
  • Parameter filenames_encryption_mode menentukan algoritma kriptografi mana yang digunakan untuk mengenkripsi nama file. Bisa berupa aes-256-cts , aes-256-heh , adiantum , atau aes-256-hctr2 . Jika tidak ditentukan, nilai defaultnya adalah aes-256-cts jika contents_encryption_mode adalah aes-256-xts , atau ke adiantum jika contents_encryption_mode adalah adiantum .
  • Parameter flags , yang 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. 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 kunci dalam jumlah besar secara efisien. Hal ini dilakukan dengan hanya memperoleh satu kunci enkripsi konten file per kunci CE atau DE, bukan satu kunci per file. Pembuatan IV (vektor inisialisasi) disesuaikan.
    • Bendera emmc_optimized mirip dengan inlinecrypt_optimized , tetapi ia 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 oleh karena itu 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 IV 64-bit.
    • Pada perangkat yang mendukung kunci yang dibungkus perangkat keras , flag wrappedkey_v0 memungkinkan penggunaan kunci yang dibungkus perangkat keras untuk FBE. Ini hanya dapat digunakan bersama dengan opsi mount inlinecrypt , dan flag inlinecrypt_optimized atau emmc_optimized .
    • Bendera dusize_4k memaksa ukuran unit data enkripsi menjadi 4096 byte bahkan ketika ukuran blok sistem file bukan 4096 byte. Ukuran unit data enkripsi adalah rincian enkripsi isi file. Flag ini tersedia sejak Android 15 (eksperimental AOSP). Tanda ini hanya boleh digunakan untuk mengaktifkan penggunaan perangkat keras enkripsi inline yang tidak mendukung unit data yang lebih besar dari 4096 byte, pada perangkat yang menggunakan ukuran halaman lebih besar dari 4096 byte dan yang menggunakan sistem file f2fs.

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 akselerasi AES dalam bentuk apa pun, Adiantum dapat digunakan sebagai pengganti AES dengan menyetel fileencryption=adiantum .

Sejak Android 14, AES-HCTR2 adalah mode enkripsi nama file pilihan untuk perangkat dengan instruksi kriptografi yang dipercepat. Namun, hanya kernel Android terbaru yang mendukung AES-HCTR2. Di rilis Android mendatang, rencananya akan menjadi mode default untuk enkripsi nama file. Jika kernel Anda memiliki dukungan AES-HCTR2, maka dapat diaktifkan untuk enkripsi nama file dengan mengatur 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 diterapkan oleh kernel umum Android, namun dapat diterapkan oleh vendor yang menggunakan patch kernel khusus. Format pada disk yang dihasilkan oleh mode ini spesifik 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 pemasangan 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 secara bersamaan.

Menentukan opsi fileencryption fstab 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 mengatur 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 pada opsi fileencryption fstab, dan menggunakan default yang sama. Lihat rekomendasi fileencryption di 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 .

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 kolom ro.crypto.volume.options pertama yang dipisahkan titik dua.
  • ro.crypto.volume.filenames_mode memilih mode enkripsi nama file. Ini setara dengan kolom ro.crypto.volume.options kedua yang dipisahkan titik dua, 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 memilih 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 . Hal ini karena FBE mengharuskan Keymaster siap menangani permintaan pada fase booting 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 terenkripsi seperti direktori yang berisi kunci DE sistem itu sendiri dan direktori yang berisi direktori pengguna CE atau DE. 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 melalui argumen encryption=<action> ke perintah mkdir dalam skrip init. Kemungkinan nilai <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 versi lebih lama, 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 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 untuk hal ini adalah untuk mendukung kemampuan OTA yang lama.

Mendukung Direct Boot dalam aplikasi sistem

Membuat aplikasi Direct Boot sadar

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 orang.

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

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

Atribut defaultToDeviceProtectedStorage mengalihkan lokasi penyimpanan aplikasi default ke penyimpanan DE, bukan ke penyimpanan CE. Aplikasi sistem yang menggunakan tanda ini harus mengaudit dengan cermat 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 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-rekannya yang Dilindungi Perangkat.

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

Mendukung banyak pengguna

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

Aplikasi yang sadar kripto berinteraksi antar pengguna dengan cara berikut: INTERACT_ACROSS_USERS dan INTERACT_ACROSS_USERS_FULL memungkinkan aplikasi bertindak di seluruh pengguna di perangkat. Namun, aplikasi tersebut hanya dapat mengakses direktori terenkripsi CE untuk pengguna yang sudah membuka kuncinya.

Sebuah aplikasi mungkin dapat berinteraksi secara bebas di seluruh area DE, namun satu pengguna yang tidak terkunci tidak berarti 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. Ketika tantangan kerja terpenuhi, pengguna profil tidak terkunci dan Keymaster (di 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 pengoperasian normal, tidak diperlukan pemulihan untuk mengakses data pada drive terenkripsi.

Saat menggunakan solusi OTA lama, 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 Mengecualikan direktori ).
  3. Buat direktori di dalam direktori tingkat atas untuk menampung 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 diterapkan 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. 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 memverifikasi bahwa penyimpanan CE dikunci sebelum perangkat dibuka kuncinya untuk pertama kalinya sejak booting. Untuk melakukannya, gunakan userdebug atau eng build, atur PIN, pola, atau kata sandi pada pengguna utama, dan reboot perangkat. Sebelum membuka kunci perangkat, jalankan perintah berikut untuk memeriksa penyimpanan CE pengguna utama. Jika perangkat menggunakan Mode Pengguna Sistem Tanpa Kepala (sebagian besar perangkat Otomotif), pengguna utamanya adalah pengguna 10, maka jalankan:

adb root; adb shell ls /data/user/10

Di perangkat lain (sebagian besar perangkat non-Otomotif), pengguna utamanya adalah pengguna 0, jadi jalankan:

adb root; adb shell ls /data/user/0

Verifikasi bahwa nama file yang terdaftar berkode Base64, yang menunjukkan bahwa nama file dienkripsi dan kunci untuk mendekripsinya belum tersedia. Jika nama file dicantumkan dalam teks biasa, berarti ada yang salah.

Produsen perangkat juga didorong untuk menjajaki pengujian upstream Linux 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 rincian 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 pada 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. Ketika enkripsi Adiantum diaktifkan, konten file dan nama file dienkripsi dengan Adiantum.

fscrypt mendukung dua versi kebijakan enkripsi: versi 1 dan versi 2. Versi 1 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 mendapatkan kebijakan enkripsi sebenarnya kunci enkripsi dari kunci yang disediakan ruang pengguna.

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

Kelas penyimpanan

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

Kelas penyimpanan Keterangan Direktori
Tidak terenkripsi Direktori di /data yang tidak bisa atau tidak perlu dilindungi oleh FBE. Pada perangkat yang menggunakan enkripsi metadata , direktori ini tidak benar-benar tidak terenkripsi melainkan dilindungi oleh kunci enkripsi metadata yang setara dengan System DE.
  • /data/apex , tidak termasuk /data/apex/decompressed dan /data/apex/ota_reserved yang merupakan sistem DE
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Semua direktori yang subdirektorinya menggunakan kunci FBE berbeda. Misalnya, karena setiap direktori /data/user/${user_id} menggunakan kunci per pengguna, /data/user tidak menggunakan kunci itu sendiri.
Sistem DE Data yang dienkripsi perangkat tidak terikat dengan pengguna tertentu
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • Semua subdirektori /data lain yang tidak disebutkan dalam tabel ini memiliki kelas yang berbeda
Per-boot File sistem sementara yang tidak perlu bertahan saat reboot /data/per_boot
Pengguna CE (internal) Data terenkripsi kredensial per pengguna di penyimpanan internal
  • /data/data (alias /data/user/0 )
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
Pengguna DE (internal) Data terenkripsi perangkat per pengguna di penyimpanan internal
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
Pengguna CE (dapat diadopsi) Data terenkripsi kredensial per pengguna pada penyimpanan yang dapat diadopsi
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
Pengguna DE (dapat diadopsi) Data terenkripsi perangkat per pengguna pada penyimpanan yang dapat diadopsi
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

Penyimpanan dan perlindungan kunci

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

Jenis kunci Lokasi kunci Kelas penyimpanan lokasi utama
Kunci sistem DE /data/unencrypted Tidak terenkripsi
Kunci CE pengguna (internal). /data/misc/vold/user_keys/ce/${user_id} Sistem DE
Kunci DE (internal) pengguna /data/misc/vold/user_keys/de/${user_id} Sistem DE
Kunci CE pengguna (dapat diadopsi). /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} Pengguna CE (internal)
Kunci DE pengguna (dapat diadopsi). /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} Pengguna DE (internal)

Seperti yang ditunjukkan pada tabel sebelumnya, sebagian besar kunci FBE disimpan di direktori yang dienkripsi oleh kunci FBE lain. Kunci tidak dapat dibuka kuncinya hingga kelas penyimpanan yang berisi kunci tersebut telah dibuka kuncinya.

vold juga menerapkan lapisan enkripsi ke semua kunci FBE. Setiap kunci selain kunci CE untuk penyimpanan internal dienkripsi dengan AES-256-GCM menggunakan kunci Keystore sendiri yang tidak diekspos di luar TEE. Hal ini memastikan bahwa kunci FBE tidak dapat dibuka kecuali sistem operasi tepercaya telah melakukan booting, seperti yang diterapkan oleh Verified Boot . Resistensi rollback juga diminta pada kunci Keystore, yang memungkinkan kunci FBE dihapus dengan aman pada perangkat di mana Keymaster mendukung resistensi rollback. Sebagai upaya terbaik untuk melakukan fallback ketika resistensi rollback tidak tersedia, hash SHA-512 sebesar 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 tersebut tidak dapat dibuka tanpa mengetahui Faktor Pengetahuan Layar Kunci (LSKF) (PIN, pola, atau kata sandi) pengguna, token pengaturan ulang kode sandi yang aman , atau keduanya di 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 sintetis pengguna. Kata sandi sintetis adalah rahasia kriptografi entropi tinggi yang tidak dapat diubah dan dibuat secara acak untuk setiap pengguna. LockSettingsService di system_server mengelola kata sandi sintetis dan cara perlindungannya.

Untuk melindungi kata sandi sintetis dengan LSKF, LockSettingsService pertama-tama memperluas LSKF dengan meneruskannya melalui 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 Pembatasan tarif yang diberlakukan Elemen Aman (SE) atau TEE yang dijelaskan di bawah.

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 sintetis dua kali: pertama dengan kunci perangkat lunak yang berasal dari LSKF yang diregangkan dan rahasia Weaver, dan kedua dengan kunci Keystore yang tidak terikat autentikasi. Hal ini memberikan pembatasan laju tebakan LSKF yang diberlakukan SE.

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

Ketika LSKF diubah, LockSettingsService menghapus semua informasi yang terkait dengan pengikatan kata sandi sintetis ke LSKF lama. Pada perangkat yang mendukung kunci Weaver atau Keystore yang tahan rollback, hal ini menjamin penghapusan pengikatan lama dengan aman. Oleh karena itu, perlindungan yang dijelaskan di sini diterapkan meskipun pengguna tidak memiliki LSKF.