På Google I/O lärde vi oss om förbättringarna som Android Q ger. Nya säkerhets- och sekretessfunktioner och förbättringar finns i det nya Android OS.
Varje ny version av Android OS ger förbättringar av nästan alla aspekter från design, funktioner, API: er och mer. På Google I/O tidigare denna månad lärde vi oss om alla förbättringar som Android Q kommer att medföra, och naturligtvis utelämnades inte nya integritets- och säkerhetsmeddelanden från konferensen. Plattformssäkerheten är en av de viktigaste aspekterna av ett OS, särskilt för ett OS som vi tar med oss överallt i våra fickor. Om Android inte var säkert skulle vi inte lita på det med hälften så många funktioner som vi gör. NFC-betalningar skulle vara uteslutet, fildelning skulle i bästa fall vara tveksamt, och att ansluta till andra enheter skulle vara rent galenskap. Trots det långvariga problemet med versionsfragmentering har Google gjort mycket bra för att hålla antalet säkerhetsproblem till ett minimum.
Android har mognat till ett operativsystem som är både funktionsrikt och mycket säkert. Men det finns naturligtvis alltid utrymme för förbättringar. Det finns många bidragande faktorer till denna säkerhet, och några av dem förbättras på något sätt med Android Q.
Kryptering
Eftersom det är en av de mest grundläggande säkerhetsmetoderna är det viktigt att varje enhet stöder stark kryptering. Många OEM-tillverkare skickar idag sina enheter med dedikerad krypteringshårdvara. Även om detta är fördelaktigt, är det också dyrt. Som sådan har dedikerad hårdvara vanligtvis begränsats för enheter med medel till hög nivå. Detta är inte att säga att low-end enheter kan inte stöder kryptering, men utan hårdvaruaccelererad kryptering försämras den övergripande användarupplevelsen på grund av långsamma läs-/skrivtider. Det är där Adiantum kommer in.
Adiantum
I februari tillkännagav Google Adiantum som ett alternativ krypteringsalgoritm för lågpristelefoner som inte stöder vanliga AES-instruktionsuppsättningar. Adiantum är speciellt utformad för att köras utan någon dedikerad hårdvara. Det fungerar som ett lättare alternativ till Androids vanliga AES-kryptering. Googles riktmärken berätta för oss att det faktiskt är 5 gånger snabbare än AES, med nackdelen är att det kompromissar något med säkerheten. Detta gör den till den idealiska kandidaten för lågpristelefoner, som de som drivs av Android Go Edition. Adiantum är också för produkter som smartklockor och en mängd Internet of Things-enheter.
Fram till nu var Adiantum valfritt; tillverkare kunde aktivera det på enheter som startas med Android Pie, men det var inte standardkrypteringsalgoritmen. Nu ingår Adiantum som en del av Android Q. Detta innebär att alla enheter som startar med Q kommer att behöva kryptera användardata, utan undantag. Som ett resultat kommer enheter som lanseras med Android Q garanterat att ha lagringskryptering, vare sig det är via Adiantum eller inte.
Jetpack säkerhetsbibliotek
Jetpack är en uppsättning Android-stödbibliotek, och ett av de senaste tillskotten är i alfa: Jetpack Security Library. Biblioteket förenklar processen att säkra din applikation genom att hantera saker som hantering av hårdvarustödda nyckellager och generering och validering av nycklar.
TLS 1.3
Lagring är dock inte det enda område som kryptering har förbättrats i. Kommunikation med andra enheter har förbättrats mycket, med introduktionen av TLS 1.3-stöd som standard. TLS 1.3 är den senaste nätverkskrypteringsstandarden, färdigställd av IETF i augusti 2018. TLS 1.3 ger mer integritet för datautbyten genom att kryptera fler av förhandlingshandskakningarna. Utöver detta är det snabbare än TLS 1.2 på grund av att en hel tur och retur rakas av från handskakningen för anslutningsetableringen. Tillsammans med effektivare moderna algoritmer ger detta en hastighetsökning på upp till 40 %.
TLS kan nu uppdateras direkt från Google Play eftersom det är en del av "Conscrypt"-komponenten. Du kan läsa mer om det och Project Mainline här.
Med tanke på att vi litar på så många känsliga transaktioner på våra enheter dagligen är den uppgraderade TLS viktigare än någonsin. Förvara sådana som boardingkort - och till och med digitala körkort någon gång i framtiden – på Android betyder att alla enheter ska kryptera användardata så gott de kan. Adiantum och påtvingad kryptering kommer att bana väg för att även den mest känsliga data kan lagras på de billigaste enheterna. Men kryptering är inte det enda sättet som Google ökar säkerheten för Android i Q-utgåvan.
Ändringar av behörigheter och sekretess i Android Q
Räckvidd förvaring
Scoped Storage är ett nytt skydd som används för att begränsa appar från att läsa/skriva filer i extern lagring som inte finns i deras egen appspecifika katalog i sandlåde. Googles mål är trefaldigt: bättre tilldelning av vilka appar som har kontroll över vilka filer, skydd av appdata och skydd av användardata.
Google fördubblar MediaStore API för delat ljud-, video- och bildinnehåll. Som standard kan alla appar infoga, ändra eller ta bort sina egna filer i MediaStore. Bilder, MediaStore. Video och MediaStore. Ljudsamlingar utan att behöva några tillstånd. Android Q lägger också till en ny MediaStore. Nedladdningar samling för att lagra användarnedladdat innehåll, som alla appar som använder MediaStore API kan bidra till. Medan filer som lagras i appspecifika kataloger med sandlådor tas bort vid avinstallation, kvarstår alla filer som bidragit till MediaStore-samlingarna efter avinstallation.
För att komma åt filer som skapats av en annan app – oavsett om filen finns i någon av MediaStore-samlingarna eller utanför dem – måste appen använda Storage Access Framework. Dessutom redigeras EXIF-metadata för bilder om inte din app har den nya ACCESS_MEDIA_LOCATION-tillståndet. I Android Q kan appar också styra vilken lagringsenhet som media ska landa på genom att fråga dess volymnamn med getExternalVolume().
Google införde initialt Scoped Storage-begränsningar för alla appar i Android Q oavsett deras målnivåer för API, men efter feedback är företaget ge utvecklarna mer tid att göra justeringar. Den fullständiga informationen om ändringarna av Scoped Storage finns på den här sidan, och du kan ta reda på mer om Googles rekommendationer om bästa praxis för delad lagring av tittar på denna Google I/O prata.
Varningar för appar som är inriktade på API-nivå < 23
Tillståndsbegränsningar slutar dock inte där. Om du installerar en app som är inriktad på en API-nivå lägre än 23 (Android Lollipop eller äldre) kommer operativsystemet att visa en varning för användaren om appen begär känsliga behörigheter vid installationen. Innan installationen kommer användare att ha möjlighet att manuellt ange vilka behörigheter de vill ge appen innan de fortsätter. Android Q tillåter alltså inte längre appar att komma runt runtime-behörigheter.
Eventuellt SYSTEM_ALERT_DEPRECATION till förmån för Bubbles API
Bubbles API i aktion. Källa: Google.
Överlagringsbehörigheten (SYSTEM_ALERT_WINDOW) kan inte längre beviljas för appar som körs på Android Q (Go Edition). För enheter som inte är Go Edition driver Google utvecklare mot det nya Bubbles API. Bubbles API är en funktion som introduceras i Android Q Beta 2 som möjliggör funktionalitet som är som Facebook Messengers chatthuvuden. Aviseringar från appar visas som små bubblor vid kanterna på skärmen, som expanderar när användaren trycker på dem. Inom bubblan kan en app visa en aktivitet.
Denna förändring var nödvändig eftersom att tillåta appar att fritt rita överlägg över andra appar utgör uppenbara säkerhetsrisker. Den ökända"Kappa och dolk"exploatet använde denna svaghet i stor utsträckning. Funktionaliteten för överlagrings-API: et har begränsats redan i Android Oreo, men nu har Go-utgåvan av Android Q helt tagit bort åtkomsten till API: t med en framtida utgåva för att fasa ut den helt.
Bakgrundsaktivitetsstartbegränsningar
Appar i bakgrunden kan inte längre automatiskt starta en aktivitet när telefonen är upplåst, oavsett deras mål-API-nivå. Det finns en hel lista med villkor under vilka appar nu kan starta aktiviteter, som du kan läsa här. Bakgrundsappar som inte uppfyller dessa villkor och vill starta en aktivitet omedelbart måste nu meddela användaren det via ett meddelande. Om aviseringen skapas med en väntande helskärmsavsikt, startas avsikten omedelbart om skärmen är avstängd - användbart för larm eller inkommande samtal.
Bakgrund Urklipp Åtkomstbegränsning
Tillgång till urklipp i bakgrunden är inte längre möjligt. Alla program som inte är i förgrunden eller är inställda som standardinmatningsmetod kommer inte att kunna läsa ditt urklipp på något sätt. Detta drabbar appar som urklippshanterare särskilt hårt. Google säger att denna förändring endast påverkar appar som uteslutande riktar sig till Android Q, men våra tester visar att begränsningen inte diskriminerar; någon app vi försökte kunde inte se urklippet.
Denna förändring är naturligtvis vettig. Vi kopierar ofta känslig information till urklipp – sådant som lösenord och kreditkortsuppgifter – men det är fortfarande synd att se urklippshanterare gå i sjön.
Platsåtkomst endast när en app används
En ny användaraktiverad inställning tillåter bara appar att nå din plats medan appen används. Den senaste Android Q-betan har också lagt till ett meddelande som påminner dig om du har beviljat en app permanent åtkomst till platsen.
Roller
Ett nytt "Roles" API har lagts till. Roller är i huvudsak grupper med förinställda behörigheter. Till exempel kan appar med gallerirollen ha åtkomst till dina mediemappar, medan appar med uppringningsrollen kanske kan hantera samtal. Appar som tilldelas en viss roll av användaren måste också ha de komponenter som krävs. Appar med gallerirollen måste till exempel ha åtgärdsavsiktsfiltret android.avsikt.handling.HUVUDSAK och kategorins avsiktsfilter android.intent.category. APP_GALLERI för att dyka upp som en galleriapp i inställningarna.
Sensorer av Snabbinställningar
Det finns en ny "Sensorer av" snabbinställningsruta som stänger av avläsningar från Allt sensorer (accelerometer, gyroskop, etc.) på din enhet för verklig integritet. Denna ruta för snabbinställningar är dold som standard men kan aktiveras genom att gå till "utvecklarplattor för snabbinställningar" i Utvecklaralternativ.
Restriktioner för /proc/net
Appar kan inte längre åtkomst till proc/nät, vilket gör tjänster som netstat inte längre lönsamma. Detta skyddar användare från skadliga appar som övervakar vilka webbplatser och tjänster de ansluter till. Appar som behöver fortsatt åtkomst, till exempel VPN, måste använda NetworkStatsManager och Connectivity Manager klasser.
Randomiserade MAC-adresser
Din MAC-adress är en unik identifierare som nätverk använder för att komma ihåg vilken enhet som är vilken. I Android Q kommer din enhet att använda en ny, slumpmässig MAC-adress varje gång du ansluter till ett nytt nätverk. Som ett resultat, nätverk kan inte spåra din plats genom att matcha vilka WiFi-nätverk du ansluter till med din telefons MAC-adress. Enhetens faktiska MAC-adress från fabriken kan fortfarande erhållas av appar via getWifiMacAddress() kommando.
Plattformshärdning i Android Q
En enda bugg inom Android betyder inte att angripare nu har full tillgång till operativsystemet eller att de kan kringgå alla säkerhetssystem. Detta beror delvis på ett antal skyddsåtgärder som processisolering, minskning av attackytan, arkitektonisk nedbrytning och exploateringsbegränsningar. Dessa skyddsåtgärder gör sårbarheter svårare eller till och med omöjliga att utnyttja. Som ett resultat behöver angripare vanligtvis en mängd sårbarheter innan de kan uppnå sina mål. Tidigare har vi sett attacker som DRAMMER som fungerar genom att sammankoppla flera bedrifter.
Android Q vidtar sådana skyddsåtgärder och tillämpar dem på mer känsliga områden som media och Bluetooth-komponenter tillsammans med kärnan också. Detta medför några markanta förbättringar.
- En begränsad sandlåda för programvarucodecs.
- Ökad produktionsanvändning av desinfektionsmedel för att mildra hela klasser av sårbarheter i komponenter som bearbetar opålitligt innehåll.
- Shadow Call Stack, som ger backward-edge Control Flow Integrity (CFI) och kompletterar framkantsskyddet som tillhandahålls av LLVM: s CFI.
- Skyddar adressutrymmeslayout randomisering (ASLR) mot läckor med eXecute-Only Memory (XOM).
- Introduktion av Scudo-härdad allokator som gör ett antal heaprelaterade sårbarheter svårare att utnyttja.
Detta är mycket mjukvarujargong. Först och främst körs programvarucodecs i sandlådor som har färre privilegier, vilket betyder att det är mindre sannolikt att skadlig programvara kommer att kunna köra kommandon som kan skada din enhet, till exempel i fallet av Scenskräck långt tillbaka 2015.
För det andra letar Android nu efter out-of-bounds array-åtkomst på fler ställen, såväl som översvämningar. Att förhindra översvämningar och instruera processer att misslyckas på ett säkert sätt minskar avsevärt andelen sårbarheter i användarutrymmet. Vad detta betyder är att om ett skadligt program försöker få något att krascha genom att medvetet försöka få tillgång till data som inte finns, kommer Android nu att känna igen detta och avsluta programmet istället för kraschar.
För det tredje skyddar Shadow Call Stack returadresser genom att lagra dem i en separat skuggstack, vilket gör dem oåtkomliga för vanliga program. Returadresser är vanligtvis pekare till funktioner, så att skydda dessa adresser är viktigt för att säkerställa att angripare inte kan komma åt funktioner de inte borde kunna.
För det fjärde är ASLR en skyddsmetod som randomiserar var program lagras i minnet, vilket gör det svårare att ta reda på var program lagras i minnet baserat på andras plats program. Execute-only minne stärker detta genom att göra koden oläsbar.
Slutligen är Scudo en dynamisk heap-allokator som proaktivt hanterar minnet på ett sätt som gör heap-baserade sårbarheter mycket svårare att utnyttja. Du kan läsa mer om det här.
Autentisering
Uppdateringar av BiometricPrompt i Android Q
Google introducerade det nya BiometricPrompt API för över ett år sedan, i Android P Developer Preview 2. Det var tänkt att vara en generisk Android-prompt för biometriska upplåsningsmetoder. Tanken är att enheter som stöder mer än bara fingeravtrycksskanning, t.ex. irisskanning på Samsungs Galaxy S-linje, kommer att kunna använda dessa metoder när appar ber om verifiering.
Android Q lägger till robust stöd för ansikts- och fingeravtrycksverifiering, samt utökar API: et för att stödja implicit autentisering. Explicit autentisering kräver att användaren autentiserar på något sätt innan han fortsätter, medan implicit inte behöver någon mer användarinteraktion.
Utöver det kan appar nu kontrollera om en enhet stöder biometrisk autentisering via en enkel funktionsanrop, så att de inte slösar tid på att anropa en BiometricPrompt på enheter som inte stödja det. En idealisk användning för detta skulle vara om appar vill ge en "Aktivera biometrisk inloggning"-inställning baserat på om en enhet stöder biometrisk autentisering eller inte.
Byggstenarna för elektroniskt ID-stöd
Tidigare i år upptäckte vi bevis för att Google är det arbetar med stöd för elektroniska ID i Android. På I/O uppdaterade Google oss om funktionens utveckling. Google säger att de arbetar med ISO för att standardisera implementeringen av mobila körkort, med elektroniska pass på gång. För utvecklare kommer Google att tillhandahålla ett Jetpack-bibliotek så att identitetsappar kan börja skapas.
Project Mainline i Android Q
Project Mainline är ett stort åtagande från Google för att minska fragmenteringen av vissa systemmoduler och appar. Google kommer att kontrollera uppdateringar för cirka 12 systemkomponenter via Play Butik. Vi har pratat om Project Mainline på djupet i en tidigare artikel om du är intresserad av att läsa mer.
Slutsats
Säkerhet har alltid varit en central del av Androids utveckling. Google har gjort ett imponerande jobb med att hålla Android uppdaterad med de senaste säkerhetsfunktionerna, samt gjort några egna innovationer. De fortsätter denna utvecklingsprocess med Android Q och packar den full av säkerhetsfunktioner som är gjorda för att se till att din data är säkrare än någonsin tidigare.
Källa 1: Vad är nytt i Android Q Security [Google]
Källa 2: Säkerhet på Android: Vad är nästa [Google]
Källa 3: Queue the Hardening Enhancements [Google]
Med input från Mishaal Rahman och Adam Conway.