Kaikkien Android Pie (Android 9) -käyttöjärjestelmän kanssa käynnistyvien laitteiden on tuettava Verified Boot -versiota (Android Verified Boot 2.0), joka mahdollistaa palautussuojauksen.
Android Pie (Android 9) lähetettiin juuri tänään Google Pixelille, Google Pixel 2:lle ja jopa Tärkeä puhelin. Opimme niin paljon kuin voimme haastattelujen julkaisemisesta (Google Pixel 3 on vain ele-navigointi!), AOSP-koodin pudotusja lopuksi Compatibility Definition Document (CDD). Kirjoitimme aiheesta a uusi ominaisuus "raskassarjan" sovelluksille aiemmin tänään, mutta nyt olemme havainneet, että Google on muuttanut sanamuotoaan Android Oreossa esitellyssä ominaisuudessa: peruuttamissuojaus. Ominaisuuden tekee mahdolliseksi Android Verified Boot 2.0 (tunnetaan myös nimellä Verified Boot), mutta OEM-valmistajien ei tarvinnut ottaa käyttöön AVB 2.0:aa Oreo-julkaisussa. Nyt Google edellyttää, että kaikki Android Pie -sovelluksella käynnistettävät laitteet tukevat vahvistettua käynnistystä ja sitä kautta palautussuojausta.
Palautussuojaus Android Oreossa
Ominaisuuden ydin on, että se estää puhelintasi käynnistymästä, jos se havaitsee, että laite on päivitetty aiempaan, nyt hyväksymättömään ohjelmistoversioon, jota on pidetty turvattomana tietoturvan vuoksi haavoittuvuus. Hieman teknisempi selitys on, että VBMeta-tietorakenne, joka sisältää käynnistysosion hashin ja hashtree-metatiedot järjestelmä- ja toimittajaosioille, käyttää palautusindeksiä hylkäämään kuvat, joilla on vanhempi palautus. indeksi.
Tämä ominaisuus on käytettävissä laitteissa, kuten Google Pixel 2, Razer Phone ja OnePlus 6, mutta sitä ei ole monissa muissa laitteissa, kuten Samsung Galaxy S9 (vaikka Samsung tarjoaa oman tyyppinsä Knoxin perääntymissuoja.) Nyt Google tekee ominaisuudesta pakollisen kaikille laitteille, jotka käynnistetään Android Pien kanssa.
Verified Boot Android Pie -sovelluksessa
Yhteensopivuusmäärittelydokumentin Laitteen eheys-osion päivitetyn sanamuodon mukaan Android 9:n kanssa käynnistyvien laitteiden on tuettava vahvistettua käynnistystä.
9.10. Laitteen eheys
Seuraavat vaatimukset varmistavat, että laitteen eheyden tila on läpinäkyvä. Laitteen toteutukset:
- [C-0-1] TÄYTYY raportoida oikein System API -metodin PersistentDataBlockManager.getFlashLockState() kautta, salliiko käynnistyslataimen tila järjestelmävedoksen vilkkumisen. FLASH_LOCK_UNKNOWN-tila on varattu laitetoteutuksiin, jotka päivitetään aiemmasta Android-versiosta, jossa tätä uutta järjestelmän API-menetelmää ei ollut olemassa.
- [C-0-2] TÄYTYY tukea vahvistettua käynnistystä laitteen eheyden varmistamiseksi.
Jos laitetoteutukset on jo käynnistetty ilman Verified Boot -tukea aiemmassa Android-versiossa eivätkä ne voi lisätä tukea tälle ominaisuudelle järjestelmäohjelmiston päivityksellä, ne VOIDAAN olla vapautettuja vaatimus.
...
- [C-1-10] TÄYTYY ottaa käyttöön palautussuojaus Androidin käyttämissä osioissa (esim. käynnistys, järjestelmäosiot) ja käytä peukaloituvaa tallennustilaa metadatan tallentamiseen, jota käytetään pienimmän sallitun käyttöjärjestelmän määrittämiseen versio.
- PITÄÄ ottaa käyttöön palautussuojaus kaikille komponenteille, joissa on pysyvä laiteohjelmisto (esim. modeemi, kamera) ja PITÄÄ käyttää peukaloituvaa tallennustilaa metadatan tallentamiseen, jota käytetään vähimmäismäärän määrittämiseen versio.
Kuten näet kahdesta viimeisestä luettelomerkkisarjasta, on huomioitava yksi huomautus. Palautussuojaus vaaditaan Androidin käyttämissä osioissa (käynnistys, järjestelmä, toimittaja jne.), mutta ei osioissa, joissa on pysyvä laiteohjelmisto (modeemi, kamera jne.). Entinen osiosarja on paikka, jossa suurin osa tietoturva-aukoista löydetään ja korjataan, joten on mukava nähdä, että näiden osioiden suojaaminen on pakollista. On kuitenkin olemassa hyväksikäyttöjä, jotka kohdistuvat myös osioihin, joissa on pysyvä laiteohjelmisto, joten emme ole varmoja, miksi Google ei vaadi niille palautussuojausta.
XDA: n vanhempi jäsen npjohnson, LineageOS-tiimin jäsen, arvelee, että palautussuojauksen vaatiminen osioissa, joissa on pysyvä laiteohjelmisto vaativat toissijaisen käynnistyslataimen (SBL) ja eXtensible Bootloaderin (XBL) liitännät, koska nämä osiot asennetaan aiemmin käynnistyksessä käsitellä asiaa. Pienemmille OEM-valmistajille olisi kallista ottaa käyttöön räätälöityjä XBL: itä, jotka sopivat räätälöityihin modeemeihin ja muihin pysyviin osioihin, joten ehkä Google ei aseta tätä vaatimukseen, jotta laitevalmistajien olisi helpompi täyttää CDD: n uusimmat vaatimukset.
Kuinka tarkistaa, tukeeko puhelimesi AVB 2.0
Voit tarkistaa, tukeeko puhelimesi AVB 2.0:aa kahdella ADB-kuorikomentolla.
adb shell
dumpsys package | grep "verified_boot"TAI
adb shell
getprop | grep "avb"Jos ensimmäisen komennon tulos on "android.software.verified_boot", AVB 2.0 tuetaan. Jos toisen komennon tulos näyttää "[ro.boot.avb_version]" ja "[ro.boot.vbmeta.avb_version]" ja luetteloi versionumeron jokaiselle, sitä tuetaan.
Varmennettu käynnistys ja mukautettu kehitys
Android Verified Boot ei oikeastaan vaikuta useimpiin mukautettuihin ROM-käyttäjiin, vaikka se lisää ylimääräistä suojaustasoa, jota on joissakin tapauksissa kiertää. Esimerkiksi, yleisen järjestelmäkuvan vilkkuminen vaatii AVB: n poistamisen käytöstä. Tiettyjen osioiden, kuten toimittajan, muuttaminen OnePlus 6:ssa edellyttää myös AVB: n poistamista käytöstä, kuten äskettäin opin. Mukaan npjohnson, oikein toteutettu AVB 2.0 mahdollistaa mukautettujen käynnistystiedostojen toimimisen lukitun käynnistyslataimen kanssa. Katsotaan, kuinka AVB 2.0:n sisällyttäminen Android Pie -laitteisiin vaikuttaa maisemaan, mutta toivomme, että se ei johda tilanteisiin, kuten viimeaikainen muuripelko Xiaomi Redmi Note 5 Pro -yhteisössä. Pakollinen AVB 2.0 on vain yksi tapa Googlelle parantaa Android-alustan suojausta, mutta mielestämme suurin muutos on OEM-sopimusten uudelleenkäsittely säännöllisten tietoturvakorjausten määräämiseksi.