Wie bepaalt of jouw Android-apparaat veilig is?

Via de SDK kan de ontwikkelaar bij de systeemservice van Unified Attestation informeren naar beschikbare backends. Dat is nodig omdat het om een gefedereerd systeem gaat. In principe kan iedereen die dat wil een eigen backend hosten. De backends die een apparaat gebruikt, worden opgeslagen in een configuratiebestand van de systeemservice. In de praktijk zal waarschijnlijk de ROM-fabrikant of de smartphone-aanbieder de gebruikte backends bepalen.

De service kent de URL’s, ID’s en handtekeningen van de mogelijke backend-servers, maar geeft de app die erom vraagt alleen de ID’s van de mogelijke servers door. Met die informatie vraagt de app aan zijn app-server welke backend hij bij voorkeur moet gebruiken en welke hij moet negeren.

Met de gewenste backend-ID, de project-ID en de hash van de CanonicalRequestString start de app dan het eerste deel van het attestatieproces. Dat genereert eerst een nieuwe sleutel in de Android-keystore en vraagt een attestatie aan. De attestatie zelf wordt gemaakt door Android-systeemdiensten.

De SDK leest die alleen uit, samen met een handtekening waarvan de betrouwbaarheid via een certificaatketen uiteindelijk afhangt van een rootcertificaat. Dat is meestal een Google-certificaat, omdat de privésleutels vast in de hardware zijn ingebakken. In de toekomst zou bijvoorbeeld Volla zijn apparaten echter ook met een zelfondertekend certificaat kunnen leveren.

Met die keten en de overige informatie wendt de SDK zich vervolgens tot de systeemservice. Die vult de informatie aan met metadata over het apparaat en stuurt die door naar de geselecteerde backend.

Met behulp van die metadata controleert de backend vervolgens of er een bijpassende vermelding voor het apparaat in zijn database staat. Als die er is, wordt vervolgens gecontroleerd of het rootcertificaat van de doorgegeven certificaatketen en het voor het apparaat ingestelde certificaatanker dezelfde openbare sleutel hebben. Daarnaast wordt gecontroleerd of de keten ook echt zonder onderbrekingen loopt van het rootcertificaat tot aan de attestatie.

Pas daarna wordt de daadwerkelijke attestatie verwerkt. Enerzijds controleert de backend of de app die het attestatieverzoek heeft ingediend in de database staat en nog geldig ondertekend is, dus ongewijzigd, en of het verzoek dus bijvoorbeeld echt afkomstig is van de originele app van de openbaarvervoersaanbieder.

Vervolgens beoordeelt de backend de veiligheid van het apparaat aan de hand van de vereisten die voor dat specifieke apparaat zijn vastgesteld. Uiteindelijk wordt er een token met een geldigheidsduur van 60 seconden aangemaakt en door de backend ondertekend. Het token bevat de beslissing van de server, de informatie over wie het verzoek heeft ingediend en de bijbehorende request-hash. Het terugsturen van het token via de service en de SDK naar de app markeert het einde van het eerste deel van de attestatie.

Als het gelukt is, heeft de app dan een ondertekende veiligheidsbeoordeling, maar moet die nog wel controleren. Daarvoor wendt de app zich met het token en de – dit keer niet-gehashte – canonical RequestString rechtstreeks tot de app-server. Die hasht vervolgens de RequestString en vraagt bij de attestatie-backend of het token geldig is, waarbij hij zich identificeert met een API-sleutel. De backend controleert vervolgens of het token is ondertekend door een van de aangesloten backends, of de attestatie in het token overeenkomt met de gebruikte API-sleutel en of het token nog niet is verlopen.

Als alles klopt, stuurt de backend de status van het token terug en kan de app-server op basis daarvan beslissen hoe de app zich gedraagt.

Het concept van de federatie klinkt net zo veelbelovend als een Europees alternatief voor Googles Play Integrity – maar niet iedereen ziet Unified Attestation als vooruitgang. GrapheneOS, bekend om zijn soms erg confronterende en strijdlustige communicatie, maakt geen deel uit van het consortium en bekritiseert het systeem duidelijk in zijn gebruikelijke scherpe bewoordingen.

Vanuit het oogpunt van GrapheneOS biedt Unified Attestation nauwelijks een voordeel ten opzichte van de Play Integrity-API. Beide zijn gesloten systemen, gecontroleerd door één bedrijf of een concern, dat bepaalt welke apparaten als veilig worden beschouwd. Ook al is de macht verdeeld over meerdere bedrijven, het blijft een grote macht die misbruikt kan worden.

Daarnaast zit er in het Android Open Source Project (AOSP), de gemeenschappelijke basis van de verschillende Android-varianten, al een hardware-attestatiesysteem ingebouwd. Dat systeem biedt de hierboven genoemde Android-systeemdiensten, die de daadwerkelijke attestatie genereren. Zowel Play Integrity als Unified Attestation bouwen voort op dat hardware-attestatiesysteem. Meestal gebruikt het weliswaar de root-of-trust van Google, maar andere fabrikanten kunnen hun eigen root-of-trust opslaan.

Dat in AOSP geïntegreerde systeem levert echter alleen cryptografisch bewijs over bijvoorbeeld of de bootloader vergrendeld is of welk patch-niveau er is. App-ontwikkelaars moeten dus zelf beslissen welke aspecten ze willen controleren, aan welke eisen hun apps moeten voldoen en welke root-of-trust van welke aanbieders ze accepteren.

Unified Attestation en Play Integrity breiden dat systeem uit met een SDK en serverdiensten en beoordelen zelf hoe veilig een besturingssysteem is. Dat maakt het makkelijker voor ontwikkelaars, maar je geeft daarmee ook de beoordeling uit handen aan derden en sluit – bewust of onbewust – apparaten uit die eigenlijk wel aan de veiligheidseisen van je app zouden voldoen, of je beschouwt apparaten als veilig die dat eigenlijk niet zijn.

Dat laatste risico bestaat in ieder geval bij Play Integrity omdat Google relatief lakse beveiligingsnormen hanteert. Zo kan het hoogste beveiligingsniveau MEETS_STRONG_INTEGRITY op oudere Android-versies zelfs helemaal zonder recente beveiligingsupdates bereikt worden.

Pas vanaf Android 13 vereist het hoogste integriteitsniveau actuele beveiligingsupdates – waarbij ‘actueel’ hier ‘binnen het afgelopen jaar’ betekent, wat weer een erg soepele grens is.

Bij Googles attestation mag de laatste securitypatch ook voor ‘strong integrity’ een jaar oud zijn – als het al vereist is.

Maar ook afgezien van dergelijke beoordelingskwesties zijn de tot nu toe beschreven attestation-benaderingen vanuit veiligheidsoogpunt niet optimaal. Het gaat om zogenaamde root-based attestation-systemen. De attestatie is dus gebaseerd op een certificaatketen die teruggaat naar een inherent betrouwbare root.

Bij root-based attestatie begint die keten in de hardware-backed keystore, een beveiligd gedeelte van de hoofd-CPU of een speciale chip (vergelijkbaar met de TPM op pc’s). In die keystore wordt de attestatie gegenereerd, oftewel een gegevensset die de status van de bootloader, het huidige patchlevel en nog veel meer veiligheidsrelevante informatie bevat.

De attestatie wordt ondertekend met een privésleutel die in de keystore opgeslagen is. De bijbehorende openbare sleutel wordt vervolgens bijvoorbeeld via certificaten van de betreffende fabrikant tot aan de root-CA geverifieerd.

Maar niet elke smartphone heeft per se een eigen privésleutel. Vooral in de beginperiode van de Android-keystores deelden alle toestellen van hetzelfde model soms één sleutel, en soms werden sleutels zelfs voor meerdere modellen gebruikt. Als je dan op een willekeurig apparaat de keystore kraakt en de privésleutel in handen krijgt, kun je die gebruiken om attesten te genereren – voor willekeurige apparaten van hetzelfde model of zelfs voor andere soorten apparaten.

Maar ook al hebben huidige apparaten unieke privésleutels, deze zijn nog steeds niet cryptografisch aan precies dat ene apparaat gebonden.

Om het probleem uit te leggen, nemen we de Play Integrity-API als voorbeeld en gaan we ervan uit dat je de privésleutel van een Pixel 3 hebt kunnen extraheren. De hieronder beschreven problemen gelden echter ook voor andere root-based attestatiesystemen, zoals Unified Attestation.

Stel dat het toestel waarop de attestatie vervalst moet worden, een geroote Pixel 10 is. Voor de status MEETS_DEVICE_INTEGRITY controleert de Integrity-API van Google onder andere via Androids hardware-attestatie of het toestel geroot is. Normaal gesproken zou die controle op het toestel slagen, maar juist omdat het geroot is, kan er een rootmodule actief zijn die het attestatieverzoek onderschept en zelf beantwoordt.

Zelfs de rootmodule heeft geen toegang tot de echte privésleutel van de Pixel 10, maar hij kan wel zijn vervalste attest genereren met de privésleutel van de Pixel 3. Om te voorkomen dat de zwendel aan het licht komt, doet de rootmodule in principe alsof het toestel geen Pixel 10 is, maar een Pixel 3. De root-gebaseerde attestatie is niet aan een specifiek toestel gebonden, waardoor Play Integrity genoegen neemt met de vervalste Pixel 3-attestatie op een zogenaamd Pixel 3-toestel en MEETS_DEVICE_INTEGRITY rapporteert.

Google probeert dat probleem op te lossen door gelekte sleutels (zoals die van de Pixel 3 in het voorbeeld) op een blokkeerlijst te zetten. Zo ontstaat er een kat-en-muisspel om sleutels te blokkeren zodra ze op te veel toestellen opduiken. Maar omdat daarmee ook het originele toestel zijn vertrouwensstatus verliest, leidt dat tot nevenschade.

Bij de huidige modellen blijft het beperkt tot het specifieke toestel waar de sleutel uit is gehaald (en dat je terecht als niet meer betrouwbaar kunt beschouwen) omdat elke moderne Pixel een eigen privésleutel heeft. Door het eerder genoemde gebruik van sleutels op meerdere apparaten bij oudere modellen kan een blokkering echter ook gevolgen hebben voor alle apparaten van hetzelfde type.

Daarbij komt nog een tweede probleem, dat ook bestaat als er geen keystore gekraakt is. De attestatie-aanvraag die op een geroot apparaat wordt gedaan, kan in realtime worden doorgestuurd naar een tweede, niet-geroot apparaat. Daar wordt een geldige attestatie gegenereerd, die vervolgens weer wordt onderschept, teruggestuurd naar het oorspronkelijke apparaat en daar getoond. Time-outs en soortgelijke controles kunnen die omzeilingsmethode bemoeilijken, maar niet volledig voorkomen.

Een manier om die problemen op te lossen is pinning-based attestation. Die vorm van attestatie maakt gebruik van een Trust on first use-model (TOFU). De eerste controle wordt echter niet blindelings vertrouwd, die verloopt net als bij root-based attestatie via een certificaatketen die naar een bekende root of trust leidt. Vanaf dat moment wordt er echter in de keystore van het apparaat een nieuwe, individuele privésleutel gegenereerd en wordt de attestatie daarmee ondertekend. De controleur ‘pint’ die sleutel dan, dat wil zeggen dat hij de certificaatketen en de vingerafdruk van de sleutel opslaat. Vanaf dat moment gebruikt het apparaat altijd die sleutel om de attestatie te ondertekenen en kijkt de controleur of de vingerafdruk overeenkomt.

De Auditor-app van GrapheneOS gebruikt pinning-based attestation om een apparaat te controleren. (Afbeelding Graphene OS / Google Play).

Door die procedure is de privésleutel vast aan een apparaat gekoppeld omdat de controleur alleen voor dat apparaat de juiste vingerafdruk heeft vastgelegd. Daardoor zijn aanvallen zoals hierboven beschreven uitgesloten, wat de veiligheid van de procedure verhoogt en als voordeel heeft dat centrale blokkeerlijsten overbodig worden.

Een voorbeeld van dat soort attestatie is de Auditor-app van GrapheneOS. Die methode is bovendien ook geïmplementeerd in de attestation-API van AOSP, zodat apps er gebruik van kunnen maken. Ook Unified Attestation kan zijn diensten uitbreiden naar op pinning gebaseerde attestatie.

De praktische dominantie van Google op het gebied van attestatie binnen Android is problematisch. Er zijn echter niet alleen alternatieven beschikbaar, maar die zijn ook al in Android geïmplementeerd. Om echt een rol te kunnen spelen, moeten ze zich echter verder verspreiden.

Unified Attestation zou daar verandering in kunnen brengen en de situatie in ieder geval een beetje verbeteren. Want ook al is Unified Attestation zelf niet zonder problemen, het zou het Android-ecosysteem toch een stukje verder loskoppelen van Google – en in het algemeen laten zien dat app-ontwikkelaars voor attestatie niet per se op diensten van Google hoeven te vertrouwen.

Het is echter zeker niet vanzelfsprekend dat Unified Attestation aan populariteit zal winnen, vooral omdat GrapheneOS, een belangrijke speler, niet aan het project meedoet en het ook geen goed idee vindt.

App-ontwikkelaars die zo veel mogelijk veiligheid willen en daar wat moeite voor over hebben, kunnen gebruikmaken van de attestation-systemen van AOSP. Om Google de beslissingsbevoegdheid te ontnemen over wat een veilig systeem is, zouden echter heel veel ontwikkelaars die weg moeten inslaan.

[1] Axel Vahldiek en Marco den Teuling, Secure boot-problemen en de gevolgen, c’t 10/2026, p.70

App-compatibiliteit in GrapheneOS: GrapheneOS, een Android-variant die als veilig wordt beschouwd, wordt door sommige apps geblokkeerd omdat het geen Google-certificeringen heeft.

https://grapheneos.org/articles/attestation-compatibility-guide#apps-banning-grapheneos

(Mats Schoknecht en Marco den Teuling)