Enkripsi Berbasis File

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. Bisa aes-256-xts atau adiantum. Sejak Android 11 juga dapat dibiarkan kosong untuk menentukan algoritma default, yaitu aes-256-xts.
• Parameter filenames_encryption_mode menentukan algoritma kriptografi digunakan untuk mengenkripsi nama file. Bisa aes-256-cts, aes-256-heh, adiantum, atau aes-256-hctr2. Jika tidak ditentukan, defaultnya adalah aes-256-cts jika contents_encryption_mode adalah aes-256-xts, atau ke adiantum jika contents_encryption_mode adalah adiantum.
• Parameter flags, baru di Android 11, adalah daftar tanda yang dipisahkan oleh + karakter. Tanda berikut didukung:
  • Tanda v1 memilih kebijakan enkripsi versi 1; tindakan Tanda v2 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 oleh ro.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 dengan inlinecrypt_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 pemasangan inlinecrypt, dan inlinecrypt_optimized atau emmc_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 (AOSP eksperimental). 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.

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 pada fileencryption fstab, dan menggunakan default yang sama. Lihat rekomendasi untuk fileencryption 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 dari ro.crypto.volume.options.
• ro.crypto.volume.filenames_mode memilih nama file mode enkripsi. Ini sama dengan isian kedua yang dipisahkan titik dua dari ro.crypto.volume.options, kecuali jika nilai default di perangkat yang diluncurkan dengan Android 10 atau yang lebih rendah aes-256-heh. Pada sebagian besar perangkat, hal ini harus secara eksplisit diganti menjadi aes-256-cts.
• ro.crypto.fde_algorithm dan ro.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 pasangannya yang Dilindungi oleh {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:

1. Buat direktori level 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 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 ro.crypto.type ada
  • Pastikan ro.crypto.type disetel ke file

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:

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:

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 memiliki Keymaster mendukung 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.