Vovich Antonovich
0 
5108
66
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 utgivelsene av Android-operativsystemet..
De siste par dagene har vi sett nyheter om tilstedeværelsen av en "Strengt håndhevet bekreftet oppstart”I Googles siste iterasjon av verdens mest brukte mobile OS. Android Nougat vil bruke et høyere nivå av sikkerhetskontroll når enheten starter opp. Mens 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 avvik i partisjonen, endringer som er gjort i startlasteren, eller tilstedeværelsen av "ondsinnet" kode på enheten. Dette stiller spørsmålet: "Hva betyr det egentlig for brukerne?", Viser det seg at svaret er forskjellig for de to hovedkategoriene til Android-brukere (tilfeldige og strømbrukere), og vi kommer til å gi svaret for begge to.
Strengt håndhevet bekreftet oppstart
For det første litt bakgrunn på Verified Boot: Når Android kjører en verifiseringstest 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 viser seg å være tuklet med, eller er korrupte, informerer Android brukeren om problemene og overlater det til brukeren å løse det (eller ikke).
Alt som er i ferd med å endre seg med Android Nougat, og Strictly Enforced Verified Boot. Når Verified Boot kjøres i tvangsmodus, er det tåler ikke feil i partisjonene. Hvis det oppdager noen problemer, det vil ikke la enheten starte opp, og kanskje la brukeren starte opp i et miljø i sikker modus, å prøve og rette 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 muliggjort av tilstedeværelsen av Forward Error Correction codes, som kan brukes til å rette opp feil i datablokker. Dette kan imidlertid ikke alltid fungere, og i tilfeller når det ikke gjør det, er du ganske død i vannet.
Strengt håndhevet bekreftet støvel: Det gode, det dårlige og det stygge
1. Det gode
Å håndheve bekreftet oppstart på Android-enheter vil forbedre sikkerheten på enhetene. I tilfelle enheten blir infisert av skadelig programvare, vil Strictly Enforced Verified Boot oppdage den neste gang du starter opp enheten din, og enten fikser den den, eller du kan kanskje be deg om å gjøre noe med det.
Denne funksjonen vil også sjekk for datakorrupsjon, og i de fleste tilfeller vil det være i stand til å rette opp eventuelle feil som er introdusert i dataene, takket være FEC-kodene. Google bruker FEC-koder som kan rett en ukjent bitfeil i 255 biter. Jada, det virker som et ganske lite antall, 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 Developers.
Google kunne ha brukt RS (255 223) FEC-koder: disse kodene ville vært i stand til å rette opp 16 ukjente bitfeil i 255 biter, men plassen overhead på grunn av de 32 bits med overflødige data, ville vært nesten 15%, og det er mye, spesielt på mobile enheter. Legg til det faktum at Android er det dominerende operativsystemet på budsjett-smarttelefoner som leveres med 4-8 GB minner, og 15% ekstra plass som sikkert virker som mye.
Ved å ofre feilretting av muligheter, 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 biter, men plassen er bare 0,8%.
Merk: RS (255, N) er en representasjon av Reed-Solomon-koder, som er en type feilrettingskoder.
2. De dårlige
Noen gang hørt om "Det er to sider av en mynt"? Selvfølgelig har du det. Selv om Googles intensjoner med Strictly Enforced Verified Boot uten tvil var rene som en enhjørning til babyen, kommer de med sitt eget sett med problemer.
Når strengt håndhevet bekreftet støvel sjekker for skadelig programvare, det sjekker også etter ulovlige modifikasjoner til kjernen, bootloader 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 opplasteren. Noe som betyr at hvis enheten din fulgte med en låst oppstartslaster, og OEM-en ikke tillater opplåsing av opplastingslaster, kan du stort sett ikke gjøre det. Forhåpentligvis vil noen finne ut en utnyttelse av dette.
Heldigvis, de fleste som roter på enhetene sine og blitser tilpassede ROM-er for de ekstra funksjonene og funksjonaliteten, følger med utviklervennlige telefoner, for eksempel Nexus. Det er mye å ta i betraktning når det gjelder dette emnet, og det er definitivt ikke slutten på tilpassede ROM-er, i det minste ikke på enheter som følger med en ulåst oppstartslaster, eller som gjør det mulig å låse opp bootloader. Imidlertid tillater enheter som Samsung-telefoner ikke offisielt å låse opp opplasteren, og på disse enhetene vil opplåsing av opplasteren din 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 som vil påvirke til og med brukerne som ikke virkelig bryr seg om å få root-privilegier, eller installere tilpassede ROM-er. Når du bruker enheten over tid, er det helt sikkert en naturlig datakorrupsjon i minnet. ikke på grunn av tilstedeværelsen av en skadelig programvare, men bare fordi det skjer. Dette er vanligvis ikke et problem, eller i det minste ikke så alvorlig problem som Verified Boot vil gjøre det til. Hvis du har korrupte data som Strictly Enforced Verified Boot ikke kan fikse på oppstart, vil den ikke la enheten starte opp. Etter min mening er det et større og mer synlig problem enn noen korrupte data på brukerpartisjonen.
3. Den stygge
I alle fordelene med å håndheve Verified Boot, og alle potensielle problemer, er det mest urovekkende sannsynligvis 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 fullstendig tilpassbar. Strengt håndhevet bekreftet oppstart vil være i hendene på OEM-er, kraften til å sikre at folk ikke klarer å låse opp bootloaders på enhetene sine, og dermed forbyr dem å installere tilpassede ROM-er og funksjoner som forbedrer verktøy som Xposed Modules.
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 bare var å unngå potensielle problemer for tilfeldige Android-brukere, som ikke ville vite hva de skulle gjøre i tilfelle enheten deres ble påvirket av en skadelig programvare, eller hvis minnet deres hadde ødelagte datablokker, kan det ha gitt OEM-er og produsenten er det perfekte verktøyet for å låse brukere til å leve med det de ble tilbudt, og ikke noe mer.
Selvfølgelig vil noen finne ut en utnyttelse eller en løsning på denne situasjonen, og vi håper ganske enkelt at de gjør det, i Android's sanne ånd. Inntil noen finner ut av en løsning, er imidlertid alt vi, som brukere kan gjøre, sikre at vi kjøper enhetene våre fra utviklervennlige produsenter.
Utvalgt bilde høflighet: Flickr