Alle apparaten die worden gestart met Android Pie (Android 9) moeten Verified Boot (Android Verified Boot 2.0) ondersteunen, wat bescherming tegen terugdraaien mogelijk maakt.
Android Pie (Android 9) vandaag pas live gegaan voor de Google Pixel, Google Pixel 2 en zelfs de Essentiële telefoon. We leren zoveel mogelijk over de release uit interviews (de Google Pixel 3 heeft alleen gebarennavigatie!), de AOSP-codedrop, en ten slotte het Compatibility Definition Document (CDD). Wij berichtten over a nieuwe functie voor "zware" apps eerder vandaag, maar nu hebben we ontdekt dat Google hun formulering heeft gewijzigd over een functie die is geïntroduceerd in Android Oreo: bescherming tegen terugdraaien. De functie wordt mogelijk gemaakt door Android-geverifieerde opstart 2.0 (ook gewoon bekend als Verified Boot), maar OEM's hoefden AVB 2.0 niet in de Oreo-release te implementeren. Nu eist Google dat alle apparaten die worden gestart met Android Pie Verified Boot ondersteunen, en bij uitbreiding terugdraaibeveiliging.
Terugdraaibeveiliging in Android Oreo
De essentie van de functie is dat deze voorkomt dat uw telefoon opstart als deze detecteert dat het apparaat is gedowngraded naar een eerdere, nu niet-goedgekeurde versie van software die vanwege een beveiliging als onveilig wordt beschouwd kwetsbaarheid. Een iets meer technische verklaring is dat de VBMeta-gegevensstructuur, die de hash voor de opstartpartitie bevat, en hashtree-metagegevens voor systeem- en leverancierspartities, gebruikt een rollback-index om afbeeldingen te weigeren die een oudere rollback hebben inhoudsopgave.
Deze functie is aanwezig op apparaten zoals de Google Pixel 2, Razer Phone en OnePlus 6, maar is niet aanwezig op veel andere apparaten zoals de Samsung Galaxy S9 (hoewel Samsung wel hun eigen vorm van terugdraaibeveiliging in Knox.) Nu maakt Google de functie verplicht voor elk apparaat dat wordt gestart met Android Pie.
Geverifieerd opstarten in Android Pie
Volgens de bijgewerkte formulering in het gedeelte 'Apparaatintegriteit' in het Compatibiliteitsdefinitiedocument moeten apparaten die worden gestart met Android 9 Verified Boot ondersteunen.
9.10. Apparaatintegriteit
De volgende vereisten zorgen ervoor dat er transparantie is over de status van de apparaatintegriteit. Apparaatimplementaties:
- [C-0-1] MOET correct rapporteren via de System API-methode PersistentDataBlockManager.getFlashLockState() of hun bootloaderstatus het flashen van de systeemimage toestaat. De status FLASH_LOCK_UNKNOWN is gereserveerd voor apparaatimplementaties die upgraden vanaf een eerdere versie van Android waarbij deze nieuwe systeem-API-methode niet bestond.
- [C-0-2] MOET Verified Boot ondersteunen voor apparaatintegriteit.
Als apparaatimplementaties al zijn gestart zonder ondersteuning voor Verified Boot op een eerdere versie van Android en geen ondersteuning voor deze functie kunnen toevoegen met een systeemsoftware-update, KUNNEN ze worden vrijgesteld van de vereiste.
...
- [C-1-10] MOET rollback-beveiliging implementeren voor partities die door Android worden gebruikt (bijvoorbeeld opstarten, systeempartities) en gebruik manipulatiebestendige opslag voor het opslaan van de metagegevens die worden gebruikt voor het bepalen van het minimaal toegestane besturingssysteem versie.
- MOET een terugdraaibeveiliging implementeren voor elk onderdeel met persistente firmware (bijvoorbeeld modem, camera) en MOET manipulatiebestendige opslag gebruiken voor het opslaan van de metagegevens die worden gebruikt voor het bepalen van het minimaal toegestane aantal versie.
Zoals u in de laatste twee reeks opsommingstekens kunt zien, is er één kanttekening. Rollback-beveiliging is vereist voor partities die door Android worden gebruikt (opstarten, systeem, leverancier, enz.), maar niet voor partities met persistente firmware (modem, camera, enz.). In de voormalige set partities worden de meeste beveiligingsproblemen ontdekt en hersteld, dus het is goed om te zien dat het beschermen van deze partities verplicht is. Er zijn echter ook exploits geweest die zich richten op partities met persistente firmware, dus we weten niet zeker waarom Google hiervoor geen terugdraaibeveiliging verplicht stelt.
XDA Senior-lid npjohnson, een lid van het LineageOS-team, speculeert dat het vereisen van rollback-beveiliging op partities met persistente firmware dat wel zou doen vereisen Secondary Bootloader (SBL) en eXtensible Bootloader (XBL) tie-ins, aangezien deze partities eerder in de boot worden aangekoppeld proces. Het zou voor kleinere OEM's duur zijn om aangepaste XBL's te implementeren die passen bij de aangepaste modems en andere persistente partities. dus misschien stelt Google dit niet als vereiste om het voor apparaatfabrikanten gemakkelijker te maken om aan de nieuwste vereisten in de CDD te voldoen.
Hoe u kunt controleren of uw telefoon AVB 2.0 ondersteunt
Er zijn twee ADB-shellopdrachten die u kunt gebruiken om te controleren of uw telefoon AVB 2.0 ondersteunt.
adb shell
dumpsys package | grep "verified_boot"OF
adb shell
getprop | grep "avb"Als de uitvoer van het eerste commando "android.software.verified_boot" is, wordt AVB 2.0 ondersteund. Als de uitvoer van de tweede opdracht "[ro.boot.avb_version]" en "[ro.boot.vbmeta.avb_version]" toont en voor elk een versienummer vermeldt, wordt dit ondersteund.
Geverifieerde opstart- en aangepaste ontwikkeling
Android Verified Boot heeft niet echt invloed op de meeste aangepaste ROM-gebruikers, hoewel het wel een extra beveiligingslaag toevoegt waar je in sommige gevallen omheen moet werken. Bijvoorbeeld, het knipperen van een algemene systeemimage vereist het uitschakelen van AVB. Het wijzigen van bepaalde partities, zoals de leverancier op de OnePlus 6, vereist ook het uitschakelen van AVB, zoals ik onlangs heb vernomen. Volgens npjohnson, correct geïmplementeerd AVB 2.0 maakt het mogelijk dat aangepaste opstartimages werken met een vergrendelde bootloader. We zullen zien hoe de opname van AVB 2.0 op apparaten die worden geleverd met Android Pie het landschap beïnvloedt, maar we hopen dat dit niet resulteert in situaties als de recente metselangst in de Xiaomi Redmi Note 5 Pro-gemeenschap. Verplichte AVB 2.0 is gewoon een andere manier waarop Google dat doet Verbeter de beveiliging van het Android-platform, maar de grootste verandering is volgens ons de herwerking van OEM-overeenkomsten om regelmatige beveiligingspatches verplicht te stellen.