Android 7.0 dan yang lebih tinggi mendukung enkripsi berbasis file (FBE). Enkripsi berbasis file memungkinkan file yang berbeda untuk dienkripsi dengan tombol berbeda yang dapat dibuka secara independen.
Artikel ini menjelaskan cara mengaktifkan enkripsi berbasis file di perangkat baru dan bagaimana aplikasi sistem bisa menggunakan Direct Boot API untuk menawarkan pengalaman terbaik dan paling aman.
Semua perangkat yang diluncurkan dengan Android 10 dan yang lebih tinggi yang diperlukan untuk menggunakan enkripsi berbasis file.
Direct Boot
Enkripsi berbasis file memungkinkan fitur baru yang diperkenalkan di Android 7.0 bernama Direct Booting. Direct Boot memungkinkan perangkat terenkripsi untuk melakukan booting langsung ke kunci layar. Sebelumnya, pada perangkat terenkripsi yang menggunakan disk penuh enkripsi (FDE), pengguna harus memberikan kredensial sebelum data apa pun diakses, mencegah ponsel melakukan semua hal kecuali yang paling dasar operasional bisnis. Sebagai contoh, alarm tidak dapat beroperasi, layanan aksesibilitas tidak tidak tersedia, dan telepon tidak dapat menerima panggilan tetapi dibatasi hanya untuk paket dasar operasi telepon darurat.
Dengan diperkenalkannya enkripsi berbasis file (FBE) dan API baru untuk aplikasi tersebut menggunakan enkripsi, aplikasi tersebut dapat beroperasi dalam konteks terbatas. Hal ini dapat terjadi sebelum pengguna memberikan kredensial, sambil tetap melindungi informasi pribadi pengguna.
Pada perangkat yang mendukung FBE, setiap pengguna perangkat memiliki dua lokasi penyimpanan yang tersedia untuk aplikasi:
- Penyimpanan Enkripsi Kredensial (CE), yang merupakan lokasi penyimpanan default dan hanya tersedia setelah pengguna membuka kunci perangkat.
- Penyimpanan yang Dienkripsi 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 dilindungi pada suatu waktu karena enkripsi tidak lagi didasarkan pada {i>password<i} waktu {i>booting<i}.
Direct Boot API memungkinkan aplikasi yang peka enkripsi untuk mengakses area tersebut. Ada perubahan pada siklus hidup aplikasi untuk mengakomodasi kebutuhan untuk memberi tahu aplikasi saat penyimpanan CE pengguna terbuka sebagai respons terhadap memasukkan kredensial terlebih dahulu di layar kunci, atau saat menggunakan profil kerja menyediakan kantor tantangan ini. Perangkat yang menjalankan Android 7.0 harus mendukung API baru dan terlepas dari apakah mereka menerapkan FBE atau tidak. Meskipun tanpa Penyimpanan FBE, DE, dan CE akan selalu dalam status tidak terkunci.
Implementasi lengkap enkripsi berbasis file pada {i>file<i} Ext4 dan F2FS tersedia dalam Proyek Open Source Android (AOSP) dan hanya perlu diaktifkan di perangkat yang memenuhi persyaratan. Produsen yang memilih untuk menggunakan FBE mungkin ingin mempelajari cara mengoptimalkan fitur berdasarkan sistem pada chip (SoC) yang digunakan.
Semua paket yang diperlukan dalam AOSP telah diupdate agar sadar booting langsung. Namun, jika produsen perangkat menggunakan versi aplikasi yang disesuaikan, kita ingin memastikan setidaknya ada paket {i>direct-boot <i}yang menyediakan layanan berikut:
- Layanan Telepon dan Telepon
- Metode input untuk memasukkan sandi ke layar kunci
Contoh dan sumber
Android menyediakan implementasi referensi enkripsi berbasis file, yang vold (sistem/vold) menyediakan fungsi untuk mengelola perangkat penyimpanan dan Android di Android. Penambahan FBE menyediakan vold dengan beberapa perintah baru untuk mendukung pengelolaan kunci untuk kunci CE dan DE milik beberapa pengguna. Selain itu perubahan inti menggunakan model berbasis file kapabilitas enkripsi dalam kernel, banyak paket sistem termasuk dan SystemUI telah dimodifikasi untuk mendukung FBE dan Direct Fitur booting. Ini mencakup:
- Telepon AOSP (paket/aplikasi/Pemanggil)
- Jam Meja (paket/aplikasi/DeskClock)
- LatinIME (paket/metode input/LatinIME)*
- Aplikasi Setelan (paket/aplikasi/Setelan)*
- SystemUI (framework/dasar/paket/SystemUI)*
* Aplikasi sistem yang menggunakan defaultToDeviceProtectedStorage
atribut manifes
Lebih banyak contoh aplikasi dan layanan
yang peka enkripsi dapat
ditemukan dengan menjalankan perintah mangrep directBootAware
di
direktori framework atau paket AOSP
dalam hierarki sumber.
Dependensi
Untuk menggunakan implementasi AOSP dari FBE secara aman, perangkat harus memenuhi dependensi berikut:
- Dukungan Kernel untuk enkripsi Ext4 atau enkripsi F2FS.
- Master Dukungan dengan HAL versi 1.0 atau yang lebih tinggi. Tidak ada dukungan untuk Keymaster 0.3 karena tidak memberikan kemampuan atau jaminan yang diperlukan perlindungan yang memadai untuk kunci enkripsi.
- Keymaster/Keystore dan Gatekeeper harus diterapkan dalam Trusted Execution Environment (TEE) untuk memberikan perlindungan bagi kunci DE sehingga tidak sah (OS khusus yang di-flash ke perangkat) tidak bisa begitu saja meminta Kunci DE.
- Hardware Root of Trust dan Booting Terverifikasi terikat dengan inisialisasi Keymaster diperlukan untuk memastikan bahwa kunci DE tidak dapat diakses oleh sistem operasi yang tidak resmi.
Implementasi
Pertama dan terpenting, aplikasi seperti jam alarm, ponsel, dan fitur aksesibilitas harus dibuat android:directBootAware sesuai dengan Booting dokumentasi developer.
Dukungan kernel
Dukungan kernel untuk enkripsi Ext4 dan F2FS tersedia di sistem operasi Android {i>kernel<i}, versi 3.18 dan yang lebih tinggi. Untuk mengaktifkannya pada kernel versi 5.1 atau yang lebih tinggi, gunakan:
CONFIG_FS_ENCRYPTION=y
Untuk kernel yang lebih lama, gunakan CONFIG_EXT4_ENCRYPTION=y
jika perangkat Anda
Sistem file userdata
adalah Ext4, atau gunakan
CONFIG_F2FS_FS_ENCRYPTION=y
jika userdata
perangkat Anda
sistem file adalah F2FS.
Apakah perangkat Anda dapat dapat digunakan penyimpanan atau akan menggunakan metadata enkripsi pada penyimpanan internal, juga mengaktifkan opsi konfigurasi kernel. yang diperlukan untuk enkripsi metadata seperti yang dijelaskan dalam dokumentasi enkripsi metadata.
Selain dukungan fungsional untuk enkripsi Ext4 atau F2FS, perangkat produsen 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 menyetel opsi konfigurasi kernel berikut:
CONFIG_CRYPTO_AES_ARM64_CE_BLK=y CONFIG_CRYPTO_SHA2_ARM64_CE=y
Untuk lebih meningkatkan performa dan mengurangi penggunaan daya, produsen perangkat mungkin pertimbangkan juga 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 tinggi) berisi kerangka kerja yang memungkinkan enkripsi {i>inline<i} digunakan ketika dukungan driver perangkat keras dan vendor yang tersedia. Framework enkripsi inline dapat diaktifkan dengan menyetel atribut opsi konfigurasi kernel berikut ini:
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 di perangkat mengharuskan Anda mengaktifkannya di penyimpanan internal
(userdata
). Tindakan ini juga otomatis mengaktifkan FBE di jaringan yang
penyimpanan; Namun, format enkripsi pada penyimpanan yang dapat
diadopsi dapat diabaikan
jika perlu.
Penyimpanan internal
FBE diaktifkan dengan menambahkan opsi
fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]]
ke kolom fs_mgr_flags dari baris fstab
untuk
userdata
. Opsi ini menentukan format enkripsi pada
Storage. File ini berisi hingga tiga parameter yang dipisahkan titik dua:
- Parameter
contents_encryption_mode
menentukan algoritma kriptografi digunakan untuk mengenkripsi konten file. Bisaaes-256-xts
atauadiantum
. Sejak Android 11 juga dapat dibiarkan kosong untuk menentukan algoritma default, yaituaes-256-xts
. - Parameter
filenames_encryption_mode
menentukan algoritma kriptografi digunakan untuk mengenkripsi nama file. Bisaaes-256-cts
,aes-256-heh
,adiantum
, atauaes-256-hctr2
. Jika tidak ditentukan, defaultnya adalahaes-256-cts
jikacontents_encryption_mode
adalahaes-256-xts
, atau keadiantum
jikacontents_encryption_mode
adalahadiantum
. - Parameter
flags
, baru di Android 11, adalah daftar tanda yang dipisahkan oleh+
karakter. Tanda berikut didukung:- Tanda
v1
memilih kebijakan enkripsi versi 1; tindakan Tandav2
memilih kebijakan enkripsi versi 2. Versi 2 kebijakan enkripsi menggunakan fungsi derivasi kunci yang lebih aman dan fleksibel. Defaultnya adalah v2 jika perangkat diluncurkan di Android 11 atau yang lebih baru (sebagaimana ditentukan olehro.product.first_api_level
), atau v1 jika perangkat yang diluncurkan pada Android 10 atau lebih rendah. - Tanda
inlinecrypt_optimized
memilih enkripsi format yang dioptimalkan untuk hardware enkripsi inline yang tidak menangani kunci dalam jumlah besar secara efisien. Hal ini dilakukan dengan mengambil hanya ada satu kunci enkripsi isi file per kunci CE atau DE, dan bukan satu per file. Pembuatan IV (vektor inisialisasi) disesuaikan. - Flag
emmc_optimized
mirip denganinlinecrypt_optimized
, tetapi juga memilih IV yang membatasi IV hingga 32 bit. Tanda ini hanya boleh digunakan pada hardware enkripsi inline yang mematuhi Spesifikasi JEDEC eMMC v5.2 dan karenanya hanya mendukung 32-bit IV. Pada hardware enkripsi inline lainnya, gunakan Sebagai gantinya,inlinecrypt_optimized
. Penanda ini tidak boleh digunakan pada penyimpanan berbasis UFS; spesifikasi UFS memungkinkan penggunaan IV 64-bit. - Di perangkat yang mendukung perangkat keras yang digabungkan
kunci, flag
wrappedkey_v0
memungkinkan penggunaan kunci yang dibungkus perangkat keras untuk FBE. Ini hanya dapat digunakan dalam kombinasi dengan opsi pemasanganinlinecrypt
, daninlinecrypt_optimized
atauemmc_optimized
penanda. - Tanda
dusize_4k
memaksa ukuran unit data enkripsi menjadi 4096 byte meskipun ukuran blok sistem file bukan 4096 {i>byte.<i} Ukuran unit data enkripsi adalah tingkat perincian file enkripsi konten. Tanda ini tersedia sejak Android 15. Penanda ini hanya boleh digunakan untuk mengaktifkan penggunaan perangkat keras enkripsi sebaris yang tidak mendukung data unit yang lebih besar dari 4096 byte, pada perangkat yang menggunakan ukuran halaman berukuran lebih besar dari 4096 byte dan menggunakan sistem file f2fs.
- Tanda
Jika Anda tidak menggunakan hardware enkripsi inline, setelan yang direkomendasikan untuk sebagian besar
perangkat adalah fileencryption=aes-256-xts
. Jika Anda menggunakan fungsi inline
perangkat keras enkripsi, pengaturan yang
disarankan untuk sebagian besar perangkat adalah
fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized
(atau yang setara dengan fileencryption=::inlinecrypt_optimized
). Aktif
perangkat tanpa akselerasi AES apa pun, sebaiknya gunakan Adiantum, bukan AES
menyetel fileencryption=adiantum
.
Sejak Android 14, AES-HCTR2 adalah mode yang lebih disukai untuk enkripsi nama file
untuk perangkat dengan petunjuk
kriptografi yang dipercepat. Namun, hanya kernel Android baru yang mendukung
AES-HCTR2. Dalam rilis Android mendatang, mode ini akan menjadi mode default untuk nama file
enkripsi. Jika {i>kernel<i} Anda mendukung AES-HCTR2, enkripsi nama file
dapat diaktifkan dengan
menyetel 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 yang lebih rendah,
fileencryption=ice
juga diterima untuk menentukan penggunaan
Mode enkripsi konten file FSCRYPT_MODE_PRIVATE
. Mode ini adalah
tidak diimplementasikan oleh {i>kernel<i} umum Android, tetapi itu dapat diimplementasikan oleh
vendor menggunakan {i>patch<i} {i>
kernel<i} khusus. Format dalam {i>disk <i}yang dihasilkan oleh mode ini
bergantung pada vendor. Pada perangkat yang diluncurkan dengan Android
11 atau lebih tinggi, mode ini tidak lagi diizinkan dan
format enkripsi standar harus digunakan.
Secara {i>default<i}, enkripsi isi file
dilakukan menggunakan paket
cryptography API. Jika Anda ingin menggunakan hardware enkripsi inline,
tambahkan opsi pemasangan inlinecrypt
. Misalnya,
Baris fstab
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 opsi fstab fileencryption
untuk
userdata
juga otomatis mengaktifkan FBE dan enkripsi metadata di aplikasi yang dapat diadopsi
Storage. Namun, Anda dapat mengganti format enkripsi FBE dan/atau metadata di
penyimpanan yang dapat diadaptasi
dengan mengatur properti di
PRODUCT_PROPERTY_OVERRIDES
.
Pada 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 yang dapat diadopsi. {i>Function<i} ini memiliki {i>syntax<i} yang sama dengan argumen padafileencryption
fstab, dan menggunakan default yang sama. Lihat rekomendasi untukfileencryption
di atas untuk hal yang dapat dilakukan gunakan di sini.ro.crypto.volume.metadata.encryption
memilih metadata format enkripsi pada penyimpanan yang dapat diadopsi. Lihat metadata dokumentasi enkripsi.
Pada perangkat yang diluncurkan dengan Android 10 atau yang lebih rendah, gunakan properti berikut:
ro.crypto.volume.contents_mode
memilih konten mode enkripsi. Ini sama dengan isian pertama yang dipisahkan titik dua dariro.crypto.volume.options
.ro.crypto.volume.filenames_mode
memilih nama file mode enkripsi. Ini sama dengan isian kedua yang dipisahkan titik dua dariro.crypto.volume.options
, kecuali jika nilai default di perangkat yang diluncurkan dengan Android 10 atau yang lebih rendahaes-256-heh
. Pada sebagian besar perangkat, hal ini harus secara eksplisit diganti menjadiaes-256-cts
.ro.crypto.fde_algorithm
danro.crypto.fde_sector_size
pilih enkripsi metadata format penyimpanan yang dapat diadaptasi. Lihat metadata dokumentasi enkripsi.
Mengintegrasikan dengan Keymaster
Keymaster HAL harus dimulai sebagai bagian dari class early_hal
.
Hal ini karena FBE mengharuskan Keymaster siap menangani permintaan oleh
Fase booting post-fs-data
, yaitu saat vold
disiapkan
kunci awal.
Mengecualikan direktori
init
menerapkan kunci DE sistem untuk
semua direktori tingkat atas dari /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
diterapkan secara rekursif dan tidak dapat diganti oleh subdirektori.
Di Android 11 dan lebih tinggi, kunci yang
init
yang berlaku untuk direktori yang dapat dikontrol oleh
Argumen encryption=<action>
ke mkdir
dalam skrip init. Kemungkinan nilai <action>
adalah
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 agar tidak tidak terenkripsi sama sekali. Jika modifikasi semacam ini dilakukan maka perangkat produsen harus menyertakan Kebijakan SELinux yang hanya memberikan akses ke aplikasi yang perlu menggunakan direktori yang tidak terenkripsi. Hal ini akan mengecualikan semua aplikasi yang tidak terpercaya.
Satu-satunya kasus penggunaan yang dapat diterima yang diketahui untuk hal ini adalah dukungan OTA lama kemampuan IT.
Mendukung Direct Boot pada aplikasi sistem
Membuat aplikasi sadar Booting Langsung
Untuk memfasilitasi migrasi cepat aplikasi sistem, ada dua atribut baru yang
yang dapat ditetapkan di tingkat aplikasi. Tujuan
Atribut defaultToDeviceProtectedStorage
hanya tersedia untuk
aplikasi sistem. Atribut directBootAware
tersedia untuk semua pengguna.
<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 default
ke penyimpanan DE dan bukan menunjuk ke penyimpanan CE.
Aplikasi sistem yang menggunakan tanda ini harus mengaudit semua data yang disimpan di setelan default dengan cermat
lokasi, dan mengubah jalur data
sensitif untuk menggunakan penyimpanan CE. Perangkat
diproduksi menggunakan opsi ini harus secara
cermat memeriksa data yang
untuk memastikan bahwa data itu tidak berisi informasi pribadi.
Saat berjalan dalam mode ini, System API berikut adalah tersedia untuk secara eksplisit mengelola Konteks yang didukung oleh penyimpanan CE jika diperlukan, yang setara dengan perangkat yang dilindungi {i>Device Protected<i}.
Context.createCredentialProtectedStorageContext()
Context.isCredentialProtectedStorage()
Mendukung banyak pengguna
Setiap pengguna dalam lingkungan multi-pengguna mendapatkan kunci enkripsi terpisah. Setiap pengguna memiliki dua kunci: sebuah kunci DE dan sebuah kunci CE. Pengguna 0 harus masuk ke perangkat terlebih dahulu sebagaimana adanya seorang pengguna khusus. Hal ini relevan untuk Perangkat Penggunaan Administrasi.
Aplikasi yang sadar kriptografis berinteraksi di seluruh pengguna dengan cara berikut:
INTERACT_ACROSS_USERS
dan INTERACT_ACROSS_USERS_FULL
memungkinkan aplikasi untuk bertindak
dengan semua pengguna pada perangkat. Namun,
aplikasi akan dapat mengakses direktori yang
dienkripsi CE untuk pengguna yang
sudah dibuka.
Sebuah aplikasi mungkin dapat berinteraksi dengan bebas di seluruh area DE, tetapi satu pengguna tidak terkunci tidak berarti bahwa semua pengguna di perangkat itu tidak terkunci. Tujuan 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, profil pengguna tidak terkunci dan Keymaster (di TEE) dapat memberikan kunci TEE profil.
Menangani update
Partisi pemulihan tidak dapat mengakses penyimpanan yang dilindungi DE di partisi {i>userdata<i}. Perangkat yang menerapkan FBE sangat direkomendasikan untuk mendukung OTA menggunakan update sistem A/B. Sebagai OTA dapat diterapkan selama operasi normal. Tidak perlu pemulihan untuk mengakses data yang ada di {i>drive<i} yang terenkripsi.
Saat menggunakan solusi OTA lama, yang memerlukan pemulihan untuk mengakses file OTA
pada partisi userdata
:
- Buat direktori level teratas (misalnya
misc_ne
) di Partisiuserdata
. - Konfigurasikan direktori tingkat atas ini agar tidak dienkripsi (lihat Mengecualikan direktori).
- Buat direktori di dalam direktori {i>level<i} teratas untuk menyimpan paket OTA.
- Tambahkan aturan SELinux dan konteks file untuk mengontrol akses ke direktori ini dan isinya. Hanya proses atau aplikasi yang menerima pembaruan OTA yang harus mampu membaca dan menulis ke direktori ini. Tidak ada aplikasi atau proses lain seharusnya memiliki akses ke direktori ini.
Validasi
Untuk memastikan versi fitur yang diterapkan berfungsi sebagaimana mestinya, pertama-tama jalankan berbagai uji 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 yang mengaktifkan FBE:
- Pastikan
ro.crypto.state
ada- Pastikan
ro.crypto.state
dienkripsi
- Pastikan
- Pastikan
ro.crypto.type
ada- Pastikan
ro.crypto.type
disetel kefile
- Pastikan
Selain itu, penguji dapat memverifikasi bahwa penyimpanan CE dikunci sebelum perangkat
tidak terkunci untuk
pertama kalinya sejak {i>booting<i}. Untuk melakukannya, gunakan
userdebug
atau eng
build, setel PIN, pola, atau
{i>password<i} pada pengguna utama, dan mulai ulang perangkat. Sebelum membuka kunci perangkat,
jalankan perintah berikut untuk memeriksa penyimpanan CE pengguna utama. Jika
perangkat menggunakan Headless System
Mode Pengguna (sebagian besar perangkat Automotive), pengguna utamanya adalah pengguna 10, jadi 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 tercantum berenkode Base64, yang menunjukkan bahwa nama file dienkripsi dan kunci untuk membongkarnya belum tersedia. Jika nama file tercantum dalam teks biasa, berarti ada yang salah.
Produsen perangkat juga didorong untuk menjalankan pengujian Linux upstream untuk fscrypt di perangkat mereka atau {i>kernel<i}. 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 enkripsi berbasis file bekerja. Produsen perangkat tidak perlu melakukan hal itu melakukan perubahan di sini untuk menggunakan FBE dan Direct Boot pada perangkat mereka.
enkripsi fscrypt
Implementasi AOSP menggunakan "fscrypt" enkripsi (didukung oleh ext4 dan f2fs) dalam 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 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 aktual dari kunci yang disediakan pengguna.
Untuk mengetahui informasi selengkapnya tentang fscrypt, lihat dokumentasi kernel upstream.
Kelas penyimpanan
Tabel berikut ini mencantumkan kunci FBE dan direktori yang dilindunginya detail:
Kelas penyimpanan | Deskripsi | Direktori |
---|---|---|
Tidak terenkripsi | Direktori di /data yang tidak boleh atau tidak harus
dilindungi oleh FBE. Di perangkat yang menggunakan metadata
enkripsi, direktori ini tidak sepenuhnya dienkripsi,
dilindungi oleh kunci enkripsi metadata
yang setara dengan
System DE. |
|
Sistem DE | Data yang dienkripsi dengan perangkat yang tidak terkait dengan pengguna tertentu |
|
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 |
|
DE pengguna (internal) | Data per pengguna yang dienkripsi dengan perangkat di penyimpanan internal |
|
CE Pengguna (dapat diadopsi) | Data yang dienkripsi dengan kredensial per pengguna di penyimpanan yang dapat diadaptasi |
|
Pengguna DE (dapat diadopsi) | Data yang dienkripsi perangkat per pengguna di penyimpanan yang dapat diadopsi |
|
Perlindungan dan penyimpanan kunci
Semua kunci FBE dikelola oleh vold
dan disimpan terenkripsi di dalam disk,
kecuali untuk kunci {i>per-boot<i} 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 (internal) pengguna | /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 (dapat diadopsi) pengguna | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} |
CE pengguna (internal) |
Kunci DE (dapat diadopsi) pengguna | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} |
DE pengguna (internal) |
Seperti ditunjukkan dalam tabel sebelumnya, sebagian besar kunci FBE disimpan dalam direktori yang dienkripsi oleh kunci FBE lain. Kunci tidak dapat dibuka hingga penyimpanan yang berisi file tersebut telah dibuka.
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 yang tidak
terbuka di luar TEE. Hal ini memastikan bahwa kunci FBE tidak
dapat dibuka kecuali jika
sistem operasi tepercaya telah melakukan booting, sebagaimana diterapkan oleh Booting Terverifikasi. Rollback
resistensi juga diminta pada kunci Keystore, yang memungkinkan kunci FBE untuk
dihapus dengan aman di perangkat yang didukung Keymaster pada ketahanan rollback. Sebagai
upaya terbaik ketika ketahanan rollback tidak tersedia, SHA-512
hash 16.384 byte acak yang disimpan di file secdiscardable
yang disimpan
di samping kunci digunakan sebagai ID aplikasi
pada kunci Keystore. Semua {i>byte<i} ini perlu
dipulihkan untuk memulihkan
Tombol FBE.
Kunci CE untuk penyimpanan internal menerima tingkat perlindungan yang lebih kuat yang memastikan kunci ini tidak dapat dibuka tanpa mengetahui Layar Kunci pengguna Knowledge Factor (LSKF) (PIN, pola, atau sandi), aman token reset kode sandi, atau kunci sisi klien dan sisi server untuk Operasi Resume-on-Reboot. Token reset kode sandi hanya boleh dibuat untuk profil kerja dan sepenuhnya perangkat terkelola.
Untuk mencapai hal ini, vold
mengenkripsi setiap kunci CE untuk penyimpanan internal
menggunakan kunci AES-256-GCM yang berasal dari sandi sintetis pengguna.
{i>Password<i} sintetis adalah rahasia
kriptografi entropi tinggi yang tidak dapat diubah
dibuat secara acak untuk setiap pengguna. LockSettingsService
inci
system_server
mengelola sandi sintetis dan cara
terlindungi.
Untuk melindungi {i>password<i}
sintetik dengan LSKF,
LockSettingsService
pertama-tama merentangkan LSKF dengan meneruskannya melalui
scrypt
, yang menargetkan waktu sekitar 25 milidetik dan
penggunaan memori sekitar 2 MiB. Karena LSKF biasanya pendek, langkah ini biasanya
tidak memberikan banyak keamanan. Lapisan utama keamanan adalah Sistem
Pembatasan kapasitas yang diberlakukan oleh Elemen (SE) atau TEE yang dijelaskan di bawah.
Jika perangkat memiliki Elemen Pengaman (SE), LockSettingsService
memetakan LSKF yang direntangkan ke secret acak entropi tinggi yang disimpan di SE menggunakan
Weaver HAL. LockSettingsService
lalu mengenkripsi
sandi sintetis dua kali: pertama dengan kunci perangkat lunak yang berasal dari
LSKF dan secret Weaver direntangkan, dan kedua dengan Keystore yang tidak terikat
tombol. Hal ini menyediakan pembatasan kapasitas yang diberlakukan SE untuk tebakan LSKF.
Jika perangkat tidak memiliki SE, LockSettingsService
sebagai gantinya
menggunakan LSKF yang direntangkan sebagai Gatekeeper
{i>password<i}. LockSettingsService
lalu mengenkripsi sandi sintetis
dua kali: pertama dengan kunci perangkat lunak
yang berasal dari LSKF yang direntangkan dan {i>hash<i} dari
file secdiscardable, dan kedua dengan kunci Keystore yang terikat dengan autentikasi
Pendaftaran Gatekeeper. Hal ini memberikan pembatasan kapasitas yang diberlakukan oleh TEE untuk tebakan LSKF.
Ketika LSKF diubah, LockSettingsService
akan menghapus semua
informasi yang terkait dengan pengikatan
sandi sintetis ke {i>password<i} lama
{i>LSKF<i}. Pada perangkat yang mendukung kunci Keystore yang tahan terhadap Weaver atau rollback,
menjamin penghapusan aman dari binding lama. Karena alasan ini, perlindungan
yang dijelaskan di sini diterapkan meskipun pengguna tidak memiliki LSKF.