På Google I/O lærte vi om forbedringene som Android Q bringer. Nye sikkerhets- og personvernfunksjoner og forbedringer finnes over hele det nye Android OS.
Hver nye versjon av Android OS gir forbedringer til nesten alle aspekter fra design, funksjoner, APIer og mer. På Google I/O tidligere denne måneden lærte vi om alle forbedringer som Android Q kommer til å bringe, og selvfølgelig ble nye personvern- og sikkerhetskunngjøringer ikke utelatt fra konferansen. Plattformsikkerheten er en av de viktigste aspektene ved et OS, spesielt for et OS som vi har med oss overalt i lommen. Hvis Android ikke var sikker, ville vi ikke stole på den med halvparten så mange funksjoner som vi gjør. NFC-betalinger ville være utelukket, fildeling ville i beste fall være tvilsomt, og å koble til andre enheter ville være direkte galskap. Til tross for det langvarige problemet med versjonsfragmentering, har Google gjort svært godt for å holde antallet sikkerhetsproblemer på et minimum.
Android har modnet til et OS som er både funksjonsrikt og svært sikkert. Men det er selvfølgelig alltid rom for forbedring. Det er mange medvirkende faktorer til denne sikkerheten, og noen av dem blir forbedret på en eller annen måte med Android Q.
Kryptering
Siden det er en av de mest grunnleggende sikkerhetsmetodene, er det viktig at hver enhet støtter sterk kryptering. Mange OEM-er sender i disse dager enhetene sine med dedikert krypteringsmaskinvare. Selv om dette er gunstig, er det også dyrt. Som sådan har dedikert maskinvare vanligvis vært begrenset for enheter i middels til høyt nivå. Dette er ikke å si at low-end enheter kan ikke støtter kryptering, men uten maskinvareakselerert kryptering blir den generelle brukeropplevelsen forringet på grunn av trege lese-/skrivetider. Det er her Adiantum kommer inn.
Adiantum
I februar annonserte Google Adiantum som et alternativ krypteringsalgoritme for lavere-end telefoner som ikke støtter vanlige AES-instruksjonssett. Adiantum er spesielt designet for å kjøre uten noen dedikert maskinvare. Det fungerer som et lettere alternativ til Androids vanlige AES-kryptering. Googles benchmarks fortell oss at den faktisk er 5 ganger raskere enn AES, med ulempen at den går litt på akkord med sikkerheten. Dette gjør den til den ideelle kandidaten for lavere-end-telefoner, for eksempel de som drives av Android Go Edition. Adiantum er også for produkter som smartklokker og en rekke Internet of Things-enheter.
Frem til nå var Adiantum valgfritt; produsenter kunne aktivere det på enheter som lanseres med Android Pie, men det var ikke standard krypteringsalgoritme. Nå er Adiantum inkludert som en del av Android Q. Dette betyr at alle enheter som starter med Q vil bli pålagt å kryptere brukerdata, uten unntak. Som et resultat er enheter som lanseres med Android Q garantert å ha lagringskryptering, enten det er via Adiantum eller ikke.
Jetpack sikkerhetsbibliotek
Jetpack er et sett med Android-støttebiblioteker, og et av de nyeste tilskuddene er i alfa: Jetpack Security Library. Biblioteket forenkler prosessen med å sikre applikasjonen din ved å håndtere ting som administrasjon av maskinvarestøttede nøkkellagre og generere og validere nøkler.
TLS 1.3
Lagring er imidlertid ikke det eneste området kryptering har blitt forbedret i. Kommunikasjon med andre enheter har blitt mye forbedret, med introduksjonen av TLS 1.3-støtte som standard. TLS 1.3 er den siste nettverkskrypteringsstandarden, ferdigstilt av IETF i august 2018. TLS 1.3 gir mer personvern for datautveksling ved å kryptere flere av forhandlingshåndtrykkene. På toppen av dette er det raskere enn TLS 1.2 på grunn av at en hel rundtur blir barbert av fra tilkoblingsetableringens håndtrykk. Sammen med mer effektive moderne algoritmer gir dette en hastighetsøkning på opptil 40 %.
TLS kan nå oppdateres direkte fra Google Play fordi det er en del av "Conscrypt"-komponenten. Du kan lese mer om det og Project Mainline her.
Gitt at vi stoler på så mange sensitive transaksjoner på enhetene våre daglig, er den oppgraderte TLS viktigere enn noen gang. Oppbevaring av slike som boardingkort - og til og med digitale førerkort på et tidspunkt i fremtiden – på Android betyr at alle enheter bør kryptere brukerdata så godt de kan. Adiantum og tvungen kryptering vil bane vei for at selv de mest sensitive data kan lagres på de billigste enhetene. Men kryptering er ikke den eneste måten Google øker sikkerheten til Android i Q-utgivelsen.
Tillatelser og personvernendringer i Android Q
Omfanget lagring
Scoped Storage er en ny beskyttelse som brukes for å begrense apper fra å lese/skrive filer i ekstern lagring som ikke er inneholdt i deres egen appspesifikke katalog med sandkasse. Googles mål er tredelt: bedre tilordning av hvilke apper som har kontroll over hvilke filer, beskyttelse av appdata og beskyttelse av brukerdata.
Google dobler ned på MediaStore API for delt lyd-, video- og bildeinnhold. Som standard kan alle apper sette inn, endre eller slette sine egne filer i MediaStore. Bilder, MediaStore. Video og MediaStore. Lydsamlinger uten å trenge noen tillatelser. Android Q legger også til en ny MediaStore. Nedlastinger samling for å lagre brukernedlastet innhold, som alle apper som bruker MediaStore API kan bidra til. Mens filer som er lagret i appspesifikke kataloger med sandkasse slettes ved avinstallering, vedvarer alle filer som er bidratt til MediaStore-samlingene utover avinstallering.
For å få tilgang til filer som er opprettet av en annen app – enten filen er i en av MediaStore-samlingene eller utenfor dem – må appen bruke Storage Access Framework. Videre blir EXIF-metadata for bilder redigert med mindre appen din har den nye ACCESS_MEDIA_LOCATION-tillatelsen gitt. I Android Q kan apper også kontrollere hvilken lagringsenhet media skal landes på ved å spørre volumnavnet ved hjelp av getExternalVolume().
Google innførte i utgangspunktet Scoped Storage-begrensninger for alle apper i Android Q uavhengig av mål-API-nivåer, men etter tilbakemelding er selskapet gi utviklere mer tid å gjøre justeringer. Du finner alle detaljer om endringene i omfanget av lagring på denne siden, og du kan finne ut mer om Googles anbefalinger om beste fremgangsmåter for delt lagring av ser på denne Google I/O snakke.
Advarsler for apper som målretter mot API-nivå < 23
Tillatelsesbegrensninger slutter imidlertid ikke der. Installering av en app som retter seg mot et API-nivå lavere enn 23 (Android Lollipop eller eldre) vil føre til at operativsystemet viser en advarsel til brukeren hvis appen ber om sensitive tillatelser ved installasjon. Før installasjonen vil brukerne ha mulighet til manuelt å spesifisere hvilke tillatelser de vil gi appen før de fortsetter. Dermed tillater ikke Android Q lenger apper å omgå kjøretidstillatelser.
Eventuell SYSTEM_ALERT_DEPRECATION til fordel for Bubbles API
Bubbles API i aksjon. Kilde: Google.
Overleggstillatelsen (SYSTEM_ALERT_WINDOW) kan ikke lenger gis for apper som kjører på Android Q (Go Edition). For enheter som ikke er i Go Edition, presser Google utviklere mot det nye Bubbles API. Bubbles API er en funksjon introdusert i Android Q Beta 2 som gir mulighet for funksjonalitet som er som Facebook Messengers chat-hoder. Varsler fra apper vises som små bobler i kantene av skjermen, som utvides når brukeren trykker på dem. Innenfor boblen kan en app vise en aktivitet.
Denne endringen var nødvendig fordi det å la apper fritt tegne overlegg over andre apper utgjør åpenbare sikkerhetsrisikoer. Den beryktede"Kappe og dolk"Exploit brukte denne svakheten mye. Funksjonaliteten til overleggs-API-en har blitt begrenset så tidlig som i Android Oreo, men nå har Go-utgaven av Android Q fullstendig fjernet tilgangen til API-en med en fremtidig utgivelse for å avskrive den fullstendig.
Bakgrunnsaktivitetsstartrestriksjoner
Apper i bakgrunnen kan ikke lenger starte en aktivitet automatisk mens telefonen er ulåst, uavhengig av mål-API-nivået. Det er en hel liste over forhold som apper nå kan starte aktiviteter under, som du kan lese her. Bakgrunnsapper som ikke oppfyller disse betingelsene og ønsker å starte en aktivitet raskt, må nå fortelle brukeren det via et varsel. Hvis varselet opprettes med en ventende fullskjerm-intensjon, startes intensjonen umiddelbart hvis skjermen er av – nyttig for alarmer eller innkommende anrop.
Bakgrunnsutklippstavle tilgangsbegrensning
Bakgrunnsutklippstavle tilgang er ikke lenger mulig. Ethvert program som ikke er i forgrunnen eller er satt som standard inndatametode, vil ikke kunne lese utklippstavlen på noen måte. Dette rammer apper som utklippstavleadministratorer spesielt hardt. Google sier at denne endringen bare påvirker apper som utelukkende er rettet mot Android Q, men testene våre indikerer at begrensningen ikke diskriminerer; noen apper vi prøvde kunne ikke se utklippstavlen.
Denne endringen gir selvfølgelig mening. Vi kopierer ofte sensitiv informasjon til utklippstavlen – ting som passord og kredittkortdetaljer – men det er fortsatt synd å se utklippstavleledere gå i vasken.
Posisjonstilgang kun mens en app er i bruk
En ny brukeraktivert innstilling lar apper bare nå posisjonen din mens appen er i bruk. Den siste Android Q-betaen har også lagt til et varsel som minner deg på om du har gitt en app permanent tilgang til stedet.
Roller
En ny "Roles" API er lagt til. Roller er i hovedsak grupper med forhåndsinnstilte tillatelser tilgang. For eksempel kan apper med gallerirollen ha tilgang til mediemappene dine, mens apper med oppringerrollen kan håndtere anrop. Apper som får en viss rolle av brukeren, må også ha de nødvendige komponentene. Apper med gallerirollen må for eksempel ha handlingsintensjonsfilteret android.hensikt.handling.HOVED og kategoriens hensiktsfilter android.intent.category. APP_GALLERI for å vises som en galleriapp i innstillingene.
Sensorer av Hurtiginnstillinger-flisen
Det er en ny "Sensorer av" hurtiginnstillingsflis som slår av avlesninger fra alle sensorer (akselerometer, gyroskop, etc.) på enheten for ekte personvern. Denne hurtiginnstillinger-flisen er skjult som standard, men kan aktiveres ved å gå til "hurtiginnstillinger-utviklerflisene" i utvikleralternativer.
Begrensninger til /proc/net
Apper kan ikke lenger tilgang proc/net, noe som gjør tjenester som netstat ikke lenger levedyktige. Dette beskytter brukere mot ondsinnede apper som overvåker hvilke nettsteder og tjenester de kobler til. Apper som trenger fortsatt tilgang, for eksempel VPN-er, må bruke NetworkStatsManager og ConnectivityManager klasser.
Randomiserte MAC-adresser
MAC-adressen din er en unik identifikator som nettverk bruker for å huske hvilken enhet som er hvilken. I Android Q vil enheten din bruke en ny, tilfeldig MAC-adresse hver gang du kobler til et nytt nettverk. Som et resultat, nettverk kan ikke spore posisjonen din ved å matche hvilke WiFi-nettverk du kobler til med MAC-adressen til telefonen din. Enhetens faktiske MAC-adresse fra fabrikken kan fortsatt fås av apper via getWifiMacAddress() kommando.
Plattformherding i Android Q
En enkelt feil i Android betyr ikke at angripere nå har full tilgang til operativsystemet eller at de kan omgå eventuelle sikkerhetssystemer. Dette skyldes delvis en rekke sikkerhetstiltak som prosessisolering, reduksjon av angrepsoverflate, arkitektonisk dekomponering og utnyttelsesreduksjoner. Disse sikkerhetstiltakene gjør sårbarheter vanskeligere eller til og med umulige å utnytte. Som et resultat trenger angripere vanligvis en rekke sårbarheter før de kan nå målene sine. Tidligere har vi sett angrep slik som DRAMMER som fungerer ved å lenke flere utnyttelser sammen.
Android Q tar sikkerhetstiltak som disse og bruker dem på mer sensitive områder som media og Bluetooth-komponenter sammen med kjernen også. Dette gir noen markante forbedringer.
- En begrenset sandkasse for programvarekodeker.
- Økt produksjonsbruk av rensemidler for å redusere hele klasser av sårbarheter i komponenter som behandler ikke-pålitelig innhold.
- Shadow Call Stack, som gir backward-edge Control Flow Integrity (CFI) og komplementerer foroverkantbeskyttelsen som tilbys av LLVMs CFI.
- Beskyttelse av randomisering av adresseromsoppsett (ASLR) mot lekkasjer ved hjelp av eXecute-Only Memory (XOM).
- Introduksjon av Scudo-herdet allokator som gjør en rekke heap-relaterte sårbarheter vanskeligere å utnytte.
Dette er mye programvaresjargong. Beinene med det er at for det første kjører programvarekodeker nå i sandkasser som har færre privilegier, noe som betyr at det er mindre sannsynlig at skadelig programvare vil kunne kjøre kommandoer som kan skade enheten din, for eksempel i etuiet av Sceneskrekk helt tilbake i 2015.
For det andre sjekker Android nå for arraytilgang utenfor grensene flere steder, samt overløp. Å forhindre overløp og instruere prosesser til å mislykkes på en sikker måte, reduserer prosentandelen av sårbarheter i brukerområdet betydelig. Hva dette betyr er at hvis et ondsinnet program prøver å få noe til å krasje ved bevisst forsøk på det få tilgang til data som ikke finnes, vil Android nå gjenkjenne dette og avslutte programmet, i stedet for krasje.
For det tredje beskytter Shadow Call Stack returadresser ved å lagre dem i en separat skyggestabel, noe som gjør dem utilgjengelige for vanlige programmer. Returadresser er vanligvis pekepinner til funksjoner, så det er viktig å beskytte disse adressene for å sikre at angripere ikke får tilgang til funksjoner de ikke burde kunne.
For det fjerde er ASLR en beskyttelsesmetode som randomiserer hvor programmer er lagret i minnet, noe som gjør det vanskeligere å finne ut hvor programmer lagres i minnet basert på plasseringen til andre programmer. Kun eXecute-minne styrker dette ved å gjøre koden uleselig.
Til slutt er Scudo en dynamisk heap-allokator som proaktivt administrerer minne på en måte som gjør heap-baserte sårbarheter mye vanskeligere å utnytte. Du kan lese mer om det her.
Autentisering
Oppdateringer til BiometricPrompt i Android Q
Google introduserte den nye BiometricPrompt API for over et år siden, i Android P Developer Preview 2. Det var ment å være en generisk Android-forespørsel for biometriske opplåsingsmetoder. Tanken er at enheter som støtter mer enn bare fingeravtrykkskanning, f.eks. irisskanning på Samsungs Galaxy S-linje, vil kunne bruke disse metodene når apper ber om bekreftelse.
Android Q legger til robust støtte for ansikts- og fingeravtrykkverifisering, samt utvider API-en for å støtte implisitt autentisering. Eksplisitt autentisering krever at brukeren autentiserer på en eller annen måte før han fortsetter, mens implisitt ikke trenger mer brukerinteraksjon.
På toppen av det kan apper nå sjekke om en enhet støtter biometrisk autentisering via en enkel funksjonsanrop, slik at de ikke kan kaste bort tid på å påkalle en BiometricPrompt på enheter som ikke støtte det. En ideell bruk for dette ville være hvis apper vil gi en "Aktiver biometrisk pålogging"-innstilling basert på om en enhet støtter biometrisk autentisering eller ikke.
Byggesteinene for elektronisk ID-støtte
Tidligere i år oppdaget vi bevis på at Google er det jobber med støtte for elektroniske IDer i Android. På I/O oppdaterte Google oss om fremdriften til funksjonen. Google sier at de jobber med ISO for å standardisere implementeringen av mobile førerkort, med elektroniske pass i arbeid. For utviklere vil Google tilby et Jetpack-bibliotek slik at identitetsapper kan begynne å lages.
Project Mainline i Android Q
Project Mainline er en stor oppgave fra Google for å redusere fragmenteringen av visse systemmoduler og apper. Google vil kontrollere oppdateringer for rundt 12 systemkomponenter via Play Store. Vi har snakket om Project Mainline i dybden i en tidligere artikkel hvis du er interessert i å lese mer.
Konklusjon
Sikkerhet har alltid vært en kjernedel av Androids utvikling. Google har gjort en imponerende jobb med å holde Android oppdatert med de nyeste sikkerhetsfunksjonene, i tillegg til å lage noen egne innovasjoner. De fortsetter denne utviklingsprosessen med Android Q, og pakker den full av sikkerhetsfunksjoner som er laget for å sikre at dataene dine er tryggere enn noen gang før.
Kilde 1: Hva er nytt i Android Q Security [Google]
Kilde 2: Sikkerhet på Android: Hva er neste [Google]
Kilde 3: Queue the Hardening Enhancements [Google]
Med innspill fra Mishaal Rahman og Adam Conway.