Všetky zariadenia spúšťané s Android Pie (Android 9) musia podporovať Verified Boot (Android Verified Boot 2.0), čo umožňuje ochranu proti vráteniu.
Android Pie (Android 9) práve dnes vysielali naživo pre Google Pixel, Google Pixel 2 a dokonca aj Základný telefón. O vydaní sa učíme čo najviac z rozhovorov (Google Pixel 3 bude mať iba navigáciu gestami!), pokles kódu AOSPa nakoniec dokument o definícii kompatibility (CDD). Uverejnili sme o a nová funkcia pre „ťažké“ aplikácie dnes už skôr, ale teraz sme zistili, že spoločnosť Google zmenila svoje znenie funkcie zavedenej v systéme Android Oreo: ochrana proti spätnému chodu. Funkciu umožňuje Android Verified Boot 2.0 (známy tiež jednoducho ako Verified Boot), avšak OEM nemuseli implementovať AVB 2.0 vo vydaní Oreo. Google teraz nariaďuje, aby všetky zariadenia spustené so systémom Android Pie podporovali overené spustenie a v rozšírení aj ochranu proti vráteniu.
Ochrana proti vráteniu v systéme Android Oreo
Podstatou funkcie je, že zabráni spusteniu vášho telefónu, ak zistí, že zariadenie bolo znížené na staršiu, teraz neschválenú verziu softvéru, ktorá bola z dôvodu zabezpečenia považovaná za nezabezpečenú zraniteľnosť. Trochu technickejším vysvetlením je, že dátová štruktúra VBMeta, ktorá obsahuje hash pre zavádzací oddiel a metaúdaje hashtree pre systémové oddiely a oddiely dodávateľa, používa index vrátenia na odmietnutie obrázkov so starším vrátením späť index.
Táto funkcia je prítomná na zariadeniach ako Google Pixel 2, Razer Phone a OnePlus 6, ale nie je prítomná na mnohých iných zariadeniach, ako je Samsung Galaxy S9 (hoci Samsung ponúka svoju vlastnú formu ochrana proti spätnému chodu v Knoxe.) Teraz spoločnosť Google robí túto funkciu povinnou pre každé zariadenie so systémom Android Pie.
Overené spustenie v systéme Android Pie
Podľa aktualizovaného znenia v časti „Integrita zariadenia“ v dokumente o definícii kompatibility musia zariadenia, ktoré sa spúšťajú so systémom Android 9, podporovať overené spustenie.
9.10. Integrita zariadenia
Nasledujúce požiadavky zabezpečujú transparentnosť stavu integrity zariadenia. Implementácie zariadení:
- [C-0-1] MUSIA správne nahlásiť prostredníctvom metódy System API PersistentDataBlockManager.getFlashLockState(), či ich stav zavádzača povoľuje blikanie obrazu systému. Stav FLASH_LOCK_UNKNOWN je vyhradený pre implementácie zariadenia inovujúce zo staršej verzie systému Android, kde táto nová metóda systémového rozhrania API neexistovala.
- [C-0-2] MUSÍ podporovať overené spustenie pre integritu zariadenia.
Ak sú implementácie zariadení už spustené bez podpory overeného spustenia v staršej verzii Androidu a nemôžu pridať podporu pre túto funkciu s aktualizáciou systémového softvéru, MÔŽU byť oslobodení od požiadavka.
...
- [C-1-10] MUSÍ implementovať ochranu proti vráteniu pre oddiely používané systémom Android (napr. zavádzacie, systémové oddiely) a na ukladanie metadát používaných na určenie minimálneho povoleného operačného systému použite úložisko s evidenčným neoprávneným zásahom verzia.
- MALI by ste implementovať ochranu pred návratom pre akýkoľvek komponent s trvalým firmvérom (napr. modem, kamera) a MALI by ste na ukladanie metadát používaných na určenie minimálneho prípustného množstva používať úložisko, ktoré je evidentné proti neoprávnenej manipulácii verzia.
Ako môžete vidieť v posledných dvoch sériách odrážok, je potrebné poznamenať jednu výhradu. Ochrana proti vráteniu je potrebná pre oddiely používané systémom Android (boot, systém, dodávateľ atď.), ale nie pre oddiely s trvalým firmvérom (modem, fotoaparát atď.). V bývalej skupine oddielov sa objavuje a opravuje väčšina bezpečnostných nedostatkov, takže je pekné vidieť, že ochrana týchto oddielov je povinná. Vyskytli sa však zneužitia, ktoré sa zameriavajú aj na oddiely s trvalým firmvérom, takže si nie sme istí, prečo na ne Google nenariaďuje ochranu proti vráteniu.
Senior člen XDA npjohnson, člen tímu LineageOS, špekuluje, že by to vyžadovalo ochranu pred návratom na oddiely s pretrvávajúcim firmvérom vyžadujú prepojenie sekundárneho zavádzača (SBL) a eXtensible Bootloader (XBL), pretože tieto oddiely sú pripojené skôr pri zavádzaní proces. Pre menších výrobcov OEM by bolo nákladné implementovať prispôsobené XBL tak, aby zodpovedali prispôsobeným modemom a iným trvalým oddielom, takže možno to Google nerobí ako požiadavku, aby uľahčil výrobcom zariadení splniť najnovšie požiadavky v CDD.
Ako skontrolovať, či váš telefón podporuje AVB 2.0
Existujú dva príkazy prostredia ADB, ktoré môžete použiť na kontrolu, či váš telefón podporuje AVB 2.0.
adb shell
dumpsys package | grep "verified_boot"ALEBO
adb shell
getprop | grep "avb"Ak je výstupom prvého príkazu "android.software.verified_boot", potom je podporovaný AVB 2.0. Ak výstup druhého príkazu zobrazuje „[ro.boot.avb_version]“ a „[ro.boot.vbmeta.avb_version]“ a uvádza číslo verzie pre každý, potom je podporovaný.
Overené zavádzanie a vlastný vývoj
Android Verified Boot skutočne neovplyvňuje väčšinu vlastných používateľov ROM, aj keď pridáva ďalšiu vrstvu zabezpečenia, ktorú musíte v niektorých prípadoch obísť. napr. blikanie všeobecného obrazu systému vyžaduje vypnutie AVB. Úprava určitých oddielov, ako je napríklad dodávateľ na OnePlus 6, vyžaduje aj vypnutie AVB, ako som sa nedávno dozvedel. Podľa npjohnson, správne implementované AVB 2.0 umožňuje, aby vlastné zavádzacie obrazy fungovali s uzamknutým zavádzačom. Uvidíme, ako zahrnutie AVB 2.0 do zariadení dodávaných so systémom Android Pie ovplyvní krajinu, ale dúfame, že to nepovedie k situáciám ako napr. nedávne tehlové strašenie v komunite Xiaomi Redmi Note 5 Pro. Povinné AVB 2.0 je pre Google len ďalším spôsobom zlepšiť zabezpečenie platformy Android, ale najväčšou zmenou je podľa nášho názoru prepracovanie dohôd OEM, aby nariadili pravidelné bezpečnostné záplaty.