Nederlandse onderzoekers vinden kwetsbaarheden in hardwarematige encryptie ssd's

Beveiligingsonderzoekers van de Radboud Universiteit van Nijmegen hebben diverse kwetsbaarheden in verschillende self-encrypting-ssd's van Samsung en Crucial aangetroffen. Ze verwachten dat veel meer ssd's kwetsbaar zijn.

De onderzoekers van de Radboud Universiteit van Nijmegen, Carlo Meijer en Bernard van Gastel, kochten verschillende ssd's van Crucial en Samsung om de implementatie van de beveiliging die self-encrypting drives moeten bieden, te onderzoeken. Daarbij extraheerden ze de firmware en kregen ze inzicht in de beveiliging door deze te reverse engineeren.

"De encryptie van ssd's is niet op orde", stelt Bernard van Gastel tegenover Tweakers. Hij en zijn collega ontdekten onder andere dat de cryptografische sleutel bij de onderzochte ssd's niet afhankelijk is van het wachtwoord. "Het wachtwoord voegt niets toe. Als je de beschikking over de ssd hebt, is dat voldoende. We wisten de check eruit te halen zodat elk wachtwoord goedgekeurd werd."

Deze kwetsbaarheid, met aanduiding CVE-2018-12037, deed zich voor bij de Crucial MX100, MX200 en MX300, de externe Samsung T3- en T5-ssd's en de Samsung 840 Evo en 850 Evo. De onderzoekers wisten de juiste ingang tot de beveiliging onder andere te vinden via bufferoverflows en de debuginterface JTAG, die fabrikanten soms op drives aanwezig laten. Er zijn volgens Van Gastel ook andere manieren om het uitvoeren van code op de controller mogelijk te maken, zoals via power glitching.

Een andere kwetsbaarheid, CVE-2018-12038, heeft te maken met wear levelling bij de chip waarop de sleutel is opgeslagen. Vanuit de fabriek worden de ssd's zonder wachtwoord geleverd, al wordt standaard wel alles versleuteld waarbij de sleutel onbeschermd is opgeslagen. Bij het veranderen van een wachtwoord wordt er alsnog een beschermde sleutel weggeschreven, maar door wear levelling kan de onbeschermde nog op andere sectoren staan. De sleutel zonder wachtwoord kan zo op die andere locatie uitgelezen worden, al is die logisch gezien niet te onttrekken. Dit bleek bij de Samsung 840 Evo het geval.

Meijer en Van Gastel hebben bijna twee jaar over hun onderzoek gedaan, waarbij ze onder andere de ssd's moesten openschroeven en moesten solderen voor de eerste resultaten. Volgens Van Gastel is de methode makkelijk te automatiseren en leert de ervaring dat er binnen afzienbare tijd programma's verschijnen die helpen om toegang tot encrypted drives te krijgen. Er is wel fysieke toegang tot de ssd nodig om de beveiliging te omzeilen.

Fabrikanten van opslagmedia hebben een standaard voor de hardwarematige encryptie van opslagmedia ontwikkeld: TGC Opal. Dat het standaardiseren geen soelaas biedt, komt volgens de onderzoeker doordat de implementatie te complex is en te veel eisen stelt. "De standaard vertelt fabrikanten niet hoe ze de beveiliging moeten implementeren. Als er al een referentie-implementatie is, dan is die niet openbaar, maar wij vermoeden dat die er helemaal niet is."

Voor doorsnee gebruikers is de impact volgens hem laag, omdat die waarschijnlijk toch geen gebruik maken van hardwarematige encryptie. "Maar gevorderde gebruikers die het hebben aanstaan om gevoelige gegevens te beschermen, moeten uitkijken. Ook voor organisaties is het een probleem, die zetten niet alles even om. Daarom hebben we die twee weken geleden al gewaarschuwd", volgens Van Gastel.

De kwetsbaarheden zijn niet eenvoudig te verhelpen met firmware-updates, als gebruikers die al massaal zouden doorvoeren. De onderzoekers adviseren daarom om niet exclusief te vertrouwen op hardwarematige encryptie en gebruik te maken van softwarematige encryptie, zoals VeraCrypt.

Ook waarschuwen ze dat BitLocker van Windows automatisch voor hardwarematige encryptie kan kiezen als een drive met TCG Opal-ondersteuning aanwezig is. Alleen een geheel nieuwe installatie, met opnieuw formatteren van de schijf, dwingt dan software-encryptie af. "Het commando om te kijken of Windows de encryptie uitbesteedt aan de schijf is 'manage-bde -status' in de Command Prompt of PowerShell. Als 'Hardware Encryption' achter 'Encryption Method' staat, wordt de encryptie uitbesteed aan de ssd's", aldus Van Gastel.

Voor de externe ssd's T1, T3 en T5 heeft Samsung nieuwe firmware vrijgegeven. Voor de interne ssd's verwijst ook Samsung door naar encryptiesoftware. Crucial, een dochtermerk van Micron, lijkt nog geen mededeling over de kwetsbaarheid gepubliceerd te hebben.

De onderzoekers hebben hun bevindingen in een voorlopige rapportage met als titel Self-encrypting deception: weaknesses in the encryption of solid state drives gepubliceerd. Ze hebben voor de publicatie de beginselen van responsible disclosure gevolgd, en Samsung en Crucial zes maanden geleden ingelicht. Er is ook een advisory voor organisaties beschikbaar.

Reacties (84)

[Verwijderd]

Voor de MX100 en MX200 heeft crucial een security update beschikbaar gemaakt op 25 mei 2018
MX300 heeft als nieuwste firmware M0CR060 van 12 september 2017

http://www.crucial.com/us...pport-product-support-ssd

[CARLiCiOUS]

Klopt. Die updates zijn gereleased na onze (vertrouwelijke) disclosure. Ze zorgen er onder andere voor dat de JTAG feature wordt uitgeschakeld, maar ze lossen het probleem niet op.

[Verwijderd]

Bedankt voor de info dat probleem nog steeds aanwezig is.

Had al zo'n vermoeden want update werd geïnstalleerd met behoud van data en zonder zonder password wijziging, vooral dat laatste leek me onmogelijk na het lezen van jullie paper.

[Fastfreddy666]

Voor de MX300 doe ik eerst voor "de gein een secure erase". Dan als ik het verhaal goed begrijp moet je een nieuw master ATA password in de bios aanmaken. De Crucial MX300 heeft een lege string als password. Oops.

Alleen irritant dat je dan steeds het password moet intypen bij het opstarten. Hoge veiligheid gaat ten koste van het comfort zullen we maar zeggen. Bovendien heb ik mijn OS en data gescheiden. Alleen het OS staat op de SSD. De rest van de data staat op relatief goedkope HDs. Dingen die echt beveiligd moeten pak ik in met het open source 7-zip (1) uiteraard met password en AES-256 beveiliging.

(1) Moet je wel de nieuwste versie van de website halen. 18.0.5. In de oude versies zitten kwetsbaarheden. Heeft verder niets met de encryptie te maken maar wel goed om even te melden. Want mocht je toevallig een "fout" rar bestand uitpakken dan zou zomaar kwaadwillige code uitgevoerd kunnen worden. En dat willen we natuurlijk niet hebben.

Hier een lijst met de (opgeloste) kwetsbaarheden van 7-zip

https://www.cvedetails.co...vendor_id-9220/7-zip.html

Zet versie 18.0.5 er dus op! Veiligheid kost inspanning.

[Samsonait]

Slightly offtopic:

Zijn er nog wel voordelen aan hardwarematige encryptie t.o.v software matige encryptie?
Levert een softwarematige fulldisk encryptie (Bitlocker e.d.) een trager systeem op dan een hardwarematige encryptie?

-edit

Bedankt allemaal voor de reactie! Weer een stukje wijzer geworden!

[Reactie gewijzigd door Samsonait op 23 juli 2024 01:06]

[keranoz]

Voor systemen met een CPU die AES-NI ondersteunt (inmiddels zo'n beetje elke desktop CPU) is de performance winst om het hardwarematig te doen volgens mij nihiel. Hier een screenshotje van een encryption benchmark op mijn laptop met een 4de generatie i7. Vanwege AES-NI is mijn laptop instaat om gigantisch AES te encrypten en decrypten. https://i.imgur.com/kG2Y4Xc.png (zie rechts onder in beeld: Hardware-accelerated AES: Yes)

EDIT: ervanuitgaande dat je niet al je schijven 100% belast, want dan ga je het zeker weten wel merken, helemaal op een niet zo nieuwe/krachtige CPU. Zie hieronder.

OT: Ik vind dit wel zeer kwalijk van Samsung, Crucial en weet ik welke partijen nog meer. Dit neemt alle encryptie weg. <tinfoil hat talk>Stel dat alle inlichtingendiensten dit allang wisten? Dan denk jij dat je veilig zit maar dat is dus totaal niet het geval. Het wordt helemaal makkelijk gemaakt als je in Windows via group policies instelt dat alleen hardwarematige encryptie toegestaan is.</tinfoil hat talk>

[Reactie gewijzigd door keranoz op 23 juli 2024 01:06]

[Olaf van der Spek]

is de performance winst om het hardwarematig te doen volgens mij nihiel.

Waarom denk je dat?
Als de CPU de encryptie moet doen, moet de data uit de page cache dus gelezen, versleuteld, ergens anders weer geschreven worden en dan kan de drive die tweede versie wegschrijven. Zonder encryptie of met hardware encryptie heb je alleen die laatste stap..
Is de drive niet zo snel en heb je CPU en geheugen bandbreedte genoeg, dan merk je er misschien niks van, maar dat wil niet zeggen dat het niets kost.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 01:06]

[keranoz]

Je hebt gelijk. Maar ik ging niet uit van volledige belasting. Als je een SATA SSD volledig belast, zeg maar 500MB/s, ja dan gaan er zeker wel een procentje of 10 naar het encrypten van data ja, maar bij gewoon gebruik... ik heb er zelf nog nooit echt last van gehad.

[Verwijderd]

Ajoh de inlichtingendiensten in Europa kunnen er alsnog niks mee, alleen in USA kan je fucked zijn.

[Bytemaester]

Laat die tinfoil hat talk maar weg. Dit is gewoon de gang van zaken inmiddels.

[Rob Coops]

Het voordeel is dat de CPU het harde werk van de en/decryptie niet hoeft te doen. Het is namelijk niet niets even een data stroom zo aanpassen dat het niet meer te lezen is zonder een bijbehorende sleutel die vervolgens zo opgeslagen wordt dat deze niet zomaar uit te lezen is.

Natuurlijk kun je dat in software doen net zo als je bijvoorbeeld alle graphics ook in software kan renderen en met een redelijke kwaliteit, maar vergeet niet dat dat betekend dat de CPU dan minder tijd heeft voor andere dingen en het dus de overal performance van het systeem raakt.

Wat ik interessant vind aan het verhaal is dat het schijnbaar niet geheel in software opgelost kan worden omdat er bepaalde fouten zitten in de hardware implementatie die niet zomaar op te lossen zijn. Dat laatste verbaasd me niet helemaal. Encryptie is een moeilijk iets en met voldoende adoptie in de markt is er ook voldoende reden om te proberen deze encryptie te breken, wat er voor zorgt dat je als je ook maar iets een klein beetje fout hebt gedaan dit hoogstwaarschijnlijk redelijk snel gevonden zal worden.

[bwerg]

Het is namelijk niet niets even een data stroom zo aanpassen dat het niet meer te lezen is zonder een bijbehorende sleutel die vervolgens zo opgeslagen wordt dat deze niet zomaar uit te lezen is.

Klopt, maar de meeste CPUs hebben gewoon een AES-component. Zolang je niet tijdens de I/O ook nog andere zaken aan het encrypten bent zal dat dus weinig ander rekenwerk in de weg zitten.

Encryptie is een moeilijk iets en met voldoende adoptie in de markt is er ook voldoende reden om te proberen deze encryptie te breken

Dit zou ik niet een gebroken encryptie noemen, maar gewoon een foutieve implementatie. De encryptie zelf staat nog steeds als een huis alleen daar heb je niets aan als de sleutel gewoon uitgelezen kan worden.

[Reactie gewijzigd door bwerg op 23 juli 2024 01:06]

[Xorgye]

Hardware matig zou minder risico van onderschepping op moeten leveren. Van de sleutel, van het uitvoeren van de decryptie, etc.

[cdwave]

Met als nadeel dat als er een kwetsbaarheid in de hardware zit, je daar doorgaans helemaal niets tegen kunt ondernemen om dat op te lossen.

[Verwijderd]

Voor een multiboot systeem is hardwarematige encryptie erg handig, ieder OS kan zijn normale drivers gebruiken.
Ook voor een OS dat geen encryptie van de systeem partitie kent is het zeer bruikbaar.

[PilatuS]

Voordeel van hardware is dat je niet hoeft te encrypten. Laat je Bitlocker hardware gebruiken is het instant klaar na een reboot. Via software ben je heel veel uren verder voordat het klaar is.

[Reactie gewijzigd door PilatuS op 23 juli 2024 01:06]

[Helium-3]

een softwarematige fulldisk encryptie (Bitlocker e.d.)

Bitlocker maakt indien aanwezig gewoon gebruik van je Security Processor (of Trusted Platform Module) voor hardwarematige encryptie functionaliteit.

[ELD]

In Max security mode is een nieuwe(lees leeg) 840/850 EVO dus nog steeds veilig. Alleen als de SSD's pas later in Max security mode is gezet en er staat al data op, kan door middel van de aanval via wear leveling data worden achterhaald.

Paar opmerkingen:

• Max security mode is de best practice
• Bij activering is het best practice om een nieuwe DEK te generen
• Voor activering is het de best practice om ATA secure erase uit te voeren
• Best practice is dat je nooit data op een SSD moet laten landen voor encryptie is geactiveerd

Neemt niet weg dat het een foutieve implementatie betreft.

[Reactie gewijzigd door ELD op 23 juli 2024 01:06]

[CARLiCiOUS]

Bijna goed. Bij de Samsung 840/850 evo's is de versleuteling volledig te omzeilen als je de drive doormiddel van ATA security in High mode hebt geconfigureerd. In de andere gevallen niet, dus niet in Max mode of als je TCG Opal (o.a. BitLocker doet dit) gebruikt.

Maar: als je een 840 evo hebt, dan bestaat er de kans dat je alsnog kwetsbaar bent. Door de wear leveling kan er een onbeschermde kopie van het sleutelmateriaal (DEK) in het flashgeheugen achterblijven. Als dat zo is kan een aanvaller die terugplaatsen en bij de gegevens komen. Het maakt dan niet uit of je ATA security in welke modus dan ook, of Opal gebruikt. Overigens is de kans niet zo groot dat dat laatste probleem je raakt; meestal is een achtergebleven kopie na een paar dagen al overschreven.

(Ik ben een van de auteurs)

[ELD]

Hi CARLiCiOUS korte vraag, hebben jullie ook de pro varianten getest?

Verder denk ik dat we hetzelfde zeggen want ik geef aan dat alleen de max mode veilig is.

[Reactie gewijzigd door ELD op 23 juli 2024 01:06]

[CARLiCiOUS]

Nee helaas. Zo'n firmware uitpluizen is veel werk, dus we hebben een selectie moeten maken. Ik kan alleen maar zeggen dat firmwares van de pro en evo varianten duidelijk een grote gedeelde codebase hebben, maar daar moet je je eigen conclusies uit trekken ben ik bang. Samsung zelf adviseert overigens om helemaal af te stappen van hun hardware encryptie.

[Kain_niaK]

Ik snap het niet, kan de drive niet geencrypteerd worden met de hash van het password van de gebruiker zonder dat dat password word opgeslagen op de drive zelf?

[CARLiCiOUS]

Dat is vanwege de TCG Opal standaard. Die dwingt af dat er ondersteuning moet zijn voor meerdere wachtwoorden (credentials in hun terminologie) en meerdere partities (locking ranges). Vervolgens moet één credential toegang toegewezen kunnen krijgen tot meerdere locking ranges, en één locking range moet door meerdere credentials kunnen worden ge-unlockt. Ofwel, in database termen, een many to many relatie. Denk er eens over na hoe je dat zelf zou implementeren, met de eis dat de encryptiesleutel afhankelijk is van het wachtwoord natuurlijk. Ohja, en locking ranges moeten onafhankelijk van elkaar kunnen worden gewist door de bijbehorende key weg te gooien en een nieuwe te genereren, zonder dat je alle wachtwoorden weet die toegang verschaffen tot die range. In andere woorden: Opal is een gedrocht.

Het kán wel, en we hebben gezien dat Samsung dit ook fatsoenlijk heeft gedaan (maar andere dingen minder), maar ik denk niet dat het als een verrassing komt dat die standaard niet overal optimaal is geïmplementeerd. Bovendien is er geen referentie-implementatie vanuit TCG en worden de implementaties niet meegenomen in de certificering.

Als je meer wil weten verwijs ik je graag door naar het paper.

[Tourmaline]

De 860 staat er niet bij...Dat is de nieuwste versie van Samsung...

[ELD]

Die hebben ze net als de 840/850 pro niet getest.

[Tourmaline]

Misschien minder kwetsbaar als de standaard uitvoeringen.

[ELD]

Ik denk dat ze exact dezelfde implementatie hebben, maar dat is een aanname.

Ik vind het jammer dat ze voor deze paper niet de pro modellen hebben meegenomen in het onderzoek.

[Reactie gewijzigd door ELD op 23 juli 2024 01:06]

[Tourmaline]

Dat hoeft niet natuurlijk, bios updates, update encryptiesoftware. Zou zo maar kunnen.

[Qwerty-273]

Hmzz, dat is toch wel vreemd voor de opal-standaard. Juist daarmee werd al lang hardware matige encryptie gepusht voor opslag media. Ben benieuwd of dit alleen geldt voor de genoemde ssd's of dat ook de hdd's hier last van hebben. In de meeste disk encryptie producten werd juist voor opal drives vertrouwd op de hardware matige encryptie ipv het op software niveau te doen. Als nu blijkt dat deze hardware matige encryptie gebreken vertoond (oa door dat de key uit te lezen lijkt te zijn) is dat voor een aantal klanten een behoorlijk bedrijfsrisico.

[Tjark]

Het lijkt me niet dat matige encryptie überhaupt gepusht wordt. Dan liever goede encryptie, hardwarematig of softwarematig.

[ToolBee]

Helaas wordt er tegenwoordig wel meer "gepushed" dat nog niet volledig getest, of überhaupt "af" is.

"Sign o' the times" zou Prince zingen...

[Tourmaline]

Goed nummer...

[Iblies]

Ik denk dat je sowieso niet meer moet vertrouwen op encryptie van de grotere bedrijven. De kans dat ze daadwerkelijk iets potdicht maken is heel klein omdat uiteindelijk een overheid altijd kan komen vragen voor een backdoor en/of masterkey. Theoretisch vasthouden aan principes klinkt heel nobel, maar de kans dat een overheid je kapot gaat maken is reëel.

Apple is een bekend voorbeeld dat met een sisser afliep,
maar een ander extreem is ZTE die dacht dat meewerken aan bepaalde maatregelen van oa de VS soms een optie is. Dat bedrijf staat nu deels aan de afgrond.


Als bepaalde data echt veilig moet zijn,
dan zul je het ouderwets moeten afsluiten. Binnen een gesloten netwerk, in een gebouw met beperkte toegang, op pc die consequent gemonitord worden door wie ze gebruikt worden en wat ze er doen.

[Olaf van der Spek]

[q]Hmzz, dat is toch wel vreemd voor de opal-standaard./]
Wat is er vreemd aan? SSDs met hardware encryptie verkopen gewoon beter...

[Rev-anche]

Hmzz, dat is toch wel vreemd voor de opal-standaard. Juist daarmee werd al lang hardware matige encryptie gepusht voor opslag media. Ben benieuwd of dit alleen geldt voor de genoemde ssd's of dat ook de hdd's hier last van hebben. In de meeste disk encryptie producten werd juist voor opal drives vertrouwd op de hardware matige encryptie ipv het op software niveau te doen. Als nu blijkt dat deze hardware matige encryptie gebreken vertoond (oa door dat de key uit te lezen lijkt te zijn) is dat voor een aantal klanten een behoorlijk bedrijfsrisico.

Maar we hebben het hier wel over een storm in "een bierglas/glas water"!
Per slot van rekening moet je eerst fysiek bij de SSD/HDD kunnen komen!?

Dat evt een op/inlichtingendienst dat wel voor elkaar zal krijgen is imo geen wonder met een volmacht!
Maar of je je concurrent, of zelfs ex-vrouw toegang geeft tot je encrypte opslag lijkt me wel heel
onverstandig, om het maar zacht uit te drukken!

Op/inlichting komt doordat ik Hunted heb gezien

[Reactie gewijzigd door Rev-anche op 23 juli 2024 01:06]

[Qwerty-273]

Juist disk encryptie wordt toegepast op het veiligstellen van de data in rust op laptops (uit/hibernate stand). Zodat wanneer je een laptop verliest (of gestolen wordt) de bedrijfsdata veilig is. Dus inderdaad fysieke toegang tot de hardware, maar als deze ergens in een taxi of hotel gegrepen kan worden, en vervolgens de data op redelijk eenvoudige manier ontsleuteld kan worden, dan zou ik het niet direct een storm in een glas water willen noemen.
Er zijn juist verschillende overheid organisaties die voor diskencryptie en opal-drives hebben gekozen vanwege de 'beloofde' veiligheid en snelheid. Samen met het beheer van het complete platform.

[Jace / TBL]

dat de cryptografische sleutel bij de onderzochte ssd's niet afhankelijk is van het wachtwoord.

Dan is het dus een soort van security through obscurity. Wat eigenlijk helemaal geen security is.

[PilatuS]

Iemand de firmware van de T3 of T5 al geupdate ? Heb de tool gedownload van de site, maar niets over een firmware update te vinden. Dit met een nieuwe install van versie 1.6.2. Het enige wat er aan updates is te vinden lijkt van de software zelf te zijn, niet de firmware van de SSD. Zou niet weten hoe ik dit nou kan updaten.

[BobV]

Voor de mensen die 'manage-bde -status' willen proberen, let op de extra spatie, die mist in het artikel!

[joyrider3774]

Het commando is "manage-bde -status" niet "manage-bde-status" er moet een spatie staan tussen "manage-bde" en "-status"

[xiphoid]

macOS noemt een SSD 'disk', al jaren. Oa. in hun disk manager. physical disk: ssd, etc ..