- Implementatie van een gedetailleerd zichtbaarheidssysteem dat de monolithische beveiligingspatch vervangt door een componentgebaseerde analyse.
- Mogelijkheid om specifieke kwetsbaarheden te controleren door integratie met de OSV-database en CVE-registratie.
- Standaardisatie van de communicatie tussen fabrikanten en applicaties via de Security State Provider voor het beheer van OTA-updates.
Het beveiligen van een Android-smartphone is tegenwoordig eerlijk gezegd een behoorlijke uitdaging. Door de complexiteit van het ecosysteem vertrouwden ontwikkelaars vroeger op een zeer algemene maatstaf, het Security Patch Level (SPL). Dat was in feite alsof je probeerde te bepalen of een huis veilig was door alleen te kijken naar de datum van de laatste grote renovatie, zonder te weten of het slot van de achterdeur nog steeds kapot is.
Om deze informatiekloof te dichten, zijn de AndroidX Security State- en Security State Provider -bibliotheken beschikbaar . Deze tools zijn baanbrekend en bieden gedetailleerd inzicht in elk aspect van het systeem, waardoor software echt bestand is tegen aanvallen en apps intelligente beslissingen kunnen nemen op basis van concrete gegevens in plaats van louter aannames. Zo wordt een zero-trust- model gecreëerd.
Vaarwel aan de enkele patch: het tijdperk van granulariteit.
Het grootste probleem met het vertrouwen op één enkele SPL is dat Android nu stapsgewijs wordt bijgewerkt dankzij Project Mainline en systeemupdates van Google Play. Om orde in deze chaos te scheppen, splitsen de nieuwe bibliotheken de beveiliging op in drie pijlers: het kernbesturingssysteem (dat draadloos wordt bijgewerkt), systeemmodules (geleverd via Google Play) en de Linux-kernel , die de basis vormt van alles en wordt gemeten aan de hand van LTS-versies in plaats van maandelijkse releasedatums.
Voor elk van deze componenten kunnen drie verschillende staten worden geraadpleegd, wat een volledig beeld van de situatie geeft:
- Apparaat SPL (DSPL): Het geeft aan wat er op dat precieze moment op het apparaat is geïnstalleerd en draait, zonder dat een internetverbinding nodig is.
- Gepubliceerde SPL (PSPL): Dit is de meest recente versie die officieel is gepubliceerd in het Android-beveiligingsbulletin.
- Beschikbare SPL (ASPL): Het geeft aan of er al een update is gedownload of klaar is om te worden geïnstalleerd via een interprocescommunicatiemechanisme (IPC).
Controle op kwetsbaarheden en audits van CVE's
Een van de pronkstukken is de integratie met de Open Source Vulnerabilities (OSV) -database . Het is niet langer nodig om te gissen of een patch van een bepaalde maand een specifieke kwetsbaarheid verhelpt; het is nu mogelijk om specifieke CVE's programmatisch te volgen.
Dit is goud waard voor fintech-, bank- of zorgapplicaties, omdat ze transacties met hoge waarde of de toegang tot gevoelige gegevens kunnen beperken als ze detecteren dat een kritieke Bluetooth- of NFC-kwetsbaarheid nog steeds actief is op het apparaat. Kwetsbaarheden zoals het schrijven buiten de toegestane geheugenlimieten naar libimagecodec.quram.so zouden bijvoorbeeld externe aanvallers in staat kunnen stellen willekeurige code uit te voeren, waardoor een verouderd apparaat een achterdeur wordt naar bedrijfsnetwerken.
Implementatie van technologie en vloeiende trabajo
Om dit werkend te krijgen, moet de ontwikkelaar de afhankelijkheid toevoegen. androidx.security:security-state:1.1.0 in je Gradle-bestand. De initialisatie is eenvoudig en vereist een Android-context, hoewel de snelheid kan worden verbeterd door een kwetsbaarheidsrapport in JSON-formaat rechtstreeks aan de constructor door te geven. Beveiligingspatchstatus.
De workflow is over het algemeen onderverdeeld in drie soorten controles:
- Synchrone verificaties: Ze worden gebruikt om de DSPL te controleren wanneer de app start en deze te vergelijken met een verplichte basisdatum.
- Asynchrone query's: Door
fetchAvailableSecurityPatchLevelDe app kan de gebruiker laten weten dat er een update beschikbaar is en hem of haar doorverwijzen naar de instellingen. - Grondige audits: met
queryAllAvailableUpdatesJe kunt de actualiteit van de gegevens analyseren en achterhalen welke updateprovider reageert.
Het is belangrijk om te weten dat de ondersteuning verschilt per systeemversie. Android 11 en latere versies bieden volledige ondersteuning, maar Android 10 heeft geen officiële kernelondersteuning. In versies 9 en ouder, waar Project Mainline-modules nog niet bestonden, geeft het systeem standaard de Unix-datum (1970-01-01) weer.
De rol van de Security State Provider en nieuwe functies in Android 17
Om dit hele systeem te laten werken, moet iemand aankondigen dat er updates beschikbaar zijn. Hier komt de Security State Provider (ASPL) in beeld , die de manier standaardiseert waarop updateclients rapporteren aan de ASPL. Voorheen was de OTA-informatie van elke fabrikant opgesloten in eigen systemen; nu heeft elke geautoriseerde app toegang tot de gegevens, ongeacht het merk van de telefoon.
Bovendien introduceerde Android 17 een krachtige verbetering voor fabrikanten (OEM's) via een Supplemental Patches XML- bestand . Hiermee kunnen ze hun eigen geïmplementeerde beveiligingspatches aangeven zonder te hoeven wachten op de wereldwijde SPL-release. Dit zorgt ervoor dat lopende patch-inspanningen direct worden herkend en dat het apparaat niet kwetsbaar lijkt, zelfs niet nadat het is beveiligd.
Andere tools in het AndroidX Security-ecosysteem
Naast de systeemstatus zijn er nog andere belangrijke componenten. De security-crypto- bibliotheek is essentieel voor het beheren van sleutels en het versleutelen van bestanden of SharedPreferences. Hoewel sommige versies van JetSec inmiddels verouderd zijn, is het raadzaam om gevoelige gegevens niet te vaak op te slaan, aangezien het sandbox-model van Android en bestandsgebaseerde versleuteling al zeer robuust zijn.
Ook noemenswaardig is security-app-authenticator , dat het verifiëren van de betrouwbaarheid van een applicatie vereenvoudigt op basis van de ondertekeningsidentiteit. Door gebruik te maken van XML met pakketnamen en identiteiten, zorgt de bibliotheek ervoor dat alleen legitieme applicaties kunnen communiceren met kritieke systeemcomponenten.
De overgang naar gedetailleerde inspectie op componentniveau, de mogelijkheid om CVE's te controleren via OSV en de standaardisatie van OTA-updates maken AndroidX Security State de gouden standaard voor verbeterde mobiele beveiliging. Door deze tools te integreren, worden kritieke workflows robuuster en zijn eindgebruikers altijd beschermd tegen de nieuwste bedreigingen in het digitale landschap.