- Implementering av et granulært synlighetssystem som erstatter den monolittiske sikkerhetsoppdateringen med en komponentbasert analyse.
- Mulighet til å revidere spesifikke sårbarheter gjennom integrasjon med OSV-databasen og CVE-sporing.
- Standardisering av kommunikasjon mellom produsenter og applikasjoner gjennom Security State Provider for å administrere OTA-oppdateringer.
Å holde en Android-smarttelefon sikker i disse dager er ærlig talt en skikkelig hodepine. Med tanke på hvor komplekst økosystemet har blitt, pleide utviklere å stole på en veldig generell måleenhet kalt Security Patch Level (SPL), som i utgangspunktet var som å prøve å avgjøre om et hus er sikkert bare ved å se på datoen for den siste større renoveringen, uten å ane om bakdørlåsen fortsatt er ødelagt.
For å håndtere dette informasjonsgapet har AndroidX Security State og Security State Provider -bibliotekene kommet . Disse verktøyene er banebrytende og tilbyr detaljert innsikt i hvert hjørne av systemet, slik at programvare blir virkelig motstandsdyktig mot angrep og lar apper ta intelligente beslutninger basert på reelle bevis, ikke bare antagelser, og dermed etablere en nulltillitsmodell.
Farvel til den enkle oppdateringen: granularitetens æra
Hovedproblemet med å stole på én enkelt SPL er at Android nå oppdateres stykkevis takket være Project Mainline og Google Play-systemoppdateringer. For å bringe orden i dette kaoset deler de nye bibliotekene sikkerheten inn i tre søyler: kjerneoperativsystemet ( oppdatert trådløst), systemmoduler (levert via Google Play) og Linux-kjernen , som er grunnlaget for alt og måles ved hjelp av LTS-versjoner i stedet for månedlige utgivelsesdatoer.
For hver av disse komponentene kan tre forskjellige tilstander konsulteres, noe som gir et komplett bilde av situasjonen:
- Enhetslydstyrke (DSPL): Den indikerer hva som er installert og kjører på enheten i det nøyaktige øyeblikket, uten behov for internettforbindelse.
- Publisert SPL (PSPL): Den representerer den nyeste versjonen som offisielt er publisert i Android-sikkerhetsbulletinen.
- Tilgjengelig lydtrykk (ASPL): Den avslører om det allerede er en oppdatering nedlastet eller klar til å installeres gjennom en IPC-mekanisme (interprosesskommunikasjon).
Sårbarhetskontroll og CVE-revisjon
En av kronjuvelene er integrasjonen med databasen for åpen kildekode-sårbarheter (OSV) . Det er ikke lenger noe gjetting involvert i å avgjøre om en bestemt måneds oppdatering fikser en spesifikk sårbarhet; nå er det mulig å spore spesifikke CVE-er programmatisk .
Dette er rent gull for fintech-, bank- eller helseapplikasjoner, ettersom de kan begrense verdifulle overføringer eller tilgang til sensitive data hvis de oppdager at en kritisk Bluetooth- eller NFC-sårbarhet fortsatt er aktiv på enheten. For eksempel kan feil som skriving utenfor grensene til libimagecodec.quram.so tillate eksterne angripere å kjøre vilkårlig kode, og dermed gjøre en utdatert enhet til en bakdør inn i bedriftsnettverk.
Implementación técnica y flujo de trabajo
For å få dette i gang, må utvikleren legge til avhengigheten androidx.security:security-state:1.1.0 i Gradle-filen din. Initialiseringen er enkel og krever en Android-kontekst, men hastigheten kan forbedres ved å sende en sårbarhetsrapport i JSON-format direkte til konstruktøren. Sikkerhetsoppdateringstilstand.
Arbeidsflyten er vanligvis delt inn i tre typer kontroller:
- Synkrone verifiseringer: De brukes til å inspisere DSPL-en når appen starter og sammenligne den med en obligatorisk basisdato.
- Asynkrone spørringer: gjennom
fetchAvailableSecurityPatchLevelAppen kan varsle brukeren om at det er en ventende oppdatering og omdirigere dem til innstillingene. - Dybdegående revisjoner: med
queryAllAvailableUpdatesDu kan analysere dataenes aktualitet og finne ut hvilken oppdateringsleverandør som svarer.
Det er viktig å merke seg at støtten varierer avhengig av systemversjonen. Selv om Android 11 og nyere tilbyr full støtte, har Android 10 ingen offisiell kjernestøtte, og i versjon 9 og tidligere, der Project Mainline-moduler ikke fantes, returnerer systemet Unix- datoen (1970-01-01) som standard.
Rollen til Security State Provider og nye funksjoner i Android 17
For at hele dette systemet skal fungere, må noen annonsere at oppdateringer er tilgjengelige. Det er her Security State Provider kommer inn i bildet, og standardiserer hvordan oppdateringsklienter rapporterer til ASPL. Tidligere var hver produsents OTA-informasjon låst i proprietære siloer; nå kan enhver autorisert app få tilgang til dataene uavhengig av telefonmerke.
Videre introduserte Android 17 en kraftig forbedring for produsenter (OEM-er) gjennom en XML-fil for tilleggsoppdateringer . Dette lar dem deklarere sine egne implementerte sikkerhetsrettinger uten å vente på den globale SPL-utgivelsen, noe som sikrer at pågående oppdateringsarbeid gjenkjennes umiddelbart og at enheten ikke virker sårbar selv etter at den er sikret.
Andre verktøy i AndroidX Security-økosystemet
Utover systemtilstanden finnes det andre viktige komponenter. Sikkerhets- og krypteringsbiblioteket er viktig for å administrere nøkler og kryptere filer eller SharedPreferences. Selv om noen versjoner av JetSec nå er foreldet, er det best å ikke overbruke lagring av sensitive data, ettersom Androids sandkassemodell og filbaserte kryptering allerede er svært robuste.
Det er også verdt å merke seg security-app-authenticator , som forenkler verifiseringen av et programs pålitelighet basert på dets signeringsidentitet. Ved å bruke XML med pakkenavn og identiteter sikrer biblioteket at bare legitime applikasjoner kan samhandle med kritiske systemkomponenter.
Overgangen til detaljert inspeksjon på komponentnivå, muligheten til å revidere CVE-er via OSV og standardiseringen av OTA-oppdateringer gjør AndroidX Security State til gullstandarden for forbedret mobilsikkerhet. Ved å integrere disse verktøyene blir kritiske arbeidsflyter robuste, og sluttbrukere er alltid beskyttet mot de nyeste truslene i det digitale landskapet.