Android Q: Alle de nye sikkerheds- og privatlivsfunktioner, der kommer til Android 10

Hos Google I/O lærte vi om de forbedringer, som Android Q bringer. Nye sikkerheds- og privatlivsfunktioner og forbedringer findes overalt i det nye Android OS.

Hver ny version af Android OS bringer forbedringer til næsten alle aspekter fra design, funktioner, API'er og mere. På Google I/O tidligere på måneden lærte vi om alle de forbedringer, som Android Q kommer til at bringe, og selvfølgelig blev nye fortroligheds- og sikkerhedsmeddelelser ikke udeladt fra konferencen. Platformsikkerheden er et af de vigtigste aspekter af et OS, især for et OS, som vi har med os overalt i lommen. Hvis Android ikke var sikker, ville vi ikke stole på den med halvt så mange funktioner som vi gør. NFC-betalinger ville være udelukket, fildeling ville i bedste fald være tvivlsom, og at oprette forbindelse til andre enheder ville være direkte vanvid. På trods af det langvarige problem med versionsfragmentering har Google gjort det ekstremt godt for at holde antallet af sikkerhedsproblemer på et minimum.

Android er modnet til et OS, der er både funktionsrigt og meget sikkert. Men der er selvfølgelig altid plads til forbedringer. Der er mange medvirkende faktorer til denne sikkerhed, og nogle få af dem bliver forbedret på en eller anden måde med Android Q.


Kryptering

Da det er en af ​​de mest grundlæggende sikkerhedsmetoder, er det vigtigt, at hver enhed understøtter stærk kryptering. Mange OEM'er sender i disse dage deres enheder med dedikeret krypteringshardware. Selvom dette er fordelagtigt, er det også dyrt. Som sådan er dedikeret hardware typisk blevet begrænset til enheder på mellem- til højniveau. Dette er ikke at sige, at low-end enheder kan ikke understøtter kryptering, men uden hardwareaccelereret kryptering er den overordnede brugeroplevelse forringet på grund af langsomme læse-/skrivetider. Det er her, Adiantum kommer ind.

Adiantum

I februar annoncerede Google Adiantum som et alternativ krypteringsalgoritme til lavere-end telefoner der ikke understøtter almindelige AES-instruktionssæt. Adiantum er specielt designet til at køre uden nogen dedikeret hardware. Det fungerer som et lettere alternativ til Androids almindelige AES-kryptering. Googles benchmarks fortæl os, at det faktisk er 5 gange hurtigere end AES, med ulempen er, at det går lidt på kompromis med sikkerheden. Dette gør den til den ideelle kandidat til lavere-end telefoner, såsom dem, der drives af Android Go Edition. Adiantum er også til produkter som smartwatches og en række Internet of Things-enheder.

Indtil nu var Adiantum valgfrit; producenter kunne aktivere det på enheder, der starter med Android Pie, men det var ikke standardkrypteringsalgoritmen. Nu er Adiantum inkluderet som en del af Android Q. Dette betyder, at alle enheder, der starter med Q, skal kryptere brugerdata uden undtagelser. Som et resultat er enheder, der lanceres med Android Q, garanteret at have lagerkryptering, hvad enten det er via Adiantum eller ej.

Jetpack sikkerhedsbibliotek

Jetpack er et sæt Android-understøttelsesbiblioteker, og en af ​​de nyeste tilføjelser er i alfa: Jetpack Security Library. Biblioteket forenkler processen med at sikre din applikation ved at håndtere ting som administration af hardware-understøttede nøglelagre og generering og validering af nøgler.

TLS 1.3

Opbevaring er dog ikke det eneste område, hvor kryptering er blevet forbedret. Kommunikation med andre enheder er blevet meget forbedret med introduktionen af TLS 1.3 understøttelse som standard. TLS 1.3 er den seneste netværkskryptografiske standard, færdiggjort af IETF i august 2018. TLS 1.3 giver mere privatliv til dataudvekslinger ved at kryptere flere af forhandlingshåndtryk. Oven i dette er det hurtigere end TLS 1.2 på grund af en hel rundtur, der er barberet af fra forbindelsesetableringens håndtryk. Sammen med mere effektive moderne algoritmer giver dette en hastighedsforøgelse på op til 40 %.

TLS 1.3 i Google Chrome. Kilde: Google.

TLS kan nu opdateres direkte fra Google Play, fordi det er en del af "Conscrypt"-komponenten. Du kan læse mere om det og Project Mainline her.

Da vi stoler på så mange følsomme transaktioner på vores enheder dagligt, er den opgraderede TLS vigtigere end nogensinde. Opbevaring af boardingkort - og endda digitale kørekort på et tidspunkt i fremtiden – på Android betyder, at alle enheder skal kryptere brugerdata så godt de overhovedet kan. Adiantum og tvungen kryptering vil bane vejen for, at selv de mest følsomme data kan lagres på de billigste enheder. Men kryptering er ikke den eneste måde, hvorpå Google øger sikkerheden for Android i Q-udgivelsen.


Tilladelser og ændringer i privatlivets fred i Android Q

Omfanget opbevaring

Scoped Storage er en ny beskyttelse, der bruges til at begrænse apps fra at læse/skrive filer i eksternt lager, som ikke er indeholdt i deres egen sandboxed app-specifikke mappe. Googles mål er tredelt: bedre tilskrivning af, hvilke apps der har kontrol over hvilke filer, beskyttelse af appdata og beskyttelse af brugerdata.

Google fordobler MediaStore API for delt lyd-, video- og billedindhold. Som standard kan alle apps indsætte, ændre eller slette deres egne filer i MediaStore. Billeder, MediaStore. Video og MediaStore. Lydsamlinger uden behov for tilladelser. Android Q tilføjer også en ny MediaStore. Downloads samling til at gemme brugerdownloadet indhold, som alle apps, der bruger MediaStore API kan bidrage til. Mens filer, der er gemt i app-specifikke mapper med sandkasse, slettes ved afinstallation, fortsætter alle filer, der er bidraget til MediaStore-samlingerne, ud over afinstallation.

For at få adgang til filer, der er oprettet af en anden app – uanset om filen er i en af ​​MediaStore-samlingerne eller uden for dem – skal appen bruge Storage Access Framework. Desuden redigeres EXIF-metadata for billeder, medmindre din app har den nye ACCESS_MEDIA_LOCATION-tilladelse. I Android Q kan apps også kontrollere, hvilken lagerenhed der skal landes medier på, ved at forespørge på dens volumennavn ved hjælp af getExternalVolume().

Google pålagde oprindeligt Scoped Storage-begrænsninger for alle apps i Android Q uanset deres mål-API-niveauer, men efter feedback er virksomheden give udviklerne mere tid at foretage justeringer. De fulde detaljer om ændringerne af omfanget af lagring kan findes på denne side, og du kan finde ud af mere om Googles anbefalinger om bedste praksis for delt lagring af ser denne Google I/O tale.

Advarsler for apps, der er målrettet mod API-niveau < 23

Tilladelsesbegrænsninger slutter dog ikke der. Installation af en app, der er målrettet mod et API-niveau lavere end 23 (Android Lollipop eller ældre), vil få OS til at vise en advarsel til brugeren, hvis appen anmoder om følsomme tilladelser ved installationen. Før installationen vil brugerne have mulighed for manuelt at angive, hvilke tilladelser de vil give appen, før de fortsætter. Android Q tillader således ikke længere apps at komme uden om runtime-tilladelser.

Ligesom CopperheadOS lader lager Android Q nu brugeren deaktivere alle anmodede farlige tilladelser, før de kører en app for første gang. Dette gælder kun for apps, der er målrettet mod API-niveau 22 eller derunder, hvilket er før runtime-tilladelser blev introduceret (i Android Marshmallow).

Eventuel SYSTEM_ALERT_DEPRECATION til fordel for Bubbles API

Bubbles API i aktion. Kilde: Google.

Overlejringstilladelsen (SYSTEM_ALERT_WINDOW) kan ikke længere gives til apps, der kører på Android Q (Go Edition). For ikke-Go Edition-enheder skubber Google udviklere mod den nye Bubbles API. Bubbles API er en funktion introduceret i Android Q Beta 2 som giver mulighed for funktionalitet, der ligner Facebook Messengers chathoveder. Notifikationer fra apps vises som små bobler i kanterne af skærmen, som udvider sig, når brugeren trykker på dem. Inden for boblen kan en app vise en aktivitet.

Denne ændring var nødvendig, fordi det indebærer åbenlyse sikkerhedsrisici at tillade apps frit at tegne overlejringer over andre apps. den berygtede"Kappe og Dolk" exploit brugte denne svaghed i vid udstrækning. Funktionaliteten af ​​overlejrings-API'en er blevet begrænset så tidligt som Android Oreo, men nu har Go-udgaven af ​​Android Q fuldstændigt fjernet adgangen til API'et med en fremtidig udgivelse for helt at udfase den.

Baggrundsaktivitetsstartbegrænsninger

Apps i baggrunden kan ikke længere automatisk starte en aktivitet, mens telefonen er låst op, uanset deres mål-API-niveau. Der er en hel liste over betingelser, hvorunder apps nu kan starte aktiviteter, som du kan læse her. Baggrundsapps, som ikke opfylder disse betingelser og ønsker at starte en aktivitet hurtigt, skal nu fortælle brugeren det via en notifikation. Hvis meddelelsen oprettes med en afventende hensigt i fuld skærm, startes hensigten med det samme, hvis skærmen er slukket - nyttigt til alarmer eller indgående opkald.

Baggrundsudklipsholder adgangsbegrænsning

Baggrundsudklipsholderadgang er ikke længere muligt. Ethvert program, der ikke er i forgrunden eller er indstillet som standardindtastningsmetode, vil ikke kunne læse dit udklipsholder på nogen måde. Dette rammer apps som udklipsholdere særligt hårdt. Google siger, at denne ændring kun påvirker apps, der udelukkende er målrettet mod Android Q, men vores test viser, at begrænsningen ikke diskriminerer; enhver app, vi prøvede, kunne ikke se udklipsholderen.

Denne ændring giver selvfølgelig mening. Vi kopierer ofte følsomme oplysninger til udklipsholderen – ting som adgangskoder og kreditkortoplysninger – men det er stadig en skam at se udklipsholdere gå i vasken.

Kun adgang til placering, mens en app er i brug

Nye muligheder for placeringstilladelse

En ny brugeraktiveret indstilling tillader kun apps at nå din placering, mens appen er i brug. Den seneste Android Q beta har også tilføjet en notifikation, der minder dig om, hvis du har givet en app permanent adgang til placeringen.

Roller

Roller

En ny "Roles" API er blevet tilføjet. Roller er i det væsentlige grupper med forudindstillede tilladelsesadgang. For eksempel kan apps med gallerirollen have adgang til dine mediemapper, mens apps med opkaldsrollen muligvis kan håndtere opkald. Apps, der tildeles en bestemt rolle af brugeren, skal også have de nødvendige komponenter. Apps med gallerirollen skal for eksempel have handlingsintentionsfilteret android.hensigt.handling.HOVED og kategoriens hensigtsfilter android.intent.category. APP_GALLERI for at blive vist som en galleri-app i indstillinger.

Sensorer fra Hurtige indstillinger flise

Sensorer Hurtige indstillinger flise

Der er en ny "Sensorer fra" hurtige indstillingsfelt, som slår aflæsninger fra alle sensorer (accelerometer, gyroskop osv.) på din enhed for ægte privatliv. Denne flise med hurtige indstillinger er skjult som standard, men kan aktiveres ved at gå til "hurtige indstillinger udviklerfliser" i Udviklerindstillinger.

Begrænsninger til /proc/net

Apps kan ikke længere adgang proc/net, hvilket gør tjenester som netstat ikke længere levedygtige. Dette beskytter brugere mod ondsindede apps, der overvåger, hvilke websteder og tjenester de opretter forbindelse til. Apps, der har brug for fortsat adgang, såsom VPN'er, skal bruge NetworkStatsManager og ConnectivityManager klasser.

Randomiserede MAC-adresser

Din MAC-adresse er en unik identifikator, som netværk bruger til at huske, hvilken enhed der er hvilken. I Android Q, hver gang du opretter forbindelse til et nyt netværk, vil din enhed bruge en ny, tilfældig MAC-adresse. Som resultat, netværk kan ikke spore din placering ved at matche hvilke WiFi-netværk du opretter forbindelse til med din telefons MAC-adresse. Enhedens faktiske MAC-adresse fra fabrikken kan stadig fås af apps via getWifiMacAddress() kommando.


Platformhærdning i Android Q

En enkelt fejl i Android betyder ikke, at angribere nu har fuld adgang til operativsystemet, eller at de kan omgå alle sikkerhedssystemer. Dette skyldes til dels en række sikkerhedsforanstaltninger såsom procesisolering, reduktion af angrebsoverflader, arkitektonisk nedbrydning og udnyttelsesbegrænsninger. Disse sikkerhedsforanstaltninger gør sårbarheder sværere eller endda umulige at udnytte. Som følge heraf har angribere typisk brug for et væld af sårbarheder, før de kan nå deres mål. Tidligere har vi set angreb såsom DRAMMER der virker ved at kæde flere udnyttelser sammen.

Android Q tager sikkerhedsforanstaltninger som disse og anvender dem på mere følsomme områder som medierne og Bluetooth-komponenter sammen med kernen også. Dette medfører nogle markante forbedringer.

  • En begrænset sandkasse til software-codecs.
  • Øget produktionsbrug af desinfektionsmidler for at afbøde hele klasser af sårbarheder i komponenter, der behandler indhold, der ikke er tillid til.
  • Shadow Call Stack, som giver baglæns kontrolflowintegritet (CFI) og komplementerer den fremadgående beskyttelse fra LLVMs CFI.
  • Beskyttelse af Address Space Layout Randomization (ASLR) mod lækager ved hjælp af eXecute-Only Memory (XOM).
  • Introduktion af Scudo-hærdet allokator, som gør en række heap-relaterede sårbarheder sværere at udnytte.

Dette er en masse software-jargon. Knoglerne ved det er, at for det første kører software-codecs nu i sandkasser, som har færre privilegier, hvilket betyder, at det er mindre sandsynligt, at ondsindet software vil være i stand til at køre kommandoer, der kan skade din enhed, f.eks. i etuiet af Sceneskræk helt tilbage i 2015.

En begrænset sandkasse til software-codecs. Kilde: Google.

For det andet tjekker Android nu for out-of-bounds array-adgang flere steder, såvel som overløb. Forebyggelse af overløb og instruering af processer til at fejle sikkert reducerer procentdelen af ​​brugerrumssårbarheder markant. Hvad dette betyder er, at hvis et ondsindet program forsøger at få noget til at gå ned ved bevidst at forsøge det få adgang til data, der ikke findes, vil Android nu genkende dette og afslutte programmet, i stedet for styrter ned.

For det tredje beskytter Shadow Call Stack returadresser ved at gemme dem i en separat skyggestak, hvilket gør dem utilgængelige for almindelige programmer. Returadresser er typisk henvisninger til funktioner, så det er vigtigt at beskytte disse adresser for at sikre, at angribere ikke kan få adgang til funktioner, de ikke burde være i stand til.

For det fjerde er ASLR en beskyttelsesmetode, der randomiserer, hvor programmer er gemt i hukommelsen, hvilket gør det sværere at finde ud af, hvor programmer gemmes i hukommelsen baseret på andres placering programmer. Kun eXecute-hukommelse styrker dette ved at gøre koden ulæselig.

Endelig er Scudo en dynamisk heap-allokator, som proaktivt styrer hukommelsen på en måde, der gør heap-baserede sårbarheder meget sværere at udnytte. Du kan læse mere om det her.


Godkendelse

Opdateringer til BiometricPrompt i Android Q

Google introducerede den nye BiometricPrompt API for over et år siden, i Android P Developer Preview 2. Det var beregnet til at være en generisk Android-prompt til biometriske oplåsningsmetoder. Tanken er, at enheder som understøtter mere end blot fingeraftryksscanning, f.eks. iris-scanning på Samsungs Galaxy S-linje, vil være i stand til at bruge disse metoder, når apps beder om bekræftelse.

Android Q tilføjer robust understøttelse af ansigts- og fingeraftryksbekræftelse samt udvider API'et til at understøtte implicit godkendelse. Eksplicit godkendelse kræver, at brugeren godkender på en eller anden måde, før han fortsætter, mens implicit ikke behøver mere brugerinteraktion.

BiometricPrompt API implicit og eksplicit flow. Kilde: Google.

Oven i det kan apps nu tjekke, om en enhed understøtter biometrisk godkendelse via en simpel funktionskald, så de ikke kan spilde tid på at kalde en BiometricPrompt på enheder, der ikke støtte det. En ideel brug for dette ville være, hvis apps vil give en "Aktiver biometrisk login"-indstilling baseret på, om en enhed understøtter biometrisk godkendelse eller ej.

Byggestenene til elektronisk ID-support

Tidligere i år opdagede vi beviser på, at Google er arbejder med support til elektroniske ID'er i Android. På I/O opdaterede Google os om funktionens fremskridt. Google siger, at de arbejder sammen med ISO for at standardisere implementeringen af ​​mobile kørekort, med elektroniske pas på vej. Til udviklere vil Google levere et Jetpack-bibliotek, så identitetsapps kan begynde at blive lavet.


Project Mainline i Android Q

Project Mainline er en stor opgave fra Googles side for at reducere fragmenteringen af ​​visse systemmoduler og apps. Google vil kontrollere opdateringer til omkring 12 systemkomponenter via Play Butik. Vi har talt om Project Mainline i dybden i en tidligere artikel hvis du er interesseret i at læse mere.


Konklusion

Sikkerhed har altid været en central del af Androids udvikling. Google har gjort et imponerende stykke arbejde med at holde Android opdateret med de nyeste sikkerhedsfunktioner, samt lavet nogle egne innovationer. De fortsætter denne udviklingsproces med Android Q og pakker den fuld af sikkerhedsfunktioner, der er lavet for at sikre, at dine data er sikrere end nogensinde før.


Kilde 1: Hvad er nyt i Android Q Security [Google]

Kilde 2: Sikkerhed på Android: Hvad er det næste [Google]

Kilde 3: Sæt de hærdende forbedringer i kø [Google]

Med input fra Mishaal Rahman og Adam Conway.