Az Android Pie-vel induló telefonokon az Android Oreo visszaállítási védelme szükséges

Android Pie (Android 9) csak ma indult élőben a Google Pixel, a Google Pixel 2 és a még a Alapvető telefon. A lehető legtöbbet tanulunk az interjúkból való megjelenésről (a Google Pixel 3 csak kézmozdulatokkal történő navigáció lesz!), a AOSP kód ledobása, és végül a Compatibility Definition Document (CDD). Körülbelül a új funkció a „nehézsúlyú” alkalmazásokhoz korábban, de most azt tapasztaltuk, hogy a Google megváltoztatta az Android Oreo-ban bevezetett funkció megfogalmazását: visszagurulás elleni védelem. A funkciót az teszi lehetővé Android Verified Boot 2.0 (más néven Verified Boot), azonban az OEM-eknek nem kellett az AVB 2.0-t implementálniuk az Oreo kiadásban. A Google most előírja, hogy az Android Pie-vel induló összes eszköz támogassa a Verified Boot funkciót, és ennek megfelelően a visszaállítási védelmet.

Visszaállítási védelem az Android Oreo rendszerben

A funkció lényege, hogy megakadályozza a telefon elindulását, ha azt észleli, hogy az eszközt leminősítették. a szoftver egy korábbi, ma már nem jóváhagyott verziójára, amelyet egy biztonság miatt nem biztonságosnak ítéltek meg sebezhetőség. Egy kicsit technikaibb magyarázat az, hogy a VBMeta adatstruktúra, amely tartalmazza a rendszerindító partíció hashét és hashtree metaadatok rendszer- és szállítói partíciókhoz, visszaállítási indexet használ a régebbi visszaállítással rendelkező képek elutasításához index.

Ez a funkció megtalálható az olyan eszközökön, mint a Google Pixel 2, a Razer Phone és a OnePlus 6, de sok más eszközön, például a Samsung Galaxy S9-en nem (bár a Samsung kínálja a saját formáját visszagurulás elleni védelem a Knoxban.) A Google most kötelezővé teszi a funkciót minden Android Pie-t futtató eszközön.

Ellenőrzött rendszerindítás az Android Pie-ben

A kompatibilitásdefiníciós dokumentum „Eszköz integritása” szakaszának frissített megfogalmazása szerint az Android 9 rendszerrel induló eszközöknek támogatniuk kell a Verified Boot-ot.

9.10. Eszköz integritása

A következő követelmények biztosítják az eszköz integritásának állapotának átláthatóságát. Eszköz implementációk:

• [C-0-1] A PersistentDataBlockManager.getFlashLockState() System API metóduson keresztül helyesen jelenteni KELL, hogy a rendszerbetöltő állapotuk lehetővé teszi-e a rendszerkép flashelését. A FLASH_LOCK_UNKNOWN állapot az Android egy korábbi verziójáról frissített eszközmegvalósítások számára van fenntartva, ahol ez az új rendszer API-módszer nem létezett.
• [C-0-2] Támogatnia KELL az ellenőrzött rendszerindítást az eszköz integritásához.

Ha az eszközmegvalósítások már elindultak a Verified Boot támogatása nélkül az Android egy korábbi verzióján és nem tudják támogatni ezt a funkciót rendszerszoftver-frissítéssel, mentesülhetnek az alól követelmény.

...

• [C-1-10] Az Android által használt partíciók (pl. rendszerindítás, rendszerpartíciók) visszaállítási védelmét KELL megvalósítani. és hamisítatlan tárhelyet használjon a minimálisan megengedett operációs rendszer meghatározásához használt metaadatok tárolására változat.
• A visszafordulás elleni védelmet KELL megvalósítani minden állandó firmware-rel rendelkező alkatrésznél (pl. modem, kamera) és Hamisítatlan tárhelyet KELL használni a minimálisan megengedhető mennyiség meghatározásához használt metaadatok tárolására. változat.

Amint az az utolsó két felsorolásból látható, egy figyelmeztetést kell megjegyezni. Visszagörgetés elleni védelem szükséges az Android által használt partíciókhoz (boot, rendszer, szállító stb.), de nem az állandó firmware-rel rendelkező partíciókhoz (modem, kamera stb.). A partíciók korábbi készletében fedezik fel és javítják ki a legtöbb biztonsági rést, így jó látni, hogy ezeknek a partícióknak a védelme kötelező. Vannak azonban olyan kihasználások, amelyek a tartós firmware-rel rendelkező partíciókat is megcélozzák, így nem vagyunk biztosak abban, hogy a Google miért nem írja elő rajtuk a visszaállítási védelmet.

XDA vezető tag npjohnson, a LineageOS csapatának tagja, úgy véli, hogy a visszaállítási védelem megkövetelése a tartós firmware-rel rendelkező partíciókon Másodlagos rendszerbetöltő (SBL) és eXtensible Bootloader (XBL) kapcsolódást igényel, mivel ezek a partíciók korábban fel vannak csatolva a rendszerindítás során folyamat. A kisebb OEM-ek számára költséges lenne a testreszabott XBL-ek megvalósítása, hogy megfeleljenek a testreszabott modemeknek és más állandó partícióknak, így talán a Google nem teszi ezt követelményként, hogy megkönnyítse az eszközgyártók számára a CDD legújabb követelményeinek való megfelelést.

Hogyan ellenőrizhető, hogy telefonja támogatja-e az AVB 2.0-t

Két ADB shell-parancs segítségével ellenőrizheti, hogy telefonja támogatja-e az AVB 2.0-t.

adb shell
dumpsys package | grep "verified_boot"

VAGY

adb shell
getprop | grep "avb"

Ha az első parancs kimenete "android.software.verified_boot", akkor az AVB 2.0 támogatott. Ha a második parancs kimenete a „[ro.boot.avb_version]” és „[ro.boot.vbmeta.avb_version]” értéket mutatja, és mindegyikhez felsorol egy verziószámot, akkor ez támogatott.

Ellenőrzött rendszerindítás és egyedi fejlesztés

Az Android Verified Boot nem igazán érinti a legtöbb egyéni ROM-felhasználót, bár további biztonsági réteget ad hozzá, amelyet bizonyos esetekben meg kell oldani. Például, általános rendszerkép villogása szükséges az AVB letiltása. Bizonyos partíciók, például a OnePlus 6 gyártójának módosításához le kell tiltani az AVB-t is, ahogy nemrég megtudtam. Alapján npjohnson, a megfelelően megvalósított AVB 2.0 lehetővé teszi, hogy az egyéni rendszerindító képek zárolt rendszerbetöltővel működjenek. Meglátjuk, hogy az Android Pie-vel szállított eszközökön az AVB 2.0 beépítése hogyan befolyásolja a tájat, de reméljük, hogy ez nem eredményez olyan helyzeteket, mint közelmúltbeli téglaépítési rémület a Xiaomi Redmi Note 5 Pro közösségben. A kötelező AVB 2.0 csak egy másik lehetőség a Google számára javítja az Android platform biztonságát, de a legnagyobb változás véleményünk szerint az az OEM-megállapodások újradolgozása a rendszeres biztonsági javítások előírása érdekében.