staging.inyokaproject.org

Hallo,

Ist noch nicht ganz fertig...vielleicht hat jemand Lust mal drueber zu lesen.

Danke

Also die Idee ist, im "Notfall" den PC runterzufahren, den USB-Stick reinzuschieben, den Rechner aufzuwecken (diesmal aber das System auf dem USB-Stick) und dieser löscht dann die SSD, richtig?

Wie zuverlässig ist denn die Zuordnung über /dev/sdX? Kann man das auch über die UUID o.ä. machen?

Mal von den Fehlern (Typos u. fehlende Leerzeichen) abgesehen, ist das ne ziemlich komplexe und unzuverlässige Methode.

Das Hauptproblem an dem Artikel ist aber: Kein Mensch braucht das. Klingt mir mehr nach einem Artikel fürs eigene Blog als fürs Wiki.

Interessant dazu auch http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions 5.18

Surst schrieb:

Also die Idee ist, im "Notfall" den PC runterzufahren, den USB-Stick reinzuschieben, den Rechner aufzuwecken (diesmal > aber das System auf dem USB-Stick) und dieser löscht dann die SSD, richtig?

In diesem Fall ist der Computer schon im Standby und wir haben vom USB-Stick gebootet und das Skript aufgerufen. Nun aktivierst du deinen Auslöser. Zb eine Türe wird unbefugt geöffnet; Der Mechanismus betätigt eine Taste an der Tastatur; System wacht auf und macht ein Secure-Erase.

Wie zuverlässig ist denn die Zuordnung über /dev/sdX? Kann man das auch über die UUID o.ä. machen?

Solange das System nicht verändert wird bleib die Laufwerksbezeichnung auch die Selbe. Eine Version mit UUID’s sollte aber auch machbar sein.

frostschutz schrieb:

Mal von den Fehlern (Typos u. fehlende Leerzeichen) abgesehen, ist das ne ziemlich komplexe und unzuverlässige Methode.

Welcher Teil genau ist unzuverlässig?

Das Hauptproblem an dem Artikel ist aber: Kein Mensch braucht das. Klingt mir mehr nach einem Artikel fürs eigene Blog > als fürs Wiki.

Alles ist relativ. Versetz dich mal in die Lage eines Menschen dessen Leben von einem Datenträger anhängt, oder sogar das Leben Anderer die durch eine Kompromittierung betroffen würden.

Interessant dazu auch http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions 5.18

Nimm mal an du lebst in GB und dein Computer wird auf Grund eines Verdachtes beschlagnahmt. Dein System ist komplett verschlüsselt und du hast keine Lust den Schlüssel aufzugeben. Jetzt kannst du in Beugehaft kommen und das solange bis du den Schlüssel aufgibst. So hat es ja gar keinen Sinn mehr seine Daten zu verschlüsseln. Und GB is nicht mehr der einzige Platz wo dir das passieren kann; schau mal hier.

Welcher Teil genau ist unzuverlässig?

Alles? Schon allein daß es nur greift wenn jemand blöd genug ist die Schaltung zu aktivieren. Und eben nicht mehr nach Stromausfall etc. pp.

Das Secure Delete mit dem (sehr richtigen) Zusatz daß man dem Hersteller vertrauen muß, in dem Paranoiaszenario keine Option. Nebenbei gibts auch sonst einfach zu viele Fälle wo Secure Delete nicht funktioniert, das hdparm mit passwort usw. ist ne ziemlich wacklige Angelegenheit.

Wenn du sowieso schon Verschlüsselung einsetzt, bist du mit einem Script das den LUKS-Header überschreibt, oder einem Setup das den LUKS-Header überhaupt extern verwahrt, besser unterwegs. Auf einem MicroSD-Cardreader am Schlüsselbund, wenn du weißt wie eine MicroSD-Karte aufgebaut ist kannst du die mit einem Handgriff zerstören (den Chip brechen). Wenn man dir nicht glaubt daß du keinen Schlüssel mehr hast und auch kein Backup existiert, wirst du dann halt trotzdem gefoltert. Pech gehabt.

frostschutz schrieb:

Welcher Teil genau ist unzuverlässig?

Alles? Schon allein daß es nur greift wenn jemand blöd genug ist die Schaltung zu aktivieren.

Das hat wohl nichts mit blöd zu tun. Es kommt nur darauf an wie raffiniert der Auslöser aufgebaut ist.

Und eben nicht mehr nach Stromausfall etc. pp.

Das System muss natürlich über eine Backup- Stromversorgung verfügen.

Das Secure Delete mit dem (sehr richtigen) Zusatz daß man dem Hersteller vertrauen muß, in dem Paranoiaszenario keine > Option.

Dann sollte man am besten gar keine Computer mehr benutzen da man wohl allen Hardware Komponenten vertrauen muss.

Nebenbei gibts auch sonst einfach zu viele Fälle wo Secure Delete nicht funktioniert, das hdparm mit passwort usw. ist > ne ziemlich wacklige Angelegenheit.

Natürlich muss man das vorher testen. Jede SSD ist verschieden. Aber wenn du das Skript einige Male laufen lässt und alles zur Zufriedenheit Abläuft, dann funktioniert es auch das nächste Mal.

Das System muss natürlich über eine Backup- Stromversorgung verfügen.

Interessanterweise sind gerade USV sehr häufig der Grund für - Stromausfälle. ☺ Ist eben ein Teil mehr in der Kette das kaputtgehen kann.

Dann sollte man am besten gar keine Computer mehr benutzen da man wohl allen Hardware Komponenten vertrauen muss.

Bei Secure Erase sind die Zweifel berechtigt, gibt/gab schon einige Modelle wo das nicht so funktioniert hat wie versprochen.

Wenn du Zufallsdaten auf ein Speichermedium schreibst und anschliessend wieder auslesen kannst, dann müssen die Daten auch geschrieben worden sein, da sich Zufallsdaten nicht wegoptimieren lassen (anders als Nullen, die auch durch TRIM oder Komprimierung ersetzt werden können). Solange die SSD dann intern nicht viermal so viel Speicherkapazität verbaut hat wie angegeben, ist der größte Teil der Daten dann auch tatsächlich weg. Und das garantiert.

Ich stimme dir zu; Secure-Erase funktioniert nur wenn es richtig implementiert ist. Das Ergebnis sollte wie im PDF link erläutert, getestet werden.

Überschreiben ist aber auch nicht das Gelbe vom Ei. Schau dir mal Punkt 3.2.2 an: https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf

frostschutz schrieb:

Wenn du sowieso schon Verschlüsselung einsetzt, bist du mit einem Script das den LUKS-Header überschreibt, oder einem Setup das den LUKS-Header überhaupt extern verwahrt, besser unterwegs. Auf einem MicroSD-Cardreader am Schlüsselbund, wenn du weißt wie eine > MicroSD- Karte aufgebaut ist kannst du die mit einem Handgriff zerstören (den Chip brechen). Wenn man dir nicht glaubt daß du keinen Schlüssel > mehr hast und auch kein Backup existiert, wirst du dann halt trotzdem gefoltert. Pech gehabt.

Absolut gute Idee! Gibt es da ne Doku wie man ein voll verschlüsseltes System mit externem Header aufsetzt?

Da das keine Standardlösung (im Sinne von was du im Installer auswählen kannst) ist wirst du wohl dein eigenes Initramfs stricken müssen (oder zumindest einen eigenen Hook schreiben).

Externer Header ist ansonsten gar kein Problem, wird von cryptsetup/LUKS direkt unterstützt.

Du musst beim cryptsetup luksFormat bzw. cryptsetup luksOpen einfach angeben wo der Header gespeichert ist/werden soll.

--header <device or file storing the LUKS header>
    Use  a  detached  (separated)  metadata device or file where the
    LUKS header is stored. This options allows to  store  ciphertext
    and LUKS header on different devices.

Ähnlich wie hier (aber anderer Zusammenhang) http://askubuntu.com/a/323130/161981

PS: Falls dir das mit dem Chip brechen zu unsicher ist (immerhin könnte man die Bruchstücke ja noch im Labor unterm Elektronenrastermikroskop usw.) empfehle ich stattdessen eine Nagelfeile... 😛 </paranoia>

Hi.

frostschutz schrieb:

PS: Falls dir das mit dem Chip brechen zu unsicher ist (immerhin könnte man die Bruchstücke ja noch im Labor unterm Elektronenrastermikroskop usw.) empfehle ich stattdessen eine Nagelfeile... 😛 </paranoia>

Für die Nagelpfeile ist es etwas knapp, wenn schon die entsprechende Regierungsorganisation an der Tür steht. Verbrennen bei hohen Temperaturen ist recht effektiv, man muss sich nur einen kleinen Ofen basteln, der das gefahrlos und schnell möglich macht. Da ist die Sache in 1 min gegessen und niemand kann jemals wieder etwas herstellen.

Da kommen ja noch ganze tolle Ansetze hervor! ☺

Da bietet sich ja die gute alte Mikrowelle an. Der Speicher sollte in wenigen Sekunden über den Jordan sein. Hochspannung würde sich auch anbieten.

stfischr schrieb:

Verbrennen bei hohen Temperaturen ist recht effektiv, man muss sich nur einen kleinen Ofen basteln, der das gefahrlos und schnell möglich macht.

Du meinst ein handelsübliches Feuerzeug? Gut, aber ich bin Nichtraucher, daher hab ich sowas nicht. 😉

Hallo,

frostschutz schrieb:

Das Hauptproblem an dem Artikel ist aber: Kein Mensch braucht das. Klingt mir mehr nach einem Artikel fürs eigene Blog als fürs Wiki.

+1, absolut

Gruß, noisefloor