Saya baru saja menginstal Marshmallow pada Nexus 5 melalui pembaruan yang didorong. Saya bingung tentang cara enkripsi bekerja. Saya memiliki pengetahuan teknis enkripsi yang baik di komputer. Saya ingin mendapatkan pengetahuan serupa tentang Android 6.

Berikut ini adalah apa yang saya lakukan dan bagaimana saya menjadi bingung. Setelah reset pabrik, saya mengatur PIN kemudian mengenkripsi perangkat. Saat boot, ia meminta PIN saya, yang diharapkan. Saya kemudian menghapus PIN dan memulai kembali perangkat. Itu tidak meminta PIN apa pun saat boot tetapi perangkat masih melaporkan dirinya sebagai terenkripsi dalam menu pengaturan. Yang terakhir inilah yang membingungkan saya karena saya mengharapkan PIN untuk membuka kunci kunci dekripsi.

Pertanyaan:

• Dalam hal enkripsi tanpa PIN, dari mana kunci dekripsi berasal? Saya menganggap itu disimpan pada chip yang mirip dengan TPM, apakah ini benar? Jika demikian, apa yang mencegah seorang hacker meminta kunci ini dari chip? Apakah itu memeriksa hash firmware? Ada yang lain? Detail teknis akan sangat dihargai.
• Dalam hal enkripsi dengan PIN, apakah PIN digunakan sebagai token tambahan untuk mengakses kunci dekripsi? Atau apakah proses dekripsi bekerja persis seperti jika tidak ada PIN.

TL; DL jawaban:

Kunci dekripsi dibuka dengan semua hal berikut:

• PIN (atau kata sandi, dll.) Atau kata sandi standar jika tidak ada
• TEE (generator tanda tangan yang didukung perangkat keras yang menggunakan kunci yang tidak dapat diekstraksi)
• Garam (tersedia tetapi mencegah serangan tabel pelangi)

Saya mengutip dari Manual Android di sini , tetapi:

CATATAN:

Sumber yang saya gunakan tidak secara langsung relevan dengan Marshmallow tetapi relevan untuk Lollipop dan lebih tinggi.

TL: DR

Saya hanya akan menjawab pertanyaan OP sekarang. Rincian teknis akan mengikuti.

1. Kunci enkripsi default berasal dari sumber perangkat keras (chip yang mirip dengan TPM) dan kata sandi standar AOSP didefinisikan seperti default_passworddalam cryptfs.cfile sumber, lihat di bawah.

2. Ya, bukan hanya default, tetapi kata sandi apa pun dibuat menjadi kunci dan disimpan pada chip mirip TPM, disebut TEE (kependekan dari "Lingkungan Eksekusi Tepercaya", lihat di bawah untuk perincian lebih lanjut).

3. Seorang hacker dengan akses UART / JTAG ke chip pada SoC perangkat secara teknis bisa mendapatkan akses ke kunci TEE, atau kernel kustom dapat membocorkan informasi ini ke seorang hacker. Beberapa agensi 3 huruf dalam teori konspirasi mungkin dapat bermitra dengan OEM untuk mendapatkan kernel yang tidak aman ini digunakan dalam perangkat produksi, tapi saya tidak akan meletakkan banyak toko olehnya. Sekali lagi, lihat bagian terakhir dari jawaban ini untuk perincian lebih lanjut.

Satu-satunya hal yang menghentikan seorang hacker dari mendapatkan akses ke kunci adalah banyaknya upaya yang diperlukan untuk melakukannya.

4. Memeriksa hash of (checksumming) firmware (disebut "Boot Terverifikasi" oleh Google) sebenarnya dilakukan pada dan di atas Lollipop secara default (dan tersedia dari JellyBean 4.3 dan seterusnya), oleh modul kernel yang disebut dm-verity. Namun, ini tidak tergantung pada status enkripsi.

Sumber: panduan keamanan AOSP di sini .

5. Tentang proses yang terlibat dalam mendekripsi sistem dengan kata sandi khusus, lihat di bawah. Saya hanya akan memberi tahu Anda di sini bahwa kata sandi pengguna terlibat dalam pembuatan dan penggunaan kunci enkripsi.

Gambaran

Saat boot pertama, perangkat membuat kunci master 128-bit yang dihasilkan secara acak dan kemudian mem-hash-nya dengan kata sandi default dan garam yang disimpan. Kata sandi default adalah: "default_password" Namun, hash yang dihasilkan juga masuk melalui TEE (seperti TrustZone), yang menggunakan hash tanda tangan untuk mengenkripsi kunci master.

Anda dapat menemukan kata sandi default yang ditentukan dalam file cryptfs.c Android Open Source Project .

Ketika pengguna menetapkan PIN / pass atau kata sandi pada perangkat, hanya kunci 128-bit yang dienkripsi ulang dan disimpan. (mis. perubahan PIN / pass / pola pengguna TIDAK menyebabkan enkripsi ulang partisi data pengguna.)

Mulai perangkat terenkripsi dengan enkripsi default

Inilah yang terjadi ketika Anda mem-boot perangkat terenkripsi tanpa kata sandi. Karena perangkat Android 5.0 dienkripsi pada boot pertama, seharusnya tidak ada kata sandi yang ditetapkan dan oleh karena itu ini adalah status enkripsi default.

1. Mendeteksi data terenkripsi / tanpa kata sandi

Mendeteksi bahwa perangkat Android dienkripsi karena / data tidak dapat dipasang dan salah satu dari bendera encryptableatau forceencryptdiatur.

volddiatur vold.decryptke trigger_default_encryption, yang memulai defaultcryptolayanan. trigger_default_encryptionmemeriksa jenis enkripsi untuk melihat apakah / data dienkripsi dengan atau tanpa kata sandi.

2. Dekripsi / data

Membuat dm-cryptperangkat melalui perangkat blok sehingga perangkat siap digunakan.

3. Mount / data

voldkemudian me-mount partisi real / data yang didekripsi dan kemudian menyiapkan partisi baru. Ini set properti vold.post_fs_data_doneuntuk 0dan kemudian menetapkan vold.decryptuntuk trigger_post_fs_data. Ini menyebabkan init.rcmenjalankan post-fs-dataperintahnya. Mereka akan membuat direktori atau tautan yang diperlukan dan kemudian diatur vold.post_fs_data_doneke 1.

Setelah voldmelihat 1 di properti itu, ia menetapkan properti vold.decryptke: trigger_restart_framework. Ini menyebabkan init.rcuntuk memulai layanan di kelas mainlagi dan juga memulai layanan di kelas late_start untuk pertama kalinya sejak boot.

4. Mulai kerangka kerja

Sekarang framework mem-boot semua layanannya menggunakan dekripsi / data, dan sistem siap digunakan.

Memulai perangkat terenkripsi tanpa enkripsi default

Inilah yang terjadi ketika Anda mem-boot perangkat terenkripsi yang memiliki kata sandi yang ditetapkan. Kata sandi perangkat dapat berupa pin, pola, atau kata sandi.

1. Mendeteksi perangkat terenkripsi dengan kata sandi

Mendeteksi bahwa perangkat Android dienkripsi karena bendera ro.crypto.state = "encrypted"

voldsetel vold.decryptke trigger_restart_min_frameworkkarena / data dienkripsi dengan kata sandi.

2. Pasang tmpfs

initset lima properti untuk menyimpan opsi mount awal yang diberikan untuk / data dengan parameter yang dilewati init.rc. voldmenggunakan properti ini untuk mengatur pemetaan crypto:

ro.crypto.fs_type

ro.crypto.fs_real_blkdev

ro.crypto.fs_mnt_point

ro.crypto.fs_options

ro.crypto.fs_flags (ASCII 8 digit angka hex didahului dengan 0x)

3. Mulai kerangka kerja untuk meminta kata sandi

Kerangka kerja dimulai dan melihat yang vold.decryptdiatur ke trigger_restart_min_framework. Ini memberitahu kerangka kerja bahwa itu boot pada tmpfs /datadisk dan perlu mendapatkan kata sandi pengguna.

Pertama, bagaimanapun, perlu memastikan bahwa disk itu dienkripsi dengan benar. Ini mengirimkan perintah cryptfs cryptocompleteke vold. voldmengembalikan 0 jika enkripsi berhasil diselesaikan, -1 pada kesalahan internal, atau -2 jika enkripsi tidak berhasil diselesaikan. voldmenentukan ini dengan melihat metadata crypto untuk CRYPTO_ENCRYPTION_IN_PROGRESSbendera. Jika disetel, proses enkripsi terputus, dan tidak ada data yang dapat digunakan di perangkat.

Jika voldmengembalikan kesalahan, UI harus menampilkan pesan kepada pengguna untuk reboot dan mengatur ulang perangkat, dan memberi pengguna tombol untuk menekan untuk melakukannya.

4. Dekripsi data dengan kata sandi

Setelah cryptfs cryptocompleteberhasil, kerangka kerja menampilkan UI yang menanyakan kata sandi disk. UI memeriksa kata sandi dengan mengirimkan perintah cryptfs checkpwke vold. Jika kata sandi itu benar (yang ditentukan dengan berhasil memasang yang didekripsi /datadi lokasi sementara, lalu melepaskannya), vold menyimpan nama perangkat blok yang didekripsi di properti ro.crypto.fs_crypto_blkdevdan mengembalikan status 0 ke UI. Jika kata sandi salah, ia mengembalikan -1 ke UI.

5. Hentikan kerangka kerja

UI memasang grafik booting crypto dan kemudian memanggil vold dengan perintah cryptfs restart. voldset properti vold.decryptke trigger_reset_main, yang menyebabkan init.rcharus dilakukan class_reset main. Ini menghentikan semua layanan di mainkelas, yang memungkinkan tmpfs /datauntuk di-unmount.

6. Mount / data

voldlalu pasang /datapartisi nyata yang didekripsi dan menyiapkan partisi baru (yang mungkin tidak pernah disiapkan jika dienkripsi dengan opsi penghapusan, yang tidak didukung pada rilis pertama). Ini set properti vold.post_fs_data_doneuntuk 0dan kemudian menetapkan vold.decryptuntuk trigger_post_fs_data. Ini menyebabkan init.rcmenjalankannya post-fs-data commands. Mereka akan membuat direktori atau tautan yang diperlukan dan kemudian diatur vold.post_fs_data_doneke 1. Setelah voldmelihat 1di properti itu, ia menetapkan properti vold.decryptuntuk trigger_restart_framework. Ini menyebabkan init.rcuntuk memulai layanan di kelas mainlagi dan juga memulai layanan di kelas late_startuntuk pertama kalinya sejak boot.

7. Mulai kerangka kerja penuh

Sekarang framework mem-boot semua layanannya menggunakan sistem file decrypted / data, dan sistem siap digunakan.

Menyimpan kunci terenkripsi

Kunci terenkripsi disimpan dalam metadata crypto. Dukungan perangkat keras diimplementasikan dengan menggunakan kemampuan penandatanganan TEE (Trusted Execution Environment). Sebelumnya, kami mengenkripsi kunci master dengan kunci yang dibuat dengan menerapkan scryptkata sandi pengguna dan garam yang disimpan.

Untuk membuat kunci ini tahan terhadap serangan off-box, kami memperluas algoritma ini dengan menandatangani kunci yang dihasilkan dengan kunci TEE yang tersimpan. Tanda tangan yang dihasilkan kemudian diubah menjadi kunci panjang yang sesuai oleh satu aplikasi lagi scrypt. Kunci ini kemudian digunakan untuk mengenkripsi dan mendekripsi kunci master. Untuk menyimpan kunci ini:

1. Menghasilkan kunci enkripsi disk 16-byte acak (DEK) dan garam 16-byte.
2. Berlaku scryptuntuk kata sandi pengguna dan garam untuk menghasilkan kunci menengah 32-byte 1 (IK1).
3. Pad IK1 dengan nol byte dengan ukuran kunci pribadi yang terikat perangkat keras (HBK). Secara khusus, kami mengisi sebagai: 00 || IK1 || 00.00; satu nol byte, 32 IK1 byte, 223 nol byte.
4. Masuk IK1 empuk dengan HBK untuk menghasilkan 256 byte IK2.
5. Berlaku scryptuntuk IK2 dan garam (garam yang sama seperti langkah 2) untuk menghasilkan IK3 32-byte.
6. Gunakan 16 byte pertama IK3 sebagai KEK dan 16 byte terakhir sebagai IV.
7. Enkripsi DEK dengan AES_CBC, dengan kunci KEK, dan inisialisasi vektor IV.