Hvis du har fulgt udviklingen i Android, skal du have hørt navnet "Verified Boot" ganske lidt i de sidste par år. Google introducerede sikkerhedsfunktionen i Android 4.4 (Kitkat) på en grundig ikke-påtrængende måde og har langsomt øget synligheden i de nyere udgaver af sit Android-operativsystem.
I de sidste par dage har vi set nyheder om tilstedeværelsen af en " Strengt Enforced Verified Boot " i Googles seneste iteration af verdens mest brugte mobile OS. Android Nougat bruger et højere niveau af sikkerhedskontrol, når enheden starter op. Mens på Marshmallow, Verified Boot kun gav brugeren en advarsel, hvis det opdages noget galt med systempartitionen, vil Android Nougat tage det et skridt videre og bruge, hvad Google kalder en "Strengt Enforced Verified Boot", som vil Lad ikke enheden starte op i det hele taget, hvis det opdager uregelmæssigheder i partitionen, ændringer i bootloaderen eller tilstedeværelsen af "ondsindet" kode i enheden. Dette spørger spørgsmålet: "Hvad betyder det egentlig for brugerne?", Viser sig, at svaret adskiller sig fra de to hovedkategorier af Android-brugere (tilfældige og strømbrugere), og vi skal give svaret for dem begge .
Stramt godkendt verificeret boot
Først en lille baggrund på Verified Boot: Når Android kører en verifikationstest på partitioner, gøres det typisk ved at dividere partitionerne i 4KiB-blokke og kontrollere dem mod en underskrevet tabel. Hvis alt tjekker, betyder det at systemet er helt rent. Men hvis nogle blokke kommer ud for at blive manipuleret eller ødelagt, informerer Android brugeren om problemerne og overlader det til brugeren at løse det (eller ej).
Alt, der er ved at ændre med Android Nougat, og Strictly Enforced Verified Boot. Når Verified Boot kører i Enforced mode, vil det ikke tolerere fejl i partitionerne. Hvis det registrerer problemer, tillader det ikke enheden at starte op og muligvis give brugeren mulighed for at starte i et sikkert tilstands miljø for at forsøge at rette op på problemerne. Strengt Enforced Verified Boot er imidlertid ikke bare en check mod dårlige datablokke. Det kan normalt også rette fejl i datablokke. Dette gøres muligt ved tilstedeværelsen af Forward Error Correcting-koder, der kan bruges til at rette fejl i datablokker. Dette kan dog ikke altid fungere, og i tilfælde, hvor det ikke gør, er du temmelig meget død i vandet.
Strenkt Enforced Verified Boot: The Good, The Bad og The Ugly
1. Den gode
Enforcing Verified Boot på Android-enheder vil øge sikkerheden på enhederne. Hvis enheden bliver smittet af skadelig software, vil Strictly Enforced Verified Boot detektere det næste gang du starter din enhed op, og enten retter den eller muligvis beder dig om at gøre noget ved det.
Denne funktion vil også kontrollere, om data korruption, og i de fleste tilfælde vil det være i stand til at korrigere eventuelle fejl indført i dataene takket være FEC koderne. Google bruger FEC-koder, der kan rette en ukendt bitfejl i 255 bits . Visst, det ser ud som et smukt lille nummer, men lad os sætte det i perspektiv med hensyn til en mobil enhed:
Bemærk: Værdierne nedenfor er taget fra blogindlægget af Google Engineer Sami Tolvanen på Android-udviklere.
Google kunne have brugt RS (255, 223) FEC koder: Disse koder ville have kunnet rette 16 ukendte bitfejl i 255 bit, men pladsen overhead på grund af de 32 bit redundante data ville have været næsten 15% og det er meget, især på mobile enheder. Tilføj det til, at Android er det overvejende OS på budget smartphones, der leveres med 4-8 GB minder, og 15% ekstra plads sikkert virker som en masse.
Ved at ofre fejlkorrigerende evner til fordel for at spare plads besluttede Google at bruge RS (255.253) FEC-koder. Disse koder kan kun rette en enkelt ukendt fejl i 255 bit, men rumoverhead er kun 0, 8%.
Bemærk: RS (255, N) er en repræsentation af Reed-Solomon koder, som er en type fejlkorrigeringskoder.
2. Den dårlige
Nogensinde hørt om "Der er to sider til en mønt"? Selvfølgelig har du. Mens Googles hensigter med strengt håndhævet verificeret boot var uden tvivl ren som en enheds enhjørning, kommer de med deres egne problemer.
Når der kontrolleres strengt bekræftet Boot for malware, kontrollerer den også for ulovlige ændringer af kernen, bootloaderen og andre ting, som jeg ikke vil bore dig med, men det betyder, at Android Nougat sandsynligvis vil støde på mange problemer med rooting, og blinkende brugerdefinerede ROM'er, fordi Verified Boot ikke kan skelne mellem uønsket malwarekode og den kode, der låste op for din startlader. Hvilket betyder, at hvis din enhed kom med en låst bootloader, og din OEM ikke tillader bootloader låse op, kan du stort set ikke gøre det. Forhåbentlig vil nogen finde ud af en udnyttelse af dette.
Heldigvis, de fleste mennesker, der driver deres enheder, og flash tilpassede ROM'er til de ekstra funktioner og funktionalitet, går med udviklervenlige telefoner, som f.eks. Nexus. Der er meget at overveje, hvad angår dette emne, og det er bestemt ikke slutningen på brugerdefinerede ROM'er, i det mindste ikke på enheder, der følger med en ulåst bootloader, eller som tillader låseoploaderen. Imidlertid tillader enheder som Samsung-telefoner ikke officielt opstart af opladeren, og på disse enheder vil unlocking af din bootloader absolut ses som et "problem" ved Verified Boot, hvilket forhindrer enheden i at starte op.
Et andet problem, der vil opstå med Strengt Enforced Verified Boot, er en, der vil påvirke selv de brugere, der ikke rigtig bekymrer sig om at få rodrettigheder eller installere brugerdefinerede ROM'er. Over tid, som du bruger din enhed, er der bundet til at være naturlig data korruption i hukommelsen; ikke på grund af tilstedeværelsen af en malware, men simpelthen fordi det sker. Dette er normalt ikke et problem, eller i hvert fald ikke så alvorligt et problem som Verified Boot vil gøre det til. Hvis du har korrumperet data, som Strictly Enforced Verified Boot ikke kan løse ved opstart, tillader det ikke din enhed at starte op. Det er efter min opfattelse et større, mere synligt problem end nogle korrupte data på brugerpartitionen.
3. Den grimme
I alle fordele ved at håndhæve Verified Boot og alle de potentielle problemer er det mest foruroligende sandsynligvis det faktum, at OEM'er kan begynde at misbruge dette for at låse deres enheder, så folk ikke kan bruge Android til, hvad det var meningen at være: åben, udviklervenlig og helt tilpasselig. Strengt Enforced Verified Boot vil sætte hænderne på OEM'er i stand til at sikre, at folk ikke er i stand til at låse bootloadersne på deres enheder, hvilket forbyder dem at installere tilpassede ROM'er og funktionstegningsværktøjer som Xposed Modules.
Android Nougat: En radikal ændring i vejen Android Works?
Selv om vi er sikre på, at Googles hensigter simpelthen var at undgå potentielle problemer for casual Android-brugere, hvem der ikke ville vide, hvad de skal gøre, hvis deres enhed blev påvirket af en skadelig software eller hvis deres hukommelse havde ødelagt datablokke, kan det have overdraget OEM'er og producenten er det perfekte værktøj til at låse brugerne i at leve med det, de blev tilbudt, og ikke mere.
Selvfølgelig vil nogen finde ud af en udnyttelse eller en løsning på denne situation, og vi håber, at de gør det, i Android 's sande ånd. Indtil nogen finder ud af en løsning, er alt, hvad vi som brugerne kan sikre, at vi køber vores enheder fra udviklervenlige producenter.
Featured Image Courtesy: Flickr
