Om du har följt utvecklingen i Android måste du ha hört namnet "Verified Boot" ganska lite 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 dess Android operativsystem.
Under de senaste dagarna har vi sett nyheter om närvaron av en " Strängt Enforced Verified Boot " i Googles senaste iteration av världens mest använda mobila operativsystem. Android Nougat använder en högre säkerhetskontroll när enheten startar upp. Medan Marshmallow, Verified Boot bara gav användaren en varning, om det upptäckte något fel med systempartitionen, kommer Android Nougat ta det ett steg längre och använd vad Google kallar en "Strängt Enforced Verified Boot", vilket kommer att Låt inte enheten starta alls, om det upptäcker avvikelser i partitionen, ändringar som gjorts i startladdaren eller närvaron av "skadlig" kod i enheten. Detta ber om ursprunget: "Vad betyder detta för användarna?", Det visar sig att svaret skiljer sig från de två huvudkategorierna av Android-användare (casual och power users), och vi ska svara för dem båda .
Strängt verkställd Verifierad Boot
Först en liten bakgrund på Verified Boot: När Android kör ett verifieringsprov på partitioner gör det det genom att dela partitionerna i 4KiB-block och kontrollera dem mot ett signerat bord. Om allt checkar ut betyder det att systemet är helt rent. Men om några block kommer att bli manipulerat eller skadat, informerar Android användaren om problemen och lämnar det upp till användaren för att lösa det (eller inte).
Allt som förändras med Android Nougat, och Strictly Enforced Verified Boot. När Verified Boot körs i Enforced-läge tolererar det inte några fel i partitionerna. Om det upptäcker några problem kommer det inte att tillåta enheten att starta upp och kan låta användaren starta upp i en säker miljö för att försöka lösa problemen. Strictly Enforced Verified Boot är dock inte bara en kontroll mot dåliga datablock. Det kan vanligtvis också korrigera fel i datablock. Detta görs genom att det finns felkorrigeringskoder som kan användas för att korrigera fel i datablock. Detta kan dock inte alltid fungera, och i fall då det inte är, är du ganska död i vattnet.
Strängt verkställd Verified Boot: The Good, The Bad and the Ugly
1. Den goda
Fördriva Verified Boot på Android-enheter förbättrar säkerheten på enheterna. Om enheten blir smittad av skadlig programvara, identifieras strängt efterlevd verifierad start nästa gång du startar upp enheten, och antingen fixar den eller berätta eventuellt om att du gör något åt det.
Denna funktion kommer också att kontrollera om data korruption, och i de flesta fall kommer det att kunna korrigera eventuella fel som införs i data, tack vare FEC-koderna. Google använder FEC-koder som kan rätta ett okänt bitfel i 255 bitar . Visst, det verkar som ett ganska litet antal, men låt oss sätta det i perspektiv med avseende på en mobil enhet:
Obs! Nedanstående värden tas från blogginlägget av Google Engineer Sami Tolvanen på Android Developers.
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 på grund av 32 bitar av redundanta data skulle ha varit nästan 15% och det är mycket, särskilt på mobila enheter. Lägg till det på det faktum att Android är det dominerande operativsystemet på budget smartphones som levereras med 4-8 GB minnen, och 15% extra utrymme verkar som en hel del.
Genom att offra felsökningsfunktioner, för att spara utrymme, bestämde 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%.
Obs! RS (255, N) är en representation av Reed-Solomon-koder, som är en typ av felkorrigeringskoder.
2. Den dåliga
Har du någonsin hört talas om "Det finns två sidor på ett mynt"? Naturligtvis har du. Medan Googles avsikt med strängt verkställd verifierad boot utan tvekan var ren som en unicorn, kommer de med sina egna problem.
När strikt kontrollerad Boot kontrollerar skadlig program kontrollerar den också om olagliga modifieringar av kärnan, startladdaren och andra saker som jag inte kommer att dra dig med, men det betyder att Android Nougat troligen kommer att stöta på många problem med rooting och blinkande anpassade ROM-skivor, eftersom Verified Boot inte kan skilja mellan oönskade skadliga kod och koden som låste upp startläsaren. Det betyder att om din enhet kom med en låst bootloader, och din OEM inte tillåter upplåsning av bootloader, kan du ganska mycket 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 bläddrar anpassade ROM-skivor för de extra funktionerna och funktionaliteten, går med utvecklarvänliga telefoner, till exempel Nexus. Det är mycket att tänka på, angående detta ämne, och det är definitivt inte slutet på anpassade ROM-skivor, åtminstone inte på enheter som levereras med en olåst bootloader, eller som låter upplåsning av startlastaren. Apparater som Samsung-telefoner tillåter dock inte officiellt att starta uppladdaren, och på dessa enheter upplåses uppstartsladdaren definitivt som ett "problem" med Verified Boot, vilket hindrar enheten från att starta upp.
Ett annat problem som kommer att uppstå med Strictly Enforced Verified Boot, är en som kommer att påverka även de användare som inte bryr sig om att få root-privilegier eller installera anpassade ROM-skivor. Med tiden, när du använder din enhet, är det nödvändigt att vara naturlig data korruption i minnet; inte på grund av att en skadlig kod finns, men helt enkelt för att det händer. Det här är inte vanligtvis ett problem, eller åtminstone inte lika svårt som Verified Boot kommer att göra det till. Om du har korrumperat data som Strikt Enforced Verified Boot inte kan fixa vid start, tillåter det inte att enheten startar upp. Enligt min mening är det en större, mer synlig fråga än vissa korrupta data på användarpartitionen.
3. Den fula
I alla fördelar med att upprätthålla Verified Boot och alla potentiella problem är störst sannolikt det faktum att OEM-användare kanske börjar missbruka detta för att låsa sina enheter så att människor inte kan använda Android för vad det var meningen att vara: öppen, utvecklarvänlig och helt anpassningsbar. Strikt Enforced Verified Boot kommer att stå i händerna på OEM: er, kraften att se till att människor inte kan låsa upp startladdare på sina enheter och därigenom förbjuda dem från att installera anpassade ROM-skivor och funktioner som förbättrar verktyg som Xposed Modules.
Android Nougat: En radikal förändring i vägen Android Works?
Även om vi är säkra på att Googles avsikt var att undvika potentiella problem för casual Android-användare, vem inte skulle veta vad de skulle göra om deras enhet påverkades av en skadlig kod eller om deras minne hade skadat datablock, kan det ha lämnat OEM och tillverkaren är det perfekta verktyget för att låsa användarna till att leva med vad de erbjöds, och inget mer.
Of course kommer någon att räkna ut ett utnyttjande, eller en lösning för den här situationen, och vi hoppas att de gör det, i Android-sanna anda. Innan någon kan hitta en lösning, kan allt vi, som användare kan göra, se till att vi köper våra enheter från utvecklingsvänliga tillverkare.
Featured Image Courtesy: Flickr
