Mi az a teljes lemez titkosítás az android nyalókaben?

Nagyon sok információ található az Android 5.0 Lollipop "alapértelmezett" teljes lemez titkosításáról (FDE). Néhányan ezek jó információk, mások rossz információk, és sokuk csak a spekuláció ismétlődő részei. Noha ez jó beszélgetést tesz szükségessé - és az FDE- ről érdemes beszélni -, a finomabb pontokat egy könnyen olvasható beszélgetésbe akartuk bontani.

Ez nem azt jelenti, hogy az legyen a végső dokumentum az Android titkosításban. A Google ezt már közzétette. Megoldjuk a fogyasztóközpontú kérdéseket, amelyeket hallunk. Mint mindig, használja a megjegyzéseket a beszélgetéshez, hogy mindannyian megtanuljunk valamit.

Mi a titkosítás?

A titkosítás az adatok titkosítási kulcs segítségével történő védelme. Gondolj egy jelszóra mint kulcsra, és a titkosítás nagyon biztonságos zár. Szüksége van a kulcsra, hogy bejusson valamihez. És bár be lehet lépni a megfelelő kulcs nélkül, ez nem túl valószínű. (Igen, minden titkosítási rendszert - legalábbis elméletileg - legyőzhetnek a betegek és a ravasz emberek).

Androidjainkon az eszköz összes felhasználói adata (az Android 3.0 óta) titkosítható. Az adatokat menet közben rejtjelezzük, még mielőtt lemezen írnánk. Az adatok visszafejtése megtörténik, mielõtt visszajutnak minden olyan programhoz, amely azt kéri. Csak a helyes kulcsra van szüksége, amely jelszó alapú, az eszköz fő jelszavával.

Változások a nyalókában

Míg az FDE az Android 3.x méhsejt óta elérhető az Androidon, az Android 5.0 nagyon nagy változtatásokat és fejlesztéseket hozott az egész működésében.

A Lollipop-ban az FDE-t egy kerneljellemzővel hajtják végre, amely közvetlenül a tároló blokkrétegére hat. Ez azt jelenti, hogy a titkosítás olyan flash eszközökön is működhet, mint például az eMMC tároló - amelyeknek nincsenek natív titkosítási tulajdonságai -, mivel szabványos blokk eszközként jelennek meg a kernelben. A titkosítás nem lehetséges azokkal a fájlrendszerekkel, amelyek közvetlenül beszélnek a tárolóval (például a YAFFS). Lehet, hogy azok, akik elkészítették a telefonját vagy táblagépét, beépítettek egy módszert a külső tárolás titkosítására (például az SD-kártya), de az Android AOSP elsősorban a belső tárolással foglalkozik. Az alkalmazott algoritmus 128 bites AES CBC-vel és titkosított só-szektor inicializáló vektorral, az SHA256 hash függvény felhasználásával. A fő kulcs az OpenSSL könyvtár hívásait is használja.

Más szavakkal, átkozottul biztonságos.

Az Android első indításakor az eszköz véletlenszerűen létrehoz egy 128 bites fő kulcsot, majd kivonja és tárolja a rejtjelezés metaadataiban. Ezeket az adatokat a felhasználó jelszava nyitja meg. (És ne feledje, emberek, ne használjon gyenge jelszavakat.) Az eredményül kapott kivonatot hardver támogatással is aláírják, például a TEE-alapú (ez a Megbízható végrehajtási környezet) szolgáltatásokkal, mint például a TrustZone. Az Android 5.0 előtt a főkulcsot csak a felhasználói jelszó alapján titkosították, amely az ADB révén veszélyeztethető lehet az off-box támadásokkal szemben.

Érdekes, hogy a Google nem használja a Qualcomm hardver kriptográfiai motorját az AOSP-ben vagy a Nexus 6-ban. Ez nem hatékony, mivel kényszeríti a CPU-alapú titkosítást és visszafejtést a lemez I / O során (valószínűleg minden 512 bájt intervallumon), szemben a Qualcomm hardver-alapú használatával. teljesítmény jellemzők. Nem fogjuk másodszor kitalálni, miért történik ez, de tudjuk, hogy az eredeti gyártók szabadon alkalmazhatják azt, ahogy akarják. Reméljük, hogy meg is fogják.

A Google sokat tett azért, hogy biztonságos legyen a teljes lemezes titkosítás az Android rendszeren. Összességében nagyon jó munkát végeztek.

Teljesítménybeli problémák

Valószínűleg hallott már a lemezolvasás és -írás gyenge teljesítményéről a Nexus eszközökön, amelyek engedélyezve vannak a titkosításhoz. Igaz - amikor titkosítani és visszafejteni kell repüléssel, akkor a lemez I / O sebessége szenvedni fog. Mint fentebb említettük, a Google nem használja a Qualcomm hardver alapú kerneljellemzőit a Nexus 6-on, ami még ennél is jobban szenved. De milyen rossz ez?

A Lollipop lemez I / O többször gyorsabb, mint a KitKat és az Android korábbi verziói esetében. A szoftver optimalizálása és az eszközspecifikus kód azt jelenti, hogy az Android gyorsabban képes olvasni és írni a tárolóból, mint valaha. Ez egy nagyon jó dolog, amelyet a titkosítás miatt leginkább a lassabb I / O idők tagadnak meg.

Ha FDE-t kell használnia (vagy arra kényszeríti, hogy új Nexust vásárolt, és nem akarja telepíteni az egyedi firmware-t), akkor a teljesítménye továbbra is jobb lesz (papíron), mint a KitKat esetében. Csak nem lesz olyan jó, mint titkosítás nélkül. A valós világban a legtöbb felhasználó, akivel beszélgettünk, nem észlel semmilyen eszköz-késleltetést a lassú I / O miatt. Lehet, hogy más a tapasztalatod.

Ha FDE-t akar vagy szeretne, akkor a kompromisszum valószínűleg megéri.

A titkosítás nem kötelező (és egyébként is szüksége van rá?)

Bárki, akinek van telefonja, amely már rendelkezik a Lollipop frissítéssel, elmondhatja, hogy a Lollipop nem kényszeríti titkosításra. Míg a Nexus 6 és a Nexus 9 (és esetleg az összes jövőbeli Nexus készülék) engedélyezve van, és nem könnyű kikapcsolni, a Lollipopra frissített telefonok - mint például a Galaxy Note 4 - automatikusan nem engedélyezik a teljes lemez titkosítást.

Ugyanez vonatkozik azokra az új eszközökre, amelyeket az Android 5.x-rel szállítanak, például az LG G Flex 2-hez. A lehetőség ott van, ha engedélyezni szeretné, de alapértelmezés szerint a teljes titkosítás ki van kapcsolva. Ez választáshoz vezet bennünket - szükség van-e teljes lemez titkosításra?

Sokan hasznosnak találják a teljes lemezes titkosítást. Ha olyan érzékeny információkkal rendelkezik, amelyekkel soha nem akar a telefon rossz kezébe kerülni, az FDE egy áldás. Ahhoz, hogy valaki bejuthasson az Ön adataiba, tudnia kell az eszköz jelszavát. A vezeték fölé nem halad az adat, és ha erõs jelszót használt, akkor az adatai biztonságosak, mivel maroknyi rossz kitalálás után minden megy a zárolásba.

Másoknak elegendő a szokásos képernyővédelem. Ha elveszítünk egy telefonunkat, távolról törölhetjük azt az Android Device Manager vagy más segédprogram segítségével, és ha valaki képes offline állapotba lépni, mielőtt megtisztíthatnánk, akkor szerencsére megkerüljük a zárolási képernyő jelszavunkat (ez megtörténhet), mindegyiket get néhány kép és a Google-fiókhoz való hozzáférés, amelyen gyorsan megváltoztathatjuk a jelszót.

Az egész kormány szomorúsággal foglalkozó kérdése is gondolkodni kell. Noha többségünknek nincs oka attól, hogy semmilyen következményt ne féljen attól, amit telefonunkban tároltunk, mégis megérdemeljük a magánélet és a személyes adatok védelmét. A teljes lemeztitkosítás közelebb hoz minket az adatok biztonságának megőrzéséhez a kormányhivataloktól, akik azt gondolják, hogy látniuk kell őket.

Csak akkor tudja, ha szüksége van-e teljes eszköz-titkosításra.