Toate dispozitivele care se lansează cu Android Pie (Android 9) trebuie să accepte Verified Boot (Android Verified Boot 2.0), care permite protecția împotriva derulării.
Android Pie (Android 9) tocmai a intrat în direct astăzi pentru Google Pixel, Google Pixel 2 și pana si Telefon esential. Învățăm cât de mult putem despre lansarea din interviuri (Google Pixel 3 va avea doar navigare prin gesturi!), cel Scăderea codului AOSPși, în sfârșit, documentul de definire a compatibilității (CDD). Am postat despre o caracteristică nouă pentru aplicațiile „greu”. azi mai devreme, dar acum am descoperit că Google și-a schimbat formularea cu privire la o funcție introdusă în Android Oreo: protecție împotriva deplasării. Caracteristica este posibilă de Android Verified Boot 2.0 (cunoscut și sub numele de Verified Boot), cu toate acestea, OEM-urilor nu au fost obligați să implementeze AVB 2.0 în versiunea Oreo. Acum, Google impune ca toate dispozitivele care se lansează cu Android Pie să accepte Verified Boot și, prin extensie, protecție împotriva derulării.
Protecție împotriva retragerii în Android Oreo
Esența funcției este că va împiedica pornirea telefonului dacă detectează că dispozitivul a fost retrogradat la o versiune anterioară, acum neaprobată, de software, care a fost considerată nesigură din cauza unei securități vulnerabilitate. O explicație ceva mai tehnică este că structura de date VBMeta, care conține hash-ul pentru partiția de boot și metadatele hashtree pentru partițiile de sistem și de furnizor, utilizează un index de rollback pentru a respinge imaginile care au o derulare mai veche index.
Această caracteristică este prezentă pe dispozitive precum Google Pixel 2, Razer Phone și OnePlus 6, dar nu este prezentă pe multe alte dispozitive precum Samsung Galaxy S9 (deși Samsung oferă propria lor formă de protecție împotriva derulării în Knox.) Acum, Google face funcția obligatorie pentru orice dispozitiv care se lansează cu Android Pie.
Pornire verificată în Android Pie
Conform formulării actualizate din secțiunea „Integritatea dispozitivului” din Documentul de definire a compatibilității, dispozitivele care se lansează cu Android 9 trebuie să accepte Verified Boot.
9.10. Integritatea dispozitivului
Următoarele cerințe asigură transparența stării integrității dispozitivului. Implementări dispozitiv:
- [C-0-1] TREBUIE să raporteze corect prin metoda System API PersistentDataBlockManager.getFlashLockState() dacă starea bootloader-ului permite clipirea imaginii sistemului. Starea FLASH_LOCK_UNKNOWN este rezervată pentru implementările dispozitivelor care fac upgrade de la o versiune anterioară de Android, unde această nouă metodă API de sistem nu exista.
- [C-0-2] TREBUIE să accepte Verified Boot pentru integritatea dispozitivului.
Dacă implementările dispozitivului sunt deja lansate fără a accepta Verified Boot pe o versiune anterioară de Android și nu pot adăuga suport pentru această caracteristică cu o actualizare a software-ului de sistem, acestea POT fi exceptate de la cerinţă.
...
- [C-1-10] TREBUIE să implementeze protecție împotriva derulării pentru partițiile utilizate de Android (de exemplu, boot, partiții de sistem) și utilizați stocarea cu dovezi de falsificare pentru stocarea metadatelor utilizate pentru determinarea sistemului de operare minim permis versiune.
- TREBUIE să implementeze protecție împotriva derulării pentru orice componentă cu firmware persistent (de exemplu, modem, cameră) și TREBUIE să folosească stocarea cu dovezi de falsificare pentru stocarea metadatelor utilizate pentru determinarea minimului permis versiune.
După cum puteți vedea în ultimele două seturi de puncte, există o avertizare de reținut. Protecția împotriva derulării este necesară pentru partițiile utilizate de Android (pornire, sistem, furnizor etc.), dar nu și pentru partițiile cu firmware persistent (modem, cameră, etc.). Fostul set de partiții este locul unde sunt descoperite și corectate cele mai multe dintre vulnerabilitățile de securitate, așa că este plăcut să vedem că protejarea acestor partiții este obligatorie. Cu toate acestea, au existat exploatări care vizează și partițiile cu firmware persistent, așa că nu suntem siguri de ce Google nu impune protecție împotriva derulării acestora.
Membru senior XDA npjohnson, un membru al echipei LineageOS, speculează că necesitatea protecției de rollback pe partițiile cu firmware persistent ar fi necesită conexiuni Secondary Bootloader (SBL) și eXtensible Bootloader (XBL), deoarece aceste partiții sunt montate mai devreme în pornire proces. Ar fi costisitor pentru OEM mai mici să implementeze XBL-uri personalizate pentru a se potrivi cu modemurile personalizate și alte partiții persistente, deci, poate că Google nu face din aceasta o cerință pentru a face mai ușor pentru producătorii de dispozitive să îndeplinească cele mai recente cerințe în CDD.
Cum să verificați dacă telefonul dvs. acceptă AVB 2.0
Există două comenzi shell ADB pe care le puteți utiliza pentru a verifica dacă telefonul dvs. acceptă AVB 2.0.
adb shell
dumpsys package | grep "verified_boot"SAU
adb shell
getprop | grep "avb"Dacă rezultatul primei comenzi este „android.software.verified_boot”, atunci AVB 2.0 este acceptat. Dacă rezultatul celei de-a doua comenzi arată „[ro.boot.avb_version]” și „[ro.boot.vbmeta.avb_version]” și afișează un număr de versiune pentru fiecare, atunci este acceptat.
Pornire verificată și dezvoltare personalizată
Android Verified Boot nu afectează cu adevărat majoritatea utilizatorilor de ROM personalizate, deși adaugă un strat suplimentar de securitate pe care trebuie să o rezolvi în unele cazuri. De exemplu, afișează intermitent o imagine de sistem generică necesită dezactivarea AVB. Modificarea anumitor partiții, cum ar fi furnizorul de pe OnePlus 6, necesită și dezactivarea AVB, după cum am aflat recent. Conform npjohnson, AVB 2.0 implementat corect face posibil ca imaginile de boot personalizate să funcționeze cu un bootloader blocat. Vom vedea cum includerea AVB 2.0 pe dispozitivele livrate cu Android Pie afectează peisajul, dar sperăm că nu va duce la situații precum sperietură de cărămidă recentă în comunitatea Xiaomi Redmi Note 5 Pro. Obligatoriu AVB 2.0 este doar o altă modalitate pentru Google îmbunătățiți securitatea platformei Android, dar cea mai mare schimbare, din punctul nostru de vedere, este reelaborarea acordurilor OEM pentru a impune corecții regulate de securitate.