Hvorfor enkelte bankapper på Android bare fungerer med offisielle Google Play-tjenester

Hvorfor bankapper på Android ofte bare fungerer med offisielle Google Play-tjenester

Bankapper og andre sikkerhetskritiske applikasjoner implementerer omfattende integritets- og sikkerhetskontroller for å oppdage manipulerte systemer, root-tilgang eller ikke-sertifiserte Android-installasjoner.<ref name="android-security"/> Målet med disse kontrollene er å redusere risikoen for uautorisert tilgang, datamanipulering eller falske transaksjoner. Teknisk sett er mange av disse mekanismene basert på proprietære sikkerhets- og sertifiseringstjenester fra Google, som kun støttes fullt ut på sertifiserte Android-systemer med originale Google Play Services (GMS).

Avhengighet av Google Play Services (GMS)

Mange Android-apper bruker API-er fra Google Play Services, blant annet for push-varsler (Firebase Cloud Messaging), posisjonstjenester, lisenskontroller eller integritetsbevis via Play Integrity API.<ref name="gms-apis"/> Disse tjenestene er proprietære og ikke en del av Android Open Source Project (AOSP).

microG er en åpen kildekode-reimplementering av utvalgte GMS-grensesnitt. Den tar sikte på funksjonell kompatibilitet, men kan ikke gjenskape alle API-er fullstendig eller identisk.<ref name="microg-docs"/> Apper kan blant annet sjekke:

• Om pakken com.google.android.gms er til stede og signert med den originale Google-signaturen. microG bruker såkalt Signature Spoofing, som kan gjenkjennes eksplisitt av apper.<ref name="microg-spoofing"/>
• Om kjøretidsatferden til bestemte API-er (f.eks. feilkoder, timing, interne klasser) samsvarer nøyaktig med den originale Google Play Services.

Avvik fra forventet atferd blir ofte vurdert som integritetsbrudd av sikkerhetskritiske apper.

Enhetsintegritetskontroller: Play Integrity API

En sentral del av moderne app-sikkerhetskontroller er «Play Integrity API». Den erstatter den tidligere SafetyNet Attestation API, hvis bruk har vært begrenset eller avviklet siden 2024/2025.<ref name="play-integrity-overview"/>

Appen sender en forespørsel til Googles server, som returnerer en kryptografisk signert integritetsvurdering (Integrity Verdict).<ref name="play-integrity-details"/>

Denne kan blant annet inneholde følgende statuser:

• MEETS_BASIC_INTEGRITY: Programvarebasert kontroll av kjente manipulasjoner.
• MEETS_DEVICE_INTEGRITY: Utvidet kontroll av systemintegritet og enhetskonfigurasjon.
• MEETS_STRONG_INTEGRITY: Maskinvarebasert attestering ved bruk av Trusted Execution Environment (TEE) eller StrongBox, hvor det kontrolleres om

• enheten er Play-Protect-sertifisert,
• bootloaderen er låst,
• den verifiserte oppstartskjeden er intakt og
• operativsystemet er signert med nøkler godkjent av produsenten.<ref name="hardware-attestation"/>

På tilpassede ROM-er (f.eks. LineageOS) uten offisiell sertifisering gjelder vanligvis følgende:

• En ulåst bootloader forhindrer bestått hardwarebasert attestering.<ref name="verified-boot"/>
• Systemavbilder som ikke er signert av produsenten, oppfyller ikke kravene til Strong Integrity.
• microG kan ikke generere maskinvarebaserte attesteringer, da disse valideres direkte av Secure Hardware og Googles server.<ref name="strongbox"/>

Mange bankapper krever minst DEVICE_INTEGRITY, noen ganger eksplisitt STRONG_INTEGRITY. Hvis kravene ikke oppfylles, startes ikke appen, eller tilgangen blir begrenset.

Andre kontrollmekanismer som brukes av apper

I tillegg til Play Integrity API brukes ofte tilleggskontroller:

• Bootloader-status: Spørring om systemparametere som ro.boot.verifiedbootstate eller ro.boot.flash.locked.<ref name="bootloader"/>
• Build-egenskaper: Analyse av build-tags (release-keys vs. test-keys) og build-fingeravtrykk.<ref name="build-props"/>
• Play Protect-sertifisering: Sammenligning av enheten med Googles sertifiseringsdatabase.<ref name="play-protect"/>
• Widevine DRM: Bruk av DRM-nivå L1, som kun er tilgjengelig på sertifiserte enheter med intakt TEE.<ref name="widevine"/>
• App-spesifikke sikkerhetskontroller: Kombinasjon av root-gjenkjenning, kode-obfuskering og server-side vurdering av leverandøren.

Klassifisering av microG i sammenheng med sikkerhetskritiske apper

Custom-ROM-er med microG kan være teknisk oppdaterte og sikkert konfigurert. Likevel støttes de ikke av mange bankapper:

• Sikkerhetsmodellene er primært basert på formell sertifisering og ikke på individuell systemvurdering.<ref name="trust-chain"/>
• Finansinstitusjoner orienterer seg etter regulatoriske krav og ansvars spørsmål, hvor sertifiserte plattformer foretrekkes.<ref name="bank-compliance"/>
• Omgåelsesløsninger (f.eks. ved hjelp av root-rammeverk eller moduler) er gjenstand for regelmessige mottiltak fra Google og app-leverandører.
• Utviklingen går i retning av obligatorisk maskinvarebasert sertifisering, noe som gjør at programvarebaserte reimplementeringer blir stadig mindre viktige.<ref name="future-integrity"/>

Oppsummert er mange bankapper utformet slik at de kun kan brukes på Google-sertifiserte Android-enheter med originale Google Play-tjenester. microG gjør det mulig å bruke en rekke applikasjoner uten Google-tjenester, men støter på tekniske og konseptuelle begrensninger når det gjelder apper med høye sikkerhetskrav.

Kilder

https://developer.android.com/guide/ https://microg.org/docs https://github.com/microg/ https://source.android.com/docs/security/ https://www.widevine.com/ https://www.eba.europa.eu/regulation-and-policy/