Lær om bruken av full diskkryptering på Android-enheter, hvor det lyktes og hvor det mislyktes!
I en verden hvor personlig informasjon er ikke så personlig, hele bankkontoer er knyttet til smarttelefonene våre, og overvåking og nettkriminalitet er på det høyeste, sikkerhet er en av de fleste aspektene ved teknologisfæren.
Enkle skjermlåser i form av PIN-koder og mønstre har eksistert i lang tid, men først nylig, med lanseringen av Android Honeycomb, dukket full diskkryptering opp på Android. Kryptering og dekryptering av brukerdata underveis, dvs. under lese- og skriveoperasjoner, økte enhetens sikkerhet betraktelig, basert på en enhetshovednøkkel.
Før Android Lollipop var den nevnte hovednøkkelen kun basert på brukerens passord, og åpnet den for en rekke sårbarheter gjennom eksterne verktøy som ADB. Imidlertid utfører Lollipop full diskkryptering på kjernenivå, ved å bruke en 128-bit AES-nøkkel generert først oppstart, som fungerer sammen med maskinvarestøttet autentisering som TrustZone, og slipper den fra ADB sårbarhet.
Maskinvare vs programvarekryptering
Diskkryptering kan gjøres på to forskjellige nivåer, nemlig på programvarenivå eller på maskinvarenivå. Programvarekryptering bruker CPU til å kryptere og dekryptere data, enten ved å bruke en tilfeldig nøkkel låst opp av brukerens passord, eller ved å bruke selve passordet for å autentisere operasjoner. På den annen side bruker maskinvarekryptering en dedikert prosesseringsmodul for å generere krypteringsnøkkelen, avlaste CPU-belastningen og holde de kritiske nøklene og sikkerhetsparameterne tryggere mot brute force og kaldstart angrep.
Til tross for nyere Qualcomm SoC-er som støtter maskinvarekryptering, valgte Google CPU-basert kryptering på Android, som tvinger fram data kryptering og dekryptering under disk I/O, som okkuperer en rekke CPU-sykluser, med enhetsytelsen som får et alvorlig slag som en resultat. Med Lollipops påbudte full diskkryptering, var Nexus 6 den første enheten som ble utsatt for denne typen kryptering. Kort tid etter lanseringen viste en rekke benchmarks resultater fra en vanlig Nexus 6 versus en Nexus 6 med kryptering slått av ved hjelp av modifiserte oppstartsbilder, og resultatene var ikke pene, viser den krypterte enheten langt tregere enn den andre. I skarp kontrast har Apple-enheter støttet maskinvarekryptering siden iPhone 3GS, med iPhone 5S fortsetter å støtte maskinvareakselerasjon for AES- og SHA1-kryptering støttet av 64-biters armv8 A7 brikkesett.
Kryptering og Nexus-serien
Fjorårets Motorola Nexus 6 var den første Nexus-enheten som tvang programvarekryptering på brukere, og innvirkningen det hadde på lagringslese-/skriveoperasjoner - noe som gjorde dem ekstremt trege - var stor kritisert. I en Reddit AMA kort tid etter lanseringen av Nexus 5X og Nexus 6P uttalte imidlertid Googles VP of Engineering, Dave Burke, at også denne gangen var krypteringen programvarebasert, med henvisning til 64-bit armv8 SoCs mens den lovet resultater raskere enn maskinvare kryptering. Dessverre, a anmeldelse av AnandTech viste at til tross for en betydelig forbedring i forhold til Nexus 6, klarte Nexus 5X seg omtrent 30 % dårligere enn LG G4 i en hode-til-hode-sammenligning, til tross for et lignende spesifikasjonsark og bruken av eMMC 5.0 på begge enheter.
Innvirkning på brukeropplevelsen
Til tross for at Nexus 6, og tilsynelatende Nexus 5X, lider av disk I/O-problemer på grunn av kryptering, består programvareoptimaliseringer i Lollipop i ytelsesavdelingen, som gjorde Nexus 6 på Lollipop med full diskkryptering uten tvil raskere enn en teoretisk Nexus 6 som kjører Kit Kat. Imidlertid kan sluttbrukere med ørneøye av og til legge merke til en liten hakking når de åpner diskintensive apper som galleriet, eller når de strømmer lokalt 2K- eller 4K-innhold. På den annen side sikrer kryptering dine personlige data i betydelig grad og beskytter deg mot programmer som statlig overvåking, med en liten stamming som den eneste avveiningen, så hvis det er noe du kan leve med, er kryptering definitivt måten å gå.
OEM og kryptering
Til tross for at enhetskryptering er en overordnet velvillig mekanisme for sluttbrukere, ser noen OEM-er det sporadisk i et mindre gunstig lys, den mest beryktede blant dem er Samsung. Den sørkoreanske OEMs Gear S2 smartklokke og dens mobile betalingsløsning, Samsung Pay, er inkompatible med krypterte Samsung-enheter... med førstnevnte nekter å jobbe og sistnevnte nekter brukere å legge til kort, og informerer brukere om at full enhetsdekryptering er nødvendig for at de skal fungere. Gitt at kryptering øker enhetssikkerhetsmanifolden, er det å blokkere brukere fra å legge til kort tilsynelatende bisarre trekk, med sikkerhet som en viktig avgjørende faktor i bruken av mobilbetaling løsninger.
Er det virkelig nødvendig?
For de fleste brukere, spesielt gruppen unntatt avanserte brukere, er kryptering noe de sannsynligvis ikke vil snuble over, langt mindre aktivere villig. FDE sikrer absolutt enhetsdata og beskytter dem mot overvåkingsprogrammer, om enn med den lille ytelsen. Mens Android Device Manager gjør en anstendig jobb med å tørke data på enheter som har falt i feil hender, tar kryptering sikkerheten barriere ett skritt fremover, så hvis ytelseskompromisset er et du er villig til å ta, holder FDE utvilsomt dataene dine unna feil hender.
Hva synes du om enhetskryptering? Synes du Google bør gå veien for maskinvarekryptering? Har du kryptering på, og i så fall, har du noen ytelsesproblemer? Del dine tanker i kommentarfeltet nedenfor!