Ismerje meg a teljes lemeztitkosítás alkalmazását Android-eszközökön, hol sikerült, hol kudarcot!
Egy olyan világban, ahol a személyes adatok vannak nem annyira személyes, teljes bankszámlák kapcsolódnak okostelefonjainkhoz, és a megfigyelés és a kiberbűnözés minden idők legmagasabb szintjén áll, a biztonság a technológiai szféra egyik legfontosabb szempontja.
Az egyszerű képernyőzárak PIN-kódok és minták formájában már régóta léteznek, de csak a közelmúltban, az Android Honeycomb elindításával jelent meg a teljes lemeztitkosítás az Androidon. A felhasználói adatok menet közbeni titkosítása és visszafejtése, azaz az olvasási és írási műveletek során jelentősen megnövelte az eszköz biztonságát, az eszköz fő kulcsa alapján.
Az Android Lollipop előtt a fent említett mesterkulcs csak a felhasználó jelszaván alapult, így külső eszközökön, például ADB-n keresztül számos sebezhetőséget nyitott meg. A Lollipop azonban teljes lemeztitkosítást hajt végre a kernel szintjén, először egy 128 bites AES-kulcsot használva. rendszerindítás, amely párhuzamosan működik a hardveres hitelesítéssel, mint például a TrustZone, megszabadítva az ADB-től sebezhetőség.
Hardver vs szoftver titkosítás
A lemeztitkosítás két különböző szinten történhet, nevezetesen szoftver- vagy hardverszinten. A szoftveres titkosítás a CPU-t használja az adatok titkosítására és visszafejtésére, akár véletlenszerű kulcs használatával, amelyet a felhasználó jelszava felold, vagy magát a jelszót használja a műveletek hitelesítésére. Másrészt a hardveres titkosítás egy dedikált feldolgozó modult használ a titkosítási kulcs generálásához, a CPU tehermentesítése és a kritikus kulcsok és biztonsági paraméterek biztonságban tartása a nyers erőtől és a hideg rendszerindítástól támadások.
Annak ellenére, hogy az újabb Qualcomm SoC-k támogatják a hardveres titkosítást, a Google a CPU-alapú titkosítást választotta Androidon, ami kényszeríti az adatokat titkosítás és visszafejtés a lemez I/O során, számos CPU-ciklust lefoglalva, és az eszköz teljesítménye komoly csapást mér. eredmény. A Lollipop kötelező teljes lemeztitkosításával a Nexus 6 volt az első olyan eszköz, amelyre az ilyen típusú titkosítás nehezedett. Röviddel az indulás után számos benchmark mutatott eredményt egy normál Nexus 6 és egy Nexus 6 között, ahol a titkosítást módosított rendszerindító képek segítségével kikapcsolták, és az eredmények nem voltak szépek, amely a titkosított eszközt sokkal lassabban mutatja, mint a másik. Ezzel éles ellentétben az Apple eszközök az iPhone 3GS óta támogatják a hardveres titkosítást az iPhone-nal Az 5S továbbra is támogatja a hardveres gyorsítást az AES és SHA1 titkosításhoz, amelyet a 64 bites armv8 A7 támogatja lapkakészlet.
Titkosítás és a Nexus termékcsalád
A tavalyi Motorola Nexus 6 volt az első Nexus-eszköz, amely szoftveres titkosítást kényszerített a felhasználókra. a tárolási olvasási/írási műveletekre gyakorolt hatása – rendkívül lassúvá téve azokat – széles körben érvényesült kritizálta. A Reddit AMA-ban azonban nem sokkal a Nexus 5X és Nexus 6P megjelenése után a Google mérnöki alelnöke, Dave Burke kijelentette, hogy A titkosítás ezúttal is szoftveres volt, a 64 bites armv8 SoC-kra hivatkozva, miközben a hardvernél gyorsabb eredményeket ígért. Titkosítás. Sajnos a AnandTech véleménye kimutatta, hogy a Nexus 6-hoz képest jelentős javulás ellenére a Nexus 5X körülbelül 30%-kal rosszabbul teljesített, mint az LG G4 egy fej-fej összehasonlításban, annak ellenére, hogy hasonló a specifikáció és az eMMC 5.0 használata mindkettőn eszközöket.
A felhasználói élményre gyakorolt hatás
Annak ellenére, hogy a Nexus 6 és látszólag a Nexus 5X a titkosítás miatti lemez I/O problémákkal küzd, a Lollipop szoftveroptimalizálása a teljesítményosztály, amely a Nexus 6-ot Lollipopon vitathatatlanul gyorsabbá tette teljes lemeztitkosítással, mint egy elméleti Nexus 6-ot. Kit Kat. A sasszemű végfelhasználók azonban időnként enyhe akadozást észlelhetnek a lemezigényes alkalmazások, például a galéria megnyitásakor, vagy a helyi 2K vagy 4K tartalom streamelésekor. Másrészt a titkosítás jelentősen megvédi személyes adatait, és megvédi Önt az olyan programoktól, mint a kormányzati felügyelet, az enyhe dadogás az egyetlen kompromisszum, így ha ez olyasvalami, amivel együtt lehet élni, akkor a titkosítás mindenképpen a megoldás megy.
OEM-ek és titkosítás
Annak ellenére, hogy az eszköztitkosítás mindenekelőtt a végfelhasználók számára jóindulatú mechanizmus, egyes OEM-ek szórványosan kevésbé kedvező fényben látják, köztük a leghírhedtebb a Samsung. A dél-koreai OEM Gear S2 okosórája és mobilfizetési megoldása, a Samsung Pay nem kompatibilis a titkosított Samsung készülékekkel... az előbbivel a munka megtagadása és a ez utóbbi megtiltja a felhasználóknak kártyák hozzáadását, amely tájékoztatja a felhasználókat arról, hogy működésükhöz az eszköz teljes visszafejtésére van szükség. Tekintettel arra, hogy a titkosítás növeli az eszközbiztonsági sokaságot, a felhasználók kártyák hozzáadásának megakadályozása a bizarrnak tűnő lépés, mivel a biztonság a legfontosabb döntő tényező a mobilfizetés elterjedésében megoldásokat.
Valóban szükség van rá?
A legtöbb felhasználó számára, különösen az erős felhasználókat kivéve, a titkosítás olyan dolog, amibe valószínűleg nem botlanak bele, még kevésbé engedélyezik szívesen. Az FDE minden bizonnyal védi az eszközadatokat, és megvédi azokat a felügyeleti programoktól, bár a teljesítmény csekély kompromisszumával. Míg az Android Eszközkezelő tisztességes munkát végez az adatok törlésével a rossz kezekbe került eszközökön, a titkosítás megőrzi a biztonságot. gátat szab egy lépéssel előre, így ha a teljesítménybeli kompromisszumot hajlandó megtenni, az FDE kétségtelenül megóvja adatait a rossztól kezek.
Mi a véleményed az eszköztitkosításról? Ön szerint a Google-nak a hardveres titkosítási utat kellene választania? Be van kapcsolva a titkosítás, és ha igen, van-e teljesítménybeli problémája? Ossza meg gondolatait az alábbi megjegyzések részben!