A Google távoli kulcskezelése kötelező lesz az Android 13-ban: Mit jelent ez az Ön számára

Az Android kulcs tanúsítványa számos megbízható szolgáltatás gerincét képezi okostelefonjainkon, beleértve a SafetyNet-et, a digitális autókulcsot és az Identity Credential API. Az Android részeként az Android 8 Oreo óta szükséges, és gyárilag az eszközre telepített gyökérkulcsra támaszkodott. Ezeknek a kulcsoknak a biztosítása a legnagyobb titoktartást követelte meg a gyártótól, és ha egy kulcs kiszivárgott, az azt jelentené, hogy a kulcsot vissza kell vonni. Ez azt eredményezné, hogy a fogyasztó nem tudja használni e megbízható szolgáltatások egyikét sem, ami sajnálatos lenne, ha valaha is lenne olyan sebezhetőség, amely felfedheti. Remote Key Provisioning, amely kötelező lesz Android 13, a probléma megoldását célozza.

Az Android jelenlegi bizalmi láncát alkotó összetevők

Mielőtt elmagyarázná, hogyan működik az új rendszer, fontos, hogy kontextust biztosítson a rendszer működéséhez 

régi (és még mindig sok eszköznél működik) a rendszer működik. Manapság sok telefon hardveres kulcs tanúsítványt használ, amelyet Ön is ismerhet, mint a koporsó szögét bármilyen SafetyNet bypass esetén. Számos olyan fogalom van, amelyeket fontos megérteni a kulcsok tanúsításának jelenlegi állapotához.

Ezeknek a fogalmaknak a kombinációja biztosítja, hogy a fejlesztő megbízhasson abban, hogy az eszközt nem manipulálták, és képes kezelni a TEE-ben lévő érzékeny információkat.

Megbízható végrehajtási környezet

A Trusted Execution Environment (TEE) az SoC biztonságos régiója, amelyet kritikus adatok kezelésére használnak. A TEE kötelező az Android 8 Oreo vagy újabb rendszert futtató eszközökön, ami azt jelenti, hogy minden újabb okostelefon rendelkezik vele. Minden, ami nincs a TEE-n belül, „nem megbízhatónak” minősül, és csak titkosított tartalmat láthat. Például a DRM-védett tartalom olyan kulcsokkal van titkosítva, amelyekhez csak a TEE-n futó szoftverek férhetnek hozzá. A főprocesszor csak a titkosított tartalom folyamát láthatja, míg a tartalmat a TEE vissza tudja fejteni, majd megjeleníteni a felhasználó számára.

ARM Trustzone

A Trusty egy biztonságos operációs rendszer, amely TEE-t biztosít Androidon, ARM rendszereken pedig az ARM Trustzone-ját használja. A Trusty ugyanazon a processzoron fut, mint az elsődleges operációs rendszer, és hozzáfér az eszköz teljes teljesítményéhez, de teljesen el van szigetelve a telefon többi részétől. A Trusty a következőkből áll:

• Egy kis operációs rendszer kernel, amelyből származik Kis Kernel
• Linux kernel-illesztőprogram a biztonságos környezet és az Android közötti adatátvitelhez
• Android felhasználói terület könyvtár a megbízható alkalmazásokkal (vagyis biztonságos feladatokkal/szolgáltatásokkal) való kommunikációhoz a kernel-illesztőprogramon keresztül

A szabadalmaztatott TEE-rendszerekkel szemben az az előnye, hogy ezek a TEE-rendszerek költségesek lehetnek, és instabilitást okozhatnak az Android-ökoszisztémában. A Trusty-t a Google ingyenesen biztosítja a partner OEM-eknek, és ez nyílt forráskódú. Az Android más TEE-rendszereket is támogat, de a Google leginkább a Trusty-t támogatja.

StrongBox

A StrongBox eszközök teljesen különálló, erre a célra épített és tanúsítvánnyal rendelkező biztonságos CPU-k. Ezek közé tartozhatnak a beágyazott biztonsági elemek (eSE) vagy egy on-SoC biztonságos feldolgozó egység (SPU). A Google azt állítja, hogy a StrongBox jelenleg "erősen ajánlott" az olyan eszközökhöz, amelyekkel indítható Android 12 (a kompatibilitási meghatározási dokumentum szerint), mivel ez valószínűleg követelmény lesz egy jövőbeli Android-kiadásban. Ez lényegében a hardverrel támogatott kulcstároló szigorúbb megvalósítása, és a TrustZone mellett is megvalósítható. A StrongBox megvalósításának példája a Titan M chip a Pixel okostelefonokban. Nem sok telefon használja a StrongBoxot, és a legtöbb az ARM Trustzone-ját.

Keymaster TA

A Keymaster Trusted Application (TA) egy biztonságos kulcsmester, amely kezeli és végrehajtja az összes kulcstároló műveletet. Például futhat az ARM TrustZone-ján.

Hogyan változik a kulcsok tanúsítása az Android 12 és Android 13 rendszerrel

Ha egy kulcs látható egy Android okostelefonon, a Google-nak vissza kell vonnia azt. Ez minden olyan eszköznél problémát jelent, amelyre gyárilag befecskendezték a kulcsot – a kulcsot felfedő bármilyen szivárgás azt jelentené, hogy a felhasználók nem férhetnek hozzá bizonyos védett tartalmakhoz. Ez akár az olyan szolgáltatásokhoz való hozzáférés visszavonását is magában foglalhatja, mint a Google Pay, amire sokan számítanak. Ez nem szerencsés a fogyasztók számára, mert anélkül, hogy telefonját a gyártó megjavíttaná, nem tudná saját maga megjavítani.

Lépjen be a Remote Key Provisioningba. Az Android 12-től kezdődően a Google lecseréli a gyári magánkulcs-szolgáltatást a következők kombinációjára gyári nyilvános kulcs kinyerése és az éteren keresztüli tanúsítványkiépítés rövid élettartammal tanúsítványokat. Ez a séma szükséges lesz az Android 13-ban, és van néhány előnye is. Mindenekelőtt megakadályozza, hogy az OEM-eknek és ODM-eknek kezelniük kelljen a kulcstitkot egy gyárban. Másodszor, lehetővé teszi az eszközök visszaállítását, ha kulcsaik veszélybe kerülnek, ami azt jelenti, hogy a fogyasztók nem veszítik el örökre a védett szolgáltatásokhoz való hozzáférést. Most ahelyett, hogy egy olyan tanúsítványt használna, amelyet az eszközön lévő kulcs alapján számítanak ki, és amely kiszivároghat a biztonsági rés esetén a Google-tól minden alkalommal ideiglenes tanúsítványt kell kérni, amikor egy tanúsítványt igénylő szolgáltatás jelentkezik használt.

Ami a működését illeti, elég egyszerű. Minden eszköz egyedi, statikus kulcspárt állít elő, és ennek a kulcspárnak a nyilvános részét az OEM-gyártó kinyeri ki a gyárában, és elküldi a Google szervereire. Ott ezek szolgálnak majd a bizalom alapjául a későbbi ellátáshoz. A privát kulcs soha nem hagyja el azt a biztonságos környezetet, amelyben előállították.

Amikor egy eszközt először használnak az internethez való csatlakozáshoz, tanúsítvány-aláírási kérelmet generál a következőhöz: által generált kulcsokat, aláírva azt a titkos kulccsal, amely megfelel a ben gyűjtött nyilvános kulcsnak gyár. A Google háttérkiszolgálói ellenőrzik a kérés hitelességét, majd aláírják a nyilvános kulcsokat, visszaküldve a tanúsítványláncokat. Az eszköz kulcstárolója ezután tárolja ezeket a tanúsítványláncokat, és minden alkalommal hozzárendeli őket az alkalmazásokhoz, amikor tanúsítványt kérnek. Ez bármi lehet a Google Paytől a Pokemon Go-ig.

Ez a pontos tanúsítványkérési lánc rendszeresen megtörténik a tanúsítványok lejártakor vagy az aktuális kulcskészlet kimerülésekor. Minden alkalmazás más tanúsító kulcsot kap, és maguk a kulcsok rendszeresen cserélődnek, mindkettő biztosítja a magánélet védelmét. Ezenkívül a Google háttérkiszolgálói úgy vannak szegmentálva, hogy az eszköz nyilvános kulcsát ellenőrző szerver nem látja a csatolt tanúsító kulcsokat. Ez azt jelenti, hogy a Google nem tudja visszahozni a tanúsítási kulcsokat az azokat kérő eszközhöz.

A Google szerint a végfelhasználók nem fognak észrevenni semmilyen változást, bár a fejlesztőknek a következőkre kell figyelniük.

• Tanúsítványlánc felépítése
  • Új online szolgáltatási infrastruktúránk természetéből adódóan a lánc hossza hosszabb, mint korábban volt, és változhat.
• A bizalom gyökere
  • A bizalom gyökere végül az aktuális RSA-kulcsról ECDSA-kulcsra frissül.
• Az RSA tanúsítvány elavultsága
  • A KeyMint által generált és tanúsított összes kulcs ECDSA kulccsal és a megfelelő tanúsítványlánccal lesz aláírva. Korábban az aszimmetrikus kulcsokat a megfelelő algoritmussal írták alá.
• Rövid élettartamú bizonyítványok és tanúsítványkulcsok
  • Az eszközökhöz kiadott tanúsítványok általában legfeljebb két hónapig érvényesek, mielőtt lejárnak, és kicserélik őket.

Felvettük a kapcsolatot a Google-lal, és megkérdeztük, hogy ennek van-e jelentősége a Widevine DRM-re vonatkozóan, és hogy egyes Pixel-felhasználók hogyan számoltak be arról, hogy DRM-szintjüket leminősítették egy zárolt rendszerbetöltővel. Azt is megkérdeztük, hogy ez most OTA-frissítésként terjeszthető-e a felhasználók számára a Google Play-szolgáltatásokon keresztül. Biztosan frissítjük ezt a cikket, ha visszajelzést kapunk. Nem világos, hogy a jelenlegi bizalmi lánc mely összetevőit érinti és milyen módon.

---

Forrás: Google