Yurko Brovko
0 
1808
395
Om du har följt utvecklingen inom Android måste du ha hört namnet “Verified Boot” ganska mycket de senaste åren. Google introducerade säkerhetsfunktionen i Android 4.4 (Kitkat) på ett grundligt icke-påträngande sätt och har långsamt ökat synligheten i de nyare versionerna av Android-operativsystemet.
Under de senaste dagarna har vi sett nyheter om förekomsten av en "Strikt tvingad verifierad start”I Googles senaste iteration av världens mest använda mobila operativsystem. Android Nougat kommer att använda en högre säkerhetskontrollnivå när din enhet startar. Medan på Marshmallow, Verified Boot bara gav användaren en varning, om den upptäckte något fel med systempartitionen, kommer Android Nougat att ta det ett steg längre, och använda det som Google kallar en "Strictly Enforced Verified Boot", som kommer låt inte enheten starta upp alls, i händelse av att den upptäcker avvikelser i partitionen, ändringar gjorda i startlasteren eller förekomsten av "skadlig" kod i enheten. Detta ger upphov till frågan: "Vad betyder det exakt för användarna?", Visar sig, svaret skiljer sig åt de två huvudkategorierna för Android-användare (casual och power-användare), och vi kommer att ge svaret för dem båda.
Strikt tvingad verifierad start
Först lite bakgrund om Verified Boot: När Android kör ett verifieringstest på partitioner gör det det genom att dela upp partitionerna i 4KiB-block och kontrollera dem mot ett signerat bord. Om allt checkar ut betyder det att systemet är helt rent. Men om vissa block kommer att bli manipulerade med eller skadade informerar Android användaren om problemen och lämnar det upp till användaren att lösa det (eller inte).
Allt som håller på att förändras med Android Nougat och Strictly Forced Verified Boot. När Verified Boot körs i Enforced-läge är det tål inte några fel i partitionerna. Om det upptäcker några problem, det tillåter inte enheten att starta upp, och makt låt användaren starta om till en säkerhetsmiljö, att försöka korrigera problemen. Strict Enforced Verified Boot är dock inte bara en kontroll mot dåliga datablock. Det kan också vanligtvis korrigera fel i datablock. Detta möjliggörs av förekomsten av framåtfelkorrigeringskoder, som kan användas för att korrigera fel i datablock. Men detta kan inte alltid fungera, och i de fall det inte är, är du ganska död i vattnet.
Strikt tvingad bekräftad boot: The Good, The Bad and The Ugly
1. Det goda
Att verkställa verifierad start på Android-enheter kommer förbättra säkerheten på enheterna. Om enheten smittas av skadlig programvara, kommer Strictly Enforced Verified Boot att upptäcka det nästa gång du startar upp din enhet och antingen fixar den, eller så kan du uppmana dig att göra något åt det.
Den här funktionen kommer också kontrollera om datakorruption, och i de flesta fall kommer det att kunna korrigera eventuella fel som införts i data, tack vare FEC-koderna. Google använder FEC-koder som kan korrigera ett okänt bitfel i 255 bitar. Visst, det verkar som ett ganska litet antal, men låt oss sätta det i perspektiv när det gäller en mobil enhet:
Notera: Värdena nedan är hämtade från blogginlägget av Google Engineer Sami Tolvanen på Android-utvecklare.
Google kunde ha använt RS (255 223) FEC-koder: dessa koder skulle ha kunnat korrigera 16 okända bitfel i 255 bitar, men utrymmet ovanför på grund av de 32 bitarna med redundanta data skulle ha varit nästan 15%, och det är mycket, särskilt på mobila enheter. Lägg till det till det faktum att Android är det dominerande operativsystemet på budgettelefoner som levereras med 4-8 GB minnen, och 15% extra utrymme verkar verkligen mycket.
Genom att offra felkorrigeringsfunktioner, för att spara utrymme, beslutade Google att använda RS (255 253) FEC-koder. Dessa koder kan bara korrigera ett enda okänt fel i 255 bitar, men utrymmet är bara 0,8%.
Notera: RS (255, N) är en representation av Reed-Solomon-koder, som är en typ av felkorrigeringskoder.
2. De dåliga
Har du någonsin hört talas om "Det finns två sidor i ett mynt"? Naturligtvis har du det. Medan Googles avsikter med Strictly Enforced Verified Boot utan tvekan var rena som en enhörning för barn, kommer de med sina egna problem..
När strikt verkställt verifierad start kontrollerar för skadlig programvara, det kontrollerar också efter olagliga ändringar till kärnan, startladdaren och andra saker som jag inte kommer att bära dig med, men det betyder att Android Nougat förmodligen kommer att stöta på många problem med rooting och blinkande anpassade ROM: er, eftersom Verified Boot inte kan skilja mellan oönskad skadlig kod, och koden som låste upp din bootloader. Vilket innebär att om din enhet levererades med en låst bootloader och din OEM inte tillåter upplåsning av bootloader så kan du inte göra det. Förhoppningsvis kommer någon att räkna ut ett utnyttjande för detta.
Tack och lov, de flesta som rotar sina enheter och flashar anpassade ROM-skivor för de extra funktioner och funktionalitet, går med utvecklarvänliga telefoner, till exempel Nexus. Det finns mycket att tänka på när det gäller detta ämne, och det är definitivt inte slutet på anpassade ROM: er, åtminstone inte på enheter som levereras med en olåst bootloader, eller som gör det möjligt att låsa upp bootloader. Men enheter som Samsung-telefoner tillåter inte officiellt upplåsning av bootloader, och på dessa enheter kommer upplåsning av din bootloader definitivt att ses som "ett problem" av Verified Boot, vilket hindrar enheten från att starta upp.
Ett annat problem som kommer att uppstå med Strictly Enforced Verified Boot, är ett som kommer att påverka även de användare som inte riktigt bryr sig om att få root-privilegier eller installera anpassade ROM-skivor. Med tiden, när du använder din enhet, är det säkert att det finns naturlig datakorruption i minnet; inte på grund av förekomsten av en skadlig programvara, utan bara för att det händer. Detta är vanligtvis inte ett problem, eller åtminstone inte så allvarligt problem som Verified Boot kommer att göra det till. Om du har skadade data som Strictly Enforced Verified Boot inte kan fixa vid start, tillåter det inte din enhet att starta upp. Enligt min mening är det ett större, mer synligt problem än vissa korrupta data på användarpartitionen.
3. Den fula
I alla fördelarna med att verkställa Verified Boot, och alla potentiella problem, är det mest störande förmodligen det faktum att OEM-tillverkare kan börja missbruka detta för att låsa sina enheter så att människor inte kan använda Android för vad det var tänkt att vara: öppen, utvecklarvänlig och helt anpassningsbar. Strikt bekräftad verifierad uppstart kommer att få händerna på OEM: er, kraften för att säkerställa att människor inte kan låsa upp startladdarna på sina enheter, och därmed förbjuda dem att installera anpassade ROM och funktionsförbättrande verktyg som Xposed Modules.
SE Också: Ingen Android N Custom ROM tillgänglig? Vi har lösningen åt dig
Android Nougat: En radikal förändring i hur Android fungerar?
Även om vi är säkra på att Googles avsikter helt enkelt var att undvika potentiella problem för tillfälliga Android-användare, som inte skulle veta vad de skulle göra om deras enhet påverkades av en skadlig programvara, eller om deras minne hade skadat datablock, kan det ha gett OEM-tillverkare och tillverkaren är det perfekta verktyget för att låsa användare att leva med det de erbjöds och ingenting mer.
Naturligtvis kommer någon att räkna ut ett utnyttjande, eller en lösning för den här situationen, och vi hoppas verkligen att de gör det i Androids sanna anda. Förrän någon räknar ut en lösning är dock allt vi som användare kan se till att vi köper våra enheter från utvecklarvänliga tillverkare.
Presenterad bild med tillstånd: Flickr