Android Oreos återställningsskydd krävs på telefoner som lanseras med Android Pie

Android Pie (Android 9) gick precis live idag för Google Pixel, Google Pixel 2 och även Viktig telefon. Vi lär oss så mycket vi kan om releasen från intervjuer (Google Pixel 3 kommer bara att ha gestnavigering!), den AOSP-kod släpp, och slutligen kompatibilitetsdefinitionsdokumentet (CDD). Vi skrev om en ny funktion för "tungvikts"-appar tidigare idag, men nu har vi upptäckt att Google har ändrat sin formulering på en funktion som introducerades i Android Oreo: rullningsskydd. Funktionen möjliggörs av Android Verified Boot 2.0 (även känd som Verified Boot), men OEM-tillverkare behövde inte implementera AVB 2.0 i Oreo-versionen. Nu kräver Google att alla enheter som lanseras med Android Pie stödjer Verified Boot och i förlängningen återställningsskydd.

Återställningsskydd i Android Oreo

Kärnan i funktionen är att den kommer att förhindra din telefon från att starta om den upptäcker att enheten har nedgraderats till en tidigare, nu ogodkänd version av programvara som har ansetts osäker på grund av en säkerhet sårbarhet. En lite mer teknisk förklaring är att VBMeta-datastrukturen, som innehåller hashen för startpartitionen och hashtree-metadata för system- och leverantörspartitioner, använder ett återställningsindex för att avvisa bilder som har en äldre återställning index.

Den här funktionen finns på enheter som Google Pixel 2, Razer Phone och OnePlus 6 men finns inte på många andra enheter som Samsung Galaxy S9 (även om Samsung erbjuder sin egen form av rullningsskydd i Knox.) Nu gör Google funktionen obligatorisk för alla enheter som lanseras med Android Pie.

Verifierad start i Android Pie

Enligt den uppdaterade formuleringen i avsnittet "Enhetsintegritet" i kompatibilitetsdefinitionsdokumentet måste enheter som startar med Android 9 stödja Verified Boot.

9.10. Enhetens integritet

Följande krav säkerställer att det finns insyn i statusen för enhetens integritet. Enhetsimplementationer:

• [C-0-1] MÅSTE korrekt rapportera via System API-metoden PersistentDataBlockManager.getFlashLockState() om deras startladdartillstånd tillåter flashning av systemavbildningen. Tillståndet FLASH_LOCK_UNKNOWN är reserverat för enhetsimplementeringar som uppgraderas från en tidigare version av Android där denna nya system-API-metod inte fanns.
• [C-0-2] MÅSTE stödja Verified Boot för enhetsintegritet.

Om enhetsimplementeringar redan har lanserats utan att stödja Verified Boot på en tidigare version av Android och inte kan lägga till stöd för den här funktionen med en uppdatering av systemprogramvara, KAN de undantas från krav.

...

• [C-1-10] MÅSTE implementera återställningsskydd för partitioner som används av Android (t.ex. start, systempartitioner) och använda manipuleringssäker lagring för att lagra metadata som används för att bestämma det lägsta tillåtna operativsystemet version.
• SKA implementera återställningsskydd för någon komponent med beständig firmware (t.ex. modem, kamera) och BÖR använda manipuleringssäker lagring för att lagra metadata som används för att bestämma det lägsta tillåtna version.

Som du kan se i de två sista uppsättningarna av punktpunkter finns det en varning att notera. Återställningsskydd krävs för partitioner som används av Android (start, system, leverantör, etc.) men inte för partitioner med beständig firmware (modem, kamera, etc.). Den tidigare uppsättningen av partitioner är där de flesta säkerhetsbristerna upptäcks och korrigeras så det är trevligt att se att skyddet av dessa partitioner är obligatoriskt. Det har dock förekommit exploateringar som också riktar sig mot partitioner med beständig firmware, så vi är osäkra på varför Google inte kräver återställningsskydd för dem.

Seniormedlem i XDA npjohnson, en medlem av LineageOS-teamet, spekulerar i att ett krav på återställningsskydd på partitioner med beständig firmware skulle kräver Secondary Bootloader (SBL) och eXtensible Bootloader (XBL) tie-ins eftersom dessa partitioner är monterade tidigare i uppstarten bearbeta. Det skulle bli dyrt för mindre OEM-tillverkare att implementera anpassade XBL: er för att matcha de skräddarsydda modemen och andra beständiga partitioner, så kanske Google inte gör detta till ett krav för att göra det lättare för enhetstillverkare att uppfylla de senaste kraven i CDD.

Så här kontrollerar du om din telefon stöder AVB 2.0

Det finns två ADB-skalkommandon som du kan använda för att kontrollera om din telefon stöder AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

ELLER

adb shell
getprop | grep "avb"

Om utdata från det första kommandot är "android.software.verified_boot" stöds AVB 2.0. Om utdata från det andra kommandot visar "[ro.boot.avb_version]" och "[ro.boot.vbmeta.avb_version]" och listar ett versionsnummer för varje, så stöds det.

Verifierad start och anpassad utveckling

Android Verified Boot påverkar egentligen inte de flesta anpassade ROM-användare även om det lägger till ett extra lager av säkerhet som du måste kringgå i vissa fall. Till exempel, blinkar en generisk systembild kräver att AVB inaktiveras. För att ändra vissa partitioner som leverantören på OnePlus 6 krävs att AVB också inaktiveras, som jag nyligen lärt mig. Enligt npjohnson, korrekt implementerad AVB 2.0 gör det möjligt för anpassade startavbildningar att fungera med en låst starthanterare. Vi får se hur införandet av AVB 2.0 på enheter som skickas med Android Pie påverkar landskapet, men vi hoppas att det inte leder till situationer som senaste tegelskrämsel i Xiaomi Redmi Note 5 Pro-communityt. Obligatorisk AVB 2.0 är bara ett annat sätt för Google att förbättra Android-plattformens säkerhet, men den största förändringen, enligt vår uppfattning, är omarbetning av OEM-avtal för att kräva regelbundna säkerhetskorrigeringar.