Enkripsi berbasis file

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

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

Artikel ini menjelaskan cara mengaktifkan enkripsi berbasis file di perangkat baru dan cara aplikasi sistem dapat 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.

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, di 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 operasi 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 mengetahui 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.

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

Direct Boot API memungkinkan aplikasi yang peka enkripsi mengakses setiap area ini. Ada perubahan pada siklus proses aplikasi untuk mengakomodasi kebutuhan untuk memberi tahu aplikasi saat penyimpanan CE pengguna tidak terkunci 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 perangkat tersebut 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 di Project Open Source Android (AOSP) dan hanya perlu diaktifkan di 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 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 memberi vold beberapa perintah baru untuk mendukung pengelolaan kunci untuk kunci CE dan DE dari 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/Telepon)
• Desk Clock (paket/aplikasi/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Aplikasi Setelan (paket/aplikasi/Setelan)*
• SystemUI (frameworks/base/packages/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 kunci DE tidak dapat diakses oleh sistem operasi yang tidak sah.

Implementasi

Pertama-tama, aplikasi seperti jam alarm, ponsel, dan fitur aksesibilitas harus dibuat 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 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 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 kriptografis 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 lebih meningkatkan performa dan mengurangi penggunaan daya, produsen perangkat mungkin juga mempertimbangkan untuk menerapkan hardware enkripsi inline, yang mengenkripsi/mendekode data saat sedang 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

Mengaktifkan enkripsi berbasis file

Mengaktifkan FBE di perangkat mengharuskan pengaktifan di penyimpanan internal (userdata). Tindakan ini juga akan otomatis mengaktifkan FBE di penyimpanan yang dapat diadopsi; namun, format enkripsi di 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. Parameter 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, kolom 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 +. Flag berikut didukung:
  • Flag v1 memilih kebijakan enkripsi versi 1; flag v2 memilih kebijakan enkripsi versi 2. Kebijakan enkripsi versi 2 menggunakan fungsi derivasi kunci yang lebih aman dan fleksibel. Nilai 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.
  • Flag 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 mematuhi spesifikasi JEDEC eMMC v5.2 dan oleh karena itu hanya mendukung IV 32-bit. Pada hardware enkripsi inline lainnya, gunakan inlinecrypt_optimized. Flag ini tidak boleh digunakan di penyimpanan berbasis UFS; spesifikasi UFS memungkinkan penggunaan IV 64-bit.
  • Di perangkat yang mendukung kunci yang digabungkan hardware, tanda wrappedkey_v0 memungkinkan penggunaan kunci yang digabungkan hardware untuk FBE. Flag ini hanya dapat digunakan bersama dengan opsi mount inlinecrypt, dan flag 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 perincian enkripsi konten file. Flag ini tersedia sejak Android 15. Flag ini hanya boleh digunakan untuk mengaktifkan penggunaan hardware enkripsi inline yang tidak mendukung unit data yang lebih besar dari 4096 byte, di perangkat yang menggunakan ukuran halaman yang lebih besar dari 4096 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, kernel tersebut dapat diaktifkan untuk enkripsi 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 diterapkan oleh kernel umum Android, tetapi dapat diterapkan oleh vendor 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.

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

Penyimpanan yang dapat diadaptasi

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 di penyimpanan yang dapat diadopsi. Namun, Anda dapat mengganti format enkripsi FBE atau metadata 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. 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. Lihat 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 setara dengan kolom pertama yang dipisahkan titik dua dari ro.crypto.volume.options.
• ro.crypto.volume.filenames_mode memilih mode enkripsi nama file. Ini setara dengan kolom kedua yang dipisahkan titik dua dari ro.crypto.volume.options, kecuali bahwa default pada 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 di penyimpanan yang dapat diadaptasi. Lihat dokumentasi enkripsi metadata.

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.

Mengecualikan 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 diterapkan 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 di-enkripsi 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 untuk hal ini adalah untuk mendukung kemampuan OTA lama.

Mendukung Direct Boot di aplikasi sistem

Membuat aplikasi mendukung Direct Boot

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 untuk 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. Produsen perangkat yang menggunakan opsi ini harus memeriksa dengan cermat data yang mereka simpan untuk memastikan data tersebut tidak berisi informasi pribadi.

Saat berjalan dalam mode ini, System API berikut tersedia untuk mengelola Context yang didukung oleh penyimpanan CE secara eksplisit jika diperlukan, yang setara dengan System API Protected Device.

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

Mendukung beberapa pengguna

Setiap pengguna di lingkungan multipengguna mendapatkan kunci enkripsi terpisah. Setiap pengguna mendapatkan dua kunci: kunci DE dan CE. Pengguna 0 harus login ke perangkat terlebih dahulu karena adalah pengguna khusus. Hal ini relevan untuk penggunaan Pengelolaan 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 terenkripsi CE untuk pengguna yang telah dibuka kuncinya.

Aplikasi mungkin dapat berinteraksi dengan bebas di seluruh area DE, tetapi satu pengguna yang tidak terkunci tidak berarti semua pengguna di perangkat tidak terkunci. Aplikasi harus memeriksa status ini sebelum mencoba mengakses area tersebut.

Setiap ID pengguna profil kerja juga mendapatkan dua kunci: DE dan CE. Saat tantangan kerja terpenuhi, pengguna profil akan dibuka kuncinya 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 dalam direktori level 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 seharusnya 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 banyak pengujian 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 dengan FBE diaktifkan:

• 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 terkunci sebelum perangkat dibuka 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 dienkode dengan Base64, yang menunjukkan bahwa nama file 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 penerapan 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:

• Mengenkripsi konten file dengan AES-256 dalam mode XTS
• Mengenkripsi 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 tinggi hanya kompatibel dengan versi 2. Kebijakan enkripsi versi 2 menggunakan HKDF-SHA512 untuk mendapatkan kunci enkripsi yang sebenarnya dari kunci yang disediakan ruang pengguna.

Untuk informasi selengkapnya tentang fscrypt, lihat dokumentasi kernel upstream.

Kelas penyimpanan

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

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:

Seperti yang ditunjukkan dalam tabel sebelumnya, sebagian besar kunci FBE disimpan dalam direktori yang dienkripsi oleh kunci FBE lain. Kunci tidak dapat dibuka kuncinya hingga class penyimpanan yang berisinya 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-nya 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. Perlawanan rollback juga diminta pada kunci Keystore, yang memungkinkan kunci FBE dihapus dengan aman di perangkat tempat Keymaster mendukung perlawanan rollback. Sebagai penggantian upaya terbaik saat ketahanan rollback tidak tersedia, hash SHA-512 dari 16.384 byte acak yang disimpan dalam file secdiscardable yang disimpan bersama kunci digunakan sebagai Tag::APPLICATION_ID 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 diizinkan untuk dibuat untuk profil kerja dan perangkat terkelola 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 meregangkan LSKF dengan meneruskannya melalui scrypt, yang menargetkan waktu sekitar 25 md dan penggunaan memori sekitar 2 MiB. Karena LSKF biasanya singkat, langkah ini biasanya tidak memberikan banyak keamanan. Lapisan keamanan utama adalah 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 memberikan pembatasan kapasitas tebakan LSKF yang diterapkan SE.

Jika perangkat tidak memiliki SE, LockSettingsService akan menggunakan LSKF yang diregangkan 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 secara aman, dan kedua dengan kunci Keystore yang terikat autentikasi ke pendaftaran Gatekeeper. Hal ini memberikan pembatasan kapasitas tebakan LSKF yang diterapkan TEE.

Saat LSKF diubah, LockSettingsService akan menghapus semua informasi yang terkait dengan pengikatan 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.