Lær om brugen af fuld diskkryptering på Android-enheder, hvor det lykkedes, og hvor det mislykkedes!
I en verden, hvor personlige oplysninger er ikke så personligt, hele bankkonti er knyttet til vores smartphones, og overvågning og cyberkriminalitet er på et rekordhøjt niveau, sikkerhed er et af de fleste aspekter af teknologisfæren.
Simple skærmlåse i form af pinkoder og mønstre har eksisteret i lang tid, men først for nylig, med lanceringen af Android Honeycomb, dukkede fuld diskkryptering op på Android. Kryptering og dekryptering af brugerdata i farten, dvs. under læse- og skriveoperationer, øgede enhedssikkerheden betydeligt, baseret på en enhedshovednøgle.
Før Android Lollipop var den førnævnte hovednøgle kun baseret på brugerens adgangskode, hvilket åbnede op for en række sårbarheder gennem eksterne værktøjer som ADB. Lollipop udfører dog fuld diskkryptering på kerneniveau ved hjælp af en 128bit AES-nøgle, der blev genereret i starten boot, som fungerer sammen med hardware-understøttet autentificering som TrustZone, der befrier den for ADB'en sårbarhed.
Hardware vs softwarekryptering
Diskkryptering kan udføres på to forskellige niveauer, nemlig på softwareniveau eller på hardwareniveau. Softwarekryptering bruger CPU'en til at kryptere og dekryptere data, enten ved hjælp af en tilfældig nøgle, der låses op af brugerens adgangskode, eller ved at bruge selve adgangskoden til at autentificere operationer. På den anden side bruger hardwarekryptering et dedikeret behandlingsmodul til at generere krypteringsnøglen, aflaste CPU-belastningen og holde de kritiske nøgler og sikkerhedsparametre sikrere mod brute force og koldstart angreb.
På trods af nyere Qualcomm SoC'er, der understøtter hardwarekryptering, valgte Google CPU-baseret kryptering på Android, hvilket fremtvinger data kryptering og dekryptering under disk I/O, der optager et antal CPU-cyklusser, og enhedens ydeevne får et alvorligt hit som en resultat. Med Lollipops obligatoriske fuld diskkryptering var Nexus 6 den første enhed, der blev ramt af denne type kryptering. Kort efter lanceringen viste adskillige benchmarks resultater af en almindelig Nexus 6 versus en Nexus 6 med kryptering slået fra ved hjælp af modificerede opstartsbilleder, og resultaterne var ikke pæne, viser den krypterede enhed langt langsommere end den anden. I skarp kontrast har Apple-enheder understøttet hardwarekryptering siden iPhone 3GS, med iPhone 5S fortsætter med at understøtte hardwareacceleration til AES og SHA1-kryptering understøttet af dens 64bit armv8 A7 chipsæt.
Kryptering og Nexus-serien
Sidste års Motorola Nexus 6 var den første Nexus-enhed til at tvinge softwarekryptering på brugere, og den havde stor indflydelse på lagringslæse-/skriveoperationer - hvilket gjorde dem ekstremt træge kritiseret. Men i en Reddit AMA kort efter lanceringen af Nexus 5X og Nexus 6P udtalte Googles VP of Engineering, Dave Burke, at også denne gang var krypteringen softwarebaseret, idet den citerede 64bit armv8 SoC'erne, mens den lovede resultater hurtigere end hardware kryptering. Desværre, a anmeldelse af AnandTech viste, at trods en væsentlig forbedring i forhold til Nexus 6 klarede Nexus 5X sig omkring 30 % dårligere end LG G4 i en direkte sammenligning, på trods af et lignende specifikationsark og brugen af eMMC 5.0 på begge enheder.
Indvirkning på brugeroplevelsen
På trods af Nexus 6 og tilsyneladende Nexus 5X, der lider af disk I/O-problemer på grund af kryptering, består softwareoptimeringer i Lollipop i ydeevneafdelingen, som gjorde Nexus 6 på Lollipop med fuld diskkryptering uden tvivl hurtigere end en teoretisk Nexus 6, der kører KitKat. Slutbrugere med et ørneøje kan dog af og til bemærke en let hakken, når de åbner disktunge apps som galleriet, eller når de streamer lokalt 2K- eller 4K-indhold. På den anden side sikrer kryptering i væsentlig grad dine personlige data og beskytter dig mod programmer som regeringsovervågning, med den lille hakken er den eneste afvejning, så hvis det er noget, du kan leve med, er kryptering helt sikkert vejen til gå.
OEM'er og kryptering
På trods af at enhedskryptering er en overordnet velgørende mekanisme for slutbrugere, ser nogle OEM'er det sporadisk i et mindre end gunstigt lys, hvor den mest berygtede blandt dem er Samsung. Den sydkoreanske OEM's Gear S2 smartwatch og dets mobile betalingsløsning, Samsung Pay, er inkompatible med krypterede Samsung-enheder... med førstnævnte nægter at arbejde og sidstnævnte forhindrer brugere i at tilføje kort, der informerer brugerne om, at fuld enhedsdekryptering er påkrævet for deres funktion. I betragtning af at kryptering øger enhedens sikkerhedsmanifold, er det en blokering af brugere fra at tilføje kort tilsyneladende bizart træk, hvor sikkerhed er en vigtig afgørende faktor i vedtagelsen af mobilbetaling løsninger.
Er det virkelig nødvendigt?
For de fleste brugere, især gruppen eksklusive superbrugere, er kryptering noget, som de sandsynligvis ikke vil støde på, meget mindre aktivere villigt. FDE sikrer bestemt enhedsdata og beskytter dem mod overvågningsprogrammer, dog med en lille afvejning af ydeevnen. Mens Android Device Manager gør et anstændigt stykke arbejde med at slette data på enheder, der er faldet i de forkerte hænder, tager kryptering sikkerheden barriere et skridt fremad, så hvis ydeevnekompromiset er et, du er villig til at tage, holder FDE utvivlsomt dine data ude af det forkerte hænder.
Hvad synes du om enhedskryptering? Synes du, at Google bør gå hardwarekrypteringsvejen? Har du kryptering på, og hvis det er tilfældet, har du problemer med ydeevnen? Del dine tanker i kommentarfeltet nedenfor!