Beveiligingsonderzoeker kraakt disk-encryptie op Android

Een beveiligingsonderzoeker heeft ontdekt hoe full disk encryption op het Android-besturingssysteem is te omzeilen. Door twee gaten in de beveiliging van Qualcomms TrustZone-implementatie kunnen versleutelde bestanden op de schijf worden achterhaald.

De exploit is bedacht en gepubliceerd door Gal Beniamini, die op zijn blog uitlegde hoe hij tot zijn vondst is gekomen. Volgens de beveiligingsonderzoeker kan er gebruik gemaakt worden van twee kwetsbaarheden in TrustZone, het door ARM ontwikkelde hardwarematige beveiligingssysteem dat onder andere in Qualcomm-chips wordt gebruikt. De bugs hebben de nummers CVE-2015-6639 en CVE-2016-2431 gekregen, maar zijn inmiddels al wel gepatcht door Google in updates die in januari en mei uitkwamen. Daardoor is niet duidelijk hoeveel Android-gebruikers nog vatbaar zijn voor de bugs.

Beniamini ontdekte dat het mogelijk is om de encryptiesleutels te achterhalen, door toegang te krijgen tot de zogenaamde Qualcomm Secure Execution Environment. Binnen deze omgeving kunnen bepaalde applicaties worden gedraaid, los van het Android-besturingssysteem zelf. Een van die apps is Keymaster, waarmee onder andere sleutels voor de disk-encryptie voor Android worden beheerd. Het is mogelijk de opgeslagen sleutels te extraheren uit TrustZone, om ze vervolgens te gebruiken om de encryptie te omzeilen.

Er is echter wel fysieke toegang nodig tot het apparaat om de sleutels uit TrustZone te halen; met slechts malware lukt het kwaadwillenden niet om de beveiliging te omzeilen. Er moet namelijk een image worden geflasht om TrustZone om de tuin te leiden. De methode is daarom vooral geschikt voor overheidsinstanties die in beslag genomen smartphones van verdachten willen kraken.

Om toegang te krijgen tot het bestandssysteem moet echter nog wel met een brute force-aanval het wachtwoord of de pin van de gebruiker worden achterhaald. Normaal gesproken werkt slechts het achterhalen van het wachtwoord niet, omdat deze in combinatie met de encryptiesleutel wordt gebruikt om de beveiliging in stand te houden. Ook na het achterhalen van de encryptiesleutel is het mogelijk dat gebruikers nog goed beschermd zijn; wie een lang en complex wachtwoord kiest is minder vatbaar voor een brute force-aanval.

Qualcomm is op de hoogte van de problemen met de implementatie van TrustZone, maar een snelle oplossing voor de kwetsbaarheden lijkt er niet te komen. Er zouden namelijk mogelijk hardwarewijzigingen voor nodig zijn, zo stelt Beniamini. Google introduceerde versleuteling van het bestandssysteem bij Android 5.0. Vanaf versie 6.0 stelde Google schijfversleuteling verplicht voor een deel van de Android-apparaten.

Door de beveilingsproblemen zijn gebruikers met een versleuteld bestandssysteem alsnog vatbaar voor het stelen van gegevens. Dat geldt dan wel alleen voor apparaten die zijn gebouwd op basis van een Qualcomm-soc, en dus draaien op een Android-versie die niet beschikt over de laatste beveiligingspatches. Overigens stelt Beniamini dat mogelijk ook andere chipmakers een kwetsbare implementatie van TrustZone hebben, maar dit is nog niet onderzocht.

Reacties (72)

[jeroen7s]

wel relevant om te melden dat dit een bug is in Quallcomm trustzone, niet in android, als je een andere processor dan een Quallcomm hebt hoef je je dus ook geen zorgen te maken. je kan makkelijk stellen dat het een bug in android is, want dan krijg je meer clicks

[BikkelZ]

Het is wel degelijk een samenspel tussen onveilige hardware en onveilige software. Voor de consument die een telefoon koopt maakt het niets uit of het aan Henkie of aan Pietje of een beetje aan allebei ligt, er staat gewoon Samsung of Huawei op die telefoon en die zijn net zo verantwoordelijk voor de software als Apple dat is. Je bent tenslotte niet verplicht om Android te installeren op die telefoons en als je voor Android kiest dan weet je dat je vaker updates moet uitbrengen om de consumenten die jouw telefoon gekocht hebben te beschermen.

Ook het feit dat full disk encryption de reputatie heeft vaker een telefoon onbruikbaar te maken en het ook lang niet altijd standaard aan staat werkt niet mee aan het wat minder stabiele en veilige imago van het Android ecosysteem. De meeste Apple gebruikers weten niet een dat die beveiliging er op zit, laat staan dat het ooit problemen geeft. De gemiddelde consument wil pas weten of gegevens veilig is nadat het kalf verdronken is.

[sharkwouter]

Deze bug is dus ook aanwezig op iPhones?

[Ducksy88]

Als je een iPhone met Quallcom SoC hebt wel.

Maar die bestaan, zover Ducksy weet, niet.

[DJFliX]

En Windows Phone dan? Lijkt me dat er daar ook gebruik wordt gemaakt van Quallcom TrustZone voor encryption?

[johnkeates]

Tsja, dit is een beetje het probleem met keys-on-device. Je moet dan vertrouwen op een secure element zoals Apple met hun SoC gemaakt heeft, of de Yubikey gebruikt voor z'n crypto. EMV chips hebben ook een secure element, net als SIM kaarten. Nagenoeg alle smartcards hebben ook zo'n onderdeel binnen het ontwerp, om dat je 'ergens' moet beginnen met het opslaan van sleutels. Voor PC's is daar weer een TPM voor verzonnen, maar in principe doen ze allemaal hetzelfde: een speciaal en 'moeilijk' toegankelijk afgeschermd stukje op de chip waar je alleen met de juiste communicatie van buiten af wat mee kan doen. Als het daar fout gaat en de software op de integriteit van zo'n onderdeel binnen een systeem leunt gaat het natuurlijk niet werken.

Een alternatief is om geen sleutels te bewaren, maar dan moet iedereen weer een ellendig lang wachtwoord onthouden wat dan met een PBKDF achtige constructie tot langere veilige key uitgewerkt kan worden, maar ook dat kent z'n beperkingen. Je kan het bruteforcen lastiger maken door crypto te gebruiken die je niet zo makkelijk kan versnellen, zoals scrypt, maar dat is het dan ook wel.

[Aegir81]

Het probleem zit hem blijkbaar in het feit dat in Android de sleutel in de software bewaard wordt, in iOS wordt dit niet gedaan en zit de sleutel in de hardware.

Een schatting van Duo Security zegt dat 37% van de toestellen nog niet gepatcht is.

Ook is het mogelijk om op geroote toestellen een oudere Androidversie te zetten die nog niet gepatcht is en zo de gegevens achterhalen. En net omdat de sleutel in de software zit blijft het in de toekomst via andere (momenteel onbekende) gaten mogelijk de encryptie te omzeilen.

Edit: meer achtergrondinfo via Ars Technica: http://arstechnica.com/se...ot-much-weaker-heres-why/

[Reactie gewijzigd door Aegir81 op 23 juli 2024 14:12]

[Thralas]

Het probleem zit hem blijkbaar in het feit dat in Android de sleutel in de software bewaard wordt, in iOS wordt dit niet gedaan en zit de sleutel in de hardware.

Een zeer belangrijk detail is dat 'de sleutel' een derivation key is welke wordt gebruikt om de daadwerkelijke FDE-sleutel af te leiden op basis van het gebruikerswachtwoord.

Het nieuwsartikel van Tweakers is wat vaag, en suggereert m.i. zelfs dat FDE op Android helemaal niets meer waard is. Dat is niet waar. Wat de onderzoeker beschijft is een manier om de KeyMaster-sleutels te lekken, waardoor je de KDF op snellere hardware ('offline') kunt uitvoeren. Bijvoorbeeld om een dictionary attack op het FDE-wachtwoord uit te voeren. Dat was nooit de bedoeling, en daarmee is de (KeyMaster-backed) FDE-implementatie 'gebroken'.

In de praktijk is er nog een zeer belangrijk detail waardoor de impact van deze bevindingen niet zo dramatisch is als het lijkt:

Om de KeyMaster keys te extraheren heb je code-executie op het apparaat nodig.

Een 'up-to-date' Androidtelefoon geeft je geen mogelijkheid om willekeurige 'images' te booten om deze sleutels te dumpen. Je zult dus een bootom- of bootloaderexploit moeten hebben (of medewerking van de fabrikant) om de sleutels uberhaupt te kunnen achterhalen.

Een tweede optie is code-executie terwijl het apparaat aanstaat (maar gelocked is met unlocked FDE). Hier schiet je niets op met de KM keys, want als je code kunt uitvoeren (als root) kun je ook direct de hele (onversleutelde) disk dumpen of de daadwerkelijke FDE-sleutel uitlezen (zonder het wachtwoord te hoeven kraken).

Het meest kwalijke is misschien nog wel dat Android (out of the box) nog steeds geen afwijkende lockscreen en FDE-wachtwoord ondersteunt. Dat maakt dat, als je de KM keys van een FDE-locked device weet te achterhalen, bruteforcen van het wachtwoord relatief gemakkelijk is omdat een complex lockscreenwachtwoord een usabilitynightmare is.

[Verwijderd]

Lang leve vingerafdrukscanners. Daarmee moet het secuur te maken zijn en zeer gebruiksvriendelijk.

[Blokker_1999]

Een wachtwoord kan je veranderen, probeer dat maar eens met je vingerafdruk. En terwijl je een wachtwoord zeer veilig kan opslaan laten we elke dag overal onze vingerafdrukken achter. Al helemaal op het toestel dat jij ermee wenst te beveiligen ... . De vingerafdruk bied schijnveiligheid. Is alleen handig om snelle toegang te voorkomen.

[Verwijderd]

Ja ok, daar heb je gelijk in hoor.
Voor het doel van een telefoon lijkt me het goed genoeg als de data op afstand gewist kan worden.
Maar, na een reboot is het feest sowieso over; dan treedt je wachtwoord eerst weer in werking.
[edit]
Je zou ook kunnen denken aan iets zoals, 10 attempts verkeerd, alles wissen,

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:12]

[daanb14]

Is een irisscanner dan niet veel veiliger wanneer deze scan hardwarematig wordt opgeslagen?

[MenN]

Nee, biometrische beveiliging is nooit een goed idee. Er hoeft maar 1 lek te zijn, en vervolgens ben je voor altijd kwetsbaar omdat je niet weet wat er met die data gebeurt. Met een wachtwoord is het alleen even veranderen en dan ben je safe.

[lappro]

Maar dat biedt geen bescherming meer tegen de overheid.
Voor zover ik weet valt het afgeven van vingerafdrukken niet onder het bijdragen aan je eigen veroordeling.

[Verwijderd]

Je bedoelt iris scanners de note 7 zal hopelijk een vaart schoppen in de iris scan business .. ( zie nieuws van paar dagen terug)

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:12]

[MacD]

En dat omzeil je net zo makkelijk als de 'face unlock': gewoon een plaatje/video voor de camera houden.

[Baseballnuts]

Vaak moet je knipperen waardoor dat niet zo maar werkt bij face unlock. Bij een iris scanner kan de scanner nog wel eens gefopt worden met een foto van hoge kwaliteit, maar daar kom je niet zo makkelijk aan.

[jeroen71974]

De lumias lijken een retina scanner te hebben en geen iris scanner. Je kan deze ook unlocken met je zonnebril op, dus dan ziet het systeem je iris niet eens.

Een foto gaat dus niet helpen, want daarop zie je het netvlies niet.

[Rutix]

Dat werkt niet bij mijn Lumia die ook irisscan heeft. Een video heb ik nog niet geprobeerd maar een plaatje pakt die niet.

[Verwijderd]

Je bent in de war met een simpele oogscan... een echte irisscan aka retinascan is zeker meer secure dan dat jij denkt

[Wim-Bart]

Lang leve vingerafdrukscanners. Daarmee moet het secuur te maken zijn en zeer gebruiksvriendelijk.

Voor overheidsinstanties zijn vingerafdruk unlocks ideaal. Ze hebben heel graag dat iedere foon is te unlocken met een vingerscanner of irisscan.

Reden: Dit is te faken met nemen van een afdruk van je vinger(s) eventueel met verdoving Een wachtwoord of pincode is veel veiliger want daar hebben ze medewerking voor nodig, voor scan hebben ze de medewerking niet nodig.

[Verwijderd]

Te maken zijn, niet zijn.
Een goede implementatie is niet moeilijk. Dat je hem kan wissen met open bootloader is algemeen bekend. Maar sensitive data is er echt niet (binnen een paar jaar) af te krijgen, zonder supercomputers...

[Verwijderd]

Je kan vrij makkelijk gedwongen worden, je vinger afdruk te geven. Daarnaast zit de vingerafdruk tegenwoordig gekoppeld aan je paspoort. De overheid en hun vrienden hebben hem dus sowieso al.

[Verwijderd]

Dat klopt als je je legitimatie in een bepaald jaar (2011?) hebt vernieuwd.
Daarna is dat toch weer afgeschaft?

[Verwijderd]

Nee, geld nog steeds, of ik heb heel toevallig 2x afdrukken moeten afgeven.
https://www.rijksoverheid...-paspoort-vingerafdrukken

[Verwijderd]

Sorry, ik had het over enkel de identiteitskaart.
Mensen zonder paspoort kunnen dus soms nog onbekend zijn qua vingerafdruk

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:12]

[Verwijderd]

Ja, al is het praktisch onmogelijk je vinger afdrukken privé te houden, wanneer iemand ze echt wil hebben.

[Aikon]

Door twee gaten in de beveiliging van Qualcomms TrustZone-implementatie

i.c.m.

TrustZone is hardware based security built into SoCs

i.c.m.

een snelle oplossing voor de kwetsbaarheden lijkt er niet te komen. Er zouden namelijk mogelijk hardwarewijzigingen voor nodig zijn

Lijkt mij eerder te duidelijk op een hardware-probleem. Ik weet niet waar jij je conclusie op baseert?

[Aegir81]

De laatste zin kun je ook interpreteren als dat er een hardwarewijziging voor nodig is om een encryptie zoals bijv. die van Apple te implementeren omdat die er nu nog niet is.

Ik ben geen expert maar de encryptie kan gebeuren via de hardware maar de sleutel wordt bewaard in de software. En net daar zit het beveiligingsprobleem.

[Aikon]

Nee, niet echt, die laatste zin spreekt van een oplossing en niet van een nieuw type beveiliging implementeren.

De keys worden niet binnen Android opgeslagen als je dat denkt, maar binnen QSEE, een apart OS'je wat naast Android leeft zogezegd. Iets in hardware opslaan is leuk (en in feite ook de enige manier maar goed), maar er zal toch software voor nodig zijn om het uit te lezen. Ook bij Apple.

[xoniq]

Kan toch ook gaan om een oplossing van een goede encryptie methode?

[blorf]

Volgens mij het gevolg van hardware-architectuur die ontworpen is tegen specifieke software. Dat slaat in het beginsel nergens op.
Imho een politiek spelletje waar de eindgebruiker die daar volledig buiten staat de dupe van is: de strijd om het baas zijn over het systeem.

[aaahaaap]

Ook is het mogelijk om op geroote toestellen een oudere Androidversie te zetten die nog niet gepatcht is en zo de gegevens achterhalen. En net omdat de sleutel in de software zit blijft het in de toekomst via andere (momenteel onbekende) gaten mogelijk de encryptie te omzeilen.

Alles waarvan de sources niet in te zien zijn, iets dat bij een hardwarematige implementatie bijna altijd het geval is, is sowieso niet te vertrouwen.

Nog los van het feit dat eigen implementaties van encryptie in de regel matig/slecht/onnodig zijn t.o.v. bestaande (open) standaarden.

[Reactie gewijzigd door aaahaaap op 23 juli 2024 14:12]

[Verwijderd]

Dit vond ik wel een belangrijke conclusie:

OEMs can comply with law enforcement to break Full Disk Encryption. Since the key is available to TrustZone, OEMs could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device. This would allow law enforcement to easily brute-force the FDE password off the device using the leaked keys.

Een Android device is dus NIET te vertrouwen als je er belangrijke data op hebt staan!

Op z'n minst moet je een sterk wachtwoord gebruiken in plaats van een PIN of vingerafdruk.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:12]

[Rutix]

Geen enkel telefoon is te vertrouwen als je doel is om data te verbergen voor de regering. Android niet, Apple niet en ook Microsoft niet.

[Eli3l]

De titel van het artikel gaf me een beetje hoop, hoop dat ik nu eindelijk mijn sd-kaartje kan decrypten. Helaas, mijn sd-kaart zal nooit meer het genot van verse data ervaren na in aanraking geweest te zijn met Android encryptie

En nee formateren van een met Android full disk encryption beveiligde sd-kaart gaat helaas niet.

[Heedless]

Zeker weten? Dit al getest?

http://www.ehow.com/how_1...crypted-microsd-card.html

[renedis]

"Qualcomm is op de hoogte van de problemen met de implementatie van TrustZone, maar een snelle oplossing voor de kwetsbaarheden lijkt er niet te komen. Er zouden namelijk mogelijk hardwarewijzigingen voor nodig zijn, zo stelt Beniamini."

Dit is geen goede zaak voor Qualcomm. Het is echter ook een lastige positie nu voor hen gezien het in de hardware zit. Daarnaast is het in mijn ogen ook niet echt een wijze uitspraak om te doen dat er voorlopig niets aan opgelost gaat worden. Vertel dan desnoods dat je alleen voor toekomstige hardware dit gaat oppakken.

[swhnld]

Ik denk dat de titel vanhet stuk fout is, het gaat om Qualcom Encryptie. Toevallig in combinatie met Android ontdekt maar deze Qualcom SoC's zitten in meer apparaten, zoals Windows Mobile toestellen.

[Verwijderd]

Windows Mobile is enkel supported voor Qualcomm. Geen enkele andere merk SoC draait Windows mobile.

[SSDtje]

Ben ik blij dat ik geen "disk" in mijn tel heb zitten

Anyhow, goed dat dit bovenwater is gekomen, voordat het wordt misbruikt (al kan het al wel misbruikt zijn geweest natuurlijk)
En dat het is bovendien niet alleen een software matig fout blijkt te zijn maar tevens hardware matig.
Er is dus weer werk aan de winkel

[Reactie gewijzigd door SSDtje op 23 juli 2024 14:12]

[Hadespuiter]

Ik probeerde onlangs een S5 met CM13 te encrypten, toestel startte daarna niet meer op. Moest opnieuw geformatteerd worden.
De functie rammelt dus sowieso aan alle kanten.

[Freedox]

Hij MOET formatteren om te encrypten. Geduld hebben dus. Kan natuurlijk ook een bug in CM zijn.

[Reactie gewijzigd door Freedox op 23 juli 2024 14:12]

[Hadespuiter]

Het toestel heb ik een nacht lang laten liggen, maar bleef op het CM13 bootlogo hangen.
Heb vervolgens handmatig moeten formatteren en alles opnieuw moeten installeren (had helaas geen backup).

[Richh]

Is het de functie die rammelt, of CyanogenMod?

[jlaarts]

Ik zou het niet weten, maar ik heb al maanden een HTC One M8 dual sim versleuteld onder Cyanogenmod 13. Dit heeft nog nooit een probleem opgeleverd (en aangezien ik er iedere keer verse nightlies op zet, zou ik daar wel gemakkelijk last van kunnen krijgen).

[doom71]

Op mijn OPT met de laatste versie OxygenOS 3.0.2 geen problemen mee. Het is niet de functie die buggy is, maar een combi van de door jou gebruikte recovery en OS. Vergeet niet: CM is ook maar een OS, deze bevat ook bugs.

[Verwijderd]

Lekker dit, meer dan driekwart van de Android-toestellen heeft een chipset van Qualcomm aan boord...
Kan mijn Moto E dus wel wegknikkeren, als ik het zo lees...
Hier heeft de AIVD (itt de FBI) Google niet nodig, hierdoor kan men het gewoon zelf- reken maar dat dit soort bugs zeer waardevol zijn voor dit soort diensten. Dacht je veilig te zijn, door FDE toe te passen, no way dus.

Bedankt he, Qualcomm. _{Stelletje f*cking prutsers.}

[Reactie gewijzigd door Verwijderd op 23 juli 2024 14:12]

[Dr. Prozac]

Wat ik me afvraag, is of hard- en software bedrijven expres "fouten" maken zodat ze in harmonie kunnen leven met zowel de consument ("JE DATA IS VEILIG/PRIVE") als ook met de regering ("_{psst, als je goed zoekt zijn er mogelijkheden om aan de data te komen}").

Ik klink misschien als iemand die een aluhoedje nodig heeft, maar de huidige (en zeker toekomstige) realiteit is denk ik dat zowel de consument veiligheid/privacy eist, maar dat ook regeringen (van machtige landen) een hard- of software maker straffen kunnen opleggen voor het tegenwerken van onderzoek.

Edit:
Ja, foutloze soft- en hardware maken is heel moeilijk (onmogelijk ?), maar het gaat ook om hoe gemotiveerd deze bedrijven zijn om fouten te vinden en te herstellen.

[Reactie gewijzigd door Dr. Prozac op 23 juli 2024 14:12]

[Verwijderd]

Dat vraag ik mij ook geregeld af. Anderzijds is het wel zo, dat er in iedere x-duizend regels code, statistisch genomen een x-honderd bugs zitten (onopzettelijk/te goeder trouw)- de vraag is alleen of het in deze situatie een dergelijke bug betreft, of om een opzettelijke fout gaat.
Als je het artikel leest en het comment van @Thralas, zou ik dit niet direct als een opzettelijke bug beschouwen. Dit laat onverlet dat het wel om een redelijke ernstige ommissie gaat, die imo Qualcomm kam worden aangerekend; het had ook voorkomen kunnen worden, dus heeft men toch niet voldoende nagedacht over de implementatie van FDE imo en dat is kwalijk, half werk.
Zeker gelet op het grote aantal devices en dus de grote impact/footprint, die deze fout achterlaat.

[SSDtje]

Mee eens, alleen is het ook weer zo dat je hardware via software ook op een andere manier kan gebruiken, door het op een andere manier aan te spreken.
Wat dus weer maakt dat het misschien via een software update te patchen is