A Google I/O-n megtudhattuk az Android Q által kínált fejlesztéseket. Új biztonsági és adatvédelmi funkciók és fejlesztések az új Android operációs rendszerben.
Az Android operációs rendszer minden új verziója szinte minden szempontból fejlesztéseket hoz a tervezés, a funkciók, az API-k és egyebek tekintetében. A hónap elején a Google I/O-n mindenről értesültünk az Android Q fejlesztései fog hozni, és természetesen az új adatvédelmi és biztonsági közlemények sem maradtak ki a konferenciáról. A platform biztonsága az egyik legfontosabb szempont egy operációs rendszerben, különösen egy olyan operációs rendszer esetében, amelyet mindenhová magunkkal viszünk a zsebünkben. Ha az Android nem lenne biztonságos, feleannyi funkciót sem bíznánk rá, mint mi. Az NFC-s fizetés szóba sem jöhetne, a fájlmegosztás legjobb esetben is kétséges, más eszközökhöz való csatlakozás pedig egyenesen őrület. A verziótöredezettség régóta fennálló problémája ellenére a Google rendkívül jól tette, hogy a minimálisra csökkentse a biztonsági problémák számát.
Az Android egy olyan operációs rendszerré érett, amely funkciókban gazdag és rendkívül biztonságos. De persze mindig van hova fejlődni. Számos tényező hozzájárul ehhez a biztonsághoz, és ezek közül néhányat valamilyen módon javítanak az Android Q segítségével.
Titkosítás
Mivel az egyik legalapvetőbb biztonsági módszer, fontos, hogy minden eszköz támogassa az erős titkosítást. Manapság sok OEM dedikált titkosító hardverrel szállítja eszközeit. Ez ugyan előnyös, de drága is. Mint ilyen, a dedikált hardver általában a közepes és magas szintű eszközökre korlátozódik. Ez nem azt jelenti, hogy alacsony kategóriás készülékek nem tud támogatja a titkosítást, de hardveres gyorsított titkosítás nélkül az általános felhasználói élmény romlik a lassú olvasási/írási idők miatt. Itt jön be az Adiantum.
Adiantum
Februárban a Google bejelentette az Adiantumot alternatívaként titkosítási algoritmus alacsonyabb kategóriás telefonokhoz amelyek nem támogatják a szokásos AES utasításkészleteket. Az Adiantumot kifejezetten arra tervezték, hogy dedikált hardver nélkül is működjön. Könnyebb alternatívaként szolgál az Android szokásos AES-titkosításához. A Google referenciaértékei Mondja el nekünk, hogy valójában 5-ször gyorsabb, mint az AES, és az a hátránya, hogy némileg veszélyezteti a biztonságot. Emiatt ideális jelölt az alacsonyabb kategóriás telefonokhoz, például az Android Go Edition rendszerrel működő telefonokhoz. Az Adiantum olyan termékekhez is használható, mint az okosórák és a tárgyak internetes eszközei.
Eddig az Adiantum opcionális volt; a gyártók engedélyezhették az Android Pie-vel induló eszközökön, de nem ez volt az alapértelmezett titkosítási algoritmus. Most az Adiantum natívan az Android Q részeként szerepel. Ez azt jelenti, hogy minden Q-val induló eszköznek titkosítania kell a felhasználói adatokat, kivétel nélkül. Ennek eredményeként az Android Q-val induló eszközök garantáltan rendelkeznek tárhelytitkosítással, akár Adiantumon keresztül, akár nem.
Jetpack biztonsági könyvtár
A Jetpack Android támogatási könyvtárak készlete, és az egyik legújabb kiegészítés alfában van: a Jetpack Security Library. A könyvtár leegyszerűsíti az alkalmazás biztonságossá tételét azáltal, hogy olyan dolgokat kezel, mint a hardverrel támogatott kulcstárolók kezelése, valamint a kulcsok generálása és érvényesítése.
TLS 1.3
A tárhely azonban nem az egyetlen terület titkosítása, amelyen javítottak. A más eszközökkel való kommunikáció jelentősen javult a bevezetésével TLS 1.3 támogatás alapértelmezés szerint. A TLS 1.3 a legújabb hálózati kriptográfiai szabvány, amelyet az IETF 2018 augusztusában véglegesített. A TLS 1.3 nagyobb adatvédelmet biztosít az adatcseréhez azáltal, hogy több tárgyalási kézfogást titkosít. Ráadásul gyorsabb, mint a TLS 1.2, mivel egy teljes oda-vissza utat le kell borotválni a kapcsolatlétesítési kézfogásból. Hatékonyabb modern algoritmusokkal párosítva ez akár 40%-os sebességnövekedést tesz lehetővé.
A TLS mostantól közvetlenül a Google Playről frissíthető, mivel a „Conscrypt” összetevő része. Erről és a Project Mainline-ról bővebben olvashat itt.
Tekintettel arra, hogy olyan sok érzékeny tranzakcióban bízunk az eszközeinken naponta, a frissített TLS fontosabb, mint valaha. A beszállókártyák kedvelőinek tárolása – sőt digitális jogosítványok valamikor a jövőben – az Androidon azt jelenti, hogy minden eszköznek a lehető legjobban titkosítania kell a felhasználói adatokat. Az Adiantum és a kényszerített titkosítás megnyitja az utat még a legérzékenyebb adatoknak is a legolcsóbb eszközön való tárolására. De a titkosítás nem az egyetlen módja annak, hogy a Google növelje az Android biztonságát a Q kiadásban.
Engedélyek és adatvédelmi változások az Android Q-ban
Hatékony tárolás
A Scoped Storage egy új biztosíték, amelyet arra használnak, hogy az alkalmazások ne olvashassanak/írhassanak olyan külső tárolón lévő fájlokat, amelyek nem találhatók a saját sandbox-alkalmazás-specifikus könyvtárukban. A Google célja három: jobb hozzárendelés, mely alkalmazások irányíthatják mely fájlokat, az alkalmazásadatok védelme és a felhasználói adatok védelme.
A Google megduplázza a MediaStore API-t a megosztott hang-, videó- és képtartalomhoz. Alapértelmezés szerint minden alkalmazás beillesztheti, módosíthatja vagy törölheti saját fájljait a MediaStore-ba. Képek, MediaStore. Videó és MediaStore. Hanggyűjtemények engedélyek nélkül. Az Android Q is hozzáad egy újat MediaStore. Letöltések gyűjtemény a felhasználók által letöltött tartalmak tárolására, amelyhez a MediaStore API-t használó összes alkalmazás hozzájárulhat. Míg a sandbox-alkalmazás-specifikus könyvtárakban tárolt fájlok törlődnek az eltávolításkor, a MediaStore-gyűjteményekhez hozzáadott összes fájl az eltávolítás után is megmarad.
A másik alkalmazás által létrehozott fájlok eléréséhez – függetlenül attól, hogy a fájl valamelyik MediaStore gyűjteményben vagy azon kívül található – az alkalmazásnak a Storage Access Framework-et kell használnia. Ezenkívül a képek EXIF-metaadatait töröljük, hacsak az alkalmazás nem rendelkezik az új ACCESS_MEDIA_LOCATION engedéllyel. Az Android Q rendszerben az alkalmazások azt is szabályozhatják, hogy melyik tárolóeszközre kerüljön a média, ha lekérdezik a kötet nevét a getExternalVolume() segítségével.
A Google eredetileg hatályos tárolási korlátozásokat vezetett be az Android Q összes alkalmazására, függetlenül azok megcélzott API-szintjétől, de a visszajelzések után a vállalat több időt adva a fejlesztőknek kiigazításokat végezni. A hatályos tárhely módosításainak teljes részlete megtalálható ezen az oldalon, és többet is megtudhat a Google által a megosztott tárolással kapcsolatos bevált módszerekről szóló ajánlásairól nézi ezt a Google I/O-t beszélgetés.
Figyelmeztetések a 23-nál kisebb API-szintet célzó alkalmazásokhoz
Az engedélyezési korlátozások azonban ezzel nem érnek véget. Ha olyan alkalmazást telepít, amely 23-nál alacsonyabb API-szintet céloz (Android Lollipop vagy régebbi), az operációs rendszer figyelmeztetést jelenít meg a felhasználó számára, ha az alkalmazás érzékeny engedélyeket kér a telepítéskor. A telepítés előtt a felhasználóknak lehetőségük lesz manuálisan megadni, hogy mely engedélyeket kívánják megadni az alkalmazásnak a folytatás előtt. Így az Android Q már nem teszi lehetővé az alkalmazások számára, hogy megkerüljék a futásidejű engedélyeket.
Az esetleges SYSTEM_ALERT_DEPRECATION a Bubbles API javára
Bubbles API működés közben. Forrás: Google.
A fedvényengedély (SYSTEM_ALERT_WINDOW) már nem adható meg az Android Q (Go Edition) rendszeren futó alkalmazások számára. A nem Go Edition készülékek esetében a Google az új Bubbles API felé tolja a fejlesztőket. A Bubbles API egy olyan szolgáltatás, amelyet bevezettek Android Q Beta 2 amely olyan funkcionalitást tesz lehetővé, mint a Facebook Messenger csevegőfejei. Az alkalmazások értesítései kis buborékokként jelennek meg a képernyő szélein, amelyek kitágulnak, amikor a felhasználó megérinti. A buborékon belül egy alkalmazás megjeleníthet egy tevékenységet.
Erre a változtatásra azért volt szükség, mert nyilvánvaló biztonsági kockázatokat rejt magában, ha lehetővé teszi az alkalmazások számára, hogy szabadon átfedjenek más alkalmazásokat. A hírhedt"Köpeny és tőrAz exploit széles körben használta ezt a gyengeséget. Az overlay API funkcióit már az Android Oreo előtt korlátozták, de most az Android Q Go kiadása teljesen megszüntette az API-hoz való hozzáférést egy jövőbeli kiadás, hogy teljesen elavult legyen.
Háttértevékenység indítási korlátozások
A háttérben lévő alkalmazások többé nem tudnak automatikusan tevékenységet indítani, amíg a telefon fel van oldva, függetlenül a cél API-szinttől. A feltételek teljes listája van, amelyek mellett az alkalmazások mostantól tevékenységeket indíthatnak el, és ezeket elolvashatja itt. Azoknak a háttéralkalmazásoknak, amelyek nem felelnek meg ezeknek a feltételeknek, és sürgősen szeretnének elindítani egy tevékenységet, értesíteniük kell a felhasználót. Ha az értesítés függőben lévő teljes képernyős szándékkal jön létre, akkor az intent azonnal elindul, ha a képernyő ki van kapcsolva – ez hasznos riasztásokhoz vagy bejövő hívásokhoz.
Háttér vágólapra való hozzáférés korlátozása
Háttér vágólap hozzáférés már nem lehetséges. Azok az alkalmazások, amelyek nincsenek előtérben vagy alapértelmezett beviteli módként vannak beállítva, semmilyen módon nem fogják tudni olvasni a vágólapot. Ez különösen keményen érinti az olyan alkalmazásokat, mint a vágólapkezelők. A Google szerint ez a változás csak azokat az alkalmazásokat érinti, amelyek kizárólag az Android Q-t célozzák, de a tesztek azt mutatják, hogy a korlátozás nem tesz megkülönböztetést; az általunk kipróbált alkalmazások nem látták a vágólapot.
Ennek a változtatásnak természetesen van értelme. Gyakran másolunk érzékeny információkat a vágólapra – például jelszavakat és hitelkártyaadatokat –, de még mindig kár látni, hogy a vágólapkezelők a csatornába mennek.
A helyhez való hozzáférés csak az alkalmazás használata közben
Egy új, felhasználó által engedélyezett beállítás csak akkor teszi lehetővé az alkalmazások számára, hogy elérjék az Ön tartózkodási helyét, amíg az alkalmazás használatban van. A legújabb Android Q béta egy értesítést is hozzáadott, amely emlékezteti Önt, ha egy alkalmazásnak állandó hozzáférést adott a helyhez.
Szerepek
Új „Szerepek” API került hozzáadásra. A szerepek lényegében előre beállított engedélyekkel rendelkező csoportok. Például a galéria szerepkörrel rendelkező alkalmazások hozzáférhetnek a médiamappákhoz, míg a tárcsázói szerepkörrel rendelkező alkalmazások kezelhetik a hívásokat. A felhasználó által meghatározott szerepkörrel rendelkező alkalmazásoknak rendelkezniük kell a szükséges összetevőkkel is. A galéria szerepkörrel rendelkező alkalmazásoknak például rendelkezniük kell a műveleti szándékszűrővel android.elszánt.akció.FŐ és a kategória szándékszűrő android.intent.category. APP_GALLERY hogy galériaalkalmazásként jelenjen meg a beállításokban.
Érzékelők kikapcsolása Gyorsbeállítások csempe
Van egy új "Érzékelők kikapcsolása" gyorsbeállítási csempe, amely kikapcsolja a leolvasásokat minden érzékelők (gyorsulásmérő, giroszkóp stb.) az eszközön a valódi adatvédelem érdekében. Ez a Gyorsbeállítások csempe alapértelmezés szerint el van rejtve, de engedélyezhető a Fejlesztői beállítások „Gyorsbeállítások fejlesztői csempék” részében.
A /proc/net korlátozásai
Az alkalmazások már nem hozzáférés proc/net, így a netstathoz hasonló szolgáltatások életképtelenné válnak. Ez megvédi a felhasználókat a rosszindulatú alkalmazásoktól, amelyek figyelik, hogy milyen webhelyekhez és szolgáltatásokhoz csatlakoznak. A folyamatos hozzáférést igénylő alkalmazásoknak (például VPN-eknek) a NetworkStatsManager és ConnectivityManager osztályok.
Véletlenszerű MAC-címek
Az Ön MAC-címe egy egyedi azonosító, amelyet a hálózatok arra használnak, hogy megjegyezzék, melyik eszköz melyik. Az Android Q rendszerben minden alkalommal, amikor új hálózathoz csatlakozik, az eszköz egy új, véletlenszerű MAC-címet fog használni. Ennek eredményeként hálózatok nem tudják nyomon követni a tartózkodási helyét a telefon MAC-címének egyeztetésével, hogy mely WiFi hálózatokhoz csatlakozik. A készülék tényleges, gyári MAC-címét az alkalmazások továbbra is megszerezhetik a következőn keresztül getWifiMacAddress() parancs.
Platform keményítés Android Q-ban
Egyetlen hiba az Androidon belül nem jelenti azt, hogy a támadók teljes hozzáféréssel rendelkeznek az operációs rendszerhez, vagy hogy megkerülhetnek minden biztonsági rendszert. Ez részben számos biztosítéknak köszönhető, mint például a folyamat elszigetelése, a támadási felület csökkentése, az építészeti dekompozíció és a kizsákmányolás mérséklése. Ezek a biztosítékok megnehezítik vagy akár lehetetlenné teszik a sérülékenységek kihasználását. Ennek eredményeként a támadóknak általában számos sebezhetőségre van szükségük, mielőtt elérhetik céljaikat. A múltban láthattunk támadásokat mint például a DRAMMER amelyek több exploit összeláncolásával működnek.
Az Android Q megteszi az ehhez hasonló biztosítékokat, és alkalmazza azokat az érzékenyebb területeken, mint például a média és a Bluetooth összetevők, valamint a kernel is. Ez jelentős javulást hoz.
- Korlátozott homokozó szoftveres kodekekhez.
- A fertőtlenítőszerek fokozott gyártási használata a nem megbízható tartalmat feldolgozó komponensek sebezhetőségeinek teljes osztályának csökkentésére.
- Shadow Call Stack, amely biztosítja a visszafelé irányuló áramlási integritást (CFI), és kiegészíti az LLVM CFI által biztosított előremenő élvédelmet.
- Az Address Space Layout Randomization (ASLR) védelme a szivárgás ellen az eXecute-Only Memory (XOM) használatával.
- A Scudo keményített allokátor bevezetése, amely számos kupachoz kapcsolódó sebezhetőséget megnehezít.
Ez egy csomó szoftveres zsargon. A lényeg az, hogy először is a szoftver kodekek mostantól homokozókban futnak, amelyek kevesebb jogosultsággal rendelkeznek, vagyis kevésbé valószínű, hogy a rosszindulatú szoftverek képesek lesznek olyan parancsokat futtatni, amelyek károsíthatják az eszközt, például a tokban nak,-nek Lámpaláz még 2015-ben.
Másodszor, az Android most több helyen ellenőrzi a határokon kívüli tömbhozzáférést, valamint a túlcsordulást. A túlcsordulás megakadályozása és a folyamatok biztonságos meghibásodására utasítása jelentősen csökkenti a felhasználói terület sebezhetőségeinek százalékos arányát. Ez azt jelenti, hogy ha egy rosszindulatú program szándékos kísérlettel megpróbál valami összeomlást okozni hozzáférést kap a nem létező adatokhoz, az Android most felismeri ezt, és kilép a programból összeomlik.
Harmadszor, a Shadow Call Stack megvédi a visszatérési címeket azáltal, hogy külön árnyékveremben tárolja azokat, így a szokásos programok nem érhetik el őket. A visszaküldési címek jellemzően funkciókra mutatnak, ezért ezeknek a címeknek a védelme fontos annak biztosítása érdekében, hogy a támadók ne férhessenek hozzá olyan funkciókhoz, amelyekhez nem kellene hozzáférniük.
Negyedszer, az ASLR egy olyan védelmi módszer, amely véletlenszerűen kiválasztja a programok tárolási helyét a memóriában, így azt nehezebb kitalálni, hogy hol tárolódnak a programok a memóriában a többiek helye alapján programokat. A csak eXecute memória ezt erősíti azáltal, hogy a kódot olvashatatlanná teszi.
Végül a Scudo egy dinamikus halomelosztó, amely proaktívan kezeli a memóriát oly módon, hogy a halomalapú sebezhetőségeket sokkal nehezebb kihasználni. Bővebben olvashatsz róla itt.
Hitelesítés
Frissítések a BiometricPrompthoz Android Q-ban
A Google több mint egy éve mutatta be az új BiometricPrompt API-t Android P fejlesztői előnézet 2. Ez egy általános Android-prompt volt a biometrikus feloldási módszerekhez. Az ötlet az, hogy olyan eszközök, amelyek nem csak ujjlenyomat-leolvasást támogatnak, pl. A Samsung Galaxy S vonal íriszszkennelése képes lesz használni ezeket a módszereket, amikor az alkalmazások ellenőrzést kérnek.
Az Android Q robusztus támogatást nyújt az arc- és ujjlenyomat-ellenőrzéshez, valamint kiterjeszti az API-t az implicit hitelesítés támogatására. Az explicit hitelesítés megköveteli, hogy a felhasználó valamilyen módon hitelesítsen a folytatás előtt, míg az implicit hitelesítéshez nincs szükség további felhasználói beavatkozásra.
Ráadásul az alkalmazások most egy egyszerű módszerrel ellenőrizhetik, hogy egy eszköz támogatja-e a biometrikus hitelesítést függvényhívást, lehetővé téve számukra, hogy ne pazarolják az idejüket a BiometricPrompt meghívásával olyan eszközökön, amelyek nem támogassa azt. Ideális felhasználási mód az lenne, ha az alkalmazások „Biometrikus bejelentkezés engedélyezése” beállítást szeretnének adni annak alapján, hogy az eszköz támogatja-e a biometrikus hitelesítést.
Az elektronikus azonosító támogatás építőkövei
Az év elején bizonyítékokat fedeztünk fel arra vonatkozóan, hogy a Google az elektronikus azonosítók támogatásán dolgozik Androidban. Az I/O-n a Google tájékoztatott minket a funkció előrehaladásáról. A Google azt állítja, hogy együttműködnek az ISO-val a mobil jogosítványok bevezetésének szabványosításán, és készül az elektronikus útlevél is. A fejlesztők számára a Google Jetpack-könyvtárat biztosít, hogy megkezdődhessen az identitás-alkalmazások készítése.
Project Mainline Android Q-ban
A Project Mainline a Google jelentős vállalkozása bizonyos rendszermodulok és alkalmazások töredezettségének csökkentésére. A Google körülbelül 12 rendszerösszetevő frissítését szabályozza a Play Áruházban. Részletesen beszéltünk a Project Mainline-ról egy korábbi cikkben ha érdekel még olvasni.
Következtetés
A biztonság mindig is központi eleme volt az Android fejlesztésének. A Google lenyűgöző munkát végzett annak érdekében, hogy az Androidot naprakészen tartsa a legújabb biztonsági funkciókkal, valamint néhány saját fejlesztést is megvalósított. Folytatják ezt a fejlesztési folyamatot az Android Q-val, tele olyan biztonsági funkciókkal, amelyek gondoskodnak arról, hogy adatai minden eddiginél biztonságosabbak legyenek.
1. forrás: Az Android Q Security újdonságai [Google]
2. forrás: Biztonság Androidon: Mi a következő lépés [Google]
Forrás 3: Queue the Hardening Enhancements [Google]
Mishaal Rahman és Adam Conway közreműködésével.