Google Remote Key Provisioning va fi solicitată în Android 13, dar este un subiect complicat. Iată ce va însemna asta pentru tine.
Atestarea cheii Android este coloana vertebrală a multor servicii de încredere pe smartphone-urile noastre, inclusiv SafetyNet, Digital Car Key și API-ul Identity Credential. A fost necesar ca parte a Android încă de la Android 8 Oreo și se baza pe o cheie rădăcină instalată pe un dispozitiv din fabrică. Furnizarea acestor chei a necesitat cel mai mare secret din partea producătorului, iar dacă o cheie a fost scursă, atunci aceasta ar însemna că cheia ar trebui să fie revocată. Acest lucru ar duce la imposibilitatea unui consumator de a utiliza niciunul dintre aceste servicii de încredere, ceea ce ar fi regretabil dacă ar exista vreodată o vulnerabilitate care o poate expune. Remote Key Provisioning, care va fi mandatat în Android 13, își propune să rezolve această problemă.
Componentele care alcătuiesc lanțul actual de încredere pe Android
Înainte de a explica modul în care funcționează noul sistem, este important să oferiți context despre modul în care
vechi (și încă în vigoare pentru o mulțime de dispozitive) sistemul funcționează. O mulțime de telefoane din zilele noastre folosesc atestarea cheii cu suport hardware, pe care s-ar putea să-l cunoști ca fiind cuiul în sicriu pentru orice tip de bypass SafetyNet. Există mai multe concepte care sunt importante de înțeles pentru starea actuală a atestării cheie.Este o combinație a acestor concepte care asigură un dezvoltator poate avea încredere că un dispozitiv nu a fost manipulat și poate gestiona informațiile sensibile din TEE.
Mediu de execuție de încredere
Un mediu de execuție de încredere (TEE) este o regiune sigură pe SoC care este utilizată pentru manipularea datelor critice. TEE este obligatoriu pe dispozitivele lansate cu Android 8 Oreo și o versiune ulterioară, ceea ce înseamnă că orice smartphone recent îl are. Orice lucru care nu este în TEE este considerat „neîncrezător” și poate vedea doar conținut criptat. De exemplu, conținutul protejat prin DRM este criptat cu chei care pot fi accesate numai de software-ul care rulează pe TEE. Procesorul principal poate vedea doar un flux de conținut criptat, în timp ce conținutul poate fi decriptat de către TEE și apoi afișat utilizatorului.
ARM Trustzone
Trusty este un sistem de operare securizat care oferă un TEE pe Android, iar pe sistemele ARM, folosește Trustzone a ARM. Trusty este executat pe același procesor ca și sistemul de operare principal și are acces la întreaga putere a dispozitivului, dar este complet izolat de restul telefonului. Trusty constă din următoarele:
- Un mic nucleu OS derivat din Micul Kernel
- Un driver de kernel Linux pentru a transfera date între mediul securizat și Android
- O bibliotecă de spațiu utilizator Android pentru a comunica cu aplicații de încredere (adică sarcini/servicii securizate) prin driverul kernelului
Avantajul pe care îl are față de sistemele TEE proprietare este că acele sisteme TEE pot fi costisitoare și, de asemenea, pot crea instabilitate în ecosistemul Android. Trusty este oferit producătorilor OEM parteneri de către Google gratuit și este open-source. Android acceptă alte sisteme TEE, dar Trusty este cel pe care Google îl împinge cel mai mult.
StrongBox
Dispozitivele StrongBox sunt procesoare securizate complet separate, create special și certificate. Acestea pot include elemente securizate încorporate (eSE) sau o unitate de procesare securizată (SPU) on-SoC. Google spune că StrongBox este în prezent „recomandat” să vină cu dispozitivele cu care se lansează Android 12 (conform documentului de definire a compatibilității), deoarece este probabil să devină o cerință într-o viitoare versiune Android. Este în esență o implementare mai strictă a unui depozit de chei susținut de hardware și poate fi implementat alături de TrustZone. Un exemplu de implementare a StrongBox este cipul Titan M din smartphone-urile Pixel. Nu multe telefoane folosesc StrongBox și majoritatea folosesc Trustzone de la ARM.
Keymaster TA
Keymaster Trusted Application (TA) este keymaster securizat care gestionează și efectuează toate operațiunile depozitului de chei. Poate rula, de exemplu, pe TrustZone a ARM.
Cum se schimbă Atestarea cheie cu Android 12 și Android 13
Dacă o cheie este expusă pe un smartphone Android, Google trebuie să o revoce. Acest lucru ridică o problemă pentru orice dispozitiv care are o cheie injectată din fabrică - orice fel de scurgere care expune cheia ar însemna că utilizatorii nu ar putea accesa un anumit conținut protejat. Aceasta poate include chiar și revocarea accesului la servicii precum Google Pay, ceva pe care se bazează mulți oameni. Acest lucru este regretabil pentru consumatori, deoarece fără ca telefonul să fie reparat de către un producător, nu ai avea nicio modalitate de a-l repara singur.
Introduceți Remote Key Provisioning. Începând cu Android 12, Google înlocuiește furnizarea cheii private din fabrică cu o combinație de extragerea cheii publice din fabrică și furnizarea de certificate prin aer cu durată scurtă certificate. Această schemă va fi necesară în Android 13 și are câteva avantaje. În primul rând, împiedică OEM-urile și ODM-urile să aibă nevoie să gestioneze secretul cheii într-o fabrică. În al doilea rând, permite recuperarea dispozitivelor în cazul în care cheile lor sunt compromise, ceea ce înseamnă că consumatorii nu vor pierde pentru totdeauna accesul la serviciile protejate. Acum, în loc să folosiți un certificat calculat folosind o cheie care se află pe dispozitiv și care ar putea fi scursă printr-o vulnerabilitate, un certificat temporar este solicitat de la Google oricând există un serviciu care necesită atestare folosit.
Cât despre cum funcționează, este destul de simplu. Fiecare dispozitiv generează o pereche de taste unică, statică, iar partea publică a acestei perechi de taste este extrasă de OEM din fabrica și trimisă serverelor Google. Acolo, ele vor servi drept bază de încredere pentru furnizarea ulterioară. Cheia privată nu părăsește niciodată mediul securizat în care este generată.
Când un dispozitiv este utilizat pentru prima dată pentru a se conecta la internet, va genera o cerere de semnare a certificatului pentru cheile pe care le-a generat, semnând-o cu cheia privată care corespunde cheii publice colectate în fabrică. Serverele de backend ale Google vor verifica autenticitatea cererii și apoi vor semna cheile publice, returnând lanțurile de certificate. Depozitul de chei de pe dispozitiv va stoca apoi aceste lanțuri de certificate, atribuindu-le aplicațiilor ori de câte ori se solicită o atestare. Acesta poate fi orice, de la Google Pay la Pokemon Go.
Acest lanț exact de solicitare a certificatelor va avea loc în mod regulat la expirarea certificatelor sau la epuizarea livrării de chei curente. Fiecare aplicație primește o cheie de atestare diferită, iar cheile în sine sunt rotite în mod regulat, ambele asigurând confidențialitatea. În plus, serverele de backend ale Google sunt segmentate astfel încât serverul care verifică cheia publică a dispozitivului nu vede cheile de atestare atașate. Aceasta înseamnă că nu este posibil ca Google să coreleze cheile de atestare înapoi cu dispozitivul particular care le-a solicitat.
Utilizatorii finali nu vor observa nicio modificare, deși dezvoltatorii trebuie să aibă grijă de următoarele, conform Google.
- Structura lanțului de certificate
- Datorită naturii noii noastre infrastructuri de furnizare online, lungimea lanțului este mai mare decât era anterior și poate fi modificată.
- Rădăcina încrederii
- Rădăcina de încredere va fi în cele din urmă actualizată de la cheia RSA actuală la o cheie ECDSA.
- Deprecierea Atestării RSA
- Toate cheile generate și atestate de KeyMint vor fi semnate cu o cheie ECDSA și lanțul de certificate corespunzător. Anterior, cheile asimetrice erau semnate de algoritmul corespunzător.
- Certificate de scurtă durată și chei de atestare
- Certificatele furnizate dispozitivelor vor fi, în general, valabile până la două luni înainte de a expira și sunt rotate.
Am contactat Google și am întrebat dacă acest lucru are vreo relevanță pentru Widevine DRM și cum anumiți utilizatori Pixel au raportat că nivelul lor DRM a fost retrogradat cu un bootloader blocat. De asemenea, am întrebat dacă acest lucru poate fi distribuit ca o actualizare OTA utilizatorilor prin serviciile Google Play acum. Vom fi sigur că actualizăm acest articol dacă vom primi răspunsuri. Nu este clar care componente ale lanțului actual de încredere vor fi afectate sau în ce mod.
Sursă: Google