Seperti sebagian besar software enkripsi disk dan file, enkripsi penyimpanan Android secara tradisional mengandalkan kunci enkripsi mentah yang ada di memori sistem sehingga enkripsi dapat dilakukan. Meskipun enkripsi dilakukan oleh hardware khusus, bukan oleh software, software umumnya masih perlu mengelola kunci enkripsi mentah.
Hal ini biasanya tidak dianggap sebagai masalah karena kunci tidak akan ada selama serangan offline, yang merupakan jenis serangan utama yang ingin dilindungi oleh enkripsi penyimpanan. Namun, ada keinginan untuk memberikan peningkatan perlindungan terhadap jenis serangan lainnya, seperti serangan cold boot, dan serangan online yang memungkinkan penyerang membocorkan memori sistem tanpa membahayakan perangkat sepenuhnya.
Untuk mengatasi masalah ini, Android 11 memperkenalkan dukungan untuk kunci yang digabungkan dengan hardware, jika dukungan hardware tersedia. Kunci yang dibungkus {i>hardware<i} adalah kunci penyimpanan yang hanya dikenal dalam bentuk mentah untuk perangkat keras khusus; perangkat lunak hanya melihat dan bekerja dengan kunci-kunci ini yang digabungkan (dienkripsi). Hardware ini harus dapat membuat dan mengimpor kunci penyimpanan, menggabungkan kunci penyimpanan dalam bentuk sementara dan jangka panjang, memperoleh subkunci, memprogram satu subkunci secara langsung ke dalam mesin kripto inline, dan menampilkan subkunci terpisah ke software.
Catatan: Inline crypto engine (atau inline encryption hardware) mengacu pada hardware yang mengenkripsi/mendekode data saat data sedang dalam perjalanan ke/dari perangkat penyimpanan. Biasanya ini adalah pengontrol host UFS atau eMMC yang mengimplementasikan ekstensi kripto yang ditentukan oleh spesifikasi JEDEC yang sesuai.
Desain
Bagian ini menyajikan desain fitur kunci yang digabungkan dengan hardware, termasuk dukungan hardware yang diperlukan untuk fitur tersebut. Diskusi ini berfokus pada enkripsi berbasis file (FBE), tetapi solusi ini juga berlaku untuk enkripsi metadata.
Salah satu cara untuk menghindari kebutuhan kunci enkripsi dalam memori sistem adalah dengan menyimpannya hanya di slot kunci sebuah mesin kripto {i>inline<i}. Namun, pendekatan ini mengalami beberapa masalah:
- Jumlah kunci enkripsi dapat melebihi jumlah slot kunci.
- Mesin kripto{i> inline<i} hanya dapat digunakan untuk mengenkripsi/mendekripsi blok penuh data pada {i>disk<i}. Namun, dalam kasus FBE, perangkat lunak masih harus dapat melakukan pekerjaan kriptografi lainnya seperti enkripsi nama file dan mendapatkan kunci pengenal. Software masih memerlukan akses ke kunci FBE mentah untuk melakukan pekerjaan lain ini.
Untuk menghindari masalah ini, kunci penyimpanan dibuat menjadi kunci yang digabungkan dengan hardware, yang hanya dapat dibuka lapisannya dan digunakan oleh hardware khusus. Hal ini memungkinkan kunci dalam jumlah tak terbatas untuk didukung. Di beberapa Selain itu, hierarki kunci dimodifikasi dan sebagian dipindahkan ke perangkat keras ini, yang memungkinkan sub-kunci dikembalikan ke perangkat lunak untuk tugas-tugas yang tidak dapat menggunakan mesin kripto inline.
Hierarki kunci
Kunci dapat diperoleh dari kunci lain menggunakan KDF (fungsi derivasi kunci) seperti HKDF, yang menghasilkan hierarki kunci.
Diagram berikut menggambarkan hierarki kunci yang umum untuk FBE ketika kunci yang digabungkan dengan hardware tidak digunakan:
Kunci class FBE adalah kunci enkripsi mentah yang diteruskan Android ke Linux {i>kernel<i} untuk membuka kunci kumpulan direktori terenkripsi tertentu, seperti penyimpanan yang dienkripsi dengan kredensial untuk pengguna Android tertentu. (Pada {i>kernel<i}, kunci tersebut disebut kunci master fscrypt.) Dari kunci ini, {i>kernel<i} memperoleh sub-kunci berikut:
- ID kunci. Ini tidak digunakan untuk enkripsi, namun merupakan nilai digunakan untuk mengidentifikasi kunci yang digunakan untuk file atau direktori tertentu terlindungi.
- Kunci enkripsi isi file
- Kunci enkripsi nama file
Sebaliknya, diagram berikut menggambarkan hierarki kunci untuk FBE ketika kunci yang digabungkan secara hardware:
Dibandingkan dengan kasus sebelumnya, tingkat tambahan telah ditambahkan ke hierarki kunci, dan kunci enkripsi konten file telah dipindahkan. Node root masih mewakili kunci yang diteruskan Android ke Linux untuk membuka kunci kumpulan direktori terenkripsi. Namun, sekarang kunci itu ada dalam bentuk yang singkat, dan agar dapat digunakan harus diteruskan ke perangkat keras khusus. Perangkat keras ini harus menerapkan dua antarmuka yang mengambil kunci yang digabungkan secara efemeral:
- Satu antarmuka untuk mendapatkan
inline_encryption_key
dan langsung memprogramnya ke dalam slot kunci mesin crypto inline. Hal ini memungkinkan file untuk dienkripsi/didekripsi tanpa perangkat lunak memiliki akses ke tombol. Dalam kernel umum Android, antarmuka ini sesuai dengan operasiblk_crypto_ll_ops::keyslot_program
, yang harus diterapkan oleh driver penyimpanan. - Satu antarmuka untuk mendapatkan dan menampilkan
sw_secret
("software rahasia" -- juga disebut "rahasia mentah" di beberapa tempat), yang merupakan kunci yang Linux digunakan untuk memperoleh sub-kunci untuk segala hal selain isi file enkripsi. Dalam kernel umum Android, antarmuka ini sesuai dengan operasiblk_crypto_ll_ops::derive_sw_secret
, yang harus diterapkan oleh driver penyimpanan.
Untuk mendapatkan inline_encryption_key
dan sw_secret
dari
kunci penyimpanan mentah, hardware harus menggunakan KDF yang kuat secara kriptografis. KDF ini
harus mengikuti praktik terbaik kriptografi; KDF harus memiliki kekuatan keamanan setidaknya
256 bit, yaitu cukup untuk algoritma apa pun yang digunakan nanti. Subkunci juga harus menggunakan
label, konteks, dan string informasi khusus aplikasi yang berbeda saat
menghasilkan setiap jenis subkunci untuk menjamin bahwa subkunci yang dihasilkan
diisolasi secara kriptografis, yaitu, pengetahuan tentang salah satunya tidak mengungkapkan
subkunci lainnya. Peregangan kunci tidak diperlukan, karena kunci penyimpanan mentah sudah merupakan
kunci acak yang seragam.
Secara teknis, KDF apa pun yang memenuhi persyaratan keamanan dapat digunakan.
Namun, untuk tujuan pengujian, perlu mengimplementasikan
kembali KDF yang sama di
kode pengujian. Saat ini, satu KDF telah ditinjau dan diterapkan; KDF ini dapat ditemukan
dalam kode sumber untuk vts_kernel_encryption_test
.
Sebaiknya hardware menggunakan KDF ini, yang menggunakan NIST SP 800-108 "KDF in Counter Mode" dengan AES-256-CMAC sebagai PRF. Perhatikan bahwa agar kompatibel, semua
bagian algoritma harus identik, termasuk pilihan konteks
dan label KDF untuk setiap subkunci.
Penggabungan tombol (key wrapping)
Untuk memenuhi sasaran keamanan kunci yang dibungkus hardware, ada dua jenis didefinisikan:
- Penggabungan sementara: hardware mengenkripsi kunci mentah menggunakan kunci yang dibuat secara acak pada setiap booting dan tidak diekspos secara langsung di luar hardware.
- Penggabungan jangka panjang: hardware mengenkripsi kunci mentah menggunakan kunci unik dan persisten yang terintegrasi dalam hardware yang tidak langsung diekspos di luar hardware.
Semua kunci yang diteruskan ke {i>kernel<i} Linux untuk membuka penyimpanan ditampilkan secara singkat. Hal ini memastikan bahwa jika penyerang dapat mengekstrak sebuah yang sedang digunakan dari memori sistem, maka kunci itu tidak hanya bisa digunakan, mati pada perangkat, tetapi juga pada perangkat setelah {i>reboot<i}.
Pada saat yang sama, Android masih harus bisa menyimpan versi terenkripsi dari kunci pada {i>disk <i}sehingga mereka dapat dibuka kuncinya. Kunci mentah akan berfungsi untuk tujuan ini. Namun, sebaiknya jangan pernah memiliki kunci ada dalam memori sistem sehingga tidak akan bisa diekstrak untuk digunakan di luar perangkat, bahkan jika diekstrak pada saat {i>booting<i}. Oleh karena itu, konsep pembungkusan jangka panjang ditentukan.
Untuk mendukung pengelolaan kunci yang digabungkan dengan dua cara berbeda ini, hardware harus implementasikan antarmuka berikut:
- Antarmuka untuk membuat dan mengimpor kunci penyimpanan, yang mengembalikannya ke
yang digabungkan dalam
jangka panjang. Antarmuka ini diakses secara tidak langsung melalui
KeyMint, dan sesuai dengan tag KeyMint
TAG_STORAGE_KEY
. Kemampuan "generate" digunakan olehvold
untuk membuat kunci penyimpanan baru yang akan digunakan oleh Android, sedangkan kemampuan "import" digunakan olehvts_kernel_encryption_test
untuk mengimpor kunci pengujian. - Antarmuka untuk mengonversi kunci penyimpanan gabungan jangka panjang menjadi
kunci penyimpanan yang
dibungkus secara efemeral. Ini sesuai dengan
metode KeyMint
convertStorageKeyToEphemeral
. Metode ini digunakan olehvold
danvts_kernel_encryption_test
untuk membuka kunci penyimpanan.
Algoritma penggabungan kunci adalah detail implementasi, tetapi harus menggunakan AEAD yang kuat seperti AES-256-GCM dengan IV acak.
Diperlukan perubahan software
AOSP sudah memiliki framework dasar untuk mendukung kunci yang digabungkan dengan hardware. Ini
menyertakan dukungan dalam komponen userspace seperti vold
, serta
sebagai dukungan kernel Linux pada blk-crypto, fscrypt, dan
kunci-default-dm.
Namun, beberapa perubahan khusus implementasi diperlukan.
Perubahan KeyMint
Penerapan KeyMint perangkat harus diubah untuk mendukung
TAG_STORAGE_KEY
dan menerapkan
metode convertStorageKeyToEphemeral
.
Di Keymaster, exportKey
digunakan sebagai pengganti
convertStorageKeyToEphemeral
.
Perubahan kernel Linux
Driver kernel Linux untuk mesin kripto inline perangkat harus dimodifikasi untuk mendukung kunci yang digabungkan dengan hardware.
Untuk kernel android14
dan yang lebih tinggi,
tetapkan BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
di blk_crypto_profile::key_types_supported
,
buat blk_crypto_ll_ops::keyslot_program
dan blk_crypto_ll_ops::keyslot_evict
mendukung pemrograman/penghapusan kunci yang digabungkan dengan hardware,
dan terapkan blk_crypto_ll_ops::derive_sw_secret
.
Untuk kernel android12
dan android13
,
setel BLK_CRYPTO_FEATURE_WRAPPED_KEYS
di blk_keyslot_manager::features
,
buat blk_ksm_ll_ops::keyslot_program
dan blk_ksm_ll_ops::keyslot_evict
mendukung pemrograman/penghapusan kunci yang digabungkan dengan hardware,
dan terapkan blk_ksm_ll_ops::derive_raw_secret
.
Untuk kernel android11
,
tetapkan BLK_CRYPTO_FEATURE_WRAPPED_KEYS
di keyslot_manager::features
,
buat keyslot_mgmt_ll_ops::keyslot_program
dan keyslot_mgmt_ll_ops::keyslot_evict
mendukung pemrograman/penghapusan kunci yang digabungkan dengan hardware,
dan terapkan keyslot_mgmt_ll_ops::derive_raw_secret
.
Pengujian
Meskipun enkripsi dengan kunci yang digabungkan dengan hardware lebih sulit untuk diuji daripada enkripsi
dengan kunci standar, masih mungkin untuk
menguji dengan mengimpor kunci pengujian dan
menerapkan kembali turunan kunci
yang dilakukan oleh perangkat keras. Hal ini diterapkan
di vts_kernel_encryption_test
. Untuk menjalankan pengujian ini,
jalankan:
atest -v vts_kernel_encryption_test
Baca log pengujian dan pastikan bahwa kasus pengujian kunci yang digabungkan dengan hardware (misalnya,
FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy
dan
DmDefaultKeyTest.TestHwWrappedKey
) tidak dilewati karena dukungan
untuk kunci yang digabungkan dengan hardware tidak terdeteksi, karena hasil pengujian masih
"lulus" dalam kasus tersebut.
Aktifkan tombol
Setelah dukungan kunci yang digabungkan dengan hardware perangkat berfungsi dengan benar, Anda dapat
melakukan perubahan berikut pada file fstab
perangkat agar
Android menggunakannya untuk FBE dan enkripsi metadata:
- FBE: tambahkan flag
wrappedkey_v0
ke Parameterfileencryption
. Misalnya, gunakanfileencryption=::inlinecrypt_optimized+wrappedkey_v0
. Untuk mengetahui detail selengkapnya, lihat dokumentasi FBE. - Enkripsi metadata: tambahkan flag
wrappedkey_v0
ke Parametermetadata_encryption
. Misalnya, gunakanmetadata_encryption=:wrappedkey_v0
. Untuk mengetahui detail selengkapnya, lihat metadata dokumentasi enkripsi.