Hvad er strengt håndhævet bekræftet boot i Android Nougat?

Hvis du har fulgt udviklingen i Android, skal du have hørt navnet “Verified Boot” en hel del 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 niveau af sikkerhedskontrol, når din enhed starter op. Mens Verified Boot på Marshmallow kun gav brugeren en advarsel, i tilfælde af at det opdagede noget galt med systempartitionen, vil Android Nougat tage det et skridt videre og bruge det, som Google kalder en "Strictlyforced Verified Boot", som vil lad ikke enheden starte op i det hele taget, i tilfælde af at det registrerer afvigelser i partitionen, ændringer, der er foretaget i bootloader, eller tilstedeværelsen af ​​"ondsindet" kode på enheden. Dette rejser spørgsmålet: "Hvad betyder det nøjagtigt for brugerne?", Viser det sig, at svaret er forskelligt 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

Først lidt baggrund om Verified Boot: Når Android kører en verifikationstest på partitioner, gør det det ved at dele partitionerne i 4KiB-blokke og kontrollere dem mod et underskrevet bord. Hvis alt tjekker ud, betyder det, at systemet er helt rent. Hvis nogle blokke dog viser sig at blive manipuleret med eller korrupte, informerer Android brugeren om problemerne og overlader det til brugeren at løse det (eller ikke).

Alt, hvad der er ved at ændre sig med Android Nougat og strengt håndhævet bekræftet boot. Når Verified Boot kører i tvungen tilstand, er det tåler ikke nogen fejl i partitionerne. Hvis det registrerer problemer, er det tillader ikke enheden at starte op, og magt lad brugeren starte i et miljø i sikker tilstand, at prøve og rette problemerne. Imidlertid er strengt håndhævet bekræftet boot ikke kun en kontrol af dårlige datablokke. Det kan normalt også rette fejl i datablokke. Dette muliggøres ved tilstedeværelsen af ​​fremadrettede fejlkorrektionskoder, der kan bruges til at rette fejl i datablokke. Dette kan dog ikke altid fungere, og i tilfælde, hvor det ikke er, er du stort set død i vandet.

Strengt håndhævet bekræftet boot: Det gode, det dårlige og det grimme

1. Det gode

Håndhævelse af bekræftet boot på Android-enheder vil forbedre sikkerheden på enhederne. I tilfælde af, at enheden bliver inficeret med malware, registrerer Strictly Enforced Verified Boot den næste gang du starter din enhed op, og enten løser den den, eller muligvis beder dig om at gøre noget ved det.

Denne funktion vil også Kontroller for datakorruption, og i de fleste tilfælde vil det være i stand til at rette eventuelle fejl, der indføres i dataene, takket være FEC-koder. Google bruger FEC-koder, der kan korriger en ukendt bitfejl i 255 bit. Ja, 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 hentet fra blogindlægget af Google Engineer Sami Tolvanen på Android Developers.

Google kunne have brugt RS (255.223) FEC-koder: disse koder ville have været i stand til at korrigere 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. Føj det til det faktum, at Android er det fremherskende operativsystem på budgettet smartphones, der leveres med 4-8 GB minder, og 15% ekstra plads er sikker på at være meget.

Ved at ofre fejlkorrektionskapaciteter til fordel for at spare plads besluttede Google at bruge RS (255.253) FEC-koder. Disse koder kan kun korrigere en enkelt ukendt fejl i 255 bit, men mellemrummet er kun 0,8%.

Bemærk: RS (255, N) er en repræsentation af Reed-Solomon-koder, som er en type fejlkorrektionskoder.

2. Den dårlige

Har du nogensinde hørt om "Der er to sider af en mønt"? Selvfølgelig har du det. Mens Googles intentioner med strengt håndhævet bekræftet boot uden tvivl var rene som en babyhjørning, kommer de med deres eget sæt af problemer.

Når strengt håndhævet bekræftet boot tjekker for malware, det tjekker også for ulovlige ændringer til kernen, bootloader og andre ting, som jeg ikke vil kede dig med, men dette betyder, at Android Nougat sandsynligvis vil støde på en masse problemer med rodfæstning og blinkende brugerdefinerede 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 leveres med en låst bootloader, og din OEM ikke tillader oplåsning af bootloader, kan du stort set ikke gøre det. Forhåbentlig er der nogen, der regner med en udnyttelse af dette.

Heldigvis er de fleste mennesker, der rodder deres enheder og blinker brugerdefinerede rom'er til 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 slutningen på brugerdefinerede rom'er, i det mindste ikke på enheder, der leveres med en ulåst bootloader, eller som tillader at låse bootloader op. Enheder som Samsung-telefoner tillader dog ikke officielt oplåsning af bootloader, og på disse enheder vil oplåsning af din bootloader helt sikkert blive set som et "problem" fra Verified Boot, hvilket forhindrer enheden i at starte op.

Et andet problem, der vil opstå med Strictly Enforced Verified Boot, er et, der vil påvirke selv de brugere, der ikke rigtig bryder sig om at få rodprivilegier eller installere brugerdefinerede ROM. Når du bruger din enhed over tid, er der helt sikkert en naturlig datakorruption i hukommelsen; ikke på grund af tilstedeværelsen af ​​en malware, men blot fordi det sker. Dette er normalt ikke et problem, eller i det mindste ikke så alvorligt et problem som Verified Boot vil gøre det til. Hvis du har korrupte data, som Strictly Enforced Verified Boot ikke kan løse på boot, tillader det ikke din enhed at starte op. Efter min mening er det et større, mere synligt problem end nogle korrupte data på brugerpartitionen.

3. Det grimme

I alle fordelene ved at håndhæve Verified Boot, og alle de potentielle problemer, er det mest foruroligende sandsynligvis det faktum, 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 beregnet til være: åben, udviklervenlig og fuldstændigt tilpasselig. Strengt håndhævet bekræftet boot vil være i hænderne på OEM'er, kraften til at sikre, at folk ikke er i stand til at låse op bootloaders på deres enheder, og derved forbyde dem at installere brugerdefinerede ROMs og funktionsforbedrende værktøjer som Xposed Modules.

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?

Selvom vi er sikre på, at Googles intentioner simpelthen var at undgå potentielle problemer for afslappede Android-brugere, som ikke ville vide, hvad de skal gøre, hvis deres enhed blev påvirket af en malware, eller hvis deres hukommelse havde ødelagte datablokke, kan det have givet OEM'er og producentens det perfekte værktøj til at låse brugerne til 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 vist, at de gør det i Android's sande ånd. Indtil nogen finder ud af en løsning, er alt, hvad vi som brugere kan gøre, at sikre, at vi køber vores enheder fra udviklervenlige producenter.

Udvalgt billede høflighed: Flickr