Hva er strengt håndhevet bekreftet oppstart i Android Nougat?

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 de nyere versjonene av Android-operativsystemet.

De siste par dagene har vi sett nyheter om tilstedeværelsen av enStrengt håndhevet bekreftet oppstart”I Googles siste iterasjon av verdens mest brukte mobile operativsystem. Android Nougat vil bruke et høyere nivå av sikkerhetskontroll når enheten starter opp. Mens, på Marshmallow, Verified Boot bare ga brukeren en advarsel, i tilfelle den oppdaget noe galt med systempartisjonen, vil Android Nougat ta det et skritt videre, og bruke det Google kaller en "Strictly Enforced Verified Boot", som vil ikke la enheten starte opp i det hele tatt, i tilfelle den oppdager uregelmessigheter i partisjonen, endringer som er gjort i bootloaderen, eller tilstedeværelsen av "ondsinnet" kode i enheten. Dette stiller spørsmålet: "Hva betyr dette egentlig for brukerne?", Viser seg, svaret er forskjellig for de to hovedkategoriene av Android-brukere (tilfeldige og strømbrukere), og vi skal gi svaret til dem begge.

Strengt håndhevet bekreftet oppstart

Først litt bakgrunn om Verified Boot: Når Android kjører en bekreftelsestest på partisjoner, gjør det det ved å dele partisjonene i 4KiB-blokker og sjekke dem mot et signert bord. Hvis alt sjekker ut, betyr det at systemet er helt rent. Imidlertid, hvis noen blokker kommer til å bli tuklet med eller ødelagt, informerer Android brukeren om problemene og overlater det til brukeren å løse det (eller ikke).

Alt som er i ferd med å endres med Android Nougat og Strictly Enforced Verified Boot. Når Verified Boot kjører i håndhevet modus, gjøres det tåler ikke feil i partisjonene. Hvis det oppdager noen problemer, det lar ikke enheten starte opp, og kanskje la brukeren starte opp i en safe-mode miljø, for å prøve å rette opp problemene. Strictly Enforced Verified Boot er imidlertid ikke bare en sjekk mot dårlige datablokker. Det kan vanligvis også rette feil i datablokker. Dette er mulig ved tilstedeværelsen av Forward Error Correcting-koder, som kan brukes til å rette feil i datablokker. Dette kan imidlertid ikke alltid fungere, og i tilfeller når det ikke gjør det, er du ganske mye død i vannet.

Strengt håndhevet bekreftet oppstart: The Good, The Bad and The Ugly

1. Det gode

Håndheve bekreftet oppstart på Android-enheter vil forbedre 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 fikse den, eller muligens be deg om å gjøre noe med det.

Denne funksjonen vil også se etter datakorrupsjon, og i de fleste tilfeller vil det være i stand til å korrigere eventuelle feil som er introdusert i dataene, takket være FEC-kodene. Google bruker FEC-koder som kan korrigere en ukjent bitfeil på 255 bits. Visst, det virker som et ganske lite tall, men la oss sette det i perspektiv med hensyn til en mobil enhet:

Merk: Verdiene nedenfor er hentet fra blogginnlegget av Google Engineer Sami Tolvanen på Android-utviklere.

Google kunne ha brukt RS (255 223) FEC-koder: disse kodene ville ha vært i stand til å korrigere 16 ukjente bitfeil på 255 bits, men plassen overhead på grunn av de 32 bitene med overflødige data, ville ha vært nesten 15%, og det er mye, spesielt på mobile enheter. Legg det til det faktum at Android er det dominerende operativsystemet på budsjett smarttelefoner som leveres med 4-8 GB minner, og 15% ekstra plass virker sikkert som mye.

Ved å ofre feilkorrigeringsegenskaper, til fordel for å spare plass, bestemte Google seg for å bruke RS (255 253) FEC-koder. Disse kodene kan bare korrigere en enkelt ukjent feil i 255 bits, men plassen er bare 0,8%.

Merk: RS (255, N) er en representasjon av Reed-Solomon-koder, som er en type feilkorrigeringskoder.

2. The Bad

Har du noen gang hørt om "Det er to sider ved en mynt"? Selvfølgelig har du det. Mens Googles intensjoner med Strictly Enforced Verified Boot uten tvil var rene som en enhjørning, kommer de med sitt eget sett med problemer.

When Strictly Enforced Verified Boot sjekker etter skadelig programvare, det ser også etter ulovlige modifikasjoner til kjernen, bootloaderen og andre ting som jeg ikke vil kjede deg med, men dette betyr at Android Nougat sannsynligvis vil støte på mange problemer med rooting og blinkende tilpassede ROM-er, fordi Verified Boot ikke kan skille mellom uønsket malware-kode, og koden som låste opp bootloaderen. Hvilket betyr at hvis enheten din fulgte med en låst oppstartslaster, og OEMen din ikke tillater opplasting av oppstartslaster, kan du ganske mye ikke gjøre det. Forhåpentligvis vil noen finne ut en utnyttelse av dette.

Heldigvis går de fleste som roter enhetene sine, og blinker tilpassede ROM-er for tilleggsfunksjonene og funksjonaliteten, 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 kommer med en ulåst oppstartslaster, eller som tillater å låse opp oppstartslasteren. Imidlertid tillater ikke enheter som Samsung-telefoner offisielt å låse opp bootloader, og på disse enhetene vil opplåsing av bootloader definitivt bli sett på som et "problem" av Verified Boot, og forhindrer at enheten starter opp..

Et annet problem som vil oppstå med Strictly Enforced Verified Boot, er et problem som vil påvirke selv brukerne som ikke bryr seg om å få root-rettigheter, eller installere tilpassede ROM-er. Over tid, når du bruker enheten, vil det sikkert være naturlig datakorrupsjon i minnet. ikke på grunn av tilstedeværelse av 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 korrupte data som Strictly Enforced Verified Boot ikke kan fikse ved oppstart, vil det ikke tillate at enheten 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 ved å håndheve Verified Boot, og alle potensielle problemer, er det mest foruroligende det faktum at OEM-er kan begynne å misbruke dette for å låse enhetene sine slik at folk ikke kan bruke Android til det det var ment å være: åpen, utviklervennlig og helt tilpassbar. Strengt håndhevet bekreftet oppstart vil gi hendene til OEM-er, makten til å sikre at folk ikke er i stand til å låse opp bootloaderne på enhetene sine, og dermed forby dem å installere tilpassede ROM-er og funksjonsforbedrende verktøy som Xposed-moduler..

SE OGSÅ: Ingen Android N Custom ROM tilgjengelig? Vi har løsningen for deg

Android Nougat: En radikal endring i måten Android fungerer på?

Selv om vi er sikre på at Googles intensjoner rett og slett var å unngå potensielle problemer for uformelle Android-brukere, som ikke ville vite hva de skulle gjøre i tilfelle enheten deres ble påvirket av skadelig programvare, eller hvis minnet deres hadde ødelagte datablokker, kan det ha levert OEM-er og produsenten er det perfekte verktøyet for å låse brukerne til å leve med det de ble tilbudt, og ikke noe mer.

Selvfølgelig vil noen finne ut en utnyttelse eller en løsning for denne situasjonen, og vi håper ganske godt at de gjør det, i den virkelige ånden til Android. Inntil noen finner ut av en løsning, er alt vi, som brukere kan gjøre, imidlertid sikre at vi kjøper enhetene våre fra utviklervennlige produsenter.

Utvalgt bilde med tillatelse: Flickr