Googleovo Remote Key Provisioning bit će obavezno u Androidu 13: Što to znači za vas

Androidov ključni atest okosnica je mnogih pouzdanih usluga na našim pametnim telefonima, uključujući SafetyNet, Digital Car Key i Identity Credential API. Bio je potreban kao dio Androida od Androida 8 Oreo i oslanjao se na root ključ instaliran na uređaj u tvornici. Pružanje ovih ključeva zahtijevalo je najveću tajnost od strane proizvođača, a ako je ključ procurio, to bi značilo da ključ treba opozvati. To bi dovelo do toga da potrošač ne bi mogao koristiti nijednu od ovih pouzdanih usluga, što bi bilo šteta ako ikada postoji ranjivost koja bi ga mogla otkriti. Remote Key Provisioning, koji će biti ovlašten u Android 13, ima za cilj riješiti taj problem.

Komponente koje čine trenutni lanac povjerenja na Androidu

Prije nego objasnite kako novi sustav funkcionira, važno je dati kontekst o tome kako star (i još uvijek na mjestu za mnoge uređaje) sustav radi. Mnogi telefoni danas koriste hardverski podržano ovjeravanje ključa, što vam je možda poznato kao čavao u lijes za bilo koju vrstu zaobilaženja SafetyNeta. Postoji nekoliko koncepata koje je važno razumjeti za trenutno stanje atestiranja ključeva.

Kombinacija ovih koncepata jamči da razvojni programer može vjerovati da uređaj nije neovlašteno mijenjan i da može rukovati osjetljivim informacijama u TEE-u.

Pouzdano izvršno okruženje

Trusted Execution Environment (TEE) sigurno je područje na SoC-u koje se koristi za rukovanje kritičnim podacima. TEE je obavezan na uređajima koji su lansirani s Androidom 8 Oreo i novijim, što znači da ga svaki noviji pametni telefon ima. Sve što nije unutar TEE-a smatra se "nepouzdanim" i može vidjeti samo šifrirani sadržaj. Na primjer, sadržaj zaštićen DRM-om šifriran je ključevima kojima može pristupiti samo softver koji radi na TEE-u. Glavni procesor može vidjeti samo tok šifriranog sadržaja, dok sadržaj može dešifrirati TEE i zatim prikazati korisniku.

ARM Trustzone

Trusty je siguran operativni sustav koji pruža TEE na Androidu, a na ARM sustavima koristi ARM Trustzone. Trusty se izvršava na istom procesoru kao i primarni operativni sustav i ima pristup punoj snazi ​​uređaja, ali je potpuno izoliran od ostatka telefona. Trusty se sastoji od sljedećeg:

• Mali OS kernel izveden iz Mali Kernel
• Linux kernel driver za prijenos podataka između sigurnog okruženja i Androida
• Knjižnica Android korisničkog prostora za komunikaciju s pouzdanim aplikacijama (to jest, sigurni zadaci/usluge) putem upravljačkog programa kernela

Prednost koju ima u odnosu na vlasničke TEE sustave je ta što ti TEE sustavi mogu biti skupi, a također stvaraju nestabilnost u Android ekosustavu. Trusty partnerskim proizvođačima originalne opreme besplatno daje Google i on je otvorenog koda. Android podržava i druge TEE sustave, ali Trusty je onaj koji Google najviše forsira.

Sef

StrongBox uređaji potpuno su odvojeni, namjenski izrađeni i certificirani sigurni CPU-ovi. Oni mogu uključivati ​​ugrađene sigurnosne elemente (eSE) ili on-SoC jedinicu za sigurnu obradu (SPU). Google kaže da se StrongBox trenutno "toplo preporučuje" za isporuku s uređajima koji se pokreću Android 12 (prema Dokumentu o definiciji kompatibilnosti) jer će vjerojatno postati uvjet u budućem izdanju Androida. To je u biti stroža implementacija hardverski podržanog spremišta ključeva i može se implementirati uz TrustZone. Primjer implementacije StrongBoxa je Titan M čip u Pixel pametnim telefonima. Nema mnogo telefona koji koriste StrongBox, a većina koristi ARM-ov Trustzone.

Keymaster TA

Keymaster Trusted Application (TA) je sigurni keymaster koji upravlja i izvodi sve operacije pohrane ključeva. Može raditi, na primjer, na ARM-ovom TrustZone-u.

Kako se potvrda ključa mijenja s Androidom 12 i Androidom 13

Ako je ključ otkriven na Android pametnom telefonu, Google ga mora opozvati. To predstavlja problem za bilo koji uređaj koji ima ključ umetnut u tvornici -- bilo kakvo curenje koje otkrije ključ značilo bi da korisnici ne bi mogli pristupiti određenom zaštićenom sadržaju. To čak može uključivati ​​i opoziv pristupa uslugama kao što je Google Pay, nešto na što se mnogi ljudi oslanjaju. To je šteta za kupce jer bez popravka vašeg telefona kod proizvođača ne bi bilo načina da ga sami popravite.

Uđite u Remote Key Provisioning. Počevši od Androida 12, Google zamjenjuje tvorničko pružanje privatnih ključeva kombinacijom in-tvorničko izdvajanje javnog ključa i over-the-air pružanje certifikata s kratkotrajnim potvrde. Ova će shema biti potrebna u Androidu 13, a ima nekoliko prednosti. Prvo i najvažnije, sprječava OEM i ODM proizvođače da moraju upravljati tajnošću ključeva u tvornici. Drugo, omogućuje oporavak uređaja ako su njihovi ključevi ugroženi, što znači da potrošači neće zauvijek izgubiti pristup zaštićenim uslugama. Sada, umjesto korištenja certifikata izračunatog pomoću ključa koji se nalazi na uređaju i koji bi mogao procuriti kroz a ranjivosti, od Googlea se traži privremena potvrda svaki put kada postoji usluga za koju je potrebna potvrda koristi se.

Što se tiče načina na koji radi, dovoljno je jednostavno. Jedinstveni, statični par ključeva generira svaki uređaj, a javni dio tog para ključeva ekstrahira OEM u svojoj tvornici i šalje ga Googleovim poslužiteljima. Ondje će služiti kao temelj povjerenja za kasnije opskrbu. Privatni ključ nikada ne napušta sigurno okruženje u kojem je generiran.

Kada se uređaj prvi put koristi za povezivanje s internetom, generirat će zahtjev za potpisivanje certifikata za ključeve koje je generirao, potpisujući ga privatnim ključem koji odgovara javnom ključu prikupljenom u tvornica. Googleovi pozadinski poslužitelji provjerit će autentičnost zahtjeva i zatim potpisati javne ključeve, vraćajući lance certifikata. Spremište ključeva na uređaju zatim će pohraniti ove lance certifikata, dodjeljujući ih aplikacijama kad god se zatraži potvrda. To može biti bilo što, od Google Paya do Pokemon Goa.

Točan lanac zahtjeva za certifikatom događat će se redovito nakon isteka certifikata ili iscrpljivanja trenutne zalihe ključeva. Svaka aplikacija dobiva drugačiji atestacijski ključ, a sami se ključevi redovito rotiraju, što oba osigurava privatnost. Osim toga, Googleovi pozadinski poslužitelji segmentirani su tako da poslužitelj koji provjerava javni ključ uređaja ne vidi priložene ključeve potvrde. To znači da Google ne može povezati atestacijske ključeve s određenim uređajem koji ih je zatražio.

Krajnji korisnici neće primijetiti nikakve promjene, iako programeri moraju paziti na sljedeće, prema Googleu.

• Struktura lanca certifikata
  • Zbog prirode naše nove mrežne infrastrukture za pružanje usluga, duljina lanca je duža nego što je bila prije i podložna je promjenama.
• Korijen povjerenja
  • Korijen povjerenja će se na kraju ažurirati iz trenutnog RSA ključa u ECDSA ključ.
• Zastarjela RSA potvrda
  • Svi ključevi koje je generirao i potvrdio KeyMint bit će potpisani ECDSA ključem i odgovarajućim lancem certifikata. Prethodno su asimetrični ključevi bili potpisani svojim odgovarajućim algoritmom.
• Kratkotrajni certifikati i ključevi potvrde
  • Certifikati dodijeljeni uređajima općenito će vrijediti do dva mjeseca prije isteka i rotacije.

Kontaktirali smo Google i pitali je li to ikakve veze s Widevine DRM-om i kako su neki korisnici Pixela prijavili da im je razina DRM-a smanjena sa zaključanim bootloaderom. Također smo pitali može li se ovo sada distribuirati kao OTA nadogradnja korisnicima putem Google Play usluga. Svakako ćemo ažurirati ovaj članak ako nam se javi. Nije jasno na koje će komponente trenutnog lanca povjerenja utjecati niti na koji način.

---

Izvor: Google