unsichere Festplattenverschlüsselung

Man verschlüsselt die Festplatte, wählt einen starken Algorithmus und packt ein wirklich ausgefeiltes Passwort mit hinein. Danach schaltet man den Rechner aus oder unmountet beispielsweise ein TrueCrypt Volume. Fertig, die Sache ist sicher, da kommt so schnell keiner heran. Nun eine neue Studie zeigt genau das Gegenteil und dieser Umstand hängt mit der Eigenschaft heutigen Speichers zusammen, der erst nach ein paar Minuten(!) wirklich vollkommen leer steht. Rechner deren verschlüsselte Volumes ungemountet wurden, die sich jedoch noch in Betrieb befinden haben da eh schlechte Karten — sprich die Verschlüsselung ist ad absurdum geführt, aber selbst Rechner die vermeintlich sicher abgeschaltet wurden beherbergen immer noch den Schlüssel im Speicher für einige Minuten. Ein Fest für jedes Memory-Dump-Tool. TrueCrypt, Microsofts Bitlocker (Vista Business, Ultimate), Apples Filevault und Linux dm-crypt wurden untersucht und diese waren alle gleichsam anfällig1 .

Das Fazit ist, insbesondere für Arbeitsplatzrechner oder Laptops mit delikaten Daten, Rechner abschalten und ein paar Minuten warten. Als belanglos oder arg theoretisch sollte man die Sache nicht einstufen, denn dazu brauchts kein FBI Labor, sondern nur das richtige Timing. Benutzer die gerne mit Standby & Co arbeiten und sich der Sicherheit ungemounteter Volumes hingeben wissen nun eines, dieser Schutz war für die Katz.

Disk encryption may not be secure enough, new research finds

Research paper (pdf)

F.A.Q.

golem

ars technica

Addendum:

Eine Stellungnahme von PGP:

PGP’s own disk encryption software is vulnerable to the attack, Callas says, though he says it does defend against such an attack better than some other companies’ software.

And while the company is working on ways to protect against this kind of attack, there’s not much any software maker can do with code, given that all modern computers have this memory flaw.

Encryption Still Good; Sleeping Mode Not So Much, PGP Says

  1. was weniger an den Schutzmaßnahmen per se liegt, sondern an der Hardware []

25 Antworten zu “unsichere Festplattenverschlüsselung”

  1. Kronkorken sagt:

    Gegenmaßnahmen? Speicherbereich überschreiben bevor man runterfährt?

  2. Oliver sagt:

    Solange das Betriebssystem arbeitet kannst du nie alle Bereiche des Speichers wirklich erfassen, drum macht z.B. auch ein Speichertest erst nach einem Kaltstart Sinn. Warte einfach ein paar Minuten und lasse keinen Rechner in Betrieb zurück, wenn sich darauf delikate Daten befinden.

  3. Grainger sagt:

    Unter MS-Betriebssystemen wird auch ein paar Minuten warten vermutlich nicht viel nutzen wenn man die Funktion «Ruhezustand aktivieren» eingeschaltet hat.

    Wenn der Computer in den Ruhezustand wechselt, wird er Inhalt des Arbeitspeichers gespeichert und der Computer wird heruntergefahren. Wenn er wieder startet, kehrt er zum vorherigen Zustand zurück.

    Da die Datei HIBERFIL.SYS genau so groß wie der installierte physikalische Speicher ist wird wohl ein genaues Speicherabbild auf die Festplatte gebannt.

    Zumindest unter den Notebook-Besitzern kenne ich einige, die diese Funktion nutzen.

  4. ~ba sagt:

    Malwieder nichts Neues. Beim CCCamp07 gab es sogar einen Vortrag dadrüber. War allerdings nur auf Linux bezogen:

    Cryptographic key recovery from Linux memory dumps

  5. Ich weiß nicht im Detail, wie TrueCrypt arbeitet, aber wenn es sinnvoll implementiert ist, dann wird es den Schlüssel im Hauptspeicher immer dann überschreiben, wenn das Volume abgehängt wird — auch beim ordentlichen Herunterfahren des Rechners. Schließlich weiß die Software ja, wo die kritischen Stellen im Speicher sind. (Natürlich kann es durch das Zusammenspiel zwischen physikalischem und virtuellem Speicher sein, daß das schief geht, aber die Wahrscheinlichkeit scheint mir nicht sehr groß zu sein.) Darin liegt nicht die große Gefahr.

    Richtig brenzelig wird es dann, wenn der Rechner hart stromlos gemacht wird, denn dann besteht keine Gelegenheit mehr, den Schlüssen zu überschreiben. Also: Rechner nicht unbewacht mit aktiver verschlüsselter Partition stehen lassen!

  6. Oliver sagt:

    >Ich weiß nicht im Detail, wie TrueCrypt arbeitet, aber wenn es sinnvoll implementiert ist, dann wird es den Schlüssel im Hauptspeicher immer dann überschreiben, wenn das Volume abgehängt wird

    Sie testeten auch TrueCrypt und was ein Betriebssystem im Speicher eventuell cached weiß auch TrueCrypt nicht.

    >aber die Wahrscheinlichkeit scheint mir nicht sehr groß zu sein

    Mmmh du solltest doch mal den Text lesen.

    @~ba

    Und es gibt sogar noch ältere Hinweise darauf von Gutmann. So what? Eine Information ist erst dann redundant, wenn sie *jeder* kennt und nicht nur ein paar Nerds die beim CCC hocken.

  7. Tux sagt:

    Die Schluessel im Hauptspeicher zu ueberschreiben loest das Problem leider nur zur Haelfte.

    Nicht zu verachten ist ja auch, dass neben den Schluesseln auch die Daten, die man eigentlich sicher im Crypto-Container waehnt, unverschluesselt in irgendwelchen Caches rumfliegen und dort per memory dump lesbar sind.

    Moeglicherweise ist es dann gar nicht mehr notwendig, den Key oder die Passphrase herauszubekommen — wenn ein belastendes Dokument schon so aus dem Speicherabbild extrahiert werden kann.

  8. @Oliver: Text lesen? Habe ich. Da steht genau dasselbe drin (unmounten sollte eigentlich helfen, wenn die Software die Schlüssel im Speicher überschreibt.) Daß es nicht schadet, «sicherheitshalber» ein paar Minuten in der Nähe des ausgeschalteten Rechners zu bleiben, ist klar.

    Wie müßte ein Szenario aussehen, daß die eine Kopie der Page, die den Schlüssel enthielt, noch im RAM ist, aber nicht mehr in das Working Set gemappt ist (denn in der Kopie, die ins Working Set gemappt ist, wird der Schlüssel ja in unserem Szenario überschrieben?) Ich habe darüber nachgedacht, aber mir fällt kein nicht-pathologischer Fall ein.

    Ich bleibe wie die Autoren bei news.com und erst recht der Autor, den Bruce Schneier in seinem Blog zitiert, dabei: Die wahre Gefahr liegt darin, daß ein Angreifer Zugriff auf den eingeschalteten Rechner bekommt, während das Volume im Zugriff und damit der Schlüssel im RAM ist. («You can’t rely on the screen saver».) Dann kann der Angreifer durch ggf. Tiefkühlen des Speichers und hartes Stromlosmachen den Schlüssel aus dem RAM lesen — entweder durch Booten eines eigenen Betriebssystems oder durch Einbau der Speicherriegel in eigene Hardware.

    Wurde das Volume ordentlich ausgehängt, der Schlüssel im RAM überschrieben (und sinnvollerweise mit verschlüsseltem Swap gearbeitet, dessen Schlüssel im RAM ebenfalls beim Herunterfahren überschrieben wurde), dann sehe ich immer noch keinen Angriffsweg, der nicht um sehr sehr viele Größenordnungen weniger aussichtsreich wäre als das, worum es in dem Artikel eigentlich geht (s. o.).

  9. @Tux: Das stimmt — allerdings auch nur so lange, bis «richtige Betriebssysteme» nicht beim Runterfahren das pyhsikalische RAM einmal überschreiben. Nach diesen Erkenntnissen wird sicher bald jemand ein paar Zeilen Code für den Linux-Kernel schreiben, die das machen. :)

    Bleibt die Gefahr des angeschalteten oder im Suspend-to-RAM-Modus befindlichen Rechners.

  10. Oliver sagt:

    >wenn die Software die Schlüssel im Speicher überschreibt

    Du gehst von einer Tatsache aus, die einfach so gar nicht belegt werden kann. Windows beispielsweise hat diverse Cache-Mechanismen an die auch nicht irgendein Programm herantreten kann, in Vista sind diese noch in weitaus größerem Maße vorhanden.

    >Countermeasures begin with efforts to avoid storing keys in memory. Software should overwrite keys when they are no longer needed, and it should attempt to prevent keys from being paged to disk. Runtime libraries and operating systems should clear memory proactively.

    Seite 18 des Research Papers.

    Es treffen also mehrere Parameter zusammen die erfüllt werden müssen, um Speicherabbilder *gänzlich* auszuschließen. Von einem minimalen Risiko kann da nicht gesprochen werden.

    Eher schaut es so aus, daß sich niemand bisher wirklich dazu Gedanken machte bzw. das dieser Umstand in die Öffentlichkeit kommuniziert wurde.

  11. Oliver sagt:

    >Nach diesen Erkenntnissen wird sicher bald jemand ein paar Zeilen Code für den Linux-Kernel schreiben, die das machen

    Das bleibt zu hoffen, auch wenn es nur ein Teil zur Sicherheit ist. Weitere Tipps sind übrigens am Ende des Papers aufgeführt und auch warum diese nur in ihrer Gesamtheit sinnvoll sind.

  12. Stefan sagt:

    wieviel minuten sinds denn? weniger als 5? damit kann ich leben. :) mein anwalt braucht bei einer hausdurchsuchung mindestens so lange bis er da ist und bis dahin fahr ich den rechner für die polizei schon mal runter :D

  13. Oliver sagt:

    Hängt von vielen Dingen ab,u.a. auch von der Raumtemperatur oder aber ob z.B. jemand Zugang zum Rechner hatte und diesen preparieren konnte (auch nur wenige Minuten).

  14. Grainger sagt:

    Eigentlich sollte es nicht sooo schwer sein, eine Funktion zu realisieren, die beim Herunterfahren des Rechners den gesamten phyikalischen Speicher überschreibt (imho sollte einmaliges überschreiben mit Nullbytes reichen).

    Behaupte ich als programmiertechnischer Noob jetzt einfach mal so. ;)

    Selbst unter Win2K/XP sollte es möglich sein, ein kleines Assemblerprogramm zu schreiben und es z.B. über

    gpedit.msc -> Windows-Einstellungen -> Scrips -> Herunterfahren

    so einzubinden, das es beim Herunterfahren so viel Speicher wie nur irgendmöglich allociert und diesen mit Nullbytes überschreibt.

    Natürlich müsste außerdem Hibernate deaktiviert sein, die diversen temporären Verzeichnisse geleert werden und auch die Auslagerungsdatei überschrieben werden (was bei größeren Auslagerungsdateien schon etwas dauern kann).

    Ich bin mir aber absolut nicht sicher, ob da damit tatsächlich alle theroretisch möglichen Methoden zum Auslesen von diversen Speicher– und Dateiinhalten wirklich eliminert wären.

  15. Grainger sagt:

    Nachtrag: im Nachhinein fällt mir ein, das ein Überschreiben mit Nullbytes kontraproduktiv wäre, weil dann jemand, der auf der Suche nach bestimmten Informationen ist, ja nur noch das suchen muss was eben nicht Null ist.

    Man würde ihm damit die Arbeit ja unter Umständen sogar erleichtern.

    Besser wäre es wohl, den Speicher und die Auslagerungsdatei mit zufälligen Bytefolgen zu überschreiben.

  16. ~ba sagt:

    @Oliver: Es war lediglich ein Hinweis darauf, dass es nichts Neues ist und nicht, wie einige News-Seiten nun darstellen, eine riesen Sensation. Research in diesem bereich gibt es eh schon lange. Somit sind auch die Erkenntnisse aus dem Video nichts Neues. Der Vortrag ist ja auch nur eine Präsentation über das Thema und nicht die Präsentation von neuartigen Forschungsergebnissen in diesem Bereich. Der Link zu dem Video sollte auch nur für Leute gedacht sein, die sich vielleicht ein wenig mehr mit der Thematik auseinandersetzen wollen bzw. Ansätze suchen, wie man soetwas macht.

    Scheinbar sind derartige Kommentare hier aber auch schon zu viel. Armes FiXMBR.

    Schönes WE euch allen!

  17. Oliver sagt:

    >wie einige News-Seiten nun darstellen, eine riesen Sensation.

    Selbst für Bruce Schneier ist es neu (abgesehen von der Sachlage, daß es allgemein ein Problem ist, wenn der Täter physischen Zugang besitzt zur Maschine), insofern hat man es wohl versäumt die Sache nach außen zu kommunizieren. Und allein darum geht es.

    http://www.schneier.com/b.….tac.html

    >Armes F!XMBR

    Ich kanns wirklich schon nicht mehr hören. Es geht nicht um euren oder unseren Egotripp, es dreht sich darum das diese Aussage von dir in diesem Rahmen sinnfrei ist, auch die weitere Erklärung. Denn wenn man es als Nerd-Kram behandelt und nicht in der Lage ist die Sache zur Außenwelt zu kommunizieren, dann ist es eben eine quasi nicht vorhandene Information.Tatsächliche Deppen Kommentare löschen wir üblicherweise und setzen uns nicht damit auseinander.

    Und ich wiederhole es noch einmal, solange diese Infos nur ein paar Nerds kennen ist sie nutzlos. Diese dort haben sich jetzt mit Microsoft & Co in Verbindung gesetzt, ebenso mit Bios-Herstellern. Wenn dann nichts geschieht okay, das ist dann Ignoranz. Aber das andere von dir erwähnte Beispiel war in seiner Wirkung nur ein coole Hacker-Gaudi.

  18. Oliver sagt:

    @grainger,

    Gemäß den Aussagen sollten mehrere Dinge wirken:

    –das Programm sollte seine Schlüssel wieder löschen
    –der Speicher sollte gelöscht werden
    –Auslagerungsdateien sind zu berücksichtigen
    –das Bios soll beim Start ebenso sein Scherflein dazu beitragen

    Sprich man geht auf Nummer sicher.

  19. […] Vor einigen Jahren war davon schon die Rede, ich war davon ausgegangen das die schwachstelle RAM geklärt ist, aber anscheint nicht. Laut F!XMBR ist der RAM unsicher, also sichert euren RAM auch ab Man verschlüsselt die Festplatte, wählt einen starken Algorithmus und packt ein wirklich ausgefeiltes Passwort mit hinein. Danach schaltet man den Rechner aus oder unmountet beispielsweise ein TrueCrypt Volume. Fertig, die Sache ist sicher, da kommt so schnell keiner heran. Nun eine neue Studie zeigt genau das Gegenteil und dieser Umstand hängt mit der Eigenschaft heutigen Speichers zusammen, der erst nach ein paar Minuten(!) wirklich vollkommen leer steht. Rechner deren verschlüsselte Volumes ungemountet wurden, die sich jedoch noch in Betrieb befinden haben da eh schlechte Karten — sprich die Verschlüsselung ist ad absurdum geführt, aber selbst Rechner die vermeintlich sicher abgeschaltet wurden beherbergen immer noch den Schlüssel im Speicher für einige Minuten…weiter lesen […]

  20. Sven sagt:

    Ich war bisher davon ausgegangen, dass Festplattenverschlüsselung sowieso nicht sicher ist, wenn ein Angreifer physischen Zugang zu dem Rechner hat, während das verschlüsselte Laufwerk gemountet ist. (Meines Wissens trifft dies zumindest bei Mac OS X auch für Hibernate aka Safe Sleep zu.) Das macht es natürlich nicht besser, da dieser Angriff eventuell einfacher ist als Software-Schwachstellen auszunutzen.

    @Oliver: Du schreibst, dass auch ungemountete Laufwerke angreifbar sind. Kann in diesem Fall nicht die Software helfen? Wenn ich die von PGP richtig verstehe, überschreibt die PGP Software den Schlüssel im Speicher, wenn man den Container auswirft. Wäre also ein PGP-Container, den ich nur bei Bedarf mounte und dann wieder unmounte, sicher? Das funktioniert natürlich nicht für vollständige Festplattenverschlüsselung.

  21. Oliver sagt:

    >Kann in diesem Fall nicht die Software helfen?

    Gemäß dem Mann von PGP kann man da natürlich einiges tun, um den Angriff zu erschweren, aber gänzlich vermeiden kann man es nur mittels dem Ansatzpunkt Hardware.

  22. Andreas sagt:

    «Als belanglos oder arg theoretisch sollte man die Sache nicht einstufen, denn dazu brauchts kein FBI Labor, sondern nur das richtige Timing.»

    Naja, ich finde das schon reichlich theoretisch. Das richtige Timing? Wie realistisch ist denn das Szenario, dass der Arbeitskollege in der Mittagspause eine externe Festplatte anstöppelt und den Computer hackt oder dass er sogar das RAM ausbaut und wenn möglich noch superkühlt?

    Ernstzunehmender ist eher die Gefahr, zur Herausgabe des Passworts gezwungen zu werden, sei es mit Gewalt oder auch bei der Einreise in die USA, UK etc.

  23. Oliver sagt:

    >RAM ausbaut und wenn möglich noch superkühlt?

    Lass das RAM drin und nutze einfach die Druckluftdose (langt für ca. 10min), gibts in jedem Baumarkt. Deinen Rechner hat man schneller auf und wieder zu als du den Kaffee geholt hast und das RAM muß man keineswegs ausbauen. Darüber hinaus ist das eigentliche «Hacken» ebenso minimal im Aufwand.

    Desweiteren Stichworte: Latops, Standby und Co.

    >Ernstzunehmender ist eher die Gefahr, zur Herausgabe des Passworts gezwungen zu werden, sei es mit Gewalt oder auch bei der Einreise in die USA, UK etc.

    Nur nebenbei, in den Staaten wurde anders entschieden.

    Last not least ist das größte Sicherheitsleck, Selbstüberschätzung, Fantasielosigkeit und technisches Unverständnis.

    P.S. ich weiß nichts obs bei dir als Kommentar geradeklappte, BIOS-Passwörter _sind_ kein Schutz. Damit hält man nur diejenigen auf, für welche obige Dinge ebenso böhmische Dörfer darstellen.

  24. tom sagt:

    das bios kann durchaus teil der lösung sein! man kann z.b. beim neustart den ram überschreiben. das schließt schonmal den angriff ohne extra hardware aus. vllt kann das bios ja auch beim langen drücken des power knopfes den ram löschen bevor dem rechner der saft entzogen wird ;) oder bei öffnen des gehäuses…

  25. Oliver sagt:

    >das bios kann durchaus teil der lösung sein! man kann z.b. beim neustart den ram überschreiben.

    Steht ja auch weiter oben schon, als notwendinger Paramter.

    >oder bei öffnen des gehäuses…

    Wenns erst einmal jeder weiß ist es eben so sicher wie die Listen von Master-Paßwörtern für den BIOS Schutz.


RSS-Feed abonnieren