Googlova oddaljena oskrba ključev bo obvezna v sistemu Android 13: Kaj to pomeni za vas

Androidovo ključno potrdilo je hrbtenica številnih zaupanja vrednih storitev na naših pametnih telefonih, vključno s SafetyNet, Digital Car Key in Identity Credential API. Od Androida 8 Oreo je bil potreben kot del Androida in je bil odvisen od korenskega ključa, nameščenega v napravi v tovarni. Zagotavljanje teh ključev je zahtevalo največjo tajnost s strani proizvajalca in če bi ključ ušel, bi to pomenilo, da bi bilo treba ključ preklicati. To bi povzročilo, da potrošnik ne bi mogel uporabljati nobene od teh zaupanja vrednih storitev, kar bi bilo žalostno, če bi kdaj obstajala ranljivost, ki bi jo lahko razkrila. Remote Key Provisioning, ki bo pooblaščen v Android 13, želi rešiti ta problem.

Komponente, ki sestavljajo trenutno verigo zaupanja v sistemu Android

Preden razložimo, kako deluje nov sistem, je pomembno zagotoviti kontekst o tem, kako star (in še vedno velja za veliko naprav) sistem deluje. Dandanes veliko telefonov uporablja potrdilo ključev, podprto s strojno opremo, ki ga morda poznate kot žebelj v krsto za kakršen koli obvod SafetyNet. Za trenutno stanje potrjevanja ključev je pomembno razumeti več konceptov.

Kombinacija teh konceptov zagotavlja, da lahko razvijalec zaupa, da naprava ni bila spremenjena, in lahko obravnava občutljive informacije v TEE.

Zaupanja vredno izvajalsko okolje

Trusted Execution Environment (TEE) je varna regija na SoC, ki se uporablja za ravnanje s kritičnimi podatki. TEE je obvezen v napravah z operacijskim sistemom Android 8 Oreo ali novejšim, kar pomeni, da ga ima vsak novejši pametni telefon. Vse, kar ni znotraj TEE, se šteje za "nezaupljivo" in lahko vidi samo šifrirano vsebino. Na primer, vsebina, zaščitena z DRM, je šifrirana s ključi, do katerih lahko dostopa samo programska oprema, ki se izvaja na TEE. Glavni procesor lahko vidi samo tok šifrirane vsebine, medtem ko lahko vsebino dešifrira TEE in jo nato prikaže uporabniku.

ARM Trustcone

Trusty je varen operacijski sistem, ki zagotavlja TEE v sistemu Android, v sistemih ARM pa uporablja Trustzone ARM. Trusty se izvaja na istem procesorju kot primarni operacijski sistem in ima dostop do celotne moči naprave, vendar je popolnoma izoliran od preostalega telefona. Trusty je sestavljen iz naslednjega:

• Majhno jedro OS, izpeljano iz Malo jedro
• Gonilnik jedra Linuxa za prenos podatkov med varnim okoljem in sistemom Android
• Knjižnica uporabniškega prostora Android za komunikacijo z zaupanja vrednimi aplikacijami (to je varna opravila/storitve) prek gonilnika jedra

Prednost, ki jo ima pred lastniškimi sistemi TEE, je, da so lahko ti sistemi TEE dragi in povzročajo nestabilnost v ekosistemu Android. Trusty partnerskim proizvajalcem originalne opreme zagotavlja Google brezplačno in je odprtokoden. Android podpira druge sisteme TEE, vendar je Trusty tisti, ki ga Google najbolj spodbuja.

StrongBox

Naprave StrongBox so popolnoma ločeni, namensko izdelani in certificirano varni procesorji. Ti lahko vključujejo vgrajene varnostne elemente (eSE) ali varno procesno enoto (SPU) na sistemu SoC. Google pravi, da je StrongBox trenutno "močno priporočljiv" za naprave, ki se zaženejo Android 12 (v skladu z dokumentom z definicijo združljivosti), saj bo verjetno postalo zahteva v prihodnji izdaji Androida. To je v bistvu strožja izvedba strojno podprte shrambe ključev in jo je mogoče implementirati skupaj z TrustZone. Primer izvedbe StrongBoxa je čip Titan M v pametnih telefonih Pixel. Ni veliko telefonov, ki uporabljajo StrongBox, večina pa uporablja Trustzone podjetja ARM.

Keymaster TA

Keymaster Trusted Application (TA) je varen keymaster, ki upravlja in izvaja vse operacije shrambe ključev. Deluje lahko na primer v ARM TrustZone.

Kako se potrditev ključev spreminja z Androidoma 12 in Androidom 13

Če je ključ razkrit na pametnem telefonu Android, ga mora Google preklicati. To predstavlja težavo za vsako napravo, ki ima ključ vstavljen v tovarni – kakršno koli puščanje, ki bi razkrilo ključ, bi pomenilo, da uporabniki ne bi mogli dostopati do določene zaščitene vsebine. To lahko vključuje celo preklic dostopa do storitev, kot je Google Pay, na kar se veliko ljudi zanaša. To je žalostno za potrošnike, saj brez popravila telefona pri proizvajalcu ne bi bilo možnosti, da ga popravite sami.

Vstopite v Remote Key Provisioning. Začenši z Androidom 12, Google nadomešča tovarniško zagotavljanje zasebnih ključev s kombinacijo pridobivanje javnega ključa v tovarni in zagotavljanje certifikatov po zraku s kratko življenjsko dobo potrdila. Ta shema bo potrebna v sistemu Android 13 in ima nekaj prednosti. Predvsem preprečuje proizvajalcem originalne opreme in proizvajalcem originalne opreme, da bi morali upravljati tajnost ključev v tovarni. Drugič, omogoča obnovitev naprav, če so njihovi ključi ogroženi, kar pomeni, da potrošniki ne bodo za vedno izgubili dostopa do zaščitenih storitev. Zdaj namesto uporabe potrdila, izračunanega s ključem, ki je v napravi in ​​bi lahko pricurljal skozi a ranljivosti, se od Googla zahteva začasno potrdilo vsakič, ko je storitev, za katero je potrebno potrdilo rabljeno.

Glede na to, kako deluje, je dovolj preprosto. Edinstven, statični par ključev ustvari vsaka naprava, javni del tega para ključev pa ekstrahira proizvajalec originalne opreme v svoji tovarni in ga pošlje Googlovim strežnikom. Tam bodo služili kot osnova zaupanja za kasnejše oskrbovanje. Zasebni ključ nikoli ne zapusti varnega okolja, v katerem je ustvarjen.

Ko je naprava prvič uporabljena za povezavo z internetom, bo ustvarila zahtevo za podpis potrdila za ključe, ki jih je ustvaril, in ga podpiše z zasebnim ključem, ki ustreza javnemu ključu, zbranemu v tovarna. Googlovi zaledni strežniki bodo preverili pristnost zahteve in nato podpisali javne ključe ter vrnili verige potrdil. Shramba ključev v napravi bo nato shranila te verige potrdil in jih dodelila aplikacijam, kadar koli bo zahtevano potrdilo. To je lahko karkoli, od Google Pay do Pokemon Go.

Točna veriga zahtev za potrdila se bo izvajala redno po poteku veljavnosti potrdil ali izčrpanju trenutne zaloge ključev. Vsaka aplikacija prejme drugačen atestacijski ključ, sami ključi pa se redno izmenjujejo, kar oboje zagotavlja zasebnost. Poleg tega so Googlovi zaledni strežniki segmentirani tako, da strežnik, ki preverja javni ključ naprave, ne vidi priloženih potrditvenih ključev. To pomeni, da Google ne more povezati potrditvenih ključev z določeno napravo, ki jih je zahtevala.

Končni uporabniki ne bodo opazili nobenih sprememb, čeprav morajo razvijalci po besedah ​​Googla paziti na naslednje.

• Struktura verige potrdil
  • Zaradi narave naše nove spletne infrastrukture za zagotavljanje storitev je dolžina verige daljša kot prej in se lahko spremeni.
• Koren zaupanja
  • Koren zaupanja bo sčasoma posodobljen iz trenutnega ključa RSA v ključ ECDSA.
• Opustitev potrdila RSA
  • Vsi ključi, ki jih ustvari in potrdi KeyMint, bodo podpisani s ključem ECDSA in ustrezno verigo potrdil. Prej so bili asimetrični ključi podpisani z ustreznim algoritmom.
• Kratkotrajni certifikati in potrdilni ključi
  • Certifikati, dodeljeni napravam, bodo na splošno veljavni do dva meseca, preden potečejo in se zamenjajo.

Stopili smo v stik z Googlom in ga vprašali, ali ima to kakršen koli pomen za Widevine DRM in kako so nekateri uporabniki Pixel sporočili, da je bila njihova raven DRM znižana z zaklenjenim zagonskim nalagalnikom. Vprašali smo tudi, ali je to mogoče zdaj distribuirati kot nadgradnjo OTA uporabnikom prek storitev Google Play. Ta članek bomo zagotovo posodobili, če se bomo oglasili. Ni jasno, na katere komponente trenutne verige zaupanja bo to vplivalo ali na kakšen način.

---

Vir: Google