Enkripsi berbasis file

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 diwajibkan untuk menggunakan enkripsi berbasis file.

Direct Boot

Enkripsi berbasis file mengaktifkan fitur baru yang diperkenalkan di Android 7.0 yang disebut Direct Boot. Booting 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 yang paling dasar. Misalnya, alarm tidak dapat beroperasi, layanan aksesibilitas tidak tersedia, dan ponsel tidak dapat menerima panggilan, tetapi terbatas hanya pada operasi dialer 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 pengguna pribadi.

Di perangkat yang mendukung 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 Di-Enkripsi 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 hanya didasarkan 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 dibuka kuncinya sebagai respons terhadap pertama kali memasukkan kredensial di layar kunci, atau dalam kasus profil kerja menyediakan 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. Namun, 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 diupdate agar mendukung booting langsung. Namun, jika produsen perangkat menggunakan versi aplikasi ini yang disesuaikan, 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, yang di dalamnya vold (system/vold) menyediakan fungsi untuk mengelola perangkat penyimpanan dan volume di Android. Penambahan FBE memberi vold beberapa perintah baru untuk mendukung pengelolaan kunci bagi kunci CE dan DE 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:

• Aplikasi Telepon AOSP (packages/apps/Dialer)
• Jam Meja (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Aplikasi Setelan (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

* Aplikasi sistem yang menggunakan atribut manifes defaultToDeviceProtectedStorage

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

Dependensi

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

• Dukungan Kernel untuk enkripsi Ext4 atau enkripsi F2FS.
• Dukungan KeyMint (atau Keymaster 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.
• KeyMint/Keymaster 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 dengan mudah.
• Root of Trust Hardware dan Booting Terverifikasi yang terikat dengan inisialisasi KeyMint diperlukan untuk memastikan bahwa kunci DE tidak dapat diakses oleh sistem operasi yang tidak sah.

Implementasi

Pertama-tama, aplikasi seperti jam alarm, telepon, 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 yang lebih 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 diadaptasi 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 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 juga dapat mempertimbangkan untuk menerapkan hardware enkripsi inline, yang mengenkripsi/mendekripsi data saat data sedang dalam perjalanan menuju/dari perangkat penyimpanan. Kernel umum Android (versi 4.14 dan yang lebih baru) berisi framework yang memungkinkan enkripsi inline digunakan jika dukungan hardware dan driver 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 memerlukan pengaktifannya 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 di penyimpanan internal. String ini berisi hingga tiga parameter yang dipisahkan dengan titik dua:

• Parameter contents_encryption_mode menentukan algoritma kriptografi yang digunakan untuk mengenkripsi konten file. Nilainya dapat berupa aes-256-xts atau adiantum. Sejak Android 11, kolom ini juga dapat dibiarkan kosong untuk menentukan algoritma default, yaitu aes-256-xts.
• Parameter filenames_encryption_mode menentukan algoritma kriptografi 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 tanda 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 perolehan kunci yang lebih aman dan fleksibel. Defaultnya adalah v2 jika perangkat diluncurkan di Android 11 atau yang lebih tinggi (seperti yang ditentukan oleh ro.product.first_api_level), atau v1 jika perangkat diluncurkan di Android 10 dan yang lebih rendah.
  • Flag inlinecrypt_optimized memilih format enkripsi yang dioptimalkan untuk hardware enkripsi inline yang tidak menangani sejumlah besar kunci secara efisien. Hal ini dilakukan dengan mendapatkan hanya satu kunci enkripsi konten file per kunci CE atau DE, bukan satu per file. Pembuatan IV (vektor inisialisasi) disesuaikan sebagaimana mestinya.
  • Flag emmc_optimized mirip dengan inlinecrypt_optimized, tetapi juga memilih metode pembuatan IV yang membatasi IV hingga 32 bit. Tanda 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 sebagai gantinya. Flag ini tidak boleh digunakan pada penyimpanan berbasis UFS; spesifikasi UFS mengizinkan penggunaan IV 64-bit.
  • Di perangkat yang mendukung kunci yang di-wrap hardware, tanda wrappedkey_v0 memungkinkan penggunaan kunci yang di-wrap hardware untuk FBE. Opsi ini hanya dapat digunakan bersama dengan opsi pemasangan 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 fileencryption=::inlinecrypt_optimized yang setara). Di perangkat tanpa bentuk akselerasi AES apa pun, Adiantum dapat digunakan sebagai pengganti AES dengan menyetel fileencryption=adiantum.

Sejak Android 14, AES-HCTR2 adalah mode enkripsi nama file yang 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 akan menjadi mode default untuk enkripsi nama file. Jika kernel Anda memiliki dukungan AES-HCTR2, dukungan ini 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.

Di perangkat yang diluncurkan dengan Android 10 dan yang lebih rendah, 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 khusus vendor. Pada perangkat yang diluncurkan dengan Android 11 atau yang lebih tinggi, mode ini tidak lagi diizinkan dan format enkripsi standar harus digunakan sebagai gantinya.

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

Sejak Android 9, FBE dan penyimpanan yang dapat diadaptasi dapat digunakan bersama.

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

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

• ro.crypto.volume.options (baru di Android 11) memilih format enkripsi FBE di penyimpanan yang dapat diadaptasi. Sintaksisnya sama dengan argumen untuk opsi fstab fileencryption, dan menggunakan default yang sama. Lihat rekomendasi untuk fileencryption di atas untuk mengetahui apa yang harus 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 dan yang lebih lama, 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 dengan titik dua dari ro.crypto.volume.options, kecuali bahwa nilai default pada perangkat yang diluncurkan dengan Android 10 dan yang lebih lama adalah aes-256-heh. Di sebagian besar perangkat, setelan 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 KeyMint

HAL KeyMint harus dimulai sebagai bagian dari class early_hal. Hal ini karena FBE mengharuskan KeyMint 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 teratas /data, kecuali 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 berlaku untuk direktori dapat dikontrol oleh argumen encryption=<action> ke perintah mkdir dalam skrip init. Nilai <action> yang mungkin didokumentasikan dalam README untuk bahasa inisialisasi Android.

Di Android 10, tindakan enkripsi init dikodekan secara permanen 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 untuk hal ini adalah dalam mendukung kemampuan OTA lama.

Mendukung Direct Boot di aplikasi sistem

Membuat aplikasi mendukung Booting Langsung

Untuk memfasilitasi migrasi cepat aplikasi sistem, 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 bahwa data tersebut tidak berisi informasi pribadi.

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

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

Mendukung beberapa pengguna

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

Aplikasi yang mendukung kripto berinteraksi dengan pengguna dengan cara ini: INTERACT_ACROSS_USERS dan INTERACT_ACROSS_USERS_FULL memungkinkan aplikasi bertindak di semua pengguna di perangkat. Namun, aplikasi tersebut hanya dapat mengakses direktori yang dienkripsi CE untuk pengguna yang sudah dibuka kuncinya.

Aplikasi mungkin dapat berinteraksi secara 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 ini.

Setiap ID pengguna profil kerja juga mendapatkan dua kunci: DE dan CE. Jika tantangan kerja terpenuhi, pengguna profil akan dibuka kuncinya dan KeyMint (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. Konfigurasi direktori tingkat teratas ini agar tidak dienkripsi (lihat Mengecualikan direktori).
3. Buat direktori dalam direktori tingkat 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 mengakses direktori ini.

Validasi

Untuk memastikan fitur yang diterapkan berfungsi sebagaimana mestinya, jalankan terlebih dahulu banyak pengujian enkripsi CTS, 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 dikunci 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 reboot 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 Boot Langsung 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 sebenarnya dari kunci yang disediakan userspace.

Untuk mengetahui 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-boot yang tidak disimpan sama sekali. Tabel berikut mencantumkan lokasi tempat berbagai kunci FBE disimpan:

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 berisi kunci tersebut 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 miliknya sendiri yang tidak diekspos di luar TEE. Hal ini memastikan bahwa kunci FBE tidak dapat dibuka kuncinya kecuali jika sistem operasi tepercaya telah di-boot, sebagaimana diterapkan oleh Booting Terverifikasi. Ketahanan terhadap rollback juga diminta pada kunci Keystore, yang memungkinkan kunci FBE dihapus dengan aman di perangkat tempat KeyMint mendukung ketahanan terhadap 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::APPLICATION_ID kunci Keystore. Semua byte ini harus dipulihkan untuk memulihkan kunci FBE.

Kunci CE untuk penyimpanan internal menerima tingkat perlindungan yang lebih kuat yang memastikan kunci tersebut tidak dapat dibuka kuncinya tanpa mengetahui Faktor Pengetahuan Layar Kunci (LSKF) pengguna (PIN, pola, atau sandi), token reset kode sandi yang aman, atau kunci sisi klien dan sisi server untuk operasi Lanjutkan saat Reboot. Token reset kode sandi hanya diizinkan untuk dibuat untuk profil kerja dan perangkat yang terkelola sepenuhnya.

Untuk mencapainya, vold mengenkripsi setiap kunci CE untuk penyimpanan internal menggunakan kunci AES-256-GCM yang berasal dari sandi sintetis pengguna. Sandi sintetis adalah rahasia kriptografi 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 terlebih dahulu meregangkan LSKF dengan meneruskannya melalui scrypt, yang menargetkan waktu sekitar 25 md dan penggunaan memori sekitar 2 MiB. Karena LSKF biasanya pendek, langkah ini biasanya tidak memberikan banyak keamanan. Lapisan keamanan utama adalah Secure Element (SE) atau pembatasan kecepatan yang diterapkan TEE yang dijelaskan di bawah.

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

Jika perangkat tidak memiliki SE, maka 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 dari file yang dapat dihapus dengan aman, dan kedua dengan kunci Keystore yang terikat dengan autentikasi pendaftaran Gatekeeper. Hal ini memberikan pembatasan kecepatan yang diterapkan TEE untuk tebakan LSKF.

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