Hallo,

Ich möchte von einem USB-Stick so booten können dass:

• ein von mir modifizierter Kernel gebootet wird (Funktionierender Kernel ist schon erstellt, als Debian Package).

• Danach soll eine Partition der Festplatte gemountet werden in dem ein komplettes Ubuntu 12.04 verschlüsselt (!) abgelegt wurde (cryptsetup)

• Die Verschlüsselung ist Tresor, im wesentlichen bau ich das hier nach: https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sophisticated_Attacks

• Dann muss vermutlich nur noch in die frisch entschlüsselte Partition mit chroot gewechselt werden? Aber wie genau, wenn der Kernel schon angefangen hat zu booten?

Für jeden sachdienlichen Hinweis dankt Konrad Höns aus unseren Aufnahemstudios, die noch bis Mitternacht geschaltet sind

Hi.

Warum nicht einfach normal verschlüsseln und /boot mit Grub dabei auf nen USB-Stick legen? Geht recht einfach über die AlternateCD mit manueller Partitionierung.

Soweit ich das gelesen habe: "Normale" Verschlüsselungen legen ihren Schlüssel im RAM ab, wo er von mehreren Stellen aus auslesbar ist.

Wenn man das vermeiden will, ist TRESOR http://d24m.de/2012/01/09/howto-tresor-unter-ubuntu-11-10-verwenden/ wohl eine gute Antwort drauf - das nutzt spezielle Prozessorregister die es zur Zeit nur in Intel i7 und manchen i5-CPUs gibt.

Den USB-Stick hätte ich gerne als "Startmedium" denn sollte ein Angreifer es schaffen, einen Keylogger unter die Tastatur einzubauen oder mich beim Tippen zu filmen braucht er immer noch den USB-Stick mit einem selbstgebauten Tresor-Kernel zum Booten. Auf dem USB-Stick kann ja zusäzlich auch noch ein key gespeichert sein oder ich könnte einen USB-Key mit eigener Tastatur und Verschlüsselung kaufen.

Das mit dem grub auf /boot - Partition hab ich mangels eigener Kompetenz leider noch nicht ganz verstanden... könntest Du nochmal etwas genauer erklären bitte? Oder zeigen wo ich weiterlesen kann?

Mit uck (Ubuntu Customization Kit) hab ih mich schon befasst, das bietet aber ein Live-System. Und ich will eigentlich nicht ein Livesystem sondern eines das in die entschlüsselte Platte hinein bootet.

Mit dem Verschlüsseln von /home allein oder so kann ich leider nicht leben, es gibt immer zu viele Hinweise in Logdateien, temporären Dateien usw. .

hagenbuch schrieb:

Soweit ich das gelesen habe: "Normale" Verschlüsselungen legen ihren Schlüssel im RAM ab, wo er von mehreren Stellen aus auslesbar ist.

Ah, wo genau hast Du was gelesen?

Wenn man das vermeiden will, ist TRESOR http://d24m.de/2012/01/09/howto-tresor-unter-ubuntu-11-10-verwenden/ wohl eine gute Antwort drauf - das nutzt spezielle Prozessorregister die es zur Zeit nur in Intel i7 und manchen i5-CPUs gibt.

Der i7 hat andere register als andere CPUs? Quelle?

Den USB-Stick hätte ich gerne als "Startmedium" denn sollte ein Angreifer es schaffen, einen Keylogger unter die Tastatur einzubauen oder mich beim Tippen zu filmen braucht er immer noch den USB-Stick mit einem selbstgebauten Tresor-Kernel zum Booten.

Und du glaubst, einen Tresorkernel zu bauen stellt jemanden vor ein Problem, der dir einen Keylogger in die Tastatur pflanzt, ohne dass Du das bemerkst?

Das mit dem grub auf /boot - Partition hab ich mangels eigener Kompetenz leider noch nicht ganz verstanden... könntest Du nochmal etwas genauer erklären bitte? Oder zeigen wo ich weiterlesen kann?

Verzeih meine Offenheit: Wenn Du an Grub scheiterst, solltest Du so komplexe Cryptooperationen erst mal nicht in Eigenarbeit angehen. Denn schlecht umgesetzte Verschlüsselung ist deutlich schlimmer als eine zwar angreifbare, aber gut umgesetzte Lösung. Und die angreifbarkeit von LUKS muss mir erst noch wer beweisen.

Mit dem Verschlüsseln von /home allein oder so kann ich leider nicht leben, es gibt immer zu viele Hinweise in Logdateien, temporären Dateien usw. .

Das Problem hätte ein LUKS-Setup schon mal nicht.

und plane bitte auch den worst case ein:

• USB Stick defekt

• eigener kompilierter Kernel weg,

• Key weg

• i7 Hauptsystem Kauputt, Ersatz ist nur ein Notebook mit Core2Duo ...

und du must dringend an deine Daten...

@redknight: Du wirst mir sicher zustimmen dass jemand der was gut machen will, zuerst lernen muss, nicht wahr? Jemand der einfach Deinem Rat folgt wäre dann sicher schlechter beraten als jemand der zuerst Zeit investiert um sich fortzubilden. Nichts anderes habe ich vor. Ich hab Dir ja noch nicht mal den Verwendungszweck genannt... dass ich nicht Assange heisse dürfte Dir klar sein.

Alle meine Quellen hatte ich genannt, also wenn Du mich dabei ertappst, was nicht genau wiederzugeben: Freu Dich! (Hach diese Linuxforen. Herrlich, man wird nie enttäuscht).

Danke für den LUKS-Hinweis. Ist aber LUKS gegen eine Cold Boot-Attacke (Auslesen aus dem RAM gefeit)?

u1000 schrieb:

und plane bitte auch den worst case ein:

• USB Stick defekt

• eigener kompilierter Kernel weg,

• Key weg

• i7 Hauptsystem Kauputt, Ersatz ist nur ein Notebook mit Core2Duo ...

Danke für die Hinweise, aber natürlich gibt es weitere Ersatzsticks / ISO-Dateien, natürlich haben wir eine Datensicherung für den Kernel, natürlich kann ich den Kernel selbst neu erzeugen, - wenn der Key weg ist, die Festplatte stirbt und alle Daten weg sind, auch kein Problem für unseren Anwendungsfall.

Im schlimmsten Fall kommt der Mensch nach Hause und arbeitet dort weiter.

hagenbuch schrieb:

@redknight: Du wirst mir sicher zustimmen dass jemand der was gut machen will, zuerst lernen muss, nicht wahr?

Sicher. Aber um fortgeschrittene Themen im Selbststudium zu erarbeiten, muss man die Basics kennen. Wenn Du also nicht weißt, wie du den selbtgebauten Kernel bootest, ist dein Lernerfolg äußerst gering sein, weil Du nicht booten kannst. Deshalb schrieb ich auch, dass Du "erst mal" sowas nicht in Eigenarbeit angehen solltest. Nicht dass Du es nie machen sollst.

Jemand der einfach Deinem Rat folgt wäre dann sicher schlechter beraten als jemand der zuerst Zeit investiert um sich fortzubilden. Nichts anderes habe ich vor.

Wenn Du nur lernen willst, fang langsam an und benutze zuerst mal ein funktionierendes Setup (zB das LUKS, das die Alternate CD automatisch anlegen kann). Daraus kannst Du dann Modalitäten ableiten, die du in deinem händisch aufgebauten setup einbauen musst.

Ich hab Dir ja noch nicht mal den Verwendungszweck genannt...

Stimmt. Wollte ich Dir aber nciht noch zusätzlich mit um die Ohren hauen. Aber da du es selbst ansprichst: Was ist denn der Verwendungszweck des guten Stücks?

dass ich nicht Assange heisse dürfte Dir klar sein.

Wer weiß. Spricht/Schreibt Julian Deutsch? Vielleicht bist Du ja auch Daniel Domscheit-Berg Aber lassen wir das.

Alle meine Quellen hatte ich genannt, also wenn Du mich dabei ertappst, was nicht genau wiederzugeben: Freu Dich! (Hach diese Linuxforen. Herrlich, man wird nie enttäuscht).

Du hast eine Quelle genannt, die eine Behauptung aufstellt, ohne diese zu belegen. Da du im weiteren darauf hinweist, dass du es "gelesen hast", ging ich davon aus, dass Du mehrere Quellen zur Recherche benutzt hast, bevor Du dich einem derart komplexen Thema näherst.

Danke für den LUKS-Hinweis. Ist aber LUKS gegen eine Cold Boot-Attacke (Auslesen aus dem RAM gefeit)?

Ehrlich gesagt: Weiß ich nicht. Halte ich auch für unwesentlich. Bei einer Refresh-Rate von 1 Sekunde und weniger sind die bisherigen Attacken eher theoretischer Natur. In einem Paper, dessen Link ich nachreichen muss, musste mit flüssigem Stickstoff bereits VOR dem Ausschalten/Entfernen der Riegel gekühlt werden. Nicht gerade das Szenario, vor dem ich auf dem Weg in die Firma Angst habe.

Alles, was da bisher wirklich funktioniert hat, ist derart aufwendig, dass man dir auch einfach nen Freiflug nach Guantanamo (oder vergleichbare Einrichtungen) spendieren könnte und dir dort auf gut Deutsch die Passphrase aus dem Leib prügelt. Weniger drastisch gesagt: Eine Verschlüsselung schützt deine Daten nur, wenn Du nicht dazu erpresst werden kannst, die Passphrase herauszugeben. Das ist bei normalen Menschen aber eigentlich im Falle von Verlust und/oder Diebstahl der Fall. In dem Fall wird aber auch keiner eine Cold-Boot-Attacke versuchen, sondern die Platte fromatieren und im nächsten Pfandhaus absetzen.

Auf den Punkt gebracht in http://xkcd.com/538/

Es ist mir ja gelungen den Kernel zu booten. Ich hatte eine andere Frage gestellt.

Das mit der Lebensdauer der Daten im RAM: Das sind nicht nur ein paar Sekunden, siehe http://www1.informatik.uni-erlangen.de/tresor - Vielleicht magst Du Dich auch etwas fortbilden?

Dann gibt es noch den Neustart mit eingelegter LiveCD, da hat das RAM nicht mal eine Unterbrechung der Stromversorgung erfahren.

Und solange der Schlüssel im RAM liegt, geht wohl die msramdump - Attacke die Mike beschreibt: https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sophisticated_Attacks

xkcd ist auch bekannt, btw. . Ich kenn auch noch Lochstreifen aus eigener Anschauung.. (Jetzt wirst Du gleich vermuten ich sei zu verkalkt, wetten?)

hagenbuch schrieb:

Es ist mir ja gelungen den Kernel zu booten. Ich hatte eine andere Frage gestellt.

Ich verstehe das vorgehen nach Überlesen der von dir verlinkten Artikel nicht. Was willst Du mit dem chroot bezwecken? Abgesehen von Tresor willst DU doch im wesentlichen:

• eine verschlüsselte Partition zur Bootzeit aufschließen

• diese als / nutzen

Das ist - mit der /boot woanders - im wesentlichen das, was auch LUKS macht. Daher mein Hinweis, dir doch mal ein LUKS zu installieren und zu schauen was da anders ist. Oder verstehe ich dein Problem falsch?

Das mit der Lebensdauer der Daten im RAM: Das sind nicht nur ein paar Sekunden, siehe http://www1.informatik.uni-erlangen.de/tresor - Vielleicht magst Du Dich auch etwas fortbilden?

Gern und grade im securitybereich immer. Allerdings müssen DRAM-Bausteine refreshed werden (meines Wissens nach alle sek einmal, les ich aber nach). Ohne den Refresh werden sind die Daten auch unter Stromversorgung flüchtig und es treten Bitflips auf. Die sind bei normalen Nutzdaten kaum problematisch, bei Keyfiles aber wohl (ich vermute, das muss ich nicht weiter erklären). Überall wird von "ein paar Sekunden BIS zu Minuten" im Laborbereich geschrieben.

Nach weiterem stöbern in deinen Links (komplett lesen schaff ich erst morgen) fällt mir auf, dass das als Ressource genannte Princeton Paper LUKS nicht explizit nennt. Einen Teil der Papers kenne ich in der Tat bereits.

Dann gibt es noch den Neustart mit eingelegter LiveCD, da hat das RAM nicht mal eine Unterbrechung der Stromversorgung erfahren.

Siehe oben: Auch dann sind die Daten nicht mehr wirklich zuverlässig, in meinen Augen

Und solange der Schlüssel im RAM liegt, geht wohl die msramdump - Attacke

Dazu würd ich gern einen Proof-of-concept sehen, sprich tatsächlich ausgelesenen Key. Nicht, dass ich die Diskussion an sich für unsinnig halte, ganz im Gegenteil. Man kann und sollte sich über derlei Risiken Gedanken machen, bevor die ausgenutzt werden können. Die Frage - die wir beide wohl vorerst nicht beantworten können - ist, ob die Attacke in the wild genutzt werden kann.

xkcd ist auch bekannt, btw. . Ich kenn auch noch Lochstreifen aus eigener Anschauung.. (Jetzt wirst Du gleich vermuten ich sei zu verkalkt, wetten?)

Nichts läge mir ferner.