Google telah mulai memperkenalkan Enkripsi Lengkap Disk (FDE) default dengan Android 5.0 Lollipop. Pada awalnya, ketika enkripsi diimplementasikan pada perangkat Nexus 6, banyak pengguna mengeluh tentang penurunan kinerja saat membaca dan menulis data ke drive, tetapi dari versi Android 6.0 masalah ini tampaknya diselesaikan.Enkripsi disk penuh melindungi semua informasi di telepon meskipun perangkat jatuh ke tangan penegak hukum atau pengganggu lainnya .Ketika enkripsi diaktifkan, setiap informasi di telepon secara otomatis dienkripsi dengan menggunakan kunci AES sebelum menulis ke media. Dan sebaliknya, ketika membaca informasi, secara otomatis didekripsi dengan kunci ini.Pada perangkat iOS 9, kunci ini merupakan turunan dari kata sandi pengguna dan kunci perangkat keras 256-bit unik yang disambungkan ke telepon pintar di pabrik. Bahkan FBI tidak dapat memecahkan enkripsi level ini menggunakan brute force, seperti diketahui dari sejarah penembak terbaru dari San Bernardino dengan smartphone, karena itu FBI dan Apple mencapai pengadilan . Akibatnya, FBI masih berhasil memecahkan telepon menggunakan kerentanan 0day yang tidak diketahui. Seperti dapat dipahami dari kata-kata kepala struktur negara, peretas harus membayar lebih dari satu juta dolar untuk menghindari perlindungan FBI .
Enkripsi disk penuh di iOSDengan demikian, FDE brute force hanya dimungkinkan menggunakan perangkat perangkat keras tertentu. Ini sangat mempersulit serangan itu. Dalam kasus biasa, Anda dapat membuat sejuta salinan dan memparalelkan bruteforce di layanan cloud, yang memungkinkan Anda menemukan 99% kata sandi asli dengan sangat cepat. Tetapi dalam hal ini, kita harus membatasi diri pada satu-satunya perangkat di mana Apple menambahkan gangguan tambahan - penundaan antara upaya kata sandi, batas jumlah upaya maksimum, dll. Itulah mengapa sangat penting bagi layanan khusus untuk menemukan cara untuk mengambil UID perangkat keras, kemudian kata sandi brute force menjadi tugas teknis biasa.Enkripsi disk lengkap di Android 5.0+ diimplementasikan agak berbeda dari di iOS 9, dan dijelaskan secara terperinci dalamBlog Nikolay Elenkov dan dokumentasi Android resmi .Di sini, kunci enkripsi juga merupakan turunan dari kata sandi pengguna yang biasanya lemah , tetapi juga dari kunci master 128-bit yang dihasilkan secara acak (Kunci Enkripsi Perangkat - DEK) dan garam 128-bit yang dihasilkan secara acak. Bidang pembuatan DEK dilindungi menggunakan skema pemikiran cermat yang menggunakan nilai yang dimasukkan oleh pengguna - kode PIN / kata sandi / pola (kunci grafik) untuk entri. Kemudian, DEK terenkripsi ditempatkan di penyimpanan terenkripsi khusus yang disebut crypto footer . Semua level enkripsi ini harus diatasi sebelum mendekripsi DEK, dan kemudian informasi apa pun yang dicatat pada drive.
Seperti halnya iOS 9, sistem operasi Android mengimplementasikan pengikatan skema enkripsi ke perangkat keras tertentu untuk mencegah kekerasan pada salinan sistem operasi. Fungsi pengikatan perangkat keras dilakukan oleh penyimpanan perangkat keras khusus - KeyMaster, yang beroperasi di Lingkungan Eksekusi Tepercaya (TEE) khusus, yang sepenuhnya independen dari sistem operasi Android. Keamanan utama di lingkungan KeyMaster sangat penting. Hanya ini yang melindungi sistem enkripsi disk penuh dari melakukan brute force yang efektif dalam aliran paralel pada salinan OS.Pada perangkat Android, lingkungan yang terisolasi tidak pernah mengeluarkan kunci sendiri ke dalam lingkungan yang "tidak aman". Sebaliknya, modul KeyMaster menerima "gumpalan kunci" dari lingkungan yang tidak aman, mendekripsi kunci yang disimpan di sana, dan mengembalikannya. Dengan kata lain, pengoperasian sistem enkripsi hanya dimungkinkan secara langsung pada perangkat perangkat keras, tetapi tidak dalam lingkungan virtual di komputer lain.Secara umum, seluruh proses dapat secara skematis digambarkan dalam diagram seperti itu, yang diberikan Nikolai Elenkov .
Perlindungan lingkungan KeyMaster dan eksekusi perintah pada prosesor aman khusus dipastikan oleh lingkungan terlindung yang disediakan oleh pabrik peralatan. Dalam kasus Qualcomm, ini adalah QSEE (Qualcomm Secure Execution Environment). Ini memungkinkan hanya aplikasi kecil yang terpisah yang disebut trustlets untuk dijalankan pada prosesor khusus. Salah satu trustlets ini adalah KeyMaster. Kode sumber Android memiliki instruksi untuk mengakses aplikasi KeyMaster. Bahkan, trustlet hanya mendukung empat instruksi: * Commands supported
*/
enum keymaster_cmd_t {
KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
KEYMASTER_SIGN_DATA = 0x00000003,
KEYMASTER_VERIFY_DATA = 0x00000004,
};
KeyMaster bekerja persis seperti yang dijelaskan di atas: ia menerima gumpalan kunci, menghitung tanda tangan dan meletakkannya di buffer.Dan sekarang kita telah sampai pada tahap di mana exploit baru beroperasi, yang muncul di domain publik pada 30 Juni ( repositori di Github ). Eksploitasi mengeksploitasi kerentanan yang baru ditemukan CVE-2015-6639 dan CVE-2016-2431 .Penulis eksploit, spesialis keamanan Gal Beniamini menulis versi palsu dari aplikasi QSEE dan, menggunakan kerentanan yang disebutkan di atas, berhasil memuatnya ke lingkungan yang aman, sehingga meningkatkan hak istimewa dan memutus perlindungan lingkungan QSEE, yang terlibat dalam proses menghasilkan kunci untuk mengenkripsi disk.Dengan demikian, penyerang hipotetis dapat "memalsukan" komponen perangkat keras dari kunci enkripsi dan menerapkan kekuatan kasar dari komponen yang tersisa, melewati perlindungan Android dengan jumlah percobaan ulang. Tetap hanya untuk memilih PIN / kata sandi pengguna dengan kekerasan.By the way, untuk kasus yang jarang terjadi ketika pengguna telah menetapkan kata sandi yang sangat kompleks dengan entropi tinggi untuk enkripsi dan tidak dapat diambil dengan kekuatan kasar untuk waktu yang dapat diterima, ada rencana cadangan. Jika melanggar enkripsi sangat diperlukan, Anda dapat menemukan telepon yang sama persis, dengan model yang sama, dengan goresan yang sama dan kasing pelindung - dan program untuk mengirim kata sandi segera setelah korban memasukkannya. Perangkat palsu ini melekat pada korban, bukan yang asli. Untuk menghindari pengungkapan dan pada saat yang sama menghilangkan risiko korban memasukkan kata sandi yang salah pada percobaan pertama, ponsel harus diprogram untuk tidak menerima kata sandi sebagai kata sandi yang benar.Tapi ini kasus ekstrim, tentu saja. Sebenarnya cukup mudah untuk mengambil kode PIN dan kata sandi biasa jika tidak ada batasan perangkat keras pada brute force.Ada satu hal yang menarik. Lingkungan aman pada perangkat seluler tidak diatur oleh Qualcomm sendiri, tetapi oleh OEM. Mereka dapat bekerja sama dengan otoritas penegak hukum di negara tempat yurisdiksinya berada dan memenuhi persyaratan permintaan pengadilan. Oleh karena itu, jika skema kriptografi seperti itu diterapkan oleh pabrikan Rusia, maka informasi pada smartphone akan dideklasifikasi atas permintaan pengadilan Rusia.Dan satu lagi momen menarik. Terlepas dari kenyataan bahwa Gal Benyamini telah membahas kerentanan ini dengan Qualcomm dan Google selama beberapa bulan, memperbaikinya tidak begitu mudah - tidak ada peningkatan perangkat lunak yang cukup (untuk dua kerentanan, tambalan untuk Android dirilis pada Januari dan Mei ), dan peningkatan perangkat keras mungkin diperlukan. Faktanya adalah bahwa jika penyerang menerima perangkat, maka secara teoritis itu dapat memutar kembali upgrade perangkat lunak, mengembalikan perangkat ke versi yang rentan dan melakukan serangan.Seperti disebutkan di atas, kode exploit diterbitkan di Github . Berikut ini diagram karyanya.
Gal Benyamini telah menulis beberapa skrip Python yang menyederhanakan bruteforce setelah eksploitasi dipicu. Dalam komentar di posting blog rekannyaMereka menyatakan keinginan untuk membantu dalam porting script pada platform yang kuat untuk brute force hashcat / oclHashcat .Benjamini menyarankan bahwa Google, bersama dengan pembuat OEM, akan mengembangkan skema enkripsi perangkat keras-perangkat lunak yang benar-benar andal, yang bahkan secara teoritis tidak dapat dipecahkan.Mari berharap skema seperti ini diterapkan pada perangkat Android generasi baru.