De Remote Key Provisioning van Google wordt verplicht gesteld in Android 13: wat dat voor u betekent

De sleutelattest van Android vormt de ruggengraat van veel vertrouwde services op onze smartphones, waaronder SafetyNet, Digital Car Key en de Identity Credential-API. Het is vereist als onderdeel van Android sinds Android 8 Oreo en was afhankelijk van een rootsleutel die in de fabriek op een apparaat was geïnstalleerd. De levering van deze sleutels vereiste uiterste geheimhouding van de kant van de fabrikant, en als een sleutel zou lekken, zou dat betekenen dat de sleutel zou moeten worden ingetrokken. Dit zou ertoe leiden dat een consument geen van deze vertrouwde diensten kan gebruiken, wat jammer zou zijn als er ooit een kwetsbaarheid zou zijn waardoor deze zou kunnen worden blootgelegd. Remote Key Provisioning, die verplicht wordt gesteld in Androïde 13, heeft tot doel dat probleem op te lossen.

De componenten waaruit de huidige vertrouwensketen op Android bestaat

Voordat we uitleggen hoe het nieuwe systeem werkt, is het belangrijk om context te bieden over hoe het systeem werkt oud (en nog steeds aanwezig voor veel apparaten) systeem werkt. Veel telefoons maken tegenwoordig gebruik van door hardware ondersteunde sleutelattesten, die u wellicht kent als de spijker in de kist voor elke vorm van SafetyNet-bypass. Er zijn verschillende concepten die belangrijk zijn om te begrijpen voor de huidige stand van zaken op het gebied van sleutelattesten.

Het is een combinatie van deze concepten die ervoor zorgt dat een ontwikkelaar erop kan vertrouwen dat er niet met een apparaat is geknoeid en dat hij gevoelige informatie in de TEE kan verwerken.

Vertrouwde uitvoeringsomgeving

Een Trusted Execution Environment (TEE) is een beveiligde regio op de SoC die wordt gebruikt voor het verwerken van kritieke gegevens. TEE is verplicht op apparaten die zijn gelanceerd met Android 8 Oreo en hoger, wat betekent dat elke recente smartphone dit heeft. Alles wat niet binnen de TEE valt, wordt als "niet-vertrouwd" beschouwd en kan alleen gecodeerde inhoud zien. DRM-beveiligde inhoud wordt bijvoorbeeld gecodeerd met sleutels die alleen toegankelijk zijn voor software die op de TEE draait. De hoofdprocessor kan alleen een stroom gecodeerde inhoud zien, terwijl de inhoud door de TEE kan worden gedecodeerd en vervolgens aan de gebruiker kan worden weergegeven.

ARM Trustzone

Trusty is een veilig besturingssysteem dat een TEE biedt op Android, en op ARM-systemen maakt het gebruik van ARM's Trustzone. Trusty wordt uitgevoerd op dezelfde processor als het primaire besturingssysteem en heeft toegang tot de volledige kracht van het apparaat, maar is volledig geïsoleerd van de rest van de telefoon. Trusty bestaat uit het volgende:

• Een kleine OS-kernel afgeleid van Kleine Kernel
• Een Linux-kerneldriver om gegevens over te dragen tussen de beveiligde omgeving en Android
• Een Android-gebruikersruimtebibliotheek om te communiceren met vertrouwde applicaties (dat wil zeggen beveiligde taken/services) via het kernelstuurprogramma

Het voordeel dat het heeft ten opzichte van propriëtaire TEE-systemen is dat die TEE-systemen duur kunnen zijn en ook instabiliteit in het Android-ecosysteem kunnen veroorzaken. Trusty wordt door Google gratis aan partner-OEM's geleverd en is open source. Android ondersteunt andere TEE-systemen, maar Trusty is degene die Google het meest pusht.

Sterke Box

StrongBox-apparaten zijn volledig afzonderlijke, speciaal gebouwde en gecertificeerde veilige CPU's. Deze kunnen ingebedde Secure Elements (eSE) of een on-SoC Secure Processing Unit (SPU) omvatten. Google zegt dat StrongBox momenteel "sterk aanbevolen" is voor apparaten die ermee worden gelanceerd Androïde 12 (volgens het Compatibiliteitsdefinitiedocument), aangezien dit waarschijnlijk een vereiste zal worden in een toekomstige Android-release. Het is in wezen een striktere implementatie van een door hardware ondersteunde keystore en kan naast TrustZone worden geïmplementeerd. Een voorbeeld van een implementatie van StrongBox is de Titan M-chip in Pixel-smartphones. Niet veel telefoons maken gebruik van StrongBox, en de meeste maken gebruik van ARM's Trustzone.

Keymaster TA

Keymaster Trusted Application (TA) is de veilige keymaster die alle sleutelopslagbewerkingen beheert en uitvoert. Het kan bijvoorbeeld draaien op ARM's TrustZone.

Hoe Key Attestation verandert met Android 12 en Android 13

Als een sleutel op een Android-smartphone wordt weergegeven, is Google verplicht deze in te trekken. Dit vormt een probleem voor elk apparaat waarop in de fabriek een sleutel is ingespoten; elk lek waardoor de sleutel wordt blootgelegd, zou betekenen dat gebruikers geen toegang zouden hebben tot bepaalde beschermde inhoud. Dit kan zelfs het intrekken van de toegang tot diensten als Google Pay omvatten, iets waar veel mensen op vertrouwen. Dit is jammer voor consumenten, want als u uw telefoon niet door een fabrikant laat repareren, kunt u deze niet zelf repareren.

Ga naar Remote Key Provisioning. Vanaf Android 12 vervangt Google de in-factory private key provisioning door een combinatie van extractie van openbare sleutels in de fabriek en levering van draadloze certificaten met een korte levensduur certificaten. Dit schema is vereist in Android 13 en er zitten een aantal voordelen aan. In de eerste plaats voorkomt het dat OEM's en ODM's sleutelgeheimen in een fabriek moeten beheren. Ten tweede kunnen apparaten worden hersteld als hun sleutels in gevaar komen, wat betekent dat consumenten de toegang tot beschermde diensten niet voor altijd zullen verliezen. In plaats van een certificaat te gebruiken dat is berekend met behulp van een sleutel die op het apparaat staat en via een kwetsbaarheid wordt er bij Google een tijdelijk certificaat gevraagd telkens wanneer een service attest vereist gebruikt.

Wat betreft hoe het werkt, het is eenvoudig genoeg. Door elk apparaat wordt een uniek, statisch sleutelpaar gegenereerd. Het openbare deel van dit sleutelpaar wordt door de OEM in de fabriek opgehaald en naar de servers van Google verzonden. Daar zullen ze dienen als basis voor vertrouwen voor latere voorzieningen. De private sleutel verlaat nooit de beveiligde omgeving waarin deze is gegenereerd.

Wanneer een apparaat voor het eerst wordt gebruikt om verbinding te maken met internet, genereert het een certificaatondertekeningsverzoek sleutels die het heeft gegenereerd, en onderteken deze met de privésleutel die overeenkomt met de openbare sleutel die is verzameld in de fabriek. De backend-servers van Google verifiëren de authenticiteit van het verzoek en ondertekenen vervolgens de openbare sleutels, waardoor de certificaatketens worden geretourneerd. De sleutelopslag op het apparaat slaat deze certificaatketens vervolgens op en wijst ze toe aan apps wanneer er om een ​​attest wordt gevraagd. Dit kan van alles zijn, van Google Pay tot Pokemon Go.

Deze exacte certificaataanvraagketen zal regelmatig plaatsvinden bij het verlopen van de certificaten of het uitputten van de huidige sleutelvoorraad. Elke applicatie krijgt een andere attestsleutel en de sleutels zelf worden regelmatig gerouleerd, wat beide de privacy garandeert. Bovendien zijn de backend-servers van Google zodanig gesegmenteerd dat de server die de openbare sleutel van het apparaat verifieert, de bijgevoegde attestsleutels niet ziet. Dit betekent dat het voor Google niet mogelijk is om attestsleutels terug te koppelen aan het specifieke apparaat waarop ze zijn aangevraagd.

Eindgebruikers zullen geen veranderingen merken, al moeten ontwikkelaars volgens Google op het volgende letten.

• Certificaatketenstructuur
  • Vanwege de aard van onze nieuwe online provisioning-infrastructuur is de ketenlengte langer dan voorheen en aan verandering onderhevig.
• Wortel van vertrouwen
  • De vertrouwenswortel zal uiteindelijk worden bijgewerkt van de huidige RSA-sleutel naar een ECDSA-sleutel.
• Beëindiging van RSA-attest
  • Alle sleutels die door KeyMint worden gegenereerd en gecertificeerd, worden ondertekend met een ECDSA-sleutel en de bijbehorende certificaatketen. Voorheen werden asymmetrische sleutels ondertekend door het bijbehorende algoritme.
• Kortlopende certificaten en attestsleutels
  • Certificaten die op apparaten zijn ingericht, zijn doorgaans maximaal twee maanden geldig voordat ze verlopen en worden gerouleerd.

We hebben contact opgenomen met Google en gevraagd of dit relevant is voor Widevine DRM en hoe sommige Pixel-gebruikers meldden dat hun DRM-niveau werd gedowngraded met een vergrendelde bootloader. We hebben ook gevraagd of dit nu als OTA-upgrade onder gebruikers kan worden gedistribueerd via Google Play Services. We zullen dit artikel zeker bijwerken als we iets horen. Het is niet duidelijk welke componenten van de huidige vertrouwensketen zullen worden beïnvloed en op welke manier.

---

Bron: Googlen