Diskkryptering: det goda och det långsamma

click fraud protection

Lär dig mer om införandet av full diskkryptering på Android-enheter, var det lyckades och var det misslyckades!

I en värld där personlig information finns inte så personligt, hela bankkonton är kopplade till våra smartphones, och övervakning och cyberbrottslighet är på den högsta nivån någonsin, säkerhet är en av de flesta aspekterna av tekniksfären.

Enkla skärmlås i form av PIN-koder och mönster har funnits länge, men först nyligen, med lanseringen av Android Honeycomb, gjorde full diskkryptering ett framträdande på Android. Kryptering och dekryptering av användardata i farten, d.v.s. under läs- och skrivoperationer, ökade enhetens säkerhet avsevärt, baserat på en enhetshuvudnyckel.

Före Android Lollipop baserades den tidigare nämnda huvudnyckeln enbart på användarens lösenord, vilket öppnade upp för en mängd sårbarheter genom externa verktyg som ADB. Lollipop utför dock fullständig diskkryptering på kärnnivån, med en 128-bitars AES-nyckel som genererades först boot, som fungerar tillsammans med hårdvarustödd autentisering som TrustZone, och befriar den från ADB sårbarhet.

Hårdvara vs mjukvarukryptering

Diskkryptering kan göras på två olika nivåer, nämligen på mjukvarunivå eller på hårdvarunivå. Programvarukryptering använder CPU: n för att kryptera och dekryptera data, antingen med en slumpmässig nyckel som låses upp av användarens lösenord, eller genom att använda själva lösenordet för att autentisera operationer. Å andra sidan använder hårdvarukryptering en dedikerad bearbetningsmodul för att generera krypteringsnyckeln, avlastar CPU-belastningen och håller de kritiska nycklarna och säkerhetsparametrarna säkrare från brute force och kallstart attacker.

Trots nyare Qualcomm SoCs som stöder hårdvarukryptering, valde Google CPU-baserad kryptering på Android, vilket tvingar fram data kryptering och dekryptering under disk I/O, som upptar ett antal CPU-cykler, med enhetens prestanda som får en allvarlig träff som en resultat. Med Lollipops obligatoriska fulldiskkryptering var Nexus 6 den första enheten som fick bära bördan av denna typ av kryptering. Kort efter lanseringen visade många riktmärken resultat av en vanlig Nexus 6 kontra en Nexus 6 med kryptering avstängd med modifierade startbilder, och resultaten var inte snygga, visar den krypterade enheten mycket långsammare än den andra. I skarp kontrast har Apple-enheter stödt hårdvarukryptering sedan iPhone 3GS, med iPhone 5S fortsätter att stödja hårdvaruacceleration för AES- och SHA1-kryptering med stöd av dess 64-bitars armv8 A7 chipset.

Kryptering och Nexus-sortimentet

Förra årets Motorola Nexus 6 var den första Nexus-enheten som tvingade fram mjukvarukryptering på användare, och påverkan det hade på lagringsläs-/skrivoperationer - vilket gjorde dem extremt tröga - var omfattande kritiserats. Men i en Reddit AMA strax efter lanseringen av Nexus 5X och Nexus 6P, uttalade Googles VP of Engineering, Dave Burke, att även denna gång var krypteringen mjukvarubaserad, med hänvisning till 64-bitars armv8 SoCs samtidigt som den lovade resultat snabbare än hårdvara kryptering. Tyvärr, a recension av AnandTech visade att trots en betydande förbättring jämfört med Nexus 6 klarade sig Nexus 5X cirka 30 % sämre än LG G4 i en direkt jämförelse, trots ett liknande specifikationsblad och användningen av eMMC 5.0 på båda enheter.

Inverkan på användarupplevelsen

Trots att Nexus 6, och till synes Nexus 5X, lider av disk I/O-problem på grund av kryptering, kom mjukvaruoptimeringarna i Lollipop i prestandaavdelningen, som gjorde Nexus 6 på Lollipop med full diskkryptering utan tvekan snabbare än en teoretisk Nexus 6 som kördes KitKat. Slutanvändare med örnöga kan dock ibland märka en lätt stamning när de öppnar diskintensiva appar som galleriet eller när de streamar lokalt 2K- eller 4K-innehåll. Å andra sidan säkrar kryptering avsevärt dina personuppgifter och skyddar dig från program som statlig övervakning, med den lilla stamningen som den enda avvägningen, så om det är något du kan leva med, är kryptering definitivt sättet att gå.

OEM och kryptering

Trots att enhetskryptering är en övergripande välvillig mekanism för slutanvändare, ser vissa OEM-tillverkare sporadiskt på det i ett mindre gynnsamt ljus, den mest ökända bland dem är Samsung. Den sydkoreanska OEM: s Gear S2 smartwatch och dess mobila betalningslösning, Samsung Pay, är inkompatibla med krypterade Samsung-enheter... med den förra vägrar att arbeta och den sistnämnda hindrar användare från att lägga till kort, informera användarna om att fullständig enhetsdekryptering krävs för att de ska fungera. Med tanke på att kryptering ökar enhetens säkerhetsmanifold, är det en blockering av användare från att lägga till kort till synes bisarrt drag, där säkerhet är en viktig avgörande faktor vid införandet av mobil betalning lösningar.

Behövs det verkligen?

För de flesta användare, särskilt gruppen exklusive avancerade användare, är kryptering något som de sannolikt inte kommer att stöta på, än mindre möjliggöra villigt. FDE säkrar verkligen enhetsdata och skyddar dem från övervakningsprogram, om än med en liten prestandaavvägning. Medan Android Device Manager gör ett anständigt jobb med att torka data på enheter som har hamnat i fel händer, tar kryptering säkerheten barriär ett steg framåt, så om prestandakompromissen är en du är villig att ta, håller FDE utan tvekan dina data borta från fel händer.

Vad tycker du om enhetskryptering? Tycker du att Google bör gå vägen för hårdvarukryptering? Har du kryptering på, och i så fall, har du några prestandaproblem? Dela dina tankar i kommentarsfältet nedan!