Gadgetshowto
Om du har följt utvecklingen inom Android måste du ha hört namnet “Verified Boot” ganska mycket under 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 sin synlighet i de nyare versionerna av sitt Android-operativsystem.
Under de senaste dagarna har vi sett nyheter om närvaron av en ”Strikt genomdriven verifierad start”I Googles senaste iteration av världens mest använda mobil-operativsystem. Android Nougat kommer att använda en högre säkerhetskontroll när enheten startar upp. Medan på Marshmallow, Verified Boot bara gav användaren en varning, om det 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 att Tillåt inte att enheten startar alls, om den upptäcker avvikelser i partitionen, ändringar som gjorts i startladdaren eller närvaron av "skadlig" kod i enheten. Detta väcker frågan: "Vad betyder detta exakt för användarna?", Visar sig, svaret skiljer sig åt för de två huvudkategorierna av Android-användare (casual och power-användare), och vi kommer att ge svaret för dem båda.
Strikt genomdriven verifierad start
Först en liten bakgrund om Verified Boot: När Android kör ett verifieringstest på partitioner gör det vanligtvis genom att dela upp partitionerna i 4KiB-block och kontrollera dem mot en signerad tabell. Om allt checkar ut betyder det att systemet är helt rent. Men om några block kommer att manipuleras med eller är korrupta, 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 Enforced Verified Boot. När Verified Boot körs i Enforced-läge, görs det tål inga fel i partitionerna. Om det upptäcker några problem, det tillåter inte att enheten startar upp, och makt tillåt användaren att starta upp i en säkerhetsmiljö, för att försöka rätta till problemen. Strictly Enforced Verified Boot är dock inte bara en kontroll mot dåliga datablock. Det kan vanligtvis också korrigera fel i datablock. Detta möjliggörs genom närvaron av Forward Error Correcting-koder, som kan användas för att korrigera fel i datablock. Men det här kan inte alltid fungera, och i fall där det inte gör det är du ganska död i vattnet.
Strictly Enforced Verified Boot: The Good, The Bad and The Ugly
1. Det goda
Genomförande av verifierad start på Android-enheter kommer att förbättra säkerheten på enheterna. Om enheten smittas av skadlig kod, kommer Strictly Enforced Verified Boot att upptäcka det nästa gång du startar upp din enhet och antingen fixar den eller möjligen uppmanar dig att göra något åt det.
Denna funktion kommer också kolla efter datakorruption, och i de flesta fall kommer den att kunna korrigera eventuella fel som införs i data, tack vare FEC-koder. Google använder FEC-koder som kan korrigera ett okänt bitfel på 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 hämtas 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 på grund av 32 bitar redundanta data skulle ha varit nästan 15%, och det är mycket, särskilt på mobila enheter. Lägg till det i det faktum att Android är det dominerande operativsystemet på budget smartphones som levereras med 4-8 GB minnen, och 15% extra utrymme säkert verkar som mycket.
Genom att offra felkorrigeringsfunktioner till förmån för att spara utrymme bestämde Google sig för att använda RS (255 253) FEC-koder. Dessa koder kan endast 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, vilket är en typ av felkorrigeringskoder.
2. Det dåliga
Har du någonsin hört talas om ”Det finns två sidor i ett mynt”? Självklart 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 sin egen uppsättning problem.
When Strictly Enforced Verified Boot söker efter skadlig kod, det söker också efter olagliga modifieringar till kärnan, bootloader och andra saker som jag inte kommer att tråka ut dig med, men det betyder att Android Nougat förmodligen kommer att stöta på många problem med att rota och blinkande anpassade ROM-skivor, 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, 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 blinkar anpassade ROM-skivor för de extra funktionerna och funktionerna, 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-skivor, åtminstone inte på enheter som levereras med en olåst startladdare, eller som tillåter upplåsning av startladdaren. Enheter som Samsung-telefoner tillåter dock inte upplåsning av bootloader officiellt, och på dessa enheter kommer upplåsning av din bootloader definitivt att ses som "ett problem" av Verified Boot, vilket förhindrar att enheten startar.
Ett annat problem som kommer att uppstå med Strictly Enforced Verified Boot, är ett som kommer att påverka även 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, kommer det naturligtvis att finnas naturliga dataskador i minnet. inte på grund av förekomsten av skadlig kod, 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 korrupta data som Strictly Enforced Verified Boot inte kan fixa vid start, kommer det inte att tillåta att din enhet startar upp. Enligt min mening är det en större, mer synlig fråga än en del korrupta data på användarpartitionen.
3. Den fula
I alla fördelarna med att genomföra Verified Boot, och alla potentiella problem, är det mest störande, förmodligen, det faktum att OEM-företag 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. Strictly Enforced Verified Boot kommer att lägga i händerna på OEM: er, makten att säkerställa att människor inte kan låsa upp bootloaders på sina enheter, vilket förbjuder dem att installera anpassade ROM-skivor och funktionsförbättrande verktyg som Xposed Modules.
SE OCH: Ingen Android N anpassad ROM tillgänglig? Vi har lösningen för 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 avslappnade Android-användare, som inte skulle veta vad de skulle göra om deras enhet påverkades av skadlig kod eller om deras minne hade skadat datablock, kan det ha överlämnat OEM-tillverkare och tillverkare är det perfekta verktyget för att låsa användare att leva med vad de erbjöds, och inget mer.
Naturligtvis kommer någon att räkna ut ett utnyttjande eller en lösning för den här situationen, och vi hoppas ganska att de gör det i Androids sanna anda. Tills någon räknar ut en lösning är allt vi, som användare kan göra, dock se till att vi köper våra enheter från utvecklarvänliga tillverkare.
Utvalda bilder med tillstånd: Flickr
![När Larry Page träffade Sergey Brin [Interaktiv infografik]](https://gadgetshowto.com/storage/img/images/when-larry-page-met-sergey-brin-[interactive-infographic].jpg)
