Googles fjernnøgleforsyning vil være påbudt i Android 13: Hvad betyder det for dig

Androids nøgleattest er rygraden i mange betroede tjenester på vores smartphones, herunder SafetyNet, Digital Car Key og Identity Credential API. Det har været påkrævet som en del af Android siden Android 8 Oreo og var afhængig af en rodnøgle installeret på en enhed fra fabrikken. Leveringen af ​​disse nøgler krævede den største hemmeligholdelse fra producentens side, og hvis en nøgle blev lækket, ville det betyde, at nøglen skulle tilbagekaldes. Dette ville resultere i, at en forbruger ikke kunne bruge nogen af ​​disse betroede tjenester, hvilket ville være uheldigt, hvis der nogensinde skulle være en sårbarhed, der kan afsløre det. Fjernnøgleforsyning, som vil blive påbudt i Android 13, har til formål at løse det problem.

Komponenterne, der udgør den nuværende tillidskæde på Android

Før du forklarer, hvordan det nye system fungerer, er det vigtigt at give kontekst for, hvordan 

gammel (og stadig på plads for mange enheder) systemet fungerer. Mange telefoner bruger i dag hardware-understøttet nøgleattestering, som du måske er bekendt med som sømmet i kisten til enhver form for SafetyNet-bypass. Der er adskillige begreber, som er vigtige at forstå for den aktuelle tilstand af nøgleattestering.

Det er en kombination af disse koncepter, der sikrer, at en udvikler kan stole på, at en enhed ikke er blevet pillet ved, og kan håndtere følsomme oplysninger i TEE'en.

Trusted Execution Environment

Et Trusted Execution Environment (TEE) er en sikker region på SoC'en, der bruges til at håndtere kritiske data. TEE er obligatorisk på enheder lanceret med Android 8 Oreo og nyere, hvilket betyder, at enhver ny smartphone har det. Alt, der ikke er inden for TEE, betragtes som "ikke-pålidelig" og kan kun se krypteret indhold. For eksempel er DRM-beskyttet indhold krypteret med nøgler, der kun kan tilgås af software, der kører på TEE. Hovedprocessoren kan kun se en strøm af krypteret indhold, hvorimod indholdet kan dekrypteres af TEE og derefter vises for brugeren.

ARM Trustzone

Trusty er et sikkert operativsystem, der giver en TEE på Android, og på ARM-systemer gør det brug af ARMs Trustzone. Trusty køres på den samme processor som det primære operativsystem og har adgang til enhedens fulde kraft, men er fuldstændig isoleret fra resten af ​​telefonen. Trusty består af følgende:

• En lille OS-kerne afledt af Lille kerne
• En Linux-kernedriver til at overføre data mellem det sikre miljø og Android
• Et Android-brugerområdebibliotek til at kommunikere med betroede applikationer (det vil sige sikre opgaver/tjenester) via kernedriveren

Fordelen, den har i forhold til proprietære TEE-systemer, er, at disse TEE-systemer kan være dyre og også skabe ustabilitet i Android-økosystemet. Trusty leveres gratis til partner-OEM'er af Google, og det er open source. Android understøtter andre TEE-systemer, men Trusty er den, som Google presser mest på.

StrongBox

StrongBox-enheder er fuldstændig separate, specialbyggede og certificerede sikre CPU'er. Disse kan omfatte indlejrede Secure Elements (eSE) eller en on-SoC Secure Processing Unit (SPU). Google siger, at StrongBox i øjeblikket "anbefales" at komme med enheder, der lanceres med Android 12 (i henhold til kompatibilitetsdefinitionsdokumentet), da det sandsynligvis bliver et krav i en fremtidig Android-udgivelse. Det er i bund og grund en strengere implementering af et hardware-understøttet nøglelager og kan implementeres sammen med TrustZone. Et eksempel på en implementering af StrongBox er Titan M-chippen i Pixel-smartphones. Ikke mange telefoner gør brug af StrongBox, og de fleste gør brug af ARMs Trustzone.

Keymaster TA

Keymaster Trusted Application (TA) er den sikre keymaster, der administrerer og udfører alle nøglelagerhandlinger. Den kan for eksempel køre på ARMs TrustZone.

Hvordan Key Attestation ændrer sig med Android 12 og Android 13

Hvis en nøgle er afsløret på en Android-smartphone, er Google forpligtet til at tilbagekalde den. Dette udgør et problem for enhver enhed, der har en nøgle indsprøjtet på fabrikken - enhver form for læk, der blotlægger nøglen, ville betyde, at brugere ikke ville være i stand til at få adgang til bestemt beskyttet indhold. Dette kan endda omfatte tilbagekaldelse af adgang til tjenester som Google Pay, noget som mange mennesker stoler på. Dette er uheldigt for forbrugerne, fordi uden at få din telefon repareret af en producent, ville der ikke være nogen måde for dig at reparere det selv.

Indtast fjernnøgleforsyning. Fra og med Android 12 erstatter Google den fabriksinstallerede privatnøgleforsyning med en kombination af udtræk af offentlige nøgler på fabrikken og over-the-air certifikatforsyning med kort levetid certifikater. Denne ordning vil være påkrævet i Android 13, og der er et par fordele ved det. Først og fremmest forhindrer det OEM'er og ODM'er i at skulle administrere nøglehemmeligheden på en fabrik. For det andet tillader det, at enheder kan gendannes, hvis deres nøgler kompromitteres, hvilket betyder, at forbrugerne ikke vil miste adgangen til beskyttede tjenester for altid. Nu, i stedet for at bruge et certifikat, der er beregnet ved hjælp af en nøgle, der er på enheden og kan blive lækket gennem en sårbarhed, anmodes Google om et midlertidigt certifikat, hver gang en tjeneste kræver attestering Brugt.

Med hensyn til hvordan det fungerer, er det simpelt nok. Et unikt, statisk nøglepar genereres af hver enhed, og den offentlige del af dette nøglepar udtrækkes af OEM'en på deres fabrik og sendes til Googles servere. Der vil de tjene som grundlag for tillid til levering senere. Den private nøgle forlader aldrig det sikre miljø, hvori den er genereret.

Når en enhed første gang bruges til at oprette forbindelse til internettet, genererer den en anmodning om certifikatsignering nøgler, den har genereret, og signerer den med den private nøgle, der svarer til den offentlige nøgle, der er indsamlet i fabrik. Googles backend-servere vil bekræfte ægtheden af ​​anmodningen og derefter underskrive de offentlige nøgler og returnere certifikatkæderne. Nøglelageret på enheden gemmer derefter disse certifikatkæder og tildeler dem til apps, hver gang der anmodes om en attestation. Dette kan være alt fra Google Pay til Pokemon Go.

Denne nøjagtige certifikatanmodningskæde vil ske regelmæssigt ved udløb af certifikaterne eller udtømning af den aktuelle nøgleforsyning. Hver applikation modtager en anden attestationsnøgle, og selve nøglerne roteres regelmæssigt, hvilket begge sikrer privatlivets fred. Derudover er Googles backend-servere segmenteret, således at den server, der verificerer enhedens offentlige nøgle, ikke kan se de vedhæftede attestationsnøgler. Det betyder, at det ikke er muligt for Google at korrelere attestnøgler tilbage til den bestemte enhed, der anmodede om dem.

Slutbrugere vil ikke bemærke nogen ændringer, selvom udviklere skal passe på følgende, ifølge Google.

• Certifikatkædestruktur
  • På grund af arten af ​​vores nye online-forsyningsinfrastruktur er kædelængden længere, end den var tidligere og kan ændres.
• Rod af tillid
  • Tillidsroden vil med tiden blive opdateret fra den nuværende RSA-nøgle til en ECDSA-nøgle.
• RSA-attest afskrivning
  • Alle nøgler, der genereres og attesteres af KeyMint, vil blive signeret med en ECDSA-nøgle og tilsvarende certifikatkæde. Tidligere blev asymmetriske nøgler signeret af deres tilsvarende algoritme.
• Kortvarige certifikater og attestnøgler
  • Certifikater, der leveres til enheder, vil generelt være gyldige i op til to måneder, før de udløber og roteres.

Vi kontaktede Google og spurgte, om dette har nogen relevans for Widevine DRM, og hvordan nogle Pixel-brugere rapporterede, at deres DRM-niveau blev nedgraderet med en låst bootloader. Vi spurgte også, om dette kan distribueres som en OTA-opgradering til brugere via Google Play Services nu. Vi vil være sikker på at opdatere denne artikel, hvis vi hører tilbage. Det er ikke klart, hvilke komponenter i den nuværende tillidskæde der vil blive påvirket eller på hvilken måde.

---

Kilde: Google