Android 7.0: a biztonsági előnyök valóban számítanak

Frissítve 2016. augusztus 13-án, az Android Nougat végső funkcióiról és API-jairól.

Az Android N.-ben sok kódváltozás érkezik. Néhányuk láthatjuk - mint az új értesítések -, mások pedig nem (de még mindig nagy ügy). Ugyanezt látjuk minden frissítéssel. Vannak finomítások és változtatások az interfészen, de a motorháztető alatt kiigazításokat és változtatásokat hajtanak végre az Android jobb és biztonságosabb futtatása érdekében.

A Google javította az Android Nougat biztonságát néhány különböző területen. Egyesek célja az, hogy megkeményítsék az Androidot, mások eszközök a fejlesztők számára, így az alkalmazások telepítésekor így marad. Vessünk egy pillantást a változásokra.

Zökkenőmentes frissítések

A Google már végrehajtja a "zökkenőmentes frissítéseket" a Chrome OS-en, és ez nagyon jól működik. A dolgok nagyon hasonlóak lesznek az Androidon.

A zökkenőmentes frissítések két különálló rendszerpartíciót használnak. Az egyik az a rendszer, amelyet futtat, amikor napi telefonját használja. Amikor ideje frissíteni, a másik rendszerpartíció megváltozik és frissül, és a következő alkalommal, amikor újraindul, automatikusan átvált. Legközelebbi frissítés esetén a másik rendszerpartíció megváltozik, és visszalép.

: Android 7.0: Mik a zökkenőmentes frissítések és hogyan működnek?

Ez azt jelenti, hogy a dolgok megtehetők munka közben vagy játék közben, és ha kész, akkor csak a normál újraindítást kell tennie. Meg fog lepődni (voltam, amikor ezt hallottam), de egy elég nagy darab ember nem frissíti a telefonját, mert időbe telik. Lehet, hogy egyszer megcsinálták, majd ott ültek várakozással, és úgy döntöttek, hogy nem teszik meg újra. Könnyű elutasítani az értesítést. De ha megváltoztatja az eljárást, megkönnyíti a frissítéseket, és kiküszöböli a szörnyű várakozási időt, miközben látja az "alkalmazások frissítése" párbeszédpanelt, több ember fogja megtenni.

Hálózati biztonsági konfiguráció

A hálózati biztonsági konfiguráció lehetővé teszi az alkalmazásfejlesztők számára, hogy a hálózati biztonsági beállításokhoz egyéni konfigurációs fájlt hozzon létre és használjon ahelyett, hogy rendszerszintű módosításokat kérne. A konfigurációs fájl megváltoztatható magának az alkalmazásnak a módosítása nélkül, és beállítható úgy, hogy az eszköz helyett egyéni tanúsító hatóságot használjon. alapértelmezett, és beállítható úgy is, hogy figyelmen kívül hagyja a rendszer által megbízható CA-kat vagy az összes CA-t. Ez fontos ahhoz, hogy csatlakozzon egy hosthoz, amely rendelkezik saját aláírással rendelkező CA-val (például a vállalati alkalmazásokhoz), vagy egy olyan alkalmazáshoz, amely csak egy adott CA-ra bízhat.

Ezen felül a konfiguráció beállítható úgy, hogy lemondjon minden egyszerű szöveges hálózati forgalomról, és a titkosított kommunikációt kényszerítse a HTTPS protokoll használatával. Ha hálózati rendszergazda vagy, vagy hálózati alkalmazásokat fejlesztett, akkor tudja, mennyire fontosak ezek a változások. Másokunk örülhetnek annak, hogy biztonságosabb hálózati forgalmat bonyolíthatunk könnyebben fejleszthető alkalmazásokban.

A Media Server edzése

Emlékszel a Stagefright-ra? Noha a média nagy része ezt aránytalanul kihúzta, a hiperbole mögött rejtett tényleges kérdés volt. A médiafájl lejátszása és az a képesség, amely arra kényszeríti Önt, hogy újraindítsa vagy elveszítse az összes hangot, csúnya kérdés, és az a tény, hogy (elméletileg) ezt fel lehet használni a root engedélyek titkos megszerzésére, még ijesztőbb. A Google nagyon komolyan veszi ezt, és havonta tapasztalunk javításokat a médiaszerver-könyvtárban, hogy megpróbáljuk megelőzni a vele járó hibákat és biztonsági aggályokat.

Az Android N esetén a médiaszerver nagy átalakításon esik át. A Google a médiakiszolgálót kisebb összetevőkre bontotta, amelyeket a teljes rendszerfrissítésen kívül frissíthetnek - ugyanúgy, mint a WebView összetevőnél. Ez azt jelenti, hogy ha új javításuk van, akkor megragadhatja a frissítést a Google Playről, ahelyett, hogy hat hónapot vagy annál tovább várna azokra a személyekre, akik telefonját készítették úgy, hogy elküldik a javítást Önnek.

Megváltoztatta a médiakiszolgáló engedélyezési modelljét is, és nem adta meg a rendszer teljes engedélyét. Az alacsony jogosultságokkal történő futtatás még nehezebbé teszi bárki számára a rendszerbe való behatolást, ha a médiaszerverre kerülnek. Ez jelentős változás, és még egyre nehezebbé teszi az Android telefonok (a rossz típusú hackelés) feltörését, mint régen.

Kulcs igazolás

A kulcs tanúsítás lehetővé teszi a fejlesztők számára, hogy megbizonyosodjanak arról, hogy a kulcsok, amelyeket esetleg az alkalmazásukban használnak, érvényesek és a telefon hardver által támogatott kulcstárolójában vannak tárolva, és nem a szoftverben. Ha az igazolási eszköznek generált álnevet ad egy kulcshoz (a tényleges kulcsot soha nem szabad megosztani), akkor létrehoz egy tanúsítási láncot, amely felhasználható a kulcs ellenőrzésére. A fejlesztők ellenőrizhetik mind a kulcsot, mind az ellenőrzött rendszerindítási állapotot, hogy megbizonyosodjanak arról, hogy minden érvényes-e.

Az Android N-tel szállító és a Google szolgáltatásait használó telefonoknak a Google által kiállított tanúsítvánnyal kell rendelkezniük, mint a gyökér (vagy elsődleges) hatóságnak, míg más frissített telefonokhoz a gyártó cég által kiállított tanúsítványra lesz szükség.

Nem minden olyan telefonon, amely képes az Android N futtatására, nincs megbízható hardverkörnyezet a titkosítási kulcsok tárolására, és ezekben az esetekben szoftverszintű kulcs-igazolást használnak. A hitelesített rendszerindítási állapot továbbra is ellenőrizhető, hogy megbizonyosodjunk arról, hogy a rendszerszoftvert nem hamisították-e meg. Igen, ez azt jelenti, hogy a fejlesztő ellenőrizheti a gyökérkövet. Ez jó dolog, feltéve, hogy nem indokolatlan büntetést szabnak ki azoknak a felhasználóknak, akik telefonját gyökerezik.

Fájlszintű titkosítás

Korábban az Android blokk szintű titkosítást használt az egész partíció vagy tároló eszköz egyszerre titkosításához. Ez egy nagyon biztonságos titkosítási módszer, és a tényleges tokenek tárolásból és a hardverből való távol tartása nagyjából azt jelentette, hogy a megfelelő jelszóval vagy PIN-kóddal lehetett bejutni. Az Android N segítségével a dolgok megváltoztak fájlszintű titkosításra.

A Direct Boot célja a fájlszintű titkosítás, hogy a konvekciót és a biztonságot is biztosítsák.

Amikor a titkosított Android-eszköz elindul (vagy újraindul a zsebében), az eszköz titkosítva lesz és le lesz zárva. Csak bizonyos alkalmazások futtathatók, és ezt közvetlen indító módnak nevezzük. Ez azt jelenti, hogy továbbra is telefonhívásokat kezdeményezhet, vagy kikapcsolhat riasztást (vagy akár üzeneteket is láthat), ám bármi más meghozatalához ki kell nyitnia és visszafejteni a készüléket. A feloldás után az N fájlszintű titkosítást használ, hogy lehetővé tegyük nekünk (a felhasználónak) és az alkalmazásoknak, hogy kicsit jobban ellenőrizzük az adatok zárolását.

Két előnye van a játéknak - az FDE (blokkrétegű teljes lemez titkosítás) az alacsony végfelhasználású eszközöket elég rosszul működteti. A Google-nak néhány próbálkozásra volt szüksége a Nexus 6-on, hogy megfelelő legyen, és minden olyan eszköz, amelynek 50 MB / s-nál alacsonyabb sebességű olvasási és írási flash tároló hardvere van, továbbra is küzd. A második (és még fontosabb) előnye a fájlszintű titkosítás használata A- hitelesített titkosításhoz A- társított D ata-val (AEAD). Az AEAD azt jelenti, hogy az adatokhoz nehezen férhetnek hozzá jogosulatlan felhasználók vagy alkalmazások. Az AEAD iránt érdeklődő embereknek itt egy igazán jó olvasmány az UC Davis professzortól, Phillip Rogaway-től (.pdf fájl).

Ez a többszintű titkosítási megközelítés lehetővé teszi a nagyon költségkímélő androidokat gyártó vállalatok számára a titkosítást a teljesítményromlás nélkül.

Közvetlen indítás

A fájlszintű titkosítás jobban működik a Közvetlen indítás funkcióval is. A Direct Boot új módot hoz létre, amelyet a fejlesztők kihasználhatnak, így alkalmazásuk futtatható, amint a rendszer bekapcsol, ahelyett, hogy arra várnának, hogy a felhasználó kinyitja a telefont, vagy visszafejtse azt.

Ezt egy új eszköztároló területtel párhuzamosan kell elvégezni, és a Direct Bootot használó alkalmazások nem lépnek kölcsönhatásba a normál hitelesítő adatokkal védett fájlrendszerrel és az egyes titkosított fájlokkal vagy könyvtárakkal.

: Android 7.0: Mi a Direct Boot, és hogyan javítja az élményét?

Hatályos könyvtár-hozzáférés

A Scoped Directory Access egy olyan módszer, amellyel az alkalmazások engedélyt kaphatnak a külső tárolóhelyen található meghatározott könyvtár elérésére (a külső tároló egy partíció a rendszeren kívül, és magában foglalja a telefon tárolóit és egy SD-kártyát vagy más csatolt tárolóeszközt) anélkül, hogy engedély a teljes kötethez, vagy egy felbukkanó ablak használata mappák engedélyének kéréséhez.

Fontos a tárolt adatok biztonságos elérése. Az alkalmazásnak, amelyhez csak a Zene vagy a Képek tárolómappájához kell hozzáférni, nem szabad más dolgot látnia, és a kód írása a meglévő Storage Access Framework használatához a dolgok szűkítésére bebizonyította, hogy sok fejlesztő megtagadja. az új Scoped Directory Access API megkönnyíti a fejlesztők számára a biztonságos és az adatok védelmét szolgáló alkalmazásokat.

Ezek a kulcsfontosságú biztonsági szolgáltatások az Android N nagy részét képezik. Bár egyes telefonok (különösen azok, amelyeket nem szállítunk a Nougat készülékkel) nem feltétlenül használják mindegyiket, mindegyikük helyes használat esetén segíti az adatok védelmét. Az Android már érett, és a Google részletekkel való figyelme a 7.0-as verziójával nem feltétlenül olyan mutatós, mint az új hangulatjelek vagy az új színséma, de ez sokkal fontosabb.