Fondasi dan Evolusi Android Verified Boot
Android Verified Boot (AVB) merupakan pilar utama integritas perangkat dalam ekosistem sistem operasi Android modern. Sejak diperkenalkan pada era Android KitKat dalam bentuk dm-verity statis, arsitektur verifikasi boot telah berevolusi secara signifikan hingga mencapai implementasi AVB 2.0 pada Android 8.0 Oreo dan versi-versi berikutnya. Tujuan mendasar dari sistem ini adalah memastikan bahwa setiap instruksi biner yang dieksekusi selama proses inisialisasi perangkat keras berasal dari sumber terpercaya yang belum mengalami manipulasi atau injeksi kode berbahaya.
Pada implementasi awal AVB 1.0, verifikasi dilakukan secara terdistribusi di mana masing-masing partisi sistem (seperti system dan vendor) memuat tabel hash verity dan tanda tangan digitalnya sendiri di bagian akhir partisi (footer). Pendekatan ini menimbulkan tantangan koordinasi yang kompleks ketika melakukan pembaruan firmware berkala serta mempersulit mekanisme rollback protection. AVB 2.0 merevolusi paradigma ini dengan memperkenalkan pustaka libavb dan sentralisasi informasi kriptografis ke dalam struktur metadata khusus yang dikenal sebagai vbmeta.
Komponen Kriptografis dan Struktur Partisi vbmeta
Pusat kendali dari AVB 2.0 berada pada partisi vbmeta. Partisi ini memuat blok data verifikasi kriptografis yang membuktikan keaslian seluruh image sistem operasi. Struktur internal biner vbmeta dirancang secara deterministik dengan header berukuran tetap yang diikuti oleh array deskriptor dinamis.
Struktur Header dan Blok Data VBMeta
Setiap image vbmeta yang valid diawali dengan empat byte magic number AVB0 (nilai heksadesimal 0x41 0x56 0x42 0x30). Header ini mendefinisikan panjang blok otentikasi (authentication data block) dan blok pembantu (auxiliary data block). Blok otentikasi memuat tanda tangan digital berbasis algoritma asimetris seperti RSA-2048, RSA-4096, atau kurva eliptik ECC, yang dihitung dari representasi hash seluruh payload metadata.
| Field Metadata | Panjang Data | Fungsi Arsitektural dalam AVB 2.0 |
|---|---|---|
magic[4] |
4 Byte | Identifier penanda validitas biner struktur metadata (ASCII 'AVB0'). |
required_libavb_version |
8 Byte | Versi kompatibilitas minimum parser libavb pada bootloader perangkat. |
authentication_data_block |
Variabel | Memuat nilai hash pohon dan digital signature yang diverifikasi dengan kunci OEM. |
auxiliary_data_block |
Variabel | Menyimpan public key, deskriptor hash partisi, dan rantai ranting vbmeta chained. |
rollback_index_location |
8 Byte | Pointer indeks anti-rollback pada register memori terisolasi (RPMB / eFuse). |
Catatan Riset Keamanan: Integritas Hardware Root of Trust
Keamanan AVB 2.0 bertumpu mutlak pada Hardware Root of Trust. Jika public key OEM pada One-Time Programmable (OTP) eFuse dapat dimanipulasi, seluruh rantai kepercayaan di atasnya akan runtuh. Oleh sebab itu, bootloader komersial mengunci pembacaan hash kunci ini di tingkat silikon SoC.
Rantai Kepercayaan Bootloader (Chain of Trust)
Proses inisialisasi boot Android berjalan secara hierarkis bertingkat. Setiap tahapan bootloader bertanggung jawab memvalidasi integritas tahapan berikutnya sebelum mengeksekusi kendali instruksi prosesor. Rangkaian ini dimulai dari Boot ROM primer pada silikon SoC hingga ke inisialisasi user-space init Android.
Tahapan Eksekusi Sekuensial
- Primary Bootloader (PBL): Kode biner statis yang tersimpan permanen di Mask ROM chip. PBL mengeksekusi self-test perangkat keras dan membaca Secondary Bootloader (SBL/XBL) dari media penyimpanan flash UFS.
- Secondary Bootloader (XBL/SBL): Memverifikasi kunci publik OEM yang tersimpan pada register eFuse, menginisialisasi bus DDR RAM, dan memuat Application Bootloader (ABL).
- Application Bootloader (ABL): Komponen bootloader tingkat tinggi berbasis standar UEFI/Little Kernel. ABL memuat pustaka
libavbuntuk memvalidasi partisivbmeta, memeriksa nomor rollback index, dan memverifikasi kernel image pada partisibootatauinit_boot. - Inisialisasi dm-verity Kernel: Kernel Linux menerima parameter
dm-veritymelalui kernel command line (bootargs) dari ABL. Kernel memvalidasi blok pohon hash partisisystem,vendor, danproductsecara on-the-fly saat pembacaan I/O filesystem berlangsung.
Mekanisme Chained Partitions dan vbmeta_system
Untuk mendukung kemandirian pembaruan partisi tanpa harus mengompilasi ulang seluruh image vbmeta utama, AVB 2.0 mendukung arsitektur Chained Partitions. Dalam model ini, partisi seperti vbmeta_system atau vbmeta_vendor memiliki pasangan kunci kriptografis tersendiri. Partisi vbmeta root utama hanya menyimpan nilai digest SHA-256 dari kunci publik partisi ranting tersebut (chain descriptor). Jika vendor chipset menerbitkan patch keamanan untuk partisi vendor, mereka cukup menandatangani ulang image vbmeta_vendor tanpa perlu meminta tanda tangan kunci OEM utama, menjaga fleksibilitas siklus rekayasa firmware.
Audit dan Validasi Verifikasi Image via Avbtool
Untuk keperluan analisis forensik dan riset keamanan, Google menyediakan utilitas open-source avbtool yang ditulis dalam Python. Utilitas ini memungkinkan peneliti memeriksa struktur metadata vbmeta, mengekstraksi kunci publik OEM, serta memvalidasi kesesuaian nilai hash tree pada image firmware.
# Menampilkan rincian struktur header dan deskriptor partisi pada vbmeta.img
avbtool info_image --image vbmeta.img
# Melakukan verifikasi integritas rantai image boot terhadap vbmeta
avbtool verify_image --image vbmeta.img --key OEM_Root_Key.pem
# Mengekstraksi kunci publik OEM dari image vbmeta untuk analisis perbandingan
avbtool extract_public_key --image vbmeta.img --output extracted_oem_key.bin
Luaran dari perintah info_image akan merinci setiap partition descriptor yang terdaftar di dalam vbmeta, termasuk algoritma digest (misalnya SHA256_RSA4096), ukuran partisi target, dan nilai root digest yang menjadi patokan verifikasi kernel.
Analisis Status Kunci dan Keadaan Perangkat (Device State)
Dalam arsitektur AVB, keadaan perangkat dikategorikan menjadi dua status utama: LOCKED dan UNLOCKED, yang menghasilkan empat warna status boot (Boot State Color Coding) yang ditampilkan kepada pengguna pada layar boot awal:
| Warna Status | Kondisi Boot State | Implikasi Keamanan dan Perilaku Sistem |
|---|---|---|
| GREEN | Device Locked + OEM Key | Perangkat sepenuhnya terkunci, image diverifikasi menggunakan sertifikat pabrikan resmi. |
| YELLOW | Device Locked + Custom Key | Perangkat terkunci menggunakan kunci root kustom yang didaftarkan pemilik (user key). |
| ORANGE | Device Unlocked | Bootloader dibuka. Verifikasi integritas dinonaktifkan atau hanya memberikan peringatan. |
| RED | Integritas Korup | Terjadi kegagalan verifikasi kriptografis pada partisi. Perangkat menghentikan proses boot. |
# Memeriksa status kunci bootloader melalui protokol fastboot
fastboot getvar unlocked
fastboot getvar secure
fastboot oem device-infoKesimpulan dan Implikasi Keamanan Sistem
Android Verified Boot 2.0 memberikan jaminan matematis terhadap keaslian biner sistem operasi Android. Melalui penggabungan Hardware Root of Trust, struktur metadata vbmeta terpusat, dan lapisan proteksi anti-rollback pada penyimpanan terisolasi RPMB, sistem operasi Android modern mampu mencegah modifikasi persisten pada partisi sistem yang tidak memiliki otorisasi kriptografis yang valid.