Semua perangkat yang diluncurkan dengan Android Pie (Android 9) diharuskan mendukung Boot Terverifikasi (Android Verified Boot 2.0), yang memungkinkan perlindungan rollback.
Android Pie (Android 9) baru saja ditayangkan hari ini untuk Google Pixel, Google Pixel 2, dan bahkan Telepon Penting. Kami belajar sebanyak mungkin tentang rilis dari wawancara (Google Pixel 3 hanya akan memiliki navigasi gerakan!), itu Penurunan kode AOSP, dan terakhir Dokumen Definisi Kompatibilitas (CDD). Kami memposting tentang a fitur baru untuk aplikasi "kelas berat". sebelumnya hari ini, tapi sekarang kami menemukan bahwa Google telah mengubah kata-kata mereka pada fitur yang diperkenalkan di Android Oreo: perlindungan kemunduran. Fitur ini dimungkinkan oleh Boot Terverifikasi Android 2.0 (juga dikenal sebagai Boot Terverifikasi), namun OEM tidak diharuskan untuk mengimplementasikan AVB 2.0 dalam rilis Oreo. Sekarang, Google mewajibkan semua perangkat yang diluncurkan dengan Android Pie mendukung Boot Terverifikasi, dan lebih jauh lagi, perlindungan rollback.
Perlindungan Kembalikan di Android Oreo
Inti dari fitur ini adalah akan mencegah ponsel Anda melakukan booting jika mendeteksi bahwa perangkat telah diturunkan versinya ke versi perangkat lunak sebelumnya yang sekarang tidak disetujui dan dianggap tidak aman karena alasan keamanan kerentanan. Penjelasan yang sedikit lebih teknis adalah struktur data VBMeta, yang menyimpan hash untuk partisi boot dan metadata hashtree untuk partisi sistem dan vendor, menggunakan indeks rollback untuk menolak gambar yang memiliki rollback lebih lama indeks.
Fitur ini hadir pada perangkat seperti Google Pixel 2, Razer Phone, dan OnePlus 6 namun tidak hadir pada banyak perangkat lain seperti Samsung Galaxy S9 (walaupun Samsung menawarkan bentuknya sendiri perlindungan rollback di Knox.) Sekarang, Google menjadikan fitur ini wajib untuk perangkat apa pun yang diluncurkan dengan Android Pie.
Boot Terverifikasi di Android Pie
Menurut kata-kata yang diperbarui di bagian "Integritas Perangkat" dalam Dokumen Definisi Kompatibilitas, perangkat yang diluncurkan dengan Android 9 harus mendukung Boot Terverifikasi.
9.10. Integritas Perangkat
Persyaratan berikut memastikan adanya transparansi terhadap status integritas perangkat. Implementasi perangkat:
- [C-0-1] HARUS melaporkan dengan benar melalui metode API Sistem PersistentDataBlockManager.getFlashLockState() apakah status bootloadernya mengizinkan flashing citra sistem. Status FLASH_LOCK_UNKNOWN dicadangkan untuk implementasi perangkat yang ditingkatkan dari versi Android sebelumnya yang tidak memiliki metode API sistem baru ini.
- [C-0-2] HARUS mendukung Boot Terverifikasi untuk integritas perangkat.
Jika implementasi perangkat telah diluncurkan tanpa mendukung Boot Terverifikasi pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk fitur ini dengan pembaruan perangkat lunak sistem, mereka MUNGKIN dikecualikan dari persyaratan.
...
- [C-1-10] HARUS menerapkan perlindungan rollback untuk partisi yang digunakan oleh Android (misalnya boot, partisi sistem) dan menggunakan penyimpanan anti rusak untuk menyimpan metadata yang digunakan untuk menentukan OS minimum yang diperbolehkan Versi: kapan.
- HARUS menerapkan perlindungan rollback untuk komponen apa pun dengan firmware persisten (misalnya modem, kamera) dan HARUS menggunakan penyimpanan anti rusak untuk menyimpan metadata yang digunakan untuk menentukan jumlah minimum yang diperbolehkan Versi: kapan.
Seperti yang Anda lihat dalam dua rangkaian poin-poin terakhir, ada satu peringatan yang perlu diperhatikan. Perlindungan rollback diperlukan untuk partisi yang digunakan oleh Android (boot, sistem, vendor, dll.) tetapi tidak untuk partisi dengan firmware persisten (modem, kamera, dll.). Kumpulan partisi sebelumnya adalah tempat sebagian besar kerentanan keamanan ditemukan dan ditambal sehingga menyenangkan untuk melihat bahwa melindungi partisi ini adalah suatu keharusan. Namun, ada juga eksploitasi yang menargetkan partisi dengan firmware persisten, jadi kami tidak yakin mengapa Google tidak mewajibkan perlindungan rollback pada partisi tersebut.
Anggota Senior XDA npjohnson, anggota tim LineageOS, berspekulasi bahwa memerlukan perlindungan rollback pada partisi dengan firmware persisten akan diperlukan memerlukan pengikatan Bootloader Sekunder (SBL) dan eXtensible Bootloader (XBL) karena partisi ini dipasang lebih awal pada boot proses. Akan memakan biaya yang besar bagi OEM yang lebih kecil untuk mengimplementasikan XBL yang disesuaikan agar sesuai dengan modem yang disesuaikan dan partisi persisten lainnya, jadi mungkin Google tidak menjadikan ini sebagai persyaratan untuk memudahkan pembuat perangkat memenuhi persyaratan terbaru dalam CDD.
Bagaimana cara memeriksa apakah ponsel Anda mendukung AVB 2.0
Ada dua perintah shell ADB yang dapat Anda gunakan untuk memeriksa apakah ponsel Anda mendukung AVB 2.0.
adb shell
dumpsys package | grep "verified_boot"
ATAU
adb shell
getprop | grep "avb"
Jika output dari perintah pertama adalah "android.software.verified_boot" maka AVB 2.0 didukung. Jika output dari perintah kedua menunjukkan "[ro.boot.avb_version]" dan "[ro.boot.vbmeta.avb_version]" dan mencantumkan nomor versi untuk masing-masing versi, maka perintah tersebut didukung.
Boot Terverifikasi dan Pengembangan Kustom
Boot Terverifikasi Android tidak terlalu memengaruhi sebagian besar pengguna ROM khusus meskipun hal ini menambah lapisan keamanan tambahan yang harus Anda atasi dalam beberapa kasus. Contohnya, mem-flash Gambar Sistem Generik membutuhkan menonaktifkan AVB. Memodifikasi partisi tertentu seperti vendor di OnePlus 6 memerlukan penonaktifan AVB juga, seperti yang baru-baru ini saya pelajari. Berdasarkan npjohnson, AVB 2.0 yang diterapkan dengan benar memungkinkan image boot khusus berfungsi dengan bootloader yang terkunci. Kita akan melihat bagaimana penyertaan AVB 2.0 pada perangkat yang dikirimkan dengan Android Pie memengaruhi lanskap, namun kami berharap hal ini tidak mengakibatkan situasi seperti ketakutan akan batu bata baru-baru ini di komunitas Xiaomi Redmi Note 5 Pro. Wajib AVB 2.0 hanyalah cara lain bagi Google untuk melakukannya meningkatkan keamanan platform Android, namun perubahan terbesar, menurut kami, adalah pengerjaan ulang perjanjian OEM untuk mewajibkan patch keamanan reguler.