Hvis du har fulgt utviklingen i Android, må du ha hørt navnet "Verified Boot" ganske mye de siste par årene. Google introduserte sikkerhetsfunksjonen i Android 4.4 (Kitkat), på en grundig, ikke-påtrengende måte, og har sakte økt synligheten i nyere utgaver av Android-operativsystemet.
I løpet av de siste dagene har vi sett nyheter om tilstedeværelsen av en " Strengt Enforced Verified Boot " i Googles siste iterasjon av verdens mest brukte mobile OS. Android Nougat vil bruke høyere sikkerhetskontroll når enheten starter opp. Mens på Marshmallow, Verified Boot bare ga brukeren en advarsel, i tilfelle det oppdaget noe galt med systempartisjonen, vil Android Nougat ta det et skritt videre, og bruk det som Google kaller en "Strengt Enforced Verified Boot", som vil Ikke la enheten starte opp i det hele tatt, hvis den oppdager anomalier i partisjonen, endringer som er gjort i oppstartslederen eller tilstedeværelsen av "ondsinnet" kode i enheten. Dette spørsmålet: "Hva betyr dette egentlig for brukerne?", Viser seg at svaret er forskjellig for de to hovedkategorier av Android-brukere (uformelle og strømbrukere), og vi skal gi svaret for dem begge .
Strengt etterlyst Verified Boot
Først en liten bakgrunn på Verified Boot: Vanligvis, når Android kjører en verifiseringstest på partisjoner, gjør den det ved å dele partisjonene i 4KiB-blokker og sjekke dem mot en signert tabell. Hvis alt sjekker ut, betyr det at systemet er helt rent. Men hvis noen blokker kommer ut for å bli manipulert med, eller korrupte, informerer Android brukeren om problemene og overlater det til brukeren å løse det (eller ikke).
Alt som skal endres med Android Nougat, og Strictly Enforced Verified Boot. Når Verified Boot kjører i Enforced-modus, vil det ikke tolerere noen feil i partisjonene. Hvis det oppdager noen problemer, vil det ikke tillate enheten å starte opp, og kan tillate brukeren å starte opp i et trygt modus-miljø for å prøve å rette opp problemene. Imidlertid er Strengt Enforced Verified Boot ikke bare en kontroll mot dårlige datablokker. Det kan også korrigere feil i datablokker. Dette gjøres mulig ved tilstedeværelse av Forward Error Correcting-koder, som kan brukes til å rette feil i datablokker. Dette kan imidlertid ikke alltid fungere, og i tilfeller der det ikke er, er du ganske mye død i vannet.
Strengt etterlyst Verified Boot: The Good, The Bad og The Ugly
1. Den gode
Enforcing Verified Boot på Android-enheter vil øke sikkerheten på enhetene. Hvis enheten blir smittet av skadelig programvare, vil Strictly Enforced Verified Boot oppdage det neste gang du starter opp enheten din, og enten fikser den, eller ber deg om mulig å gjøre noe med det.
Denne funksjonen vil også sjekke om data korrupsjon, og i de fleste tilfeller vil det være i stand til å rette eventuelle feil innført i dataene, takket være FEC-kodene. Google bruker FEC-koder som kan korrigere en ukjent bitfeil i 255 biter . Visst, det virker som et ganske lite nummer, men la oss sette det i perspektiv, med hensyn til en mobil enhet:
Merk: Verdiene nedenfor er hentet fra bloggposten av Google Engineer Sami Tolvanen på Android-utviklere.
Google kunne ha brukt RS (255, 223) FEC-koder: Disse koder ville ha kunnet korrigere 16 ukjente bitfeil i 255 biter, men mellomrommet på grunn av de 32 bitene redundante data ville ha vært nesten 15% og det er mye, spesielt på mobile enheter. Legg til det ved at Android er det overordnede operativsystemet på budsjett-smarttelefoner som sender med 4-8 GB minner, og 15% ekstra plass sikkert virker som mye.
Ved å ofre feilkorrigerende evner, for å spare plass, bestemte Google seg for å bruke RS (255, 253) FEC-koder. Disse kodene kan bare rette en enkelt ukjent feil i 255 biter, men mellomrom er bare 0, 8%.
Merk: RS (255, N) er en representasjon av Reed-Solomon-koder, som er en type feilkorrigeringskoder.
2. Den dårlige
Noen gang hørt om "Det er to sider på en mynt"? Selvfølgelig har du. Mens Googles hensikter med strengt håndhevet bekreftet oppstart var uten tvil ren som en enhjørning, kommer de med sitt eget sett med problemer.
Når kontrollert støt kontrolleres for stramt godkjent, kontrollerer den også for ulovlige endringer i kjernen, oppstartsladeren og andre ting som jeg ikke vil bore deg med, men det betyr at Android Nougat trolig støter på mange problemer med rooting, og blinkende egendefinerte rom, fordi verifisert oppstart ikke kan skille mellom uønsket skadelig programvarekode og koden som låst opp opplastingsprogrammet ditt. Det betyr at hvis enheten din kom med en låst oppstartslader, og din OEM ikke tillater opplåsing av opplaster, kan du ganske enkelt ikke gjøre det. Forhåpentligvis vil noen finne ut en utnyttelse for dette.
Heldigvis, de fleste som roter deres enheter, og blinker tilpassede ROM-er for de ekstra funksjonene og funksjonaliteten, går med utviklervennlige telefoner, for eksempel Nexus. Det er mye å vurdere, angående dette emnet, og det er definitivt ikke slutten på egendefinerte ROM-er, i det minste ikke på enheter som følger med en ulåst opplasting, eller som tillater opplåsing av opplasteren. Imidlertid tillater enheter som Samsung-telefoner ikke offisielt opplåsing av opplaster, og på disse enhetene vil opplåsing av opplastingsprogrammet ditt mest definitivt bli sett på som et "problem" ved Verified Boot, slik at enheten ikke starter opp.
Et annet problem som vil oppstå med Strengt Enforced Verified Boot, er en som vil påvirke til og med brukerne som ikke bryr seg om å få root-privilegier eller installere egendefinerte ROMer. Over tid, når du bruker enheten din, er det nødvendig å være naturlig data korrupsjon i minnet; ikke på grunn av tilstedeværelse av en skadelig programvare, men bare fordi det skjer. Dette er vanligvis ikke et problem, eller i det minste ikke så alvorlig et problem som Verified Boot vil gjøre det til. Hvis du har ødelagt data som Strengt Enforced Verified Boot ikke kan fikse ved oppstart, vil det ikke tillate at enheten din starter opp. Etter min mening er det et større, mer synlig problem enn noen korrupte data på brukerpartisjonen.
3. Den stygge
I alle fordelene med å håndheve Verified Boot, og alle de potensielle problemene, er det mest forstyrrende at sannsynligvis at OEMer kan misbruke dette for å låse enhetene slik at folk ikke kan bruke Android for hva det var ment å være: åpen, utvikler-vennlig og helt tilpassbar. Strengt Enforced Verified Boot vil sette i hendene på OEMer, kraften til å sikre at folk ikke kan låse opp opplastingsprogrammene på enhetene deres, og dermed forbyr dem å installere egendefinerte ROMer og funksjoner som forbedrer verktøy som Xposed Modules.
Android Nougat: En radikal endring i veien Android Works?
Selv om vi er sikre på at Googles hensikter var rett og slett for å unngå potensielle problemer for uformelle Android-brukere, hvem som ikke ville vite hva de skulle gjøre i tilfelle enheten ble påvirket av en skadelig programvare, eller hvis minnet hadde ødelagt datablokker, kan det ha levert OEMer og produsenten er det perfekte verktøyet for å låse brukerne i å leve med det de ble tilbudt, og ingenting mer.
Selvfølgelig vil noen finne ut en utnyttelse eller en løsning på denne situasjonen, og vi håper de gjør, i den sanne ånden til Android. Inntil noen finner ut en løsning, er alt vi, som brukere kan gjøre, sikre at vi kjøper våre enheter fra utvikler-vennlige produsenter.
Utvalgte bilder Courtesy: Flickr
