Enkripsi berbasis file

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

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

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

Perhatian: Di Android 7.0 hingga 8.1, FBE tidak kompatibel dengan penyimpanan fleksibel, dan media penyimpanan eksternal (seperti kartu SD) hanya dapat digunakan sebagai penyimpanan tradisional. Di Android 9 dan yang lebih tinggi, FBE kompatibel dengan penyimpanan yang dapat diadopsi.

Direct Boot

Enkripsi berbasis file memungkinkan fitur baru yang diperkenalkan di Android 7.0 yang disebut Direct Boot. Boot Langsung memungkinkan perangkat terenkripsi melakukan booting langsung ke layar kunci. Sebelumnya, pada perangkat terenkripsi yang menggunakan enkripsi disk penuh (FDE), pengguna harus 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 ponsel tidak dapat menerima panggilan, tetapi hanya terbatas pada operasi pemanggil darurat dasar.

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

Di perangkat yang mengaktifkan FBE, setiap pengguna perangkat memiliki dua lokasi penyimpanan yang tersedia untuk aplikasi:

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

Catatan: Jika memungkinkan, file harus berada di penyimpanan CE.

Pemisahan ini membuat profil kerja lebih aman karena memungkinkan lebih dari satu pengguna dilindungi sekaligus karena enkripsi tidak lagi hanya didasarkan pada sandi waktu booting.

Direct Boot API memungkinkan aplikasi yang mendukung enkripsi mengakses setiap area ini. Ada perubahan pada siklus proses aplikasi untuk mengakomodasi kebutuhan untuk memberi tahu aplikasi saat penyimpanan CE pengguna dibuka kuncinya sebagai respons terhadap 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 menerapkan FBE atau tidak. Meskipun demikian, tanpa FBE, penyimpanan DE dan CE selalu dalam status tidak terkunci.

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

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

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

Contoh dan sumber

Android menyediakan implementasi referensi enkripsi berbasis file, dengan vold (system/vold) menyediakan fungsi untuk mengelola volume dan perangkat penyimpanan di Android. Penambahan FBE menyediakan beberapa perintah baru guna mendukung pengelolaan kunci untuk kunci CE dan DE milik beberapa 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 mencakup:

• Telepon AOSP (paket/aplikasi/Pemanggil)
• Jam Meja (paket/aplikasi/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Aplikasi Setelan (paket/aplikasi/Setelan)*
• SystemUI (framework/dasar/paket/SystemUI)*

* Aplikasi sistem yang menggunakan atribut manifes defaultToDeviceProtectedStorage

Contoh aplikasi dan layanan lainnya yang mendukung enkripsi dapat ditemukan dengan menjalankan perintah mangrep directBootAware di direktori framework atau paket dari hierarki sumber AOSP.

Dependensi

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

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

Implementasi

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

Dukungan kernel

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

CONFIG_FS_ENCRYPTION=y

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

Jika perangkat Anda mendukung penyimpanan yang dapat diadopsi atau menggunakan enkripsi metadata di 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, di perangkat berbasis ARM64, akselerasi ARMv8 CE (Cryptography Extensions) dapat diaktifkan dengan menetapkan opsi konfigurasi kernel berikut:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Untuk meningkatkan performa dan mengurangi penggunaan daya lebih lanjut, produsen perangkat juga dapat mempertimbangkan untuk menerapkan hardware enkripsi inline, yang mengenkripsi/mendekripsi data saat dalam perjalanan ke/dari perangkat penyimpanan. Kernel umum Android (versi 4.14 dan yang lebih baru) berisi framework yang memungkinkan enkripsi inline digunakan saat dukungan driver hardware dan vendor tersedia. Framework enkripsi inline dapat diaktifkan dengan menetapkan 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

Aktifkan enkripsi berbasis file

Pengaktifan FBE di perangkat mengharuskan pengaktifannya di penyimpanan internal (userdata). Tindakan ini juga otomatis mengaktifkan FBE di 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 pada baris fstab untuk userdata. Opsi ini menentukan format enkripsi pada penyimpanan internal. File ini berisi hingga tiga parameter yang dipisahkan titik dua:

• Parameter contents_encryption_mode menentukan algoritma kriptografis yang digunakan untuk mengenkripsi konten file. Nilainya dapat berupa aes-256-xts atau adiantum. Mulai Android 11, parameter ini juga dapat dibiarkan kosong untuk menentukan algoritma default, yaitu aes-256-xts.
• Parameter filenames_encryption_mode menentukan algoritma kriptografis yang digunakan untuk mengenkripsi nama file. Dapat 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 adiantum jika contents_encryption_mode adalah adiantum.
• Parameter flags, yang baru di Android 11, adalah daftar flag yang dipisahkan oleh karakter +. Tanda berikut didukung:
  • Tanda v1 memilih kebijakan enkripsi versi 1; tanda 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 di Android 11 atau yang lebih tinggi (sebagaimana ditentukan oleh ro.product.first_api_level), atau v1 jika perangkat diluncurkan di Android 10 atau yang lebih rendah.
  • Tanda inlinecrypt_optimized memilih format enkripsi yang dioptimalkan untuk hardware enkripsi inline yang tidak menangani kunci dalam jumlah besar secara efisien. Hal ini dilakukan dengan memperoleh hanya satu kunci enkripsi konten file per kunci CE atau DE, bukan satu per file. Pembuatan IV (vektor inisialisasi) disesuaikan.
  • Flag emmc_optimized mirip dengan inlinecrypt_optimized, tetapi juga memilih metode pembuatan IV yang membatasi IV hingga 32 bit. Flag ini hanya boleh digunakan pada hardware enkripsi inline yang sesuai dengan spesifikasi JEDEC eMMC v5.2, sehingga hanya mendukung IV 32 bit. Pada hardware enkripsi inline lainnya, gunakan inlinecrypt_optimized sebagai gantinya. Flag ini tidak boleh digunakan di penyimpanan berbasis UFS; spesifikasi UFS memungkinkan penggunaan IV 64-bit.
  • Pada perangkat yang mendukung tombol yang digabungkan di hardware, flag wrappedkey_v0 memungkinkan penggunaan tombol yang digabungkan dengan hardware untuk FBE. Ini hanya dapat digunakan bersama opsi pemasangan inlinecrypt, dan tanda inlinecrypt_optimized atau emmc_optimized.
  • Flag dusize_4k memaksa ukuran unit data enkripsi menjadi 4096 byte meskipun ukuran blok sistem file bukan 4096 byte. Ukuran unit data enkripsi adalah tingkat perincian enkripsi konten file. Flag ini tersedia sejak Android 15. Tanda ini hanya boleh digunakan untuk mengaktifkan penggunaan hardware enkripsi inline yang tidak mendukung unit data yang berukuran lebih besar dari 4.096 byte, pada perangkat yang menggunakan ukuran halaman lebih besar dari 4.096 byte dan yang menggunakan sistem file f2fs.

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

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

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

Perhatian: Karena opsi fileencryption menentukan format dalam disk, opsi tersebut tidak dapat diubah oleh OTA.

Secara default, enkripsi konten file dilakukan menggunakan API kriptografi kernel Linux. Jika Anda ingin menggunakan hardware 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

Catatan:

• Opsi inlinecrypt dan fileencryption berada di kolom yang berbeda, karena inlinecrypt adalah opsi pemasangan sistem file, sedangkan fileencryption adalah flag untuk ruang pengguna Android.
• Jika hardware enkripsi inline Anda berfungsi dengan benar dan tanda wrappedkey_v0 tidak ditetapkan, opsi pemasangan inlinecrypt dapat ditambahkan atau dihapus kapan saja tanpa menghapus total perangkat. Dengan kata lain, kecuali kunci yang digabungkan dengan hardware diaktifkan, inlinecrypt hanya akan memengaruhi implementasi, bukan format dalam disk. Anda harus menguji penghapusan inlinecrypt selama pengembangan untuk memverifikasi bahwa hardware enkripsi inline Anda berfungsi dengan benar.

Penyimpanan yang dapat diadopsi

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

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

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

• ro.crypto.volume.options (baru di Android 11) memilih format enkripsi FBE di penyimpanan yang dapat diadaptasi. Parameter ini memiliki sintaksis yang sama dengan argumen untuk opsi fstab fileencryption, dan menggunakan default yang sama. Lihat rekomendasi untuk fileencryption di atas untuk mengetahui apa yang akan digunakan di sini.
• ro.crypto.volume.metadata.encryption memilih format enkripsi metadata di penyimpanan yang dapat diadaptasi. Baca dokumentasi enkripsi metadata.

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

• ro.crypto.volume.contents_mode memilih mode enkripsi konten. Ini sama dengan kolom pertama yang dipisahkan titik dua dari ro.crypto.volume.options.
• ro.crypto.volume.filenames_mode memilih nama file mode enkripsi. Ini setara dengan kolom kedua yang dipisahkan titik dua dari ro.crypto.volume.options, kecuali bahwa default di perangkat yang diluncurkan dengan Android 10 atau yang lebih rendah adalah aes-256-heh. Di sebagian besar perangkat, hal ini harus 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.

Perhatian: Pada perangkat yang diluncurkan dengan Android 10 atau yang lebih lama, mode enkripsi nama file default pada penyimpanan yang dapat diadopsi tidak valid di sebagian besar perangkat, dan berbeda dengan mode default pada penyimpanan internal. Oleh karena itu, pada perangkat tersebut, nilai tersebut harus diganti secara eksplisit, biasanya untuk aes-256-cts.

Mengintegrasikan dengan Keymaster

HAL Keymaster harus dimulai sebagai bagian dari class early_hal. Hal ini karena FBE mewajibkan Keymaster siap menangani permintaan pada fase booting post-fs-data, yaitu saat vold menyiapkan kunci awal.

Kecualikan direktori

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Di Android 9 dan yang lebih lama, 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, produsen perangkat harus menyertakan kebijakan SELinux yang hanya memberikan akses ke aplikasi yang perlu menggunakan direktori yang tidak dienkripsi. Tindakan ini akan mengecualikan semua aplikasi yang tidak tepercaya.

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

Mendukung Direct Boot di aplikasi sistem

Membuat aplikasi sadar Booting Langsung

Untuk memfasilitasi migrasi aplikasi sistem yang cepat, ada dua atribut baru yang dapat ditetapkan 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 peka enkripsi.

Atribut defaultToDeviceProtectedStorage mengalihkan lokasi penyimpanan aplikasi default agar mengarah ke penyimpanan DE, bukan mengarah ke penyimpanan CE. Aplikasi sistem yang menggunakan tanda ini harus mengaudit semua data yang disimpan di lokasi default dengan cermat, dan mengubah jalur data sensitif untuk menggunakan penyimpanan CE. Perangkat yang diproduksi menggunakan opsi ini harus memeriksa data yang disimpannya dengan cermat untuk memastikan bahwa data tidak berisi informasi pribadi.

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

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

Mendukung banyak pengguna

Setiap pengguna di lingkungan multipengguna mendapatkan kunci enkripsi terpisah. Setiap pengguna mendapatkan dua kunci: kunci DE dan CE. Pengguna 0 harus login terlebih dahulu ke perangkat karena merupakan pengguna khusus. Hal ini relevan untuk penggunaan Administrasi Perangkat.

Aplikasi yang mendukung crypto berinteraksi di seluruh pengguna dengan cara ini: INTERACT_ACROSS_USERS dan INTERACT_ACROSS_USERS_FULL memungkinkan aplikasi bertindak di seluruh pengguna di perangkat. Namun, aplikasi tersebut hanya dapat mengakses direktori yang dienkripsi CE untuk pengguna yang sudah tidak terkunci.

Aplikasi mungkin dapat berinteraksi dengan bebas di seluruh area DE, tetapi satu pengguna yang tidak terkunci bukan berarti 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. Saat tantangan kerja terpenuhi, pengguna profil akan dibuka dan Keymaster (di TEE) dapat memberikan kunci TEE profil.

Menangani update

Partisi pemulihan tidak dapat mengakses penyimpanan yang dilindungi DE di partisi userdata. Perangkat yang menerapkan FBE sangat direkomendasikan untuk mendukung OTA menggunakan update sistem A/B. Karena OTA dapat diterapkan selama operasi normal, tidak perlu pemulihan untuk mengakses data di drive terenkripsi.

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

1. Buat direktori tingkat teratas (misalnya misc_ne) di partisi userdata.
2. Konfigurasikan direktori tingkat atas ini agar tidak dienkripsi (lihat Mengecualikan direktori).
3. Buat direktori di dalam direktori {i>level<i} teratas untuk menyimpan paket OTA.
4. Tambahkan aturan SELinux dan konteks file untuk mengontrol akses ke direktori ini dan kontennya. Hanya proses atau aplikasi yang menerima update OTA yang dapat membaca dan menulis ke direktori ini. Tidak ada aplikasi atau proses lain yang boleh memiliki akses ke direktori ini.

Validasi

Untuk memastikan versi fitur yang diterapkan berfungsi sebagaimana mestinya, jalankan berbagai uji enkripsi CTS terlebih dahulu, seperti DirectBootHostTest dan EncryptionTest.

Jika perangkat menjalankan Android 11 atau yang lebih baru, 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 yang mengaktifkan FBE:

• Memastikan ro.crypto.state ada
  • Pastikan ro.crypto.state dienkripsi
• Pastikan ro.crypto.type ada
  • Pastikan ro.crypto.type disetel ke file

Selain itu, penguji dapat memverifikasi bahwa penyimpanan CE terkunci sebelum perangkat terbuka kuncinya untuk pertama kalinya sejak booting. Untuk melakukannya, gunakan build userdebug atau eng, tetapkan PIN, pola, atau sandi pada pengguna utama, lalu mulai ulang perangkat. Sebelum membuka kunci perangkat, jalankan perintah berikut untuk memeriksa penyimpanan CE pengguna utama. Jika perangkat menggunakan Mode Pengguna Sistem Headless (sebagian besar perangkat Otomotif), pengguna utama adalah pengguna 10, jadi jalankan:

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

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

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

Pastikan nama file yang tercantum berenkode Base64, yang menunjukkan bahwa nama file telah dienkripsi dan kunci untuk mendekripsinya belum tersedia. Jika nama file tercantum dalam teks biasa, ada yang salah.

Produsen perangkat juga dianjurkan untuk mempelajari cara menjalankan pengujian Linux upstream untuk fscrypt di 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 penerapan 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. Jika enkripsi Adiantum diaktifkan, konten file dan nama file akan 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 yang lebih baru hanya kompatibel dengan versi 2. Kebijakan enkripsi versi 2 menggunakan HKDF-SHA512 untuk mendapatkan kunci enkripsi sebenarnya dari kunci yang disediakan ruang pengguna.

Untuk mengetahui informasi selengkapnya tentang fscrypt, lihat dokumentasi kernel upstream.

Kelas penyimpanan

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

Kelas penyimpanan	Deskripsi	Direktori
Tidak terenkripsi	Direktori di /data yang tidak dapat atau tidak perlu dilindungi oleh FBE. Pada perangkat yang menggunakan enkripsi metadata, direktori ini tidak sepenuhnya dienkripsi, tetapi dilindungi oleh kunci enkripsi metadata yang setara dengan System DE.	/data/apex, tidak termasuk /data/apex/decompressed dan /data/apex/ota_reserved yang merupakan DE sistem /data/lost+found /data/preloads /data/unencrypted Semua direktori yang subdirektorinya menggunakan kunci FBE yang berbeda. Misalnya, karena setiap direktori /data/user/${user_id} menggunakan kunci per pengguna, /data/user tidak menggunakan kunci itu sendiri.
Sistem DE	Data terenkripsi perangkat yang tidak terikat dengan pengguna tertentu	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor Semua subdirektori /data lainnya yang tidak disebutkan dalam tabel ini sebagai memiliki class yang berbeda
Per-booting	File sistem efemeral yang tidak perlu bertahan saat reboot	/data/per_boot
CE pengguna (internal)	Data yang dienkripsi dengan kredensial per pengguna di penyimpanan internal	/data/data (alias dari /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}
DE pengguna (internal)	Data per pengguna yang dienkripsi dengan perangkat di penyimpanan internal	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
CE Pengguna (dapat diadopsi)	Data yang dienkripsi dengan kredensial per pengguna di penyimpanan yang dapat diadaptasi	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
DE Pengguna (dapat diadopsi)	Data per pengguna yang dienkripsi dengan perangkat di 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 booting yang tidak disimpan sama sekali. Tabel berikut mencantumkan lokasi penyimpanan berbagai kunci FBE:

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

Seperti ditunjukkan dalam tabel sebelumnya, sebagian besar kunci FBE disimpan di direktori yang dienkripsi oleh kunci FBE lain. Kunci tidak dapat dibuka hingga kelas penyimpanan yang memuatnya 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 ditampilkan di luar TEE. Hal ini memastikan bahwa kunci FBE tidak dapat dibuka kuncinya kecuali jika sistem operasi tepercaya telah melakukan booting, seperti yang diterapkan oleh Booting Terverifikasi. Ketahanan rollback juga diminta di kunci Keystore, yang memungkinkan kunci FBE dihapus dengan aman di perangkat tempat Keymaster mendukung ketahanan rollback. Sebagai penggantian upaya terbaik saat ketahanan rollback tidak tersedia, hash SHA-512 dari 16384 byte acak yang disimpan dalam file secdiscardable yang disimpan bersama kunci digunakan sebagai tag ID aplikasi dari kunci Keystore. Semua byte ini perlu dipulihkan untuk memulihkan kunci FBE.

Kunci CE untuk penyimpanan internal menerima tingkat perlindungan yang lebih kuat yang memastikan kunci tidak dapat dibuka tanpa mengetahui Lock Screen Knowledge Factor (LSKF) pengguna (PIN, pola, atau sandi), token reset kode sandi yang aman, atau kunci sisi klien dan sisi server untuk operasi Resume-on-Reboot. Token reset 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 sandi sintetis pengguna. Sandi sintetis adalah rahasia kriptografis entropi tinggi yang tidak dapat diubah dan dibuat secara acak untuk setiap pengguna. LockSettingsService di system_server mengelola sandi sintetis dan cara sandi tersebut dilindungi.

Untuk melindungi sandi sintetis dengan LSKF, LockSettingsService pertama-tama merentangkan LSKF dengan meneruskannya melalui scrypt, dengan target waktu sekitar 25 milidetik dan penggunaan memori sekitar 2 MiB. Karena LSKF biasanya singkat, langkah ini biasanya tidak memberikan banyak keamanan. Lapisan utama keamanan adalah Pembatasan Tingkat Elemen Aman (SE) atau pembatasan kapasitas yang diterapkan TEE yang dijelaskan di bawah.

Jika perangkat memiliki Elemen Pengaman (SE), LockSettingsService akan memetakan LSKF yang diregangkan ke secret acak entropi tinggi yang disimpan di SE menggunakan Weaver HAL. LockSettingsService kemudian mengenkripsi sandi sintetis dua kali: pertama dengan kunci software yang berasal dari LSKF yang diregangkan dan secret Weaver, dan kedua dengan kunci Keystore yang tidak terikat autentikasi. Hal ini menyediakan pembatasan kapasitas yang diberlakukan SE untuk tebakan LSKF.

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

Saat LSKF diubah, LockSettingsService akan menghapus semua informasi yang terkait dengan binding sandi sintetis ke LSKF lama. Di perangkat yang mendukung kunci Keystore Weaver atau yang tahan rollback, hal ini memastikan penghapusan binding lama dengan aman. Oleh karena itu, perlindungan yang dijelaskan di sini diterapkan meskipun pengguna tidak memiliki LSKF.