Gadgetshowto
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 grundigt ikke-påtrængende måde og har langsomt øget sin synlighed i de nyere udgivelser af sit Android-operativsystem.
I de sidste par dage har vi set nyheder om tilstedeværelsen af en ”Strengt håndhævet bekræftet boot”I Googles seneste iteration af verdens mest anvendte mobile OS. Android Nougat bruger et højere sikkerhedskontrolniveau, når din enhed starter op. Mens Verified Boot kun gav brugeren en advarsel på Marshmallow, hvis det opdagede noget galt med systempartitionen, vil Android Nougat tage det et skridt videre og bruge det, som Google kalder en "Strictly Enforced Verified Boot", som vil tillad ikke at enheden starter overhovedet, hvis den registrerer uregelmæssigheder i partitionen, ændringer foretaget i bootloaderen eller tilstedeværelsen af en "ondsindet" kode i enheden. Dette rejser spørgsmålet: "Hvad betyder det nøjagtigt for brugerne?", Viser sig, svaret adskiller sig for de to hovedkategorier af Android-brugere (casual og power-brugere), og vi vil give svaret til dem begge.
Strengt håndhævet bekræftet boot
For det første en lille baggrund om Verified Boot: Når Android kører en verifikationstest på partitioner, gør det det ved at opdele partitionerne i 4KiB-blokke og kontrollere dem mod en underskrevet tabel. Hvis alt tjekker ud, betyder det, at systemet er helt rent. Men hvis nogle blokke kommer til at blive manipuleret med eller korrupte, informerer Android brugeren om problemerne og overlader det til brugeren at løse det (eller ej).
Alt der er ved at ændre sig med Android Nougat og Strictly Enforced Verified Boot. Når Verified Boot kører i tvungen tilstand, er det tåler ikke fejl i skillevægge. Hvis det registrerer nogen problemer, det tillader ikke enheden at starte op, og magt tillad brugeren at starte i en miljø i sikker tilstand, for at prøve at rette problemerne. Strictly Enforced Verified Boot er dog ikke kun en kontrol mod dårlige datablokke. Det kan normalt også rette fejl i datablokke. Dette er muliggjort ved tilstedeværelsen af Forward Error Correcting-koder, der kan bruges til at rette fejl i datablokke. Dette kan dog ikke altid fungere, og i tilfælde hvor det ikke gør det, er du stort set død i vandet.
Strengt håndhævet verificeret boot: The Good, The Bad og The Ugly
1. Det gode
Håndhævelse af bekræftet opstart på Android-enheder vil forbedre sikkerheden på enhederne. Hvis enheden bliver inficeret med malware, registrerer Strictly Enforced Verified Boot 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å tjek for datakorruption, og i de fleste tilfælde vil det være i stand til at rette eventuelle fejl, der er introduceret i dataene takket være FEC-koder. Google bruger FEC-koder, der kan rette en ukendt bitfejl i 255 bit. Sikker på, det virker som et ret lille antal, men lad os sætte det i perspektiv med hensyn til en mobilenhed:
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 været i stand til at rette 16 ukendte bitfejl i 255 bit, men pladsomkostningerne på grund af de 32 bit overflødige data ville have været næsten 15%, og det er meget, især på mobile enheder. Tilføj det til det faktum, at Android er det dominerende operativsystem på budget-smartphones, der leveres med 4-8 GB hukommelser, og 15% ekstra plads sikkert virker som meget.
Ved at ofre fejlkorrektionsfunktioner 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 pladsoverhead er kun 0,8%.
Bemærk: RS (255, N) er en repræsentation af Reed-Solomon-koder, som er en type fejlkorrektionskoder.
2. Det dårlige
Nogensinde hørt om "Der er to sider ved en mønt"? Selvfølgelig har du det. Mens Googles intentioner med Strictly Enforced Verified Boot uden tvivl var rene som en enhjørning til baby, kommer de med deres eget sæt problemer.
Når strengt håndhævet bekræftet opstart kontrollerer for malware, det kontrollerer også for ulovlige ændringer til kernen, bootloaderen og andre ting, som jeg ikke keder dig med, men det betyder, at Android Nougat sandsynligvis vil støde på mange problemer med rooting og blinkende tilpassede ROM'er, fordi Verified Boot ikke kan skelne mellem uønsket malware-kode, og koden, der låste din bootloader op. Hvilket betyder, at hvis din enhed kom med en låst bootloader, og din OEM ikke tillader låsning af bootloader, kan du stort set ikke gøre det. Forhåbentlig vil nogen finde ud af en udnyttelse af dette.
Heldigvis går de fleste mennesker, der rodfæster deres enheder, og blinker brugerdefinerede ROM'er for de ekstra funktioner og funktionalitet, med udviklervenlige telefoner, såsom Nexus. Der er meget at overveje med hensyn til dette emne, og det er bestemt ikke afslutningen på brugerdefinerede ROM'er, i det mindste ikke på enheder, der kommer med en ulåst bootloader, eller som tillader låsning af bootloaderen. Enheder som Samsung-telefoner tillader dog ikke officielt låsning af bootloader, og på disse enheder vil oplåsning af din bootloader helt sikkert blive betragtet som "et problem" af Verified Boot, hvilket forhindrer enheden i at starte op.
Et andet problem, der vil opstå med Strictly Enforced Verified Boot, er et problem, der vil påvirke selv de brugere, der ikke rigtig bryr sig om at få rodrettigheder eller installere brugerdefinerede ROM'er. Over tid, når du bruger din enhed, er der sandsynligvis naturlig datakorruption i hukommelsen; ikke på grund af tilstedeværelsen af en malware, men simpelthen fordi det sker. Dette er normalt ikke et problem, eller i det mindste ikke et så alvorligt problem, som Verified Boot vil gøre det til. Hvis du har korrupte data, som Strictly Enforced Verified Boot ikke kan rette ved opstart, tillader det ikke din enhed at starte op. Efter min mening er det et større og mere synligt problem end nogle korrupte data på brugerpartitionen.
3. Den grimme
I alle fordelene ved at håndhæve Verified Boot og alle de potentielle problemer er sandsynligvis det mest foruroligende, at OEM'er måske begynder at misbruge dette for at låse deres enheder, så folk ikke er i stand til at bruge Android til det, det var meningen at være: åben, udviklervenlig og fuldstændig tilpasselig. Strictly Enforced Verified Boot vil give OEM'erne hænderne, der er i stand til at sikre, at folk ikke er i stand til at låse op bootloaderne på deres enheder og derved forbyde dem at installere brugerdefinerede ROM'er og funktioner, der forbedrer funktioner som Xposed-moduler..
SE OGSÅ: Ingen Android N Custom ROM tilgængelig? Vi har løsningen til dig
Android Nougat: En radikal ændring i den måde, Android fungerer på?
Selvom vi er sikre på, at Googles intentioner simpelthen var at undgå potentielle problemer for afslappede Android-brugere, som ikke ville vide, hvad de skulle gøre, hvis deres enhed blev påvirket af en malware, eller hvis deres hukommelse havde ødelagt datablokke, kan det have givet OEM'ere og producenten er det perfekte værktøj til at låse brugerne i at leve med det, de blev tilbudt, og intet mere.
Selvfølgelig vil nogen finde ud af en udnyttelse eller en løsning på denne situation, og vi håber ganske godt, at de gør det i den sande ånd af Android. Indtil nogen finder ud af en løsning, er alt, hvad vi, som brugere kan gøre, dog sikre, at vi køber vores enheder fra udviklervenlige producenter.
Fremhævet billede med tilladelse: Flickr
