Belangrijkste punten
- SafetyNet Attestation beoordeelt de integriteit van Android-devices om rooting, custom firmware of manipulatie op systeemniveau te detecteren voordat toegang tot gevoelige gegevens wordt verleend.
- Het beoordelingsproces verloopt via een beveiligde cryptografische cyclus waarin de backendserver de digitaal ondertekende statusmelding onafhankelijk controleert om vervalste antwoorden te voorkomen.
- Als betrouwbare poortwachter voor de beveiliging beperkt device attestation proactief ernstige risico’s (malware-injectie, misbruik van referenties, frauduleuze transacties).
- Omdat de oude softwarescans regelmatig werden omzeild, heeft Google SafetyNet officieel uitgefaseerd ten gunste van de robuustere, hardwarematig ondersteunde Play Integrity API.
- Organisaties doen er goed aan deze signalen over apparaatgezondheid op te nemen in bredere governance-kaders om conditional access te automatiseren, beveiligingsbeleid af te dwingen en workflows voor incident response te starten.
Mobiele devices krijgen voortdurend te maken met dreigingen van malware en rootingtools die de bedrijfsbeveiliging proberen te omzeilen. Om gevoelige gegevens te beschermen, gebruiken organisaties SafetyNet Attestation om de integriteit van een device tijdens runtime te verifiëren.
In deze gids leest u hoe deze beveiligingslaag gecompromitteerde omgevingen detecteert en mobile threat defense versterkt.
SafetyNet Attestation in het kort
Organisaties gebruiken device attestation om te verifiëren dat mobiele endpoints veilig en ongewijzigd zijn voordat ze toegang krijgen tot gevoelige gegevens.
Google SafetyNet Attestation was een centrale Google-service die de gezondheid van een Android-omgeving beoordeelde. Ontwikkelaars kregen er een cryptografisch ondertekende verklaring mee dat een device authentiek was en voldeed aan de basisnormen voor beveiliging.
Als betrouwbare SafetyNet-checker beoordeelde deze API de integriteit van een device door te zoeken naar kritieke systeemafwijkingen. Concreet controleerde de API of het device:
- Geroot of gecompromitteerd was.
- Niet-gecertificeerde of custom firmware draaide.
- Op het niveau van het kernsysteem was aangepast.
- Zakte voor de basiscontroles op Android-compatibiliteit.
Na de beoordeling genereerde de service een veilig ondertekend antwoord. Met die payload kon de backendserver van de applicatie onafhankelijk verifiëren of het device te vertrouwen was.
Belangrijkste onderdelen van een attestation-verdict
De attestation-payload leverde twee hoofdverdicts op om de status van het device te bepalen:
| Verdict | Wat het betekent | Slaagcriteria |
| Basic Integrity | Beoordeelt de algemene beveiliging van het device en de API. | Standaard devices zonder manipulatie. |
| CTS Profile Match | Strengere controles op de compatibiliteitsnormen van Android. | Ongewijzigde, door Google gecertificeerde devices met een vergrendelde bootloader. |
Zo werkt de attestation-API
Applicaties gebruiken de attestation-API om een beveiligde, geverifieerde beoordeling van de actuele status van het device op te vragen.
Om de authenticiteit te garanderen, bevat het antwoord van Google doorgaans:
- Verificatie van de basisintegriteit: controleert op gerootte of gecompromitteerde systemen.
- Status van de compatibiliteitsvalidatie: bevestigt dat het device voldoet aan de officiële Android-normen voor hardware en software.
- Cryptografische handtekening: beveiligt de payload om manipulatie van gegevens te voorkomen.
- Validatie met tijdstempel: bevestigt dat de beoordeling actueel is en geen vertraagde kopie.
Cruciaal is dat het mobiele device zichzelf niet beoordeelt. De applicatieserver moet de digitale handtekening onafhankelijk verifiëren voordat het resultaat wordt vertrouwd. Door die scheiding van taken kan een gecompromitteerd device niet liegen over de eigen beveiligingsstatus tegenover het beheerportaal.
De technische workflow
Het beoordelingsproces draait om een beveiligde cyclus in meerdere stappen tussen de app, Google en de server van de ontwikkelaar.
- Nonce genereren: de server van de ontwikkelaar maakt een uniek token voor eenmalig gebruik (nonce) zodat aanvallers oude validatieantwoorden niet opnieuw kunnen gebruiken.
- API-aanvraag: de mobiele app vraagt een attestation aan en stuurt de nonce en een API-sleutel van de ontwikkelaar naar Google.
- Signalen verzamelen: de interne scanservice van Google (DroidGuard) controleert het device op root-toegang, emulatie en aangepaste bootloaders.
- Verificatie: de servers van Google toetsen de scangegevens aan bekende veilige profielen en sturen een digitaal ondertekend antwoord terug naar de app.
- Validatie aan serverzijde: de app stuurt het antwoord door naar de server van de ontwikkelaar, die bevestigt dat de handtekening en de nonce geldig zijn.
Dreigingen die SafetyNet beperkt
Organisaties gebruiken integriteitsverificatie van Android-devices om toegang vanaf gecompromitteerde endpoints te blokkeren. Zo beperken ze proactief hun blootstelling aan ernstige beveiligingsrisico’s.
Als betrouwbare poortwachter voor de beveiliging pakt attestation diverse kritieke kwetsbaarheden aan:
| Beveiligingsdreigingen | Hoe attestation het risico beperkt |
| Misbruik van gerootte devices | Detecteert ongeautoriseerde beheerderstoegang. Daarmee blijven de ingebouwde beschermingen van het besturingssysteem actief en kunnen aanvallers geen gevoelige appgegevens stelen. |
| Malware-injectie | Fungeert als betrouwbare SafetyNet-checker die niet-gecertificeerde firmware herkent. Zo kunnen externe dreigingen kernbestanden van het systeem niet ongemerkt wijzigen. |
| Frauduleuze transacties | Bevestigt dat de hardware authentiek en ongewijzigd is. Daarmee kunnen kwaadwillenden geen veilige omgeving simuleren om illegale betalingen goed te keuren. |
| Misbruik van referenties | Detecteert of een app op een software-emulator draait in plaats van op een fysieke telefoon en blokkeert zo geautomatiseerde opzetjes om wachtwoorden te verzamelen. |
| Manipulatie door bots | Herkent niet-menselijk gedrag om te voorkomen dat kwaadaardige scripts brute-force-aanvallen op logins uitvoeren of backendservers overbelasten. |
Door devices die zakken voor deze basiscontroles automatisch de toegang te weigeren, beschermen organisaties hun gegevens efficiënt en beperken ze het operationele risico aanzienlijk.
Beperkingen en veranderende standaarden van SafetyNet Attestation
SafetyNet Attestation is geleidelijk vervangen door nieuwere mechanismen voor integriteitsverificatie, met name de Google Play Integrity API.
Om omgevingen veilig te houden, moeten organisaties begrijpen hoe deze standaarden verschuiven.
Oude methoden zijn uitgefaseerd
De oorspronkelijke API, ooit de standaard SafetyNet-checker, wordt officieel uitgefaseerd. Die steunde op softwarescans die regelmatig werden omzeild en controleerde het device slechts op één moment in de tijd.
Nieuwere API’s leveren rijkere signalen
Moderne frameworks bieden veel meer dan een simpel geslaagd/mislukt-resultaat. Ze leveren zeer gedetailleerde validatiesignalen over de authenticiteit van applicaties, accountlicenties en de precieze staat van de hardware.
Devicecertificering verandert
De controles op devicecertificering gaan steeds verder dan basale monitoring van software. Moderne integriteitsverificatie van Android-devices vereist inmiddels hardwarematig ondersteunde beveiliging, waarbij vertrouwen wordt verankerd in geïsoleerde fysieke chips die bestand zijn tegen manipulatie.
Runtimebescherming aanpassen
Omdat aanvallers voortdurend nieuwe manieren vinden om beveiligingscontroles te vervalsen, moet runtimebescherming meebewegen met platformwijzigingen. Toekomstige Android-updates schrijven dynamische, externe beveiligingssleutels voor om deze oude achterdeurtjes definitief te sluiten.
Aansluiting houden bij de geactualiseerde Android-beveiligingsnormen is cruciaal voor continue bescherming en om verstorende serviceonderbrekingen te voorkomen.
Attestation opnemen in uw governancemodel
Organisaties moeten signalen over apparaatgezondheid doorgeven aan bredere beveiligingssystemen om regels af te dwingen op basis van verifieerbare gegevens. Device attestation werkt uiteindelijk het best in combinatie met identiteitscontroles van gebruikers en strikte applicatiebeheersing.
Met een betrouwbare health checker kunnen IT-teams deviceverificatie integreren in deze belangrijke gebieden:
| Integratiegebied | Praktische toepassing |
| Conditional access afdwingen | Blokkeert of beperkt automatisch de toegang tot bedrijfsnetwerken als een smartphone zakt voor de gezondheidscontrole. |
| Beveiligingsbeleid voor mobiele applicaties | Dwingt toegangsregels in niveaus af. Een risicovol device mag gegevens bijvoorbeeld wel inzien maar niet wijzigen. |
| Systemen voor fraudedetectie | Gebruikt de status van het device om te voorkomen dat aanvallers een veilige omgeving simuleren om illegale betalingen goed te keuren. |
| Dashboards voor device-compliance | Geeft IT-teams centraal inzicht in welke devices van medewerkers in realtime aan de beveiligingsnormen van het bedrijf voldoen. |
| Workflows voor incident response | Start automatisch beveiligingsnotificaties, wist bedrijfsgegevens of blokkeert gecompromitteerde devices zonder handmatig werk van IT. |
Mobiele omgevingen beveiligen met SafetyNet Attestation
SafetyNet Attestation verandert de mobiele beveiliging doordat de gezondheid van een device wordt geverifieerd voordat toegang tot gevoelige gegevens wordt verleend.
Als onderdeel van een strategie van gelaagde verdediging voorkomen deze cryptografisch ondertekende controles proactief fraude, blokkeren ze malware en beschermen ze uw organisatie tegen gecompromitteerde hardware.
Gerelateerde onderwerpen:
- Complete gids: integraties voor mobile threat defense (MTD)
- Zo werkt lifecycle management voor mobiele devices en waarom het ertoe doet
- Wat is beheer van mobiele apparaten? MDM uitgelegd
- Beheer van mobiele apparaten: 6 functies die uw MDM-oplossing nodig heeft
- Beheer van mobiele apparaten: remote actions met NinjaOne MDM
