Ergänzungen zum Encrypted Root Filesystem Howto

Zu dem ERFH (Encrypted Root Filesystem Howto) gibt es einige wichtige Anmerkungen/Updates, denn der letzte Stand ist von Anfang 2005, also heute (2013) teilweise nicht mehr aktuell.
Gleiches gilt auch für die loop-AES.README. Einige Updates und Ergänzungen findet man in den root encryption with loop-AES FAQs, aber auch dort wird kaum auf abstreitbare Verschlüsselung (deniable encryption) eingegangen, obwohl dies nach dem direkten Datenschutz durch Verschlüsselung das zweitwichtigste Ziel eines Root-Dateisystems ist, denn sie ermöglicht es, dass die Existenz der Daten erst gar nicht angezeigt wird und bietet damit keinen Angriffspunkt. Die abstreitbare Verschlüsselung ist sozusagen die Tarnfarbe oder das Tarnnetz für Daten und daher ein passiver zusätzlicher Schutz.
Und bei einem irgendwie begründeten Verdacht erreicht man durch die Abstreibarkeit, das zu dem Zweifel das vielleicht nicht wichtiges sondern das nur Datenmüll oder (noch) nichts oder unwichtiges verschlüsselt wurde, noch der Zweifel kommt ob überhaupt etwas verschlüsselt sein könnte, so wie bei einem Hidden Container.
Diese Zweifel kann man durch reichlich Spam, also mehr Datenmüll als wirklich verschlüsselte Daten, plausibler machen.
Die Ergänzungen sind daher auch Umsetzungen des Prinzips Fear, Uncertainty and Doubt.
Deshalb sind Datenträger mit eingebauter Verschlüsselung, z. B. der Ironkey USB-Stick oder Self Encrypted Drive (SED) wie die Seagate Maxtor BlackArmor Encrypted Hard Drive keine gute Idee, selbst wenn man davon absieht, das die Hersteller die Verschlüsselung nicht selten fehlerhaft und leicht umgehbar implementieren und das zudem versteckte Hintertüren eingebaut sein können.
Deshalb sind auch die ATA-Security-Funktionen sowie Datenträger mit eingebauter Selbstzerstörung wenig sinnvoll.
Das drittwichtigste Ziel eines Root-Dateisystems ist das System zu härten, wozu u. A. auch gehört das Booten abzusichern um das Einschleppen von Malware wie Bootkits oder Rootkits zu verhindern oder zumindest so frühzeitig zu erkennen, das sie keinen Schaden einrichten kann. Das ERHF geht aber hierauf aber nicht ein, obwohl dies ein wichtiger Beitrag zur Sicherheitskultur ist, so wie beispielsweise auch die MAC-Adressen zu Randomisieren durch einige Zeilen im Boot-Skript wie
macchanger -r eth0
macchanger -r wlan0

Umgesetzt habe ich diese Ergänzungen u. A. bei einem PC und einem Notebook; die Ergänzungen habe ich alle selbst getestet. Angefangen hatte ich mit einer verschlüsselten Home-Partition, also nur Verschlüsseln der User-Daten, aber das erwies sich als unzureichend, weil sich Datenspuren an vielen anderen Stellen zeigen, beispielsweise Swap, /tmp, /var und insbesondere die Locate-Datenbank weil sie die Dateinamen enthält. Zudem ist ein verschlüsseltes Root-Dateisystem durch die Verschlüsselung vor vielen Manipulationen geschützt.

Ergänzend sind hier ein paar Links zum Thema wieso man überhaupt verschlüsseln sollte:
Why You Should Use Encryption
ENCRYPTION - Why You Should Use it.
Why do you need PGP?. Faltblatt "Sicherheit durch Verschlüsselung" vom Bundesamt für Sicherheit in der Informationstechnik, kurz BSI.
Und daneben gibt es auch das Faltblatt des BSI mit dem Titel "Freie Software", kurz FS.
Schließlich hat man mit freier Software nicht den Nachteil von versteckten Hintertüren oder General-Schlüsseln, der in nicht-freier Software versteckt lauern kann, denn Sicherheitsprüfungen sind uneingeschränkt möglich ("1000 Augen-Prinzip"); das bloße Vertrauen in die Software kann durch eigenes Wissen über die Sicherheit ersetzt werden. Damit verhindert man Fehler wie "Security by Obscurity" und ähnliches Snakeoil, durch die sich beispielsweise Trojaner wie Flame unter Microsoft-Windows über die eingebaute Aktualisierungsfunktion Windows Update verbreiten: http://www.heise.de/newsticker/meldung/Flame-Details-zum-Windows-Update-GAU-1605475.html
. Weitere Vorteile von FS, neben den meist entfallenden Kosten, sind die Verfügbarkeit, die nicht verschwindet wenn der Anbieter verschwindet (z. B. durch Konkurs) oder er seine Software plötzlich weder verkauft noch supportet. Daneben bietet FS neben Vielfalt und Interoperabilität auch offene Standards, Protokolle und Formate.

Und daneben ist auch erwähnenswert das verschlüsselte Partitionen mehrere historische Vorläufer haben. Beispielsweise antike Verschlüsselungen wie die Caesar-Verschlüsselung und mit einem Schloss verschlossene Bücker, die spätestens seit dem Mittelalter verwendet werden:
Buch mit Schloss
Man findet auch heute noch hunderte solcher Bücher auch auf Ebay mit der Suche nach "Tagebuch Schloss".
Verschlüsselte Partitionen sind daher nichts revolutionär neues, sondern nur Stand der Technik, der sich seit der Antike in vielen kleinen Schritten entwickelte.

Erwähnenswert ist auch die philosophische Grundlage der verschlüsselten Root-Dateisysteme, die Gedankenfreiheit, denn sie ist die Freiheit des Denkens, insbesondere in weltanschaulichen und politischen Dingen. Entscheidend sind ja im realen Leben nicht Gedanken, oder was eine herrschende Gruppe sich an Gedanken bei den Untertanen wünscht, sondern Taten, wie ja schon in der Bibel steht, beispielsweise "An ihren Taten sollt ihr sie erkennen! (1. Johannes 2,1-6), wobei Worte ja schon über die Gedankenfreiheit hinaus gehen und zur weitergehenden Meinungsfreiheit gehören, während es hier nur um die Gedankenfreiheit geht. Die Gedankenfreiheit ist ja der Kern, die Voraussetzung weiter Freiheiten/Rechte wie der Meinungsfreiheit, Patentrecht/Urheberrecht, Firmengeheimnis usw.. Treffener ist hier zur Gedankenfreiheit daher das Kohl-Zitat "Entscheidend ist, was hinten rauskommt", denn damit ist klar das nicht entschiedend ist was drinnen (im Kopf an Gedanken) ist sondern was an Handlungen/Aktionen herauskommt. In der Moderne ist die Gedankenfreiheit selbstverständlich, denn schon in der Allgemeinen Erklärung der Menschenrechte der UNO steht dass jedermann Anspruch auf Gedankenfreiheit hat. Aber früher war es anders. Beispielsweise findet man in Friedrich Schillers Theaterstück Don Karlos, das der Marquis von Posa vom allmächtigen König verlangt: "Geben Sie Gedankenfreiheit.". Und auch heute noch ist die Gedankenfreiheit deutlich löchig, denn beispielsweise bei der juristischen Beurteilung von Taten ist nicht nur relevant was wie passierte, die Handlungen/Aktionen, sondern auch was dabei gedacht wurde, die Absicht. In einigen Ländern gibt es sogar heute noch Gedankenverbrechen, beispielsweise im Südkoreanischen Gesetz über die Nationale Sicherheit, § 7. Zu dem Thema gibt es Romane wie 1984 und Filme wie Minority Report.
Primär betrifft die Gedankenfreiheit die Gedanken im Gehirn, im Kopf, aber wenn man sie auf einem Recher wie einem PC notiert, beispielsweise in einem Tagebuch, einem Glaubensbekenntnis oder einem politischen Manifest, betrifft sie auch diesen Rechner und solange man die Daten nur dort behält, sind sie so wie die Gedanke im Kopf ohne eine Wirkung außen; sie sind keine Handlungen/Aktionen und ein unbefugtes Verwenden, schon ein Lesen, von anderern ist daher ein Verstoß gegen die Gedankenfreiheit. Mit verschlüsselten Root-Dateisysteme wird genau dies verhindert; sie dehnen die Gedankenfreiheit, die man im Kopf automatisch hat, auch auf die im Rechner notierten Gedanken aus. Damit ist es möglich im Rechner so "Herr im eigenen Haus" zu sein, wie man es im eigenen Kopf ist. Früher verwendete man dazu versteckt meist aufbewahrte Tagebücher, einige mit Vorhängeschloss, heutzutage kann man seine Daten mit moderner Kryptografie in verschlüsselten Root-Dateisystemen sicherer aufbewahren.

Allerdings eignet sich ein verschlüsseltes Root-Dateisystem kaum für Server, weil die üblicherweise nach dem Booten oder Reboot sofort aktiv sein sollen und nicht auf eine Benutzereingabe warten sollen, selbst wenn die über Fernwartungsstandards wie IPMI oder DASH auch aus der Ferne sicher möglich sind. Auf Servern sollte man daher verschlüsselte Partitonen verwenden, denn man kann die Verzeichnisse hieraus mittels

mount --rbind < souce > < destination >

über unauffällige Verzeichnisse des unverschlüsselten Root-Dateisystem einbinden. Die entsprechenden Server-Dienste, z. B. FTP, I2P usw. müssen danach neu gestartet werden.
In die Verschlüsselte Daten-Partition gehört neben den betreffenden Dateien, z. B. die in das I2P-Netz oder Freenet gestellten Dateien, auch die lokale Datenbank unter /var/lib/mlocate/. Daneben sollte auch die Historie ~/.bash_history auf die verschlüsselte Partition, die Log-Dateien sollten nach relativ kurzer Zeit automatisch gelöscht werden und auch alles in /tmp sollte bei jedem Booten gelöscht werden.
Zusätzlch kann man noch regelmäßig die freien Speicherbereiche überschreiben um das einfach gelöschte unwiederbringbar zu Löschen.

Ein noch aktuelles Problem ist die Verwendung von verschlüsselten Root-Dateisystemen im Embedded-Bereich, beispielsweise Smartphones. Bisher gibt es das nur im Entwicklungsstadium, vereinzelt und im Rahmen von Forschungsarbeiten, beispielsweise diese Diplomarbeit von 2011: http://www.isti.tu-berlin.de/fileadmin/fg214/matthias_petschick.pdf.
Ein Problem hierbei ist das man eine Linux-Distribution, oder ein MS-Windows mit Truecrypt, nicht so einfach wie beim PC installieren kann, so das man die Einrichtung nicht kurz während der Installation erledigen kann sondern extra durchführen muss. Hinzu kommen embedded-spzifische Probleme wie die Verschlüsselung von Flash-Dateisystemen.



Passwortabfrage beim Booten tarnen oder unsichtbar machen

Wenn ein Angreifer schon beim Booten sieht das ein Passwort abgefragt wird, wird er sicherlich versuchen das Passwort zu erfahren, siehe auch nächstes Kapitel.
Es gibt natürich auch Angreifer die nicht versuchen zu Booten sondern gleich den ganzen Rechner entwenden und die enthaltenen Datenträger auslesen, aber die meisten, beispielsweise Gelegenheitsdiebe oder das Personal beim Zoll, versuchen den Rechner zu Booten um sich einen ersten Überblick zu verschaffen.
Daher ist es empfehlenswert diesen Schwachpunkt zu beseitigen und das erreicht man indem man die Abfrage versteckt, unsichtbar macht oder als etwas anderes tarnt, beispielsweise als Fehlermeldung "Disk read error", wodurch auch die Festplatte/SSD für Angreifer unattraktiver wird.
Lesefehler
Dieses Tarnen, das hier im Bild zu sehen ist, geht über die Datei /usr/share/initramfs-tools/scripts/local-top/cryptroot. Darin ist der Text mit "Enter passphrase: " zu ändern in "Disk read error" oder eine andere Fehlermeldung oder irgendetwas anderes wie beispielsweise ein Leezeichen. Im obigen Bild wurde zur Demonstration nur das Ende dieses Textes modifiziert und der Anfang "Unlocking the disk $cryptsource ($crypttarget)" stehen gelassen. Diesen verräterischen Anfang sollte man in der Anwendung natürlich weglassen.
Entsprechend ist es mit der Fehlermeldung wenn ein falsches Passwort eingegeben oder einfach nur Enter gedrückt wird; hier ist die Zeile
  message "cryptsetup: cryptsetup failed, bad password or options?"
einfach auszukommentieren (mit vorangestelltem #), damit hier nichts ausgegeben wird.
Damit die Änderung übernommen wird ist ein "update-initramfs -u" auszuführen. Daneben benötigt man das pymouth (Paket plymouth), damit dieser Text auch wirklich beim Booten angezeigt wird, aber meist ist das Paket installiert und daher kein weiterer Aufwand nötig.
Es sollte nur alle paar Monate bis Jahre vorkommen das die Datei sich durch ein Update ändert und man wieder kurz anpassen muss und wann es wieder soweit ist erfährt man indem man die Datei kopiert und mit der Datei an der originalen Stelle vergleicht. Dazu kann man beispielsweise täglich über die crontab überprüfen, also

cmp /usr/share/initramfs-tools/scripts/local-top/cryptroot /root/archiv/cryptroot

auswerten und bei Differenz (= Rückgabewert $? > 0) eine Email zum User schicken. Verwendet man zum Updaten ein Skript, genügt ganz einfach die Zeile mit cmp am Ende vom Skript, denn nur bei einer Differenz bekommt man eine zusätzliche Ausgabe wie

/usr/share/initramfs-tools/scripts/local-top/cryptroot /root/archiv/cryptroot differieren: Byte 4711, Zeile 123.

Ebenso kann man die Konfigurations-Dateien vom Grub2 überwachen.
Allerdings zeigt sich in der Praxis bei der Eingabe eines falschen Passworts noch die Fehlermeldung "No key availible with this passphrase" von einer anderen Stelle, so das man über die cryptroot nicht alle verräterischen Meldungen beseitigen kann.

Zur Passwortabfrage kann es noch eine zweite Hürde beim Verstecken geben und zwar ein sichtbares Eingabefeld für das Passwort, in dem jedes eingegebene Zeichen als gefüllter Kreis angezeigt wird. Dagegen hilft ein Anpassen der /etc/default/grub: 1.) Entkommentieren vom Eintrag #GRUB_TERMINAL=console, d. h. die Raute am Anfang löschen, und 2.) die Zeile mit GRUB_CMDLINE_LINUX_DEFAULT Auskommentieren und Einfügen der Zeile
  GRUB_CMDLINE_LINUX_DEFAULT="noplymouth nosplash"
Damit die Änderungen wirksam werden ist danach update-grub auszuführen.
Meist sind dann die letzten angezeigten Meldungen irgendwelche Kernel-Meldungen, z. B. Fehlermeldungen, und es sieht so aus als wäre der Boot-Prozess deswegen stehen geblieben.

Hilfreich ist auch den Linux-Bootloader selbst zu verstecken, z. B. indem man im UEFI als Default einen MS-Windows-Bootloader einträgt, so das es vom Linux-Bootloader beim automatischen Booten nach dem Einschalten keine Spur gibt. Das Linux bootet man dann über das UEFI-Boot-Menü, üblicherweise mit F9 aufgerufen.

Der andere Weg, das unsichtbar machen, erreicht man mit einem weißen Hintergrundbild, vor dem die weiße Schrift unsichtbar ist. Verwendet man Grub2 zum Booten, fügt dazu in der /etc/default/grub eine Zeile mit einem weißen Hintergrundild ein:

GRUB_BACKGROUND="/usr/share/images/desktop-base/white.png

Alternativ setzt man alle Farben, also die für Texte und Hintergrund, auf schwarz oder eine andere Farbe:

GRUB_COLOR_NORMAL="black/black"
GRUB_COLOR_HIGHLIGHT="black/black"

Daneben gibt es bei Notebooks, allgemein bei mobilen Geräten mit integriertem Monitor, die Möglchkeit die Helligkeit beim Booten auf Null zu stellen, die Hintergundbeleuchtung auszuschalten, beispielsweise über den Kernel-Parameter acpi_backlight. Das ist aber stark geräteabhängig.

Hilfreich ist dazu ein anderes "Vorzeige-Betriebssystem" wie ein Microsoft-Windows zu installieren und das nach einem kurzen Timeout von beispielsweise 3 Sekunden automatisch zu booten. Schon damit hat man ein leicht übersehbares Boot-Menü.

In beiden Fällen müssen andere Hintergrundfarben und -Bilder auskommentiert werden und die Änderungen übernommen werden mit "update-grub".
Allerdings können Farben, Bilder und sogar Videos auch gesetzt werden in den Dateien unter /etc/grub.d, so das man auch die bearbeiten muss und die Änderungen können durch ein Update überschrieben werden. Weit weniger aufwändig und benutzerfreundlicher ist dagegen der andere Weg, die Passwortabfrage zu tarnen.

Daneben gibt noch die Möglchkeit per Default ganz simpel etwas anderes zu booten, z. B. per DVD-Laufwerk eine Knoppix-DVD oder von einen USB-Stick mit Bankix, so das überhaupt keine Passwortabfrage erscheint. Dazu muß man nur das BIOS entsprechend einstellen und DVD bzw. Stick anbringen. Über das Boot-Menü kann man ja trotzdem einfach von HDD/SSD booten.

Mit UEFI Boot ist das Verstecken sehr einfach, denn es reicht aus Windows als Default-Eintrag zu belassen. Dann erreicht man das Linux-Bootmenü nur über das BIOS-Bootmenü, das man durch das Drücken von Tasten wie ESC, F8, F9, F10 oder F12 erreicht; die genaue Taste steht in der jeweiligen Bedienungsanleitung. Zum zusätzlichen Verstecken kann man den Linux-intrag dort Dektivieren, z. B. durch Umbenennen vom Bootloader, so das man nur über "Boot from File" den Bootloader und darüber das Linux-Bootmenü erreichen kann.
Von all dem sieht man beim normalen Booten (vom Windows), bei dem ja keine Taste gedrückt wird, überhaupt nichts. Dies ist unabhängig davon ob nur UEFI Boot oder UEFI Secure Boot verwendet wird und funktionert beispielsweise bei den HP Spectre XT Ultrabooks problemlos.

Aufforderungen zur Passwortherausgabe

In der Praxis passiert es nicht selten das man, meist beiläufig, nach dem Passwort (für die verschlüsselte Root-Partition) gefragt wird oder dreist aufgefordert wird das Passwort "herauszugeben", beispielsweise mit Phishing-Emails oder von "Ermittlern", die gerne lügen das "die Spezialisten" das Passwort sowieso in 10 Minuten herausfinden. Dies ist ein Mythos, der für verschlüselte Partitionen falsch ist. Richtig ist das man mit Tools wie Ophcrack die Login-Passwörter aus UNVERSCHLÜSSELTEN Partitionen auslesen kann, aber das ist ohnehin bedeutungslos, da von unverschlüsselten Partitionen die Daten auch ohne Login ausgelesen werden können und Forensiker genau dies machen.
Man kann man zwar ganz legal die Herausgabe verweigern, mit dem Aussageverweigerungsrecht, das schon die antiken Römer respektierten ("Accusare se nemo debet", Niemand muss sich selbst belasten). Festgeschrieben ist dieser Bestandteil der abendländischen Kultur auch im internationalen Recht, u. A. im Internationalen Pakt über bürgerliche und politische Rechte,
http://wayback.archive.org/web/20090603010329/http://www.uni-potsdam.de/u/mrz/un/int-bill/ipbprde.htm Artikel 14, Paragraph 3, Absatz g.
Veröffentlicht wurde er u. a. im Bundesgesetzblatt von 1973.
Die neueste Fassung und Liste der Unterzeichnerstaaten findet man unter http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10000627.

Das ist aber nicht optimal, weil a) keine universelle, also immer anwendbare Strateigie, beispielsweise bei illegalen Befragungen/Gummihosen Kryptoanalyse ( http://de.wikipedia.org/wiki/Rubber-hose_cryptanalysis ), und b) unnötig konfrontativ, denn viele Leute verkraften eine solche negative Auskunft schlecht, das kratzt an ihrem Ego, und es sieht auch im Protokoll schlecht aus, wenn die "Mitarbeit" verweigert wird, auch wenn man dafür nicht bezahlt wird. Zudem ist man bei einer Weigerung meist ein ständiges Ziel weiterer Anfragen (Stalking).
Etwas besser ist die Strategie zu sagen das man es vergessen hat Allerdings kommt ein simples Vergessen in der Praxis selten vor und das ein Passwort genau dann vergessen wird, wenn danach gefragt wird, erscheint meist wenig glaubhaft. Glaubhaft und sehr wahrscheinlich ist Vergessen für altes und nicht mehr verwendetes wie die PIN-Nummer der vorletzten Geldkarte oder die vorletzte Telefonnummer.
Viel häufiger, glaubhafter und damit besser als das simple Vergessen ist das Vertauschen von Passwörtern, denn ein falsches Erinnern ist mindestens zehn mal häufiger als ein komplettes Vergessen. Und praktisch unangreifbar wird diese Erklärung wenn man ein unverschlüsseltes MS-Windows neben dem verschlüsselten Linux installiert hat, denn damit ist sogar schon fraglich ob man das Passwort für das Linux je erinnern konnte und ob es für mehr als einen kurzen Test genutzt wurde. Es kann ja eine Test-Installation sein, als Proof of Conzept, zu dem ein Passwort mal kurz aufgeschrieben aber nie auswendig gelernt wurde.

Das Verwechseln von Passwörtern ist kaum zu bezweifeln weil das praktisch jedem schon mehrmals passierte und man sieht es immer wieder beispielsweise in großen Firmen, in denen die Passwörter regelmäßig geändert werden, das jemand ein oder mehrere Passwörter zurückgesetzen lassen muss, weil sie nach einem längeren Urlaub verwechselt wurden. Dazu gibt es ja das Sprichwort "Irren ist menschlich" und der Mensch ist nunmal nicht perfekt; er vergisst, verwechselt und irrt täglich.
Zudem vermindert akuter Stress oder psychischem Druck das Erinnerungsvermögen, bekannt auch als Denkblockade oder Prüfungs-Blackout, ausgelöst hauptsächlich durch das Hormon Cortisol. Damit wird das Erinnern an ein nicht-triviales Passwort blockiert, aber nicht das Erinnern an ein Default-Passwort wie z. B. Geheim1234. Bei der ersten Anfrage nach dem Passwort sollte sie daher niemals sofort eines nennen, denn das ist unnatürlich und damit verdächtig, selbst mit dem quasi allgegenwärtigen Spaceballs-Passwort, also 12345 ( https://www.pctipp.ch/news/sicherheit/50277/ihr_passwort_12345_stimmts.html).
Sie sollten daher so tun als ob sie auf die Frage nach dem Passwort angestrengt nachdenken müssten und das erreichen sie ganz automatisch, da sie sich das erste falsche falsche Passwort gut überlegen sollten. Sie sollte sich nicht wenig Zeit lassen, mindestens 10 Sekunden, um zu zeigen das das Passwort kompliziert ist und nicht so einfach wie das Spaceballs-Passwort. Danach nennen sie ein pausibles Passwort, z. B. Ubuntu12345+ wenn sie ein verschlüsseltes Ubntu verwenden. Hilfreich ist hierbei auch ein nebenan installiertes Alibi-Betriebssystem mit einem ähnlichen Passwort, z. B. Ubuntu12345, für den Administrator/Root, denn das macht die Angabe plausibler und durch die eigentlich überflüssige Herausgab des richtigen Passworts beweisen sie ihre Kooperationsbereitschaft! Die meisten Juristen und auch Polizisten kennen die Hintergründe nicht und lassen sich allein schon damit beeindrucken und überzeugen, auch weil formal ja alles korrekt und zunächst zur Zufriedenheit aller erledigt ist.
Damit ist der Anfrager erstmal zufrieden gestellt und beschäftigt, so das alle Beteiligten erstmal glücklich sind. Früher oder später wird der Anfrager sich wahrscheinlich melden und sagen das das Passwort nicht stimmt, dann sollte man nachfragen ob denn wirklich kein Tippfehler vorliegt, das Passwort vielleicht falsch aufgeschrieben wurde oder die Shift-Taste (Großschreibung) aktiv war, weil man sich doch (offiziell) sicher ist, das richtige Passwort genannt zu haben. Zudem hat man sich durch die Kooperation einen Zeitvorteil verschafft, der das Verwechseln von Passwörtern zunehmend wahrscheinlich macht; die Zeit arbeitet für Sie, auch wenn sie Monate bis Jahre auf die Rückgabe ihres Eigentums warten müssen. Erst wenn Fehler bei der Passwortübertragung ausgeschlossen sind sollten sie sagen das sie die Passwörter wohl verwechselt haben. Das ist alltäglich, insbesondere unter Stress wie auch viele Beispiele zeigen. Beispielsweise verwechselte beim TAM-Linhas-Aéreas-Flug 3054 der Kapitän die aktuelle Landeprozedur mit der alten, auf einer Landebahn bei der man einen solchen Fehler höchstens einmal macht.
Deshalb sollte sie beim Nachdenken des aktuellen Passworts so tun als ob sie angestrenkt nachdenken und schließlich ein zum ersten ähnliches Passwort nennen, z. B. ubuntu12345, weil sie wie üblich sich nicht ständig neue Passwörter ausdenken sondern alte verändern, was sehr häufig vorkommt und daher mehr als nur plausibel ist. Stellt sich auch das zweite, dritte ... Passwort als falsch heraus, war es (offiziell) offenbar eine andere Modifikation und entsprechend sollte sie ein paar weitere Passwörter angeben, z. B. UbUnTu1234, wahlweise mit X Leerzeichen, Tabulatoren, Punkten oder anderem am Ende, da Passwörter eher hinten als vorne modifiziert werden. Damit zeigt man weitere Kooperationsbereitschaft und beschäftigt den Anfrager weiter. Ab ungefähr der dritten Nachfrage sollte man aber weitere Anfragen zurückweisen mit der Begründung das das Passwort offenbar verloren ist und man nicht mehr machen kann - so wie nach dem vorletzten Urlaub, nach dem man das Passwort für den Arbeitsplatzrechner vergessen hat und man über die IT-Hotline das Passwort zurücksetzen lassen musste.

Die Aufforderungen zur Passwortherausgabe kann man sich aber praktisch immer ersparen indem man, wie oben beschrieben, die Passwortabfrage versteckt und ein Vorzeige-Betriebssystem neben dem eigentlichen installiert hat. Und das kann man noch steigern indem man beispielsweise in das DVD-Laufwerk eine Knoppix-DVD legt oder einen USB-Stick mit Bankix ansteckt, so das automatisch das gebootet wird - ohne Passwort und daher ohne Frage nach dem Passwort. Kommt dann aufgrund der genaueren Untersuchung Wochen oder Monate später tatsächlich eine Frage nach (mindestens) einem Passwort, wenden sie einfach die oben beschriebene Verwechseln-Strategie an, an der durch die inzwischen verstrichene Zeit niemand mehr Zweifel haben kann, insbesondere wenn sie einen neuen Rechner mit neuen Passwörtern haben.

Daneben ist zu beachten, das man staatlichen Ermittlern nur Fragen zur Feststellung der Identität, also Name und Anschrift, direkt beantworten sollte und alle anderen nur im Beisein eines Anwalts oder über den Anwalt beantworten sollte, um nichts "untergeschoben" zu bekommen und sich nicht selbst zu belasten, auch wenn sie häufig versuchen von der ganzen Situation her zu überfordern, damit man unabsichtlich ein bisschen zu viel plaudert. Übliche einschüchternde Vorgehensweisen dazu Abholen mit einem SEK, Abnahme von Fingerabdrücken und Speichel (genetischer Fingerabdruck) und längere Befragungen.
Das man nur nur Fragen zur Feststellung der Identität direkt beantworten muss ist auch Nachzulesen im Polizeigesetz des betreffenden Bundeslands bzw. Staats.
Dieses Aussageverweigerungsrecht ist nicht auf Zivilisten beschränkt, denn Soldaten im Krieg müssen nur Namen und Dienstgrad angeben (Haager Landkriegsordnung, Anlage Art. 9).
Auf alle weiteren Fragen gibt man immer die gleiche Antwort: "Diese Frage beantworte ich nur im Beisein neines Anwalts." beziehungsweise "Gemäß der Haager Landkriegsordnung mache ich keine weiteren Angaben.".
Hilfreich ist dies auch bei der scheinbaren Herausgabe des Passworts, denn dadurch verzögert sie sich und man gewinnt Zeit, die für einen arbeitet, weil ein Verwechseln um so wahrscheinlicher und plausibler ist je mehr Zeit vergeht; man wird mit der Zeit immer glaubhafter und Angriffe werden zunehmend aussichtsloser.
Zudem sollte man nicht ganz selbstlos sein und zumindest in Erwägung ziehen wegen dem offensichtlich durch den Befragungs-Streß verlorenen richtigen Passwort Schadensersatzansprüche nach § 823 BGB geltend zu machen. Das macht nicht viel Aufwand, denn ein Brief als Einschreiben oder per Zustellung durch den Gerichtsvollzieher ist ja nicht sehr aufwendig und man muss ja nicht aufwendig Klagen sondern kann darauf verzichten.



Staging-Strategie, Wegwerf-Prototyp

Die Installation eines Betriebssystems, egal ob verschlüsselt oder nicht, ist eine komplexe Sache zu der viel gehört, angefangen von der Einrichtung der Benutzer, Server-Dienste, Bootloader, Treiber bis zu Updates und Details des Desktops. Zudem gibt es Inkompatibilitäten, beispielsweise ein fehlender oder nicht richtig funktionierender Treiber für unbedingt benötigtes wie die beim Notebook integrierte Webcam oder das integrierte WLAN.
Es ist daher durchaus sinnvoll zuerst das Wunsch-Betriebssystem mal kurz testweise zu installieren um zu sehen ob es sich a) überhaupt installieren lässt und b) die wichtigen Sachen, z. B. integrierte Webcam und WLAN, auch funktionieren. Dazu kann man beispielsweise mit einem Ubuntu beginnen und wenn das den Ansprüchen nicht genügt instlliert man einfach mal eine andere Distribution, z. B. ein OpenSuSE.
Zudem kann man bei der richtigen Installation die Fehler weglassen, die man beim Test machte, das gelernte umsetzen. Dieses Prinzip nennt sich in der Software-Entwicklung Staging und das installierte Betriebssystem wird als Wegwerf-Prototyp bezeichnet. Dies ist aber nicht auf eine einmalige kurze Installation beschränkt, sondern kann auch dauerhaft sein, als Test-System oder Sandbox an dem man Änderungen erstmal testet bevor man sie woanders vornimmt.
Bei einer einmaligen Installation merkt man sich das Passwort normalerweise nicht und genau das sollte daher auch die Strategie zu Anfragen dazu sein: Ein zufällig generiertes und mind. 20 Zeicchen langes Passwort das natürlich nicht auswendig gelernt wurde, denn es ist ja sinnlos etwas auswendig zu lernen was man nie wieder braucht.
Aber auch bei einem Test-System, bei dem man anhand der Einträge im Boot-Sektor erkennt das es diverse Updates (Kernel) gab hilft diese Strategie, denn a) bedeutet ein Test-System ein weiteres Passwort, d. h. ein Verwechseln des Passworts (voriges Kapitel) macht man hiermit noch mehr plausibel und b) kann man hier ganz plausibel behaupten das das Passwort ein externes Passwort ist, das man für dieses unwichtige Test-System nie auswendig lernte sondern woanders notiert hat, auch weil man es nur selten verwendet. Dazu sollte man sich natürlch eine konsistente Geschichte überlegen, beispielsweise ein Notizzettel im Schreibtisch in der untersten Schublade recht oder im Bankschließfach, denn so ein Zettel kann ja auch mal bei einem Aufräumen entsorgt worden sein, so das bei einer Überprüfung auch dessen Fehlen plausibel begrindet werden kann, wenn denn die Geschichte überprüft werden sollte. Dazu sollten sie sich nur die Eckpunkte der Geschichte einprägen aber nur wenige Details, zum einen weil sie dabei leicht Fehler einbauen können und die Geschchte unglaubwürdig wird und zum anderen weil ein Detailreichtum unglaubwürdig ist.
Das aktuell benötigtes kürzlich beseitigt wurde kennt man ja auch vom Aufräumen anderer Sachen: Einige Tage oder Wochen nach dem Wegwerfen stellt man fest das man das aktuell wieder braucht und man es besser nicht entsorg hätte. Dazu gibt es auch in Firmen viele Geschichten wie ein Lagersystem das gelagertes nach X Wochen entsorgt, auch wenn es nur gelagert wurde weil die Firma die Lieferfähigkeit gegenüber den Kunden für Y Jahre vertraglich zugesichert hat und das gelagerte nicht früher entsorgt werden darf. Eine andere Variante ist während der Entwicklungszeit eingelagertes, zu dem es auch nach X Wochen keine Auslagerung gibt, weil es natürlich noch keine Kunden dazu gibt und folglich kein Umsazt, keine Lagerentnahme; auch sowas wird mal automatisch entsorgt und fehlt dann den ersten Kunden.

Wichtig ist die Strategie mit dem Testsystem oder Wegwerf-Prototyp auch für die Backup-Strategie, denn Sie sollten sich bewußt sein das das System (PC, Notebook etc.) nicht nur plötzlich defekt sein kann sondern auch komplett weg sein kann, gestohlen, beschlagnahmt oder sonstwie weg. Es kann durchaus passieren das ein Geheimdienst zu ihnen kommt und sie zwingt die (nicht versteckte) Hardware zu erstören, so geschehen beim Guardian 2013: http://heise.de/-1938552.
Und daneben gibt es ja auch die reale Gefahr das sie das Passwort tatsächlich vergessen.
Daher sollten Sie auch ein produktiv genutztes System immer als Wegwerf-Prototypen betrachten, auf den sie verzichten können, den sie notfalls einfach wegwerfen können. Dazu brauchen sie eine Backup-Strategie, mit der Sie ihre wichtigen Daten gesichert habe, beispielsweise mit einem verschlüsselten Archiv in einer Cloud, auf einem USB-Speicherstick in einem Gerät das sich ohne Werkzeug nicht öffnen läßt oder hnter einer Abdeckung versteckt oder auch im Garten vergraben und eine Festplatte im Bankschließfach, wobei die Backups natürlich alle verschlüsselt sein sollen. Im Worst case verlieren sie dann nur die Daten, die seit der letzten Aktualisierung angefallen sind, aber die allermeisten Daten haben sie durch ihre Backups gesichert.



Randomisieren des Datenträgers

Das ERFH empfiehlt eine Randomisierung des Datenträgers, also Löschen durch Überschreiben mit Zufallszahlen, mittels shred. Allerdings verwendet shred mit den angegebenen Parametern nur /dev/urandom, so das man stattdessen gleich dd oder besser ddrescue oder dd_rescue nehmen kann (d. h. ddrescue -b 4096 -r 2 -v /dev/urandom /dev/<HDD> 2>&1 | tee logr.txt).
Das /dev/urandom ist aber 2009 mit um 3 (32-Bit-Linux) bis 6 MByte/s (64-Bit-Linux), 2013 ungefähr doppelt so schnell, relativ langsam: Eine mittelgroße Festplatte mit einer Größe von 2 TB zu Randomisieren dauert entsprechend um eine halbe Woche (2.000.000 MB / 6 MB/s = 333.333 s = 92,6 h = 3,86 d).
Diese Zeit muß man vorher einplanen und natürlich muß der dafür verwendete Rechner ununterbrochen eingeschaltet sein und das Schreiben darf nicht unterbrochen werden, will man nicht mehrmals neu beginnen mit der Option --output-position=<pos>.
Man kann dies beschleunigen, indem man mindestens diese Zeit lang vorher eine große Festplatte als Zwischenspeicher nutzt, der ständig mit /dev/urandom vollgeschrieben wird, denn dann kann man diesen Platteninhalt mit ca. 80 MB/s anstatt /dev/urandom mit nur ca. 6 MB/s verwenden.
Die Geschwindigkeit von /dev/urandom hängt auch vom CPU-Takt ab: Beim Opteron 875 (2,2 GHz) liegt sie unter 64-Bit-Linux bei 5,4 MB/s während es mit W5580 (3,2 GHz +Turobo-Boost, Stepping 5) schon 9,8 MB/s sind und mit einem 32-Bit-Linux, Knoppix 6.0.1, noch 7,9 MB/s. Wie bei allen CPU-lastigen Benchmarks hängt die Geschwindigkeit auch mehr oder minder vom Stepping ab und da für /dev/urandom nur ein Thread verwendet wird, ist die Anzahl der CPU-Kerne egal (solange für /dev/urandom ein Kern praktisch komplett benutzt werden kann.).

Hintergrund für die Randomisierung ist das fabrikneue Datenträgern fast immer mit einem simplen Datenmuster, praktisch immer nur 0-Bytes, gefüllt sind und ein Formattieren an der Einfachheit (geringen Entropie, genaugenommen geringer Entropie-Belag) des Datenmusters fast nichts ändert, während verschlüsselte Daten nicht so einfach sind (hohe Entropie), so das ein Angreifer zumindest erahnen kann das und wieviel verschlüsselte Daten gespeichert wurden. Stellt man die gespeicherten Daten als Matrix von Bits dar, sieht dies ungefähr so aus (Quelle http://www.linuxjournal.com/article/7743):


Ein Beispiel mit Randomisierung und Farbe ist

dd if=/dev/urandom of=tmp1.bmp bs=1 count=3600054
dd if=tmp.bmp of=tmp1.bmp count=54 bs=1 conv=notrunc
gimp tmp1.bmp

nach dem Anlegen eines weißen 1200x1000 Pixel großen Bildes mit gimp und Abspeichern als tmp.bmp (oder Downloaden von hier).
Das Bild tmp1.bmp zeigt farbiges Rauschen, wobei für jedes Pixel ein Byte für Rot, eines für Grün und eines für Blau verwendet wird (8R 8G 8B-Format).

Ein simples Datenmuster als Vorbelegung erleichtert Angreifern die Suche nach Dateien, die zwar gelöscht, aber noch nicht überschrieben wurden, denn der Datenmüll führt zu Fehlalarmen und macht die nicht überschriebenen Dateien schwerer auffindbar. Hierzu ein Beispiel: Wird case-insensitiv und mit ANSI-Codierung nach "sex" gesucht, ist die A-Priori-Wahrscheinlichkeit für einen Treffer in einer Folge von drei Zufallsbytes 1/1283=2-21. Die gesuchte Zeichenfolge kann sich an jeder Position auf dem Datenträger befinden, also bei Byte 0, 1, usw. beginnen. Dies ist genau genommen eine Näherung, weil bei einem Treffer mit diesem Suchmuster das nächste erst hinter dem aktuellen gefunden werden kann, aber für eine grobe Berechnung (erste Näherung) reicht es. In 2 TiB = 241 Zufallsbytes ergeben sich damit im Mittel 241-21=220, also rund eine Million Fehltreffer. Case-Sensitiv ergibt sich ein Achtel, also rund eine viertel Million Fehltreffer.

Ein weiterer Punkt ist das ein Image (Speicherabbild) mit einem simplen Datenmuster als Vorbelegung leicht komprimierbar ist, was Angreifer zum Komprimieren nutzen können um das Image unauffälliger zu transferieren, z. B. mittels Trojaner, und was ihnen auch das Speichern des durch die Komprimierung verkleinerten Images erleichtert.
Für den authorisierten Benutzer hingegen gibt es durch die Randomisierung keinen Nachteil, denn wenn überhaupt benötigt er ein Image auf Dateiebene; der Datenmüll zwischen den Dateien wird bei den üblichen Images, für Backups oder zum Klonen, schicht ignoriert.
Deshalb sollte der Datenträger vor dem Speichern von Daten mit Zufallsbytes beschrieben werden (Randomisierung) und zwar unabhängig davon ob der Inhalt anschließend verschlüsselt wird oder nicht.
Dafür eignet sich sehr gut das /dev/urandom, das ein Psudozufallszahlengenerator ist, der durch echt zufällige Ereignisse wie Tastendrücke regelmäßig neu initialisiert wird, so das die Pseusozufallszahlen praktisch nicht von echten Zufallszahlen unterscheidbar sind und trotzdem relativ schnell produziert werden. Wem das einfache /dev/urandom nicht reicht, kann z. B. das Debian-Paket randomsound installieren um /dev/urandom (und /dev/random) mit mehr zufälligen Ereignissen zu füttern; bei mir wurde /dev/random damit 100 mal schneller und /dev/urandom entsprechend mehr echt zufälliger (d. h. der Entropiebelag höher).
Es gibt zwar auch Spezial-Hardware die physikalische Entropie verwendet und damit echte Zufallszahlen schneller produziert (true-random.com), aber die ist nicht billig und nur zum gelegentlichen Randomisieren übertrieben.
Vor dem Randomisieren sollte der Datenträger mit einem Schreib-Lese-Test getestet werden, denn Fehler können an vielen Stellen (Kabel, Controller, RAM, CPU, ...) auftauchen und Dateien beschädigen. Dafür reicht auch ein von CD/DVD oder USB-Stick gebootetes Knoppix völlig aus.
Führt man den Test mit einem Zufallsmuster aus, hat man sowohl den Datenträgertest als auch eine grobe Randomisierung erledigt. Hierfür reicht schon

badblocks -wsv -c 65536 -t random -o log.txt /dev/<device> 2>&1 | tee logg.txt

Sollte es hierbei Fehler geben, sollte zuerst der Fehler lokalisiert und beseitigt werden.
Um Datenverlust möglichst zu vermeiden, sollt man den Datenträger nach dem erfogreichen Test monitoren, z. B. mit

smartctl -a /dev/<device>

Und zum automatischen täglichen Testen kann man z. B. das Skript check_hds.sh mit folgender Zeile in der /etc/fstab nehmen:

1 6     * * *     root     cd /root/bin; /bin/bash ./check_hds.sh

Mit dem obigen Test durch badblocks erreicht man eine brauchbare Randomisierung, die minimalen Ansprüchen genügt, denn das badblocks randomisiert nur grob, weil a) nur Pseudozufallsdaten verwendet werden und b) nur ein Block mit diesen Zahlen verwendet wird, der nur wiederholt wird wenn der Datenträger größer ist. Diese Randomisierung ist daher relativ leicht rekonstruierbar und nicht richtig zufällig.
Zudem verwendet badblocks bei mehreren Durchläufen (Parameter -p num_passes) immer das gleiche Muster, so das mit Zufallsmuster nur ein Durchlauf sinnvoll ist.
Per default (ohne die Option -c) verwendet badblocks einen Datenblock von 64 kiB und der Startwert der Pseudozufallszahlen ist echt zufällig (time(NULL)). Dies ist zumindest beim badblocks aus dem Paket fsprogs Vers. 1.41.9 und wohl auch allen früheren Versionen der Fall.
Das reicht um einen Datenträger (und Datenkabel, Controller etc.) zu testen oder vor einem Verkauf sicher zu löschen und gleichzeitig zu dokumentieren ob er noch fehlerfrei ist, aber nicht für eine sichere Randomisierung.
Dieser Test erfolgt schnell (mit voller Schreib-/Lesegeschwindigkeit) und dauert bei einer 2 TB großen Festplatte und einer typischen mittleren 3,5"-SATA-HDD-Transferrate um 80 MB/s rund 14 Stunden (4.000.000 MB / 80 MB/s = 50.000 s = 13,89 h). Diese 14 Stunden werden beispielsweise bei einer per SATAII angesschlossenen 3.5" WD 2 TB Caviar Green WD20EARS, 7200 UPM, 64MB Cache, gemessen.
Hierbei wird das Geschriebene zur Überprüfung gelesen, so das insgesamt 4 TB transferiert werden. Daher lässt man diesen Test am Besten nebenbei, nachts oder am Wochenende laufen.
Dieser Test sollte auch deshalb nicht ausgelassen werden, weil man damit (nach badblocks) insgesamt zweimal randomisiert, und das ist sinnvoll bei Datenträgern bei denen mehrfach überschriebene Daten rekonstruiert werden können, z. B. Disketten und Festplatten, denn dort bietet man Angreifern gleich mehrfach randomisierte Daten, mit denen sie nichts anfangen können und beschäftigt sie damit etwas länger.

Empfehlenswert ist daher immer zuerst eine quck+dirty-Randomisierung mit badblocks durchzuführen. Zusätzlich sollte anschließend einmal mittels urandom randomisiert werden, zumindest wenn genügend Zeit dafür vorhanden ist.
Dieses zweimalige Randomisieren mit nur einer sehr guten Randomisierung ist ein Kompromiss, denn z. B. bei der Gutmann-Methode zum sicheren Löschen durch Überschreiben werden Daten auf der Festplatte 35-mal überschrieben, 8-mal davon mit Zufallsbytes, um sie sicher zu überschreiben. Allerdings ist beim Löschen durch Überschreiben die Qualität der Zufallszahlen nebensächlich. Deshalb werden hierfür meist simple Pseudozufallszahlengeneratoren wie Mersenne-Twister verwendet, die zwar schnell sind, aber identifiziert werden können und sich deshalb für kryptografische Anwendungen wie eine richtige Randomisierung nicht eignen.
Allerdings ist schon ein zweimaliges Randomisieren sehr sicher und mehr als ausreichend auch bei hohen Sicherheitsansprüchen, denn in der Praxis ist schon ein einmaliges Überschreiben völlig ausreichend. In der c't 2009, Heft 20 steht auf Seite 87 dazu: "Der Mythos, das es Datenrettern oder gar Geheimdiensten mit aufwendigen Gerätschaften gelingen könnte, einmal überschriebene Daten wieder hervorzuzaubern, hat sich nie bestätigt. Jeder professionelle Datenretter hat uns in den letzten Jahren versichert, das dies technisch nicht möglich sei.".
Das Bundesamt für Sicherheit in der Informationstechnik (kurz BSI) ist gleicher Meinung und schreibt dazu: "Untersuchungen von Forensik-Laboren haben gezeigt, dass bereits nach einem Durchlauf mit geeigneten Zeichenfolgen oder Zufallszahlen keine Daten mehr rekonstruiert werden konnten.", Quelle https://www.bsi.bund.de/cln_183/ContentBSI/grundschutz/kataloge/m/m02/m02433.html.

Wichtig ist, das nach dem Randomisieren das Formattieren von Dateisystemen immer quick/fast/schnell durchgeführt werden sollte, weil sonst mit der Formattierung die Partition mit einem simplen Datenmuster wie 0x00 gefüllt wird, was die Randomisierung löscht.

Abschließend noch der Hinweis das es als Alternative zum urandom das frandom gibt, das fast genau so gut ist, aber rund 15 mal schneller sein soll. Die Messung mit einem Core i7 940 (2.93GHz) zeigt um 250 MB/s, was rund 30 mal schneller ist als urandom. Damit ist beim Randomisieren meist der Datenträger der Flaschenhals und nicht der Zufallszahlengenerator.
Man kann dem shred mit der Option --random-source= angeben frandom statt urandom zu nutzen um es schneller zu machen.
frandom eignet sich auch gut um in den nicht immer zu vermeidenden unverschlüsselten Partitionen schon einfach gelöschte aber noch nicht überschriebene Dateien dadurch zu löschen, das men den freien Bereich, und damit diese Dateien, überschreibt.
Ein einfaches Beispiel:

file=/tmp/foo.bar; ddrescue -r 3 -b 4KiB /dev/frandom $file; rm -rf $file

und dies kann man einfach automatisieren, z. B. über die crontab.
Getestet habe ich statt dem GNU ddrescue auch das simple dd, aber unabhängig von den Optionen hat das zumind. bei der verwendeten 120 GB SATA HDD auch ebensoviel gelesen wie geschrieben und daher eine Schreib-Performance von nur 12 MB/s wenn eine Blockgröße von 512 (=default) verwendet wurde, während schon "cat /dev/frandom > /dev/sdb" 50 MB/s schaffte, also rund das Vierfache! Bei einer Blockgröße von 512 ist das ddrescue rund doppelt so schnell wie dd und im Gegensatz zum dd liest es nicht beim Schreiben, so das es mit den im Beispiel verwendenten 4 kiB Blockgröße ebenfalls 50 MB/s schaffte.
Der Haupt-Nachteil vom frandom ist das es manuell installiert und konfiguriert werden muß.


Art des Boot-Mediums

Empfohlen wird im ERFH als Boot-Medium eine CD, was im Prinzip nicht schlecht ist, weil sie nur schwer modifiziert werden kann, ohne das der Benutzer dies merkt.
Dies ist nicht mehr ganz zeitgemäß, denn zusätzlich zum Noteboot oder Netbook eine sicher aufbewahrte CD mitzuschleppen ist umständlich und viele kleine Notebooks wie auch Netbooks generell haben überhaupt kein Laufwerk für CD/DVD. Inzwischen können aber praktisch alle nicht uralten Rechner von USB-Sticks booten und die kleinen USB-Sticks kann man viel sicherer aufbewahren, z. B. im Inneren einer Gürtelschnalle oder als Halskette ständig am Körper: https://sslsites.de/www.true-random.com/homepage/projects/usbsticks/small.html.

Es gibt auch nicht-kleine USB-Sticks mit integriertem Passwort/Pin-Schutz wie z. B. den Corsair Padlock.
Aber solche Sticks sind verdächtig, da damit offenbar etwas verheimlicht wird, und den meisten dieser Sticks kann man auch ohne das Passwort / die Pin die Daten ohne großen Aufwand entnehmen; sie sind meist nicht sehr sicher.

Empfehlenswert ist aber weiterhin ein separates Boot-Medium zu nehmen, denn damit ist das encrypted root file system (ERF) auf dem Rechner nicht nachweisbar, solange das Passwort geheim oder vergessen bleibt, denn auf dem betreffenden Rechner ist ja nicht einmal die zum Entschlüsseln nötige Software sichtbar. Schließlich sieht der Fehlerfall eines falschen Passworts genau so aus wie eine Partition, die tatsächlich mit Datenmüll gefüllt wurde (bei Verfahren ohne unverschlüsselten Header wie Loop-AES).
Dazu gehört natürlich auch das die Passwörter die Mindestanforderungen erfüllen, also:

Wichtig ist neben dem separaten Boot-Medium natürlich die funktionierende Boot-Konfiguration, die vor dem Installieren mit dem ERF vorhanden war, unverändert zu lassen! Schließlich soll der Rechner möglichst unauffällig sein und das ERF immer glaubhaft abstreibar sein. Deshalb sollte man vorher alle anderen Betriebssysteme installieren.


Attrappen, Spam auf und mit Boot-Medien

Eine generell hilfreiche Technik sind Attrappen/Spam, denn die sind wirksam und finden sich in vielen Lebensbereichen, beispielsweise in Form von Kosmetik, Tarnkörpern/Täuschkörpern und vielem anderen mehr.
Im ERFH wird auf dem Boot-Medium nur eine Boot-Partition und die nur für das ERF verwendet, was natürlich verdächtig ist wenn jemand das Boot-Medium untersucht; das kann Fragen aufwerfen und Spekulationen anstoßen, die man sich ersparen sollte, denn die Unschuldsvermutung ist in der Rechts-Praxis häufig nicht vorhanden, auch in Rechtsstaaten wie Deutschland: http://www.lawblog.de/index.php/archives/2009/02/24/verschlusseln-macht-verdachtig/, http://www.netzeitung.de/internet/340514.html.

Daher sollte man die Verschlüsselung zmindest nicht offensichtlich konfigurierern und Spam eine Möglichkeit, neben der ein unverschlüsseltes Betriebssystem neben dem verschlüsselten zu installieren und per default zu booten, wie weiter unten beschrieben und auch empfehlenswerter ist, weil es schon etwas verdächtig ist, wenn ein Rechner kein Betriebssystem hat.
Deshalb sollte man ein vorinstalliertes Betriebssystem, ob MacOS oder MS-Windows, nicht deinstallieren oder einfach zur Überschreiben, sonder es nur Verkleinern, über die Datenträgerverwaltung und über Rechtsklick. Das Linux kann man daneben installieren. Daneben kann man die beiden Methoden auch kombinieren.
Hilfreich ist auch mehrere "Karteileichen" im Bootmenü anzulegen, z. B. Für OpenSuSE und RedHat, um glaubhaft zu machen das alles neben dem MS-Windows nur Tests sind. Dazu ist auch hilfreich entsprechende Aufkleber anzubringen, denn ein Aufkleber einer Linux-Distribution ist ja ebenso ein Beleg wie ein Windows-Aufkleber. Diese Aufkleber findet man auf Linux-Tagen, in den jeweiligen Websphops, z. B. zu Ubuntu unter http://shop.canonical.com/product_info.php?products_id=718. Man kann sie aber auch selber drucken, z. B. auf Herma Inkjet Folien-Etiketten A4 transparent 210x297 mm Folie, Für Laserdrucker und Kopierer die Etiketten transparent matt A4 210x297 mm oder Etiketten transparent glasklar A4 210x297 mm.

Wichtig ist beim Spamming das Boot-Medium für das ERF als etwas anderes zu tarnen, indem man vieles andere drauf packt; z. B. eine Knoppix-DVD, die ja auch FreeDOS und Memtest86+ hat, was man z. B. für ein BIOS-Update oder einen Speichertest gelegentlich benötigt.
Für den Zweck habe ich ein Skript gemacht, das Knoppix auf einen USB-Stick installiert: https://sslsites.de/www.true-random.com/homepage/projects/usbsticks/index.html#knoppix.
Beispielsweise erhält man durch Installieren der Knoppix 6.2 DVD, Ophcrack und Torpark auf den Stick rund 4 GB in rd. 500 Dateien.
Die Einträg für das ERF sollte man nicht oder zumindest nicht sichtbar im Bootloader-Menü eintragen; man weiß ja dass sie da sind und sollte sie daher blind benutzen.
Ein Beispiel für Knoppix (6.2) findet man hier: syslinux.cfg mit zwei beim Booten unsichtbaren Einträgen am Ende. Das Skript zum Installieren vom Knoppix auf USB-Speicherstick findet man hier.

Ein anderer Aspekt ist das wenn man Spammt nicht nur auf dem Boot-Medium spammen sollte sondern auch mit Boot-Medien selber: Statt einem oder zwei USB-Sticks sollte man ca. 10 Stück haben und alte sowie defekte Sticks sollte man sammeln um sozusagen einen Heuhaufen um eine Nadel (einen Stick mit einem ERF-Eintrag der verwendet wird) aufzuhäufen. Ein oder zwei der Sticks verwendet man zum Booten eines ERF und die anderen enthalten nur ungenutzte Einträge für ein ERF (Fake). Falls denn jemand diese Einträge finden sollte, fallen sie nicht auf weil sie ja auf allen gefundenen Sticks sind; es ist plausibel das diese Einträge nur da sind weil das "schon immer so gemacht" wurde und mehr als genug Speicherplatz dafür vorhanden ist.

Wichtig ist das Spammen auch für die Sicherheit gegenüber Manipulationen des Boot-Prozesses (siehe unten): Ein Angreifer der ein Dutzend Sticks findet, von denen jeder zum Booten eines ERF verwendet werden könnte, hat beim Manipulieren des Boot-Prozesses ein dutzend mal mehr Arbeit als mit nur einem Stick und dabei ist das Risiko, das die Manipulationen entdeckt werden, ein dutzend mal höher. Und verwendet das Opfer einen dem Angreifer unbekannten und versteckten Stick, war der Angriff erfolglos, obwohl er Spuren hinterließ, die den Angreifer verraten können.
Durch Spammen wird ein Angriff auf den Boot-Prozess daher deutlich unattraktiver und unwahrscheinlicher.

Das Verwenden von einem externen Medium schützt auch vor Bootkits auf der Festplatte und auch vor Malware, die so in den MBR schreibt, das viele Bootloader danach nicht mehr booten können. Zu dieser Sorte sabotierender Malware gehören auch die Programme von Adobe, die eine Lizenz abfragen, z. B. Adobe Creative Suite 3: http://sebastiankabis.net/WP/2008/02/27/kaputter-bootloader-adobe-cs3-kopierschutz-modifiziert-den-mbr/.


Verschlüsselungsverfahren

Mainstream ist aktuell (2011-2014) dm-crpyt, das meist mit der Erweiterung LUKS verwendet wird. Wenn man es einsetzt sollte man darauf achten es im XTS-Modus zu verwenden: http://heise.de/-2072199.
Der Haupt-Nachteil von LUKS ist das es einen Header im Klartext verwendet, der die verschlüsselte Partition enttarnt: http://de.wikipedia.org/wiki/Dm-crypt#On-Disk-Format.
Am Anfang sieht man mit einem Hex-Editor das Wort "LUKS".
LUKS ist deshalb suboptimal, denn es ist ein deutliches Indiz für ein ERF, das dessen glaubhafte Abstreitbarkeit sabotiert! Beispielsweise nervt OpenSuSE 11.1 (auf einer anderen Partition) bei einer LUKS-Partition nach jedem Booten mit einer Passwort-Abfrage, auch wenn die verschlüsselte Partition nirgends im OpenSuSE eingetragen wurde und zusätzlich die Partition im MBR als leer eingetragen ist.
Den Klartext sieht man z. B. wenn man den ersten Block ausliest (z. B. mittels dd if=/dev/sdb3 of=firstblock.bin bs=512 count=1) und sich anschließend mit einem Hex-Editor wie khexedit ansieht.
Das Klartext-Format vom LUKS-Header kann man aber nutzen um eine LUKS-Partition vorzutäuschen (faken). Hierzu braucht man nur die ersten 592 Bytes einer LUKS-Partition an den Anfang einer mit Datenmüll gefüllten Partition kopieren, z. B. mittels dd. Das Faken kann man u. A. anhand der UUID im Header erkennen.

Mit Loop-AES sieht es hingegen so aus als wäre die Partiton mit Zufallsbytes, z. B. aus /dev/urandom, gelöscht oder getestet worden oder schlicht ungenutzt geblieben nachdem die Festplatte zuvor randomisiert wurde (s. o.).
Und tatsächlich kann man solchen Datenmüll nicht von einem ERF unterscheiden, wenn man nicht das Verfahren und das Passwort sowie ggf. den Salt kennt; man kann immer plausibel behaupten es sei nur Datenmüll vorhanden, z. B. von einem Datenträgertest oder sicherem Löschen.

Außerdem gibt es noch die Variante des sicheren Löschens eines Partitionsinhalts durch Überschreiben, bei dem ein verschlüsseltes Dateisystem eingerichtet wird, schnell mit Nullen komplett gefüllt wird (z. B. dd if=/dev/zero of=foo.bin bs=4096) und das Passwort nicht gemerkt wird oder ein dem Benutzer nicht angezeigtes zufälliges Passwort im Hintergrund verwendet wird und ein evtl. vorhandener Salt nicht gespeichert wird. Damit wird nämlich um ein mehrfaches schneller als mit /dev/urandom überschrieben, aber wie bei /dev/urandom ebenfalls mit Datenmüll, der deutlich besser als der von badblocks ist, weil er mehr Entropie (und Entropie-Belag) enthält. Bei großen Datenträgern kann man hiermit deutlich Zeit sparen ohne eine (wie beim badblocks) schlechte Qualität der zum Überschreiben verwendeten Zufallsbytes.

Die einzige Einschränkung bei Verschlüsselungsverfahren ohne unverschlüsselten Header ist das beim mehrmaligen Auslesen vom ERF Änderungen in dem "Datenmüll" sichtbarsind, die auf ein ERF hindeuten können, aber dafür muß ein Angreifer die Partition ja auslesen, also Administrator-/Root-Rechte haben und die zudem mehrmals und längere Zeit, weil viele Daten gelesen werden müssen. Das ist bei gesetztem BIOS-Passwort, kontrolliertem Zugang (abgeschlossenen Türen usw.), halbwegs sicherer Grund-Konfiguration und Firewall +Virenscanner aber in der Praxis kaum möglich und mit Indizien, die auch Datenmüll oder schlicht Hardwaredefekte sein können, helfen einem Angreifer kaum weiter, denn man kann z. B. mit dd und einem Offset neuen Datenmüll (aus /dev/urandom) in eine mit Datenmüll gefüllte Partition schreiben und somit ein ERF faken, z. B. mittels

set -x; dd conv=noerror skip=$RANDOM count=$RANDOM if=/dev/urandom of=/dev/<device><partition number>

Bei diesem kleinen Beispiel sollte die Partition mind. 33,6 MB groß sein oder es sollte die letzte sein, damit nicht die dahinter liegende Partition überschrieben wird.
Diese Faken kann man auch per crontab regelmäßig ausführen lassen.

Das sichere Löschen einer Partition kann man ebenso wie die oben beschriebene Randomisierung eines Datenträgers durchführen, z. B.

ddrescue -b 4096 -r 2 -v /dev/urandom /dev/sda4

und das Testen mit einer Test-Datei erfolgt z. B. so:

blockcount=$( fdisk -b 1024 -s /dev/sdb4 )
dd if=/dev/urandom bs=1024 count=$blockcount | tee random.img > /dev/sdb4
sha1sum random.img > sha1sum1.txt &
dd if=/dev/sdb4 of=read.img bs=1024
sha1sum random.img > sha1sum2.txt
diff sha1sum1.txt sha1sum2.txt

wobei der Vergleich am Ende zeigt ob eine Differenz und damit ein Fehler auftrat oder nicht.
So ein Test ist sinnvoll bei gefälschten Datenträgern, die mehr Speicher ausweisen als vorhanden ist, was bei in Asien hergestellten billigen und großen USB-Speichersticks nicht selten ist und was u. A. auch schon bei Festplatten vorkam: Meist wiederholt der Speichercontroller einfach den letzten physikalisch vorhandenen Speicherinhalt und das kann man nicht erkennen, wenn man ein zu kurzes Testmuster verwendet. Beispielsweise verwendet badblocks per default nur einen Block von 64 kiB.
Zudem ist es möglich das der Speichercontroller ein einfaches Testmuster erkennt und dieses für beliebige Blockgrößen wiederholt (in dem physikalisch nicht vorhandenen Speicherbereich).

Zur Verschlüsselung sollte AES-256 verwendet werden, denn AES-128 und AES-192 sind schwächer.
Die für die Ver- und Entschlüsselung nötige Rechenleistung ist beim AES-256 relativ gering: Beim Schreiben mit 50 MB/s wird ein 2,2 GHz-Core (im Opteron 875) zu rund 60 % ausgelastet und beim Lesen mit 85 MB/s zu 95 %; die Verschlüsselung mit loop-AES-256 drosselt daher praktisch nur unmerklich gering, zumindest solange man nicht sehr schnelle SSDs/HDDs/RAIDs verwendet. Zudem enthalten 2010 zumindest die Intel-CPUs zunehmend Hardware-Beschleunigung wie AES-NI, durch die loop-AES um ein Vielfaches schneller wird. Die native Unterstützung dieser AES-Beschleunigung per Betriebssystem kann Windows Server 2008 R2 schon und auch einige Linux-Distributionen sollen das bis zum Ende des Jahres 2010 laut Intel beherrschen (Quelle http://www.golem.de/1003/73858-3.html).

Stand Sept. 2009 mit Debian 5.0.3

Nach einem globalen Updaten mittels

apt-get upgrade

mußte ich Anfang 2010 unter 32- wie 64-Bit feststellen, das danach nicht mehr richtig gebootet werden kann: Mit den alten Dateien im Boot-Verzeichnis auf dem USB-Stick wird, mit dem per Default verwendeten ext3, beim Booten ein defekter Superblock gemeldet, der allen Reparatur-Versuchen wiedersteht und nur root-Login im Single-User-Mode erlaubt (d. h. kein LAN, kein GUI). Mit der neuen initrd (vom Updaten) ist nicht einmal das möglich; es gibt auch mit dem richtigen Passwort nur die Fehlermeldung "decryption failed".
Als Workaround bleibt hier leider nur auf globale Updates zu verzichten, bis dieser Bug behoben ist.

Update 2011-03-01
Das Problem scheint daran zu liegen das das Paket Loop-AES nicht richtig gepflegt wurde und der Maintainer kürzlich aufgab, so das es nicht mehr gewartet wird; es ist unmaintained: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614814, http://www.debian.org/devel/wnpp/orphaned.en.html. Deshalb kann man es bei der Installation nicht mehr verwenden, weder unter Debian 6.0 noch unter Ubuntu 10.10. Als Alternative gibt es aktuell nur dm-crypt/LUKS, was derzeit Mainstream ist. Der Nachteil ist aber das es leicht erkennbar ist, wie schon ein "file -s /dev/" zeigt.
Ein Workaround ist das Dateisystem zusätzlich zu verstecken, wie im Kapitel "Dateisysteme zusätzlich verstecken" beschrieben.

Im Prinzip kann man das Loop-AES weiterhin verwenden, beispielsweise für verschlüsselte Backups auf externen Datenträgern, aber das dafür üblicherweise verwendete Modul cryptoloop fehlt bei neueren Kerneln nach 2.6.32: https://help.ubuntu.com/community/EncryptedFilesystemHowto.
Man kann das cryptloop zwar noch manuell erstellen, aber das ist etwas umständlich und es könnte in Zukunft nicht mehr funktionieren: http://fob.po8.org/node/493.
Die wohl einzige Alternative zum losetup ist cryptsetup: http://fob.po8.org/node/516.

Update 2013-08, UEFI und GPT
Die Installation schlägt auf Rechnern mit UEFI häufig fehl, siehe beispielsweise http://forum.ubuntuusers.de/topic/system-verschluesseln-geht-mit-11-10-nicht-mehr/.
Bei mir zeigte sich dies an an dem Ultrabook HP Spectre XT Touchsmart mit UEFI und GPT darin, das beim Versuch Kubuntu 13.04 (AMD64, Desktop) zu installieren die Partitionseinstellung "physical volume for encryption" die Fehlermeldung "An error occured while creating the keyfile" brachte und die Partition nicht eingerichtet werden konnte.
Erst mit der Kubuntu Alternate CD 12.04 konnte verschlüsselt installiert werden, aber nur ohne UEFI und eine Software-Auswahl war bei der Installation nicht möglich, so das nur das minimale Basissystem installiert wurde. Aber auch danach gabe es diverse Probleme wie nicht benutzbare Konsolen und das der APT-Cache gelöscht werden musste um neue Pakete installieren zu können. Immerhin war die GPT aber kein Problem: Alle Partitionen wurden richtig erkannt und das vorhanden Windows8, dessen Partition über die Datenträgerverwaltung vorher verkleinert wurde, bootete danach noch problemlos.
Der Versuch Ubuntu 13.04 zu installieren scheiterte auch, denn man kann bei der Installation zwar eine verschlüsselten Root-Partition einrichten, aber damit bleibt der Button "Install Now" ausgegraut (inaktiv) und man kann keine verschlüsselte Swap-Partition einrichten. D. h. auch beim Ubuntu 13.04 scheitert man an der Einrichtung der Partitionen.
Das Lubuntu ist die einzige verbliebene Debian-basierte Distribution, die noch eine aktuelle Alternate-CD anbietet und die bietet auch die bewährte Installation im Experten-Modus. Hierbei zeigte sich das die Menüs etwas veraltet sind, winzig auf einem HD-Monitor und beispielsweise mit Abschneiden der Partitionsbezeichnungen in einigen Menüs, aber keine Probleme. Das Partitionieren war zwar möglich, aber die verschlüsselte Partition mit Random Key (als Swap-Partition) konnte nicht eingerichtet werden. Allerdings kann man das nach dem ersten Booten nachholen, mit je einer neuen Zeile in der fstab und crypttab: http://anonymous-proxy-servers.net/wiki/index.php/Linux_Daten_verschl%C3%BCsseln#SWAP_und_TMP_verschl.C3.BCsseln
In der fstab reicht
/dev/mapper/sda11_crypt none swap sw 0 0
Um die Verschlüsselung explizit vorzugeben und eine weniger sichere Verschlüsselung mit kürzeren Schlüsseln auszuschließen verwende ich diese Zeile in der crypttab:
sda11_crypt /dev/sda11 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap

Nach dem Booten zeigten sich mit Lubuntu keine Probleme und nach dem Installieren der Pakete kdebase-bin, kde-full und kde-plasma-desktop hat man als Desktop zur Auswahl beim Einloggen unter anderem auch KDE; man ist mit Lubuntu nicht auf LXDE beschränkt.

Daneben zeigte sich das man auch berücksichtigen muss, das gelegentlich irgendetwas die Tastaturbelegung von QWERTZ auf QWERTY ändert. Wird nach einem Reboot das Passwort nicht mehr akzeptiert, sollte man daher das Passwort mit QWERTY-Tastaturbelegung eigeben.
Weitere Probleme zeigten sich mit dem Startup Disk Creator / Startmedienersteller, mit dem die ISO-Images auf USB-Stick installiert wurden: Schon beim Installieren von Knoppix zeigte sich das nur dann vom Stick gebootet werden kann wenn vorher Einstellen der fdisk-Geometrie und Partitionieren und Formattieren mit mkdiskimage erfolgte. Zudem scheiterte der Creator an Symlinks, die nicht einfach auf den Stick kopiert werden können, da das FAT32 auf dem Stick keine Symlinks hat und daher ein Kopieren mit einem einfachen cp scheitert. Dies zeigt sich daran, das der Integritätstest (Boot-Eintrag "Check disk for defects") fehlschlägt. Die Symlinks muss man daher bei den Alternate selber Kopieren, d. h. wenn der Stick unter /mnt/sdd1 ist und man aktuell im gemounteten ISO-Image ist:

cp -Lr . /mnt/sdd1/

Aber der Creator richtet die Sticks so ein, das man davon, nach diesem zusätzlichen Kopieren, im UEFI-Modus booten kann und so auch die Installation mit UEFI durchführen kann. Sind die Dateien im ISO-Image richtig signiert, funktioniert das auch wenn Secure Boot aktiviert ist.

Erwähnenswert ist daneben für SSDs das das Trim-Kommand auch bei verschlüsselten Partitionen funktioniert, aber zusätzliche Optionen erfordert: http://www.bock.nu/blog/trim-and-dm_crypt .
Wie dort beschrieben wird Trim auf verschlüsselte Partitionen aber von vielen nicht empfohlen weil es einige, eher theoretische, Angriffe erleichtert: http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html .


Mehrere Betriebssysteme

In dem ERFH fehlen andere Betriebssysteme, denn meist wird auf einem Rechner, der nicht nur als Server ständig unter einem OS laufen soll, neben ein Linux auch ein MS-Windows installiert. Sinnvoll ist dies auch zum Ablenken und für Plausibilität: Ein Rechner ohne ein OS und mit Datenmüll (Zufallsbytes) gefüllt sieht verdächtig nach einem Encrypted Root Filesystem aus, denn selbst wenn jemand mal die Partion(en) löscht, installiert er ja im Normalfall direkt anschließend mindestens ein OS. Zur Plausibilität sollte man aber neben dem (unverschlüsselten) Windows auch ein unverschlüsseltes Linux installieren um zu zeigen das man nichts zu verbergen hat und die Partition mit dem Datenmüll noch/wieder eine Baustelle für ein weiteres OS oder eine Datenpartition ist und daher mit Datenmüll sicher gelöscht oder nur getestet wurde oder nach der Randomisierung schlicht nicht genutzt wurde.

Zur Plausibilität gehört natürlich auch auf jedem Rechner mindestens eine Partition mit Datenmüll (Zufallsbytes) oder einem ERF einzurichten und jeden Datenträger zu Randomisieren, zum Einen als ersten Datenträgertest auf Fehler und zum Anderen um sie für Angreifer weniger attrakiv zu machen und zudem Angreifer mit Datenmüll zu beschäftigen.
Zum einfachen Randomisieren mit zumindest nicht leicht erkennbaren Pseudozufallsbytes reicht schon aus die betreffende Partition mit badblocks schnell zu Randomisieren:

badblocks -wsv -c 65536 -t random /dev/<device><partition number>

und man kann es während der zweiten Hälfte, die ja nur zur Überprüfung liest, vorzeitig mit Ctrl-C beenden.
Mit m Boot-Medien und n Rechnern ergeben sich mn Kombinations-Mögichkeiten. Bei m=n=10 sind es zehn Milliarden und bei m=10, n=3 sind es schon tausend. Ist nur ein ERF eingerichtet, so ist die a A-priori-Wahrscheinlichkeit, das jemand eine gültige Kombination zusammenstellt nur m-n, aber selbst in diesem unwahrscheinlichen Fall kann ein Angreifer damit nichts machen; ohne das richtige Passwort kann er nicht einmal beweisen das es die richtige Kombination ist.
Hierbei muß man natürlich darauf achten, das der betreffende Bootloader nur einfache Geräte und keine Labels oder IDs verwendet.
Den Überblick über die Sticks behält man indem man sich auswendig merkt welcher Stick zu welchem Rechner bzw. ERF gehört oder man erstellt eine Liste der Sticks mit dem Typ (Hersteller, Hersteller-Bezeichnung, Speicherplatz) und der Seriennummer, die man kurz nach dem Einstecken z. B. so angezeigt bekommt, mitsamt Uhrzeit:

tail -n 1234567 -f /var/log/messages | grep -i serialnumber:


Wenn die unverschlüsselten Betriebssysteme nur selten genutzt werden kann einem Angreifer dies zwar auffallen, aber dafür gibt es viele mögliche Gründe: Ein vom USB-Stick gebootetes Knoppix (siehe auch Kapitel "Spam auf und mit Boot-Medien") oder von CD/DVD gebootetes Bankix, PXE-Boot usw. oder einfach ein seltenes Benutzen des betreffenden Rechners, denn das ist ohne ständige Überwachung nicht nachweisbar.


Encrypted Root Filesystem (ERF) schon während der Installation einrichten

Das Einrichten schon während der Installation ist relativ neu, denn 2006 war es noch nicht möglich: http://www.linux-magazin.de/Heft-Abo/Ausgaben/2006/10/Mobiler-Datentresor.
Einige Distributionen, z. B. Debian Lenny seit mindestens 2009, haben die Einrichtung eines ERF in die Installation integriert.
Ein sehr ausführliches Beispiel findet man hier in Form von Screenshots von der Installation: http://kaoso.org/debian_installer-lenny/ .
Und für OpenSuSE ab Version 11.1 findet man eine Beschreibung hier: http://lizards.opensuse.org/2009/03/18/encrypted-root-file-system-on-lvm/.

Allerdings werden die andere Ratschläge für das ERF dort nicht berücksichtigt; man sollte diese Beispiele nur angepasst übernehmen, also möglichst ohne LUKS usw..
Und um nicht stundenlang warten zu müssen und nicht nur eine nur grobe Randomisierung zu verwenden sollte man das Randomisieren vorher erledigt haben (siehe Kapitel "Randomisieren des Datenträgers").

Mit dem bei der Installation integrierten Einrichten des ERF entfällt der etwas umständliche Weg zunächst unverschlüsselt zu installieren und erst danach ein ERF einzurichten und das installierte System dort hin zu kopieren.

Eine Installation mit ERF ist damit kaum aufwändiger als ohne; der Mehraufwand ist im Wesentlichen (neben der einmaligen Randomisierung) nur die zum Booten nötigen Dateien auf einem Wechseldatenträger zu integrieren, bei einem Kernel-Update die Boot-Dateien anzupassen und die Passworteingabe beim Booten.

Übrigens kann man ein verschlüsseltes Root-Dateisystem inzwischen (2009) nicht nur unter Linux, BSD usw. einrichten, sondern auch unter Microsoft-Windows, beispielsweise mittels Truecrypt.

Absichern der Installation

Zu einer sicheren Installation gehört vor der Installation eine Überprüfen der Installationsmedien mit den zugehörigen Hashwerten, und die sollte nicht erst nach dem Brennen auf CD/DVD/... erfolgen sondern automatisiert auch schon mit den Image-Dateien.
Dazu sollte die Signatur der Hashwerte automatisiert überprüft werden, um sicher zu sein, das die Image-Dateien auch das enthalten, was sie enthalten sollen.
Da ich Debian bevorzuge, habe ich hierfür das Skript jigdo_instab.sh gemacht, das die Debian-DVDs auch über instabile Internet-Zugänge zuverlässig downloadet
Dazu benötigt man das jigdo (im Paket jigdo) oder jigdo-lite (im Paket jigdo-file), siehe http://www.debian.org/CD/jigdo-cd/ und http://atterer.net/jigdo/ .
Eine Beispiel-.jigdo-lite-Datei findet man hier.

Nach der Installation sollte man die Image-Dateien in das ERF kopieren, z. B.:

mount -o loop debian-504-amd64-DVD-1.iso /mnt/tmp
mkdir -p /opt/debian504/dvd1
cp -a /mnt/tmp/. /opt/debian504/dvd1/
...

und in die /etc/apt/sources.list eintragen, z. B.:

deb file:/opt/lennyrc2/dvd1 testing main
...

Damit hat man die Pakete immer auch lokal verfügbar und im ERF durch die Verschlüsselung geschützt.

Außerdem sollte man direkt nach der Installation des Basis-Systems das Paket debian-keyring installieren, damit die Signaturen der Debian-Pakete vor deren Installation automatisch überprüft werden.

Man kann die Installation noch weiter Absichern durch Überprüfen der Hardware, beispielsweise der Seriennummer eines zum Booten verwendeten USB-Speichersticks. Ein "lsusb -v" verräte nämlich die Seriennummer, die durch ein verdecktes Austauschen des Sticks nicht mit ausgetauscht wird:

iSerial 3 09021000000000004002840625

Die Seriennummer ist nicht hundertprozentig sicher, weil zumindest der Hersteller Duplikate mit gleicher Seriennummer herstellen kann, aber da die Seriennummer nur direkt vom Stick gelesen werden kann und ein Duplikat mit gleicher Seriennummer erheblichen zusätzlichen Aufwand bedeutet, ist sie sehr sicher.


Dateisysteme zusätzlich verstecken

Zusätzlich zu dem sicheren und abstreitbaren Verschlüsseln kann man Dateisysteme auch zusätzlich verstecken um sie besser vor Angreifern zu schützen und das Abstreiten der Verschlüsselung plausibler zu machen.

Die erste Methode ist geschicktes Partitionieren. Das einfachste zusätzliche Verstecken ist die betreffende Partition als leer zu deklarieren, also den Partitiontyp 0 (=leer) zu verwenden. Beim Mounten/Unmounten ist der Partitiontyp egal, so das der Partitiontyp 0 daher nicht stört.
Allerdings können auch Programme, mit denen der Datenträger analysiert wird, den Partitionstyp ignorieren. Dieses einfachste Verstecken bietet daher nur wenig Schutz.
Ebenso einfach aber wenig wirksam ist das Anlegen von mehreren Partitionen auf Wechseldatenträgern, denn bei denen kann ein MS-Windows nur auf die erste Partition zugreifen (Stand Juli 2010). Unter anderem mit einem Linux läßt sich diese Limitierung leicht umgehen.

Die zweite Methode ist gar keine Partitionierung zu verwenden. Bei dieser Null-Partitioniung, die auch Superfloppy-Format genannt wird, weil Disketten fast immer in diesem Format verwendet werden, wird der gesamte Datenträger wie eine Partition verwendet.
Dieses Format eignet sich auch gut für Backups, läßt aber keinen Raum für anderes; von einem solchen Datenträger kann nicht gebootet werden.
Die meisten Analyse- oder Partitonierungs-Tools setzen voraus das Partitionen vorhanden sind und beherrschen das Superfloppy-Format nicht (mehr). Beispielsweise zeigt das fdisk Mitte 2013 zu einem USB-Stick mit einem LUKS-Dateisystem eine leere Partitionstabelle, so als ob der Stick leer wäre, und hal-get-property zeigt zum Stick Dateisystem "unknown" sowie eine leere UUID, obwohl Dateisytemtyp und UUID sogar im Klartext am Anfang stehen.
Die dritte Methode ist die betreffende Partition einfach zu löschen und wieder einzurichten, wenn man auf die Daten zugreifen möchte. Hierbei wird, wie üblich, nicht die Partition selber verändert, sondern nur deren Deklaration im Master-Boot-Record (MBR), also den erste 512 Bytes des Datenträgers. Dadurch müssen nur diese 512 Byte verändert werden, aber die Partition selber nicht.
Dies erreicht man sehr einfach mit nur primären Partitionen und zwei Versionen des MBR: Eine mit der Partition (mit dem ERF) und eine ohne. Man muß dann vor dem Verwenden des ERF den MBR ohne diese Partition ersetzen durch den MBR mit dieser Partition. Dafür reicht ein kurzes Kommando wie "dd if=mbr.bin of=/dev/sda". Diese Art des Versteckens erfordert aber jeweils ein zusätzliches unverschlüsseltes Booten und Kopieren des MBR mit der Partition, vor dem Booten mit dem ERF.
Wegen diesem zusätzlchen Aufwand wird man daher in der Regel nur für im Vorhinein bekannte Angriffe treiben, oder wenn das ERF nur selten gebootet wird.
Durch die fehlende Partition ist das Dateisystem richtig verborgen, also steganografisch.
Dieser Trick funktioniert auch bei unverschlüsselten Dateisystemen: Ohne die Partition kann nicht mehr simpel auf die Daten dort zugegriffen werden, so das ein

file -k -s /dev/<device><partition number>

mit dem man normalerweise den Dateisystem-Typ angezeigt bekommt, nicht funktioniert, da die Partition fehlt.

Die vierte Methode ist die Daten nicht wie per Voreinstellung (Default) üblich vom Anfang (von Datenträger oder Partition) an abzulegen, sondern erst hinter einigem Datenmüll (z. B. einige Bytes aus /dev/urandom).
Schließlich kann man beim Mounten auch einen Offset angeben und in den Raum davor beliebigen Datenmüll ablegen; dafür benötigt man nur die zusätzliche Mount-Option "offset=<offset>".
Hierbei ist der Offset in Bytes anzugeben. Beispiel: Das Dateisystem beginnt 123456*512 Bytes hinter dem Anfang (z. B. von /dev/sdc), und damit beim Offset 63209472, so das die ersten rund 63 MByte nur Datenmüll sind.
Dadurch kann ein Angreifer an die verschlüsselten Daten auch dann nicht heran, wenn er sowohl das Verschlüsselungsverfahren als auch das Passwort aber nicht den Offset kennt. Allerdings kann der Offset auch mittels Brute-Force ermittelt werden, so das er nur wenig zusätzliche Sicherheit bedeutet.

Die fünfte Methode ist die (zusätzliche) Verschlüsselung vom Header, der Magischen Zahl, dem Datei-Anfang. Dies leistet das Skript enc.sh, das mit der Opton -d auch entschlüsseln kann.
Damit wird aus sichtbarer Verschlüsselung wie dem Wort "LUKS" am Anfang einer mit LUKS verschlüsselten Partition ein scheinbarer Datenmüll und damit abstreitbare Verschlüsselung.

Daneben gibt es noch weitere Möglichkeiten, beispielsweise versteckte Datenträger: USB-CD/DVD-Laufwerke werden normalerweise nicht angezeigt, weder unter MS-Windows noch unter Linux, denn unter MS-Windows muß dafür meist ein Treiber geladen werden und unter Linux zeigt das übliche Auflisten, "fdisk -l", Datenträger in solchen Laufwerken nicht an. Ein Beispiel für so ein Laufwerk ist der "CnMemory externer USB-/DVD-/RW-Brenner", angeboten u. a. von Norma im August 2010. Ebenso ist es mit vielen externen Festplatten/SSDs, beispielsweise der Intenso Memory Case 2TB schwarz (USB 3.0). Über eine innenliegende Buchse kann man die auch im Gehäuse betreiben.
Allerdings sind versteckte Datenträger meist etwas umständlich und nur dann sinnvoll wenn sie physikalisch versteckt werden.
Natürlich können die Methoden beliebig kombiniert werden, also beispielsweise ein verschlüsselter Header, ein Offset und als Partitionstyp 0, aber jede Methode bedeutet mehr oder minder viel zusätzlichen Aufwand, so wie auch das Trollen durch ein Vortäuschen von einem verschlüsslten Dateisystem, das nur Fake ist und nur der Ablenkung dient, wie weiter untern im Kapitel zum Trollen (Täuschen) beschrieben.


Absichern gegen Angriffe auf den Boot-Prozess

Durch sicheres Aufbewahren der Boot-Dateien, z. B. auf einem USB-Stick der ständig am Körper getragen wird, hat man eine brauchbare Absicherung des Boot-Prozesses, aber absolut sicher ist das nicht, da der Träger auch mal schlafen muss und der Datenträger kaum überall hin mitgenommen werden kann, z. B. in das Schwimmbad oder in die Sauna. Alternativen wie Tresore sind auch nicht absolut sicher, so das es auch sinnvoll sein kann auch bei separat aufbewarten Boot-Dateien zusätzliche Sicherungsmaßnahmen zu ergreifen.
Zur zusätzlichen Sicherheit kann man von einem Boot-Skript in der verschlüsselten Partition die Integrität der Boot-Dateien (MBR, Bootloader-Menü, Bootloader, Kernel, initial Ramdisk) überprüfen um Angriffe auf den Boot-Prozess schon beim Booten relativ sicher zu erkennen.
Weil im Worst case jede Datei auf dem Boot-Medium von einem Angreifer ersetzt sein kann, benötigt man die Boot-Dateien auch in dem ERF und ein kleines Boot-Skript das die Dateien mit den Originalen vergleicht.
Ein Beispiel ist check0.sh.

Um sich Probleme wie Hash-Kollisionen zu ersparen wird dabei kein Hash verwendet, sondern simpel mittels diff verglichen und anschließend das Ergebnis per Email mitgeteilt; im Fehlerfall auch mit sofortigem Piepsen, damit der Benutzer schon vor dem Einloggen und noch beim Booten z. B. alle Netzkabel ziehen kann, nach am Rechner versteckten USB-Sticks suchen kann (z. B. auf der meist nicht direkt einsehbaren Rechner-Rückseite) und auch zeitnah protokollieren kann, wer seit der letzten erfolgreichen Überprüfung manipuliert haben könnte.
Von der Zeitschrift c't gibt es etwas ähnliches, das chkboot-Paket, was allerdings SHA1-Prüfsummen verwendet und daher nicht absolut sicher gegenüber Hash-Kollisionen ist, aber (2013) noch völlig ausreicht: Boot-Sicherung, Verschlüsselte Linux-Notebooks absichern, Softlink dazu. Beschrieben ist es auch in c't kompakt Linux 02/2012, S. 160 und in dem chkboot-Paket selbst, unter www.ct.de/cs1204160. Verwendet wird von diesen beiden Skripten zusätzlich auch die Überprüfung des MBR der inodes sowie der belegten physikalischen Blocks.

Man kann noch weiter gehen und mehr überprüfen, beispielsweise zusätzlich die Seriennummern von RAM-Riegeln, CPUs, HDDs usw. überprüfen, aber das bringt nur relativ wenig mehr Sicherheit.
Der Vollständigkeit halber ist hier ein Codeschnipselchen dazu, das die Ausgabe von hwinfo ohne die nicht selten variablen Takte, IRQs und Item-Nr. verwendet:

hwinfo --all --dump-db 1 > hwinfo.txt
sed '/Clock: /d;/IRQ:/d;s/[0-9]*: *//' hwinfo.txt > hwinfo_red.txt
diff hwinfo_red.txt hwinfo_red.original

Damit wird dann z. B. auch die Seriennummer vom USB-Stick überprüft, aber empfehlenswert ist alle eigenen USB-Sticks am Gehäuse unauffällig zu markieren, damit man einen Austausch schon vor dem Einstecken bemerkt.

Daneben muß der Benutzer auch auf verdächtige Anzeichen wie ein Reboot beim Neustart achten, denn sowas ist meist ein Anzeichen für eine Manipulation: http://www.heise.de/security/meldung/Angriff-auf-Windows-Bitlocker-877647.html.

Ebenso verdächtig ist wenn der Grafiktreiber nicht geladen wird, denn z. B. der Treiber von NVIDIA verweigert die Arbeit, wenn die Kernel-Version nicht stimmt; dann gibt es keine grafische Oberfläche mehr.

Eine weitere Möglichkeit den Boot-Prozess abzusichern gibt es bei einem Rechner mit einem Trusted Platform Module (TPM) Chip, denn der ermöglicht ein Trusted Boot mit Trusted Grub: http://www.linux-magazin.de/Heft-Abo/Ausgaben/2011/11/Trusted-Boot.
Mit UEFI statt einem einfachen BIOS nennt heißt es Secure Boot und auch mit Anleitungen gut beschrieben findet man das in c't Linux 2013 S. 24-29 sowie S. 35.


Absichern gegen Angriffe auf den Boot-Prozess bei entfernten Rechnern

Bei entfernten Rechnern, beispielsweise Server, die in einer entfernten Server-Farm stehen, kann man nicht einfach eine CD/DVD oder einen USB-Stick mit relativ sicher nicht von Angreifern manipulierten Dateien verwenden, weil der Server meist weit weg ist und zudem meist nur Wartungs-Personal Zutritt hat. Allerdings gibt es für dieses Problem eine Lösung: Per IPMI oder DASH die CD/DVD, den (schreibgeschützten) Stick oder einfach nur ein Image remote anhängen, per virtual media/USB redirect. Davon kann man dann die Programme/Skripte ausführen oder lieber booten.
Zumindest mit dem IPMI von Supermicro funktioniert das ganz brauchbar und die Software dafür gibt es kostenlos.
Man kann auch mehrere virtuelle Medien kombinieren; beispielsweise das Betriebssystem in einem (automatisch) schreibgeschützten Image, und zusätzlich ein USB-Stick zum Speichern von Daten. Damit kann man beim entfernten Rechner auf lokale Datenträger komplett verzichten, was den Rechner wenig angreifbar macht.
Lädt sich das Betriebssystem selber in das RAM, was z. B. das Knoppix mit der Option toram macht, benötigt man das Medium/Image mit dem Betriebssystem auch nur beim Booten und kann sich beim IPMI danach ausloggen.
Viele Server-Mainboards wie das Supermicro X8DTH-6F haben das IPMI onboard; da kostet auch die Hardware nichts (zusätzlich). Es kostet nur eine zweite IP für das IPMI und beim X8DTH-6F muß eine weitere Netzwerkbuchse angeschlossen werden.
Es gibt dabei noch das Rest-Problem, das das IPMI selbst gecrackt werden kann, aber bei entfernter Hardware unter fremder Kontrolle können auch andere Firmwaren im Rechner durch gecrackte ersetzt werden oder ein Memory Dump z. B. per Firewire mit DMA oder Cold Boot Attack erfolgen. Dem kann man nur beschränkt vorbeugen, beispielsweise indem man Booten von USB-Stick oder CD im Bios deaktiviert und Secure Boot aktiviert, damit ein Angreifer nicht etwas anderes Booten und ein Speicherabbild (Dump) anfertigen kann.


Keylogger (Hardware), Gehäuse/Chassis-Manipulationen

Neben Keyloggern in Software, beispielsweise in Trojanern, gibt es sie auch in Hardware und damit können alle Tastatureingaben aufzeichnet und so auch die Passwörter ermittelt werden. Das FBI nutzt sie seit den 90ern und die deutschen Geheimdienste seit den 00ern: http://www.golem.de/news/pgp-vs-geheimdienste-pgp-ist-weiterhin-sicher-1205-92043.html .
Gegen solche Manipulationen hilft ein festes Verbinden der Tastatur mit dem Rechner, z. B. mit reichlich Heißkleber, und regelmäßiges Überprüfen der Hardware, das u. A. auch mit Entstauben kombiniert werden sollte. Dazu kann man den Rechner schwer manipulierbar machen durch einen Rechner-Schrank oder durch ein Schloß. Für ein Vorhänge-Schloß reichen schon zwei an einer Ecke in das Gehäuse gebohrte Löcher und für höheren Sicherheitsbedarf gibt es Tresore mit ingegrierter Kühl-Anlage und speziellen Kabel-Durchführungen: http://lampertz.de/html/default.asp?site=1_6. Allerdings kosten sie einen fünf- bis sechsstelligen Betrag und wiegen ca. eine Tonne.

Zusätzlich oder stattdessen kann man zumindest PS/2-Tastaturen per Software ständig überwachen und so erkennen ob jemand die Verbindung unterbrochen hat, z. B. um einen Keylogger anzustecken. Dazu kann man heartbeat++.c verwenden.
Daneben kann man auch im BIOS Event Log nachsehen nach verdächtigen Einträgen wie "Keyboard not functional".
Hilfreich ist dabei auch der Watchdog vom BIOS oder IPMI, denn so ein Hardware-Watchdog ergänzt Software-Watchdogs wie das heartbeat++.
Zusätzlich kann man auch die Zeiten aufzeichnen und überprüfen, in denen der Rechner nicht lief, mit Tools wie Downtimed.

Verwandt mit Hardware-Keyloggern sind Manipulationen, für die das Gehäuse geöffnet wird. Diese machen sich im BIOS Event Log bemerkbar durch Einträge wie "Chassis Intrusion", vorausgesetzt ein entsprechender Schalter ist im Gehäuse vorhanden, an das Mainboard angeschlossen und der Rechner nicht ausgeschaltet. Aber man kann den Rechner auch in einem Rechner-Schrank unterbringen, der gegen Einbruch geschützt ist und an den Türen Türschalter hat, die beim Türöffnen den Strom und damit die Rechner abschalten (http://www.dradio.de/dlf/sendungen/computer/2144535/).
Gegen ein unbefugtes oder zumindest unbemerktes Öffnen kann man sich absichern mit Schraubensicherungslack/Schraubensiegellack (Tamper Evidence Seal) wie beispielsweise Bloc'Lube von Electrolube. Diese Lacke werden auch als Plombier- oder Signierlack bezeichnet und sie sind üblicherweise wasser-, öl- und benzinfest sowie beständig gegen verdünnte Säuren und Laugen. Eine andere Maßnahme ist ein Gehäuse, dessen Öffnen man mit einem Schloss verhindern kann. Solche Gehäuse gibt es für Desktop-PCs in vielen Varianten.

Den Schraubensicherungslack kann ein Angreifer natürlich ersetzen um einen erfolgten Angriff zu verdecken, aber dagegen gibt es mehrere Abwehrmaßnahmen:

A) Markieren der Lackoberseite mit einem billigen UV-Marker wie dem Edding 8280 und Nachweis/Überprüfung mit einer UV-Lampe, die es auch in Form eines Schlüsselanhängers mit UV-Diode ("UV-LED") gibt. Lack, Edding und UV-Lampe erhält man bei Elektronik-Versendern wie voelkner.de oder conrad.de. Dies ist die einfachste und billigste aber auch am leichtesten zu fälschende Methode.

B) Markieren des Lacks mit etwas schwacher Radioaktivität geringer Reichweite, die ungefährlich und Unterhalb der Freigrenze ist aber völlig ausreicht zum Nachweis mit einem nicht teuren Geigerzähler der auch Alphastrahlung und schwache Betastrahlung nachweisen kann, z. B. Gamma-Sout, in direkter Nähe. Zum Markieren braucht man weit weniger Radioaktivität als ein Mensch natürlicherweise enthält, also wirklich wenig. Die geringe Reichweite der radioaktiven Strahlung ist wichtig, nicht wegen dem Strahlenschutz vor dem bischen Radioaktivität sondern damit man eine dünne Schicht von unmarkiertem Lack auf dem markiertem Lack direkt messen kann, damit Angreifer nicht unerkannt Überpinseln können. Daher sollten nur Alphastrahler oder niederenergetische Betastrahler verwendet werden, die man schon durch Überkleben mit einem dünnen Klebestreifen komplett abschirmen kann. Deshalb eignet sich beispielsweise C14, mit nur 20 mm Reichweite der Betastrahlung in Luft. Das C14 ist auch ein natürliches Isotop, sozusagen öko:
14C
Solche Glaskapseln, beispielsweise vom Hersteller J. T. Baker unter der Bezeichnung MAXICOUNT (obiges Bild) sind gemacht zum Auflösen der durchsichtigen C14-Verbindung in einem Lösungsmittel und da Schraubensicherungslacke zum Großteil aus Lösungsmittel bestehen kann man sie damit leicht markieren, aber durch die geringe Reichweite der Betastrahlung schirmt ein solcher Lack sehr stark ab bis das Lösungsmittel verdunstet ist und danach hat man noch eine merkliche Schwächung durch den eingetrockneten Lack, so das man an einer Schraube nur um 1 µSv/h messen kann, ca. das sechsfache der Umgebungsaktivität. Es reicht aber auch schon 0,15 µSv/h, was bei einer üblichen Umgebungsaktivität von gleichen Wert am Lack bescheidene 0,3 µSv/h ergibt und hier gilt das Motto weniger ist mehr (Sicherheit), denn je kleiner die Aktivitätt desto länger muss man messen um sie auch nur halbwegs genau zu bestimmen. Einen Geigerzähler für eine Minute aufzulegen ist keine große Sache, aber einem Angreifer der stattdessen nur wenige Sekunden misst übersieht 0,15 µSv/h. Und sofern man nur eine Schraube markiert hat, hat man den Meßaufwand nur einmal.
Um kleine Aktivitäten genau einzustellen benötigt man eine direktverdrängende Kolbenhubpipette mit fest eingestelltem Volumen, denn damit kann man das Mischungsverhältnis und auch die Dosis pro Schraube genau einstellen.
Benötigt man keine genau eingestellte Aktivität ist die Anwendung des C14 sehr einfach: In eine MAXICOUNT-Kapsel gibt man einen Tropfen Aceton und einen Tropfen Lack, z. B. Bloc´Lube von Electrolube, mischt mit einem mit Aceton befeuchteten kleinen Pinsel wenige Sekunden durch und trägt den markierten Lack mit dem Pinsel auf. Halbtrocken und noch flexibel ist der Lack Bloc'Lube von Electrolube nach 10 Minuten, nach 24 Stunden ist die Trocknung abgeschlossen und man kann die Aktivität richtig messen. Andere Schraubensiegellacke trocknen schneller und eine MAXICOUNT-Kapsel reicht für dutzende Schrauben.

14C
Ein Klecks Siegellack, an dem vom C14 mit dem Geigerzähler deutliche 2,6 µSv/h messbar sind
Statt C14 eignen sich auch andere weiche Betastrahler, wie Tritium, Rubidium und auch reine Alphastrahler wie Po210.
Um es Angreifern nicht zu leicht zu machen sollte man nur eine oder wenige Schrauben markieren, damit ein Angreifer es nicht zu leicht hat und an jeder Schraube messen muss um später seinen Angriff mit markiertem und unmarkiertem Lack zu verdekcken.
Zusätzlich kann mnan auch die Notebook-Unterseite mit den versiegelten Schrauben hochaufgelöst scannen und die gesannten Siegellack-Formen optisch mit den aktuellen vergleichen, denn durch das Auftragen von Hand unterscheiden sich die Siegellacke auf den Schrauben wie Fingerabdrücke. Allerdings muss man davon ausgehen das Organisationen wie die NSA 3D-Drucker haben mit denen sie auch diese Sicherungsmaßnahme umgehen können. Aber auch diese Organisationen scheitern sichelich an Nanomarkierungen, beispielsweise an einem dutzend zufällig verteilten 100 x 100 nm großen Reliefs, die man mit einem CrossBeam-Elektronenmikroskop leicht ausschneiden und auch wiederfinden kann. Vor Firmen wie Zeiss bekommt man solche Geräte mit ausreichend großer Probenkammer und großem Probenhalter (Stage). Statt Reliefs kann man allgemein auch andere Nano-Markierungen verwenden, z. B. wenige nm kleine Magetisierungen oder Strahlenschäden. Sicher sind Naonmarkierungen weil sie für Lichtmikroskope unsichtbar sind und es mit einem Elektronenmikroskop Wochen dauert auch nur einige Quadratzentimeter nach allen Nanomarkierungen abzusuchen, selbst wenn vorher bekannt ist nach welcher Art (Relief, Magnetisirung, Strahlenschäden, ...) gesucht werden muss. Beispielsweise können in nur 4 cm² bis zu vierzig Milliarden nicht-überschneidende Nanomarkierungen einer Art untergeracht sein. Allerdings ist es aufwändig Nanomarkierungen zu setzen und zu überprüfen, insbesondere an großen und schweren "Proben" wie Notebooks.
Diese letzten drei Tipps gelten natürlich auch für die folgenden Methoden mit anders markiertem Lack.

C) Markieren mit einer Schwermetall-Verbindung oder Schermetall in Pulverform und Überprüfen mit einem der vielen handlichen Gammaspektrometer, mit denen die ROHS-Konformität von Teilen nachgewiesen wird.

D) Markieren des Lacks mit einem neutralen leichten Isotop, z. B. C13 oder Deuterium, und Nachweis mit einer Probenentnahme und einem Massenspektrometer. Diese Methode ist die aufwändigste aber auch die am schwersten erkennbare und fälschbare, da selbst leichte Massenspektrometer über 10 kg wiegen und auch die nötigen Vakuumpumpen einigen Strom verbrauchen.

E) Chemische Markierung, z. B. Markieren des Lacks mit künstlicher DNA (kDNA), die es als Diebstahlschutz auf dem Markt gibt.

Und natülich kann man auch alle diese Methoden kombinieren. Damit sie wirksam sein können muss man regelmä0ig überprüfen, z. B. nach jedem Grenzübertritt da der dort nicht nur der Zoll sondern viele andere Behörden auf die Hardware zugreifen können.

F) Farbloser durchsichtiger/transparenter Schraubensiegellack, so das diese Sicherungsmaßnahme auf den ersten Blick nicht erkennbar ist und das verringert die Zeit, die ein Angreifer hat um diese Sicherungsmaßnahme zu umgehen. Ein Beispiel ist der Schrauben-Sicherungslack transparent #10081 von Bader-Lacke, ein anderes der WEICONLOCK AN 302-40 von Weicon.

Etwas erschweren kann man die unauthorisierte Öffnung mit sogenannten Security Screws, z. B. vom Enermax UC-SST8 Security Screws Kit, da sich diese Schrauben nur mit speziellen Schraubendrehern einfach herausschrauben lassen. Ebenso ist es mit sogenannten Einwegschrauben, die man leicht hinein- aber kaum herausschrauben kann - auch nicht mit speziellen Schraubendrehern, so das man selbst sie nicht leicht entfernen kann.

Für den militäreischen Bereich gibt es weitere Sicherungsmaßnahmen in Form von Sprengfallen, die auch zur Selbstzerstörung dienen. Dafür reichen schon 100 g C4 (91 % Hexogen, 5,3 % Bis(2-ethylhexyl)-sebacat, 2,1 % Polyisobutylen und 1,6 % Mineralöl).


Not-Aus

Unmittelbar vor einem Angriff sollte man den Rechner ausschalten, um Angriffen auf den Bildschirmschon, wie auch Cold Boot Attacken, Viren, Trojanern u. A. sofort vorzubeugen. Dafür benötigt man ein Not-Aus, d. h. ein schnelles Ausschalten für das man eine Tastenkombination aber kein Passwort oder ähnliches benötigt, denn nur so ist sichergestellt das das Not-Aus immer funktioniert.

Um den Rechner schneller als über ein Shutdown/Ausschalten vom Betriebssystem durchzuführen hat man mehrere Möglichkeiten:

- Die Stromversorgung abschalten über eine Steckdosenleite mit Schalter oder Netzleitung (Stromkabel) ziehen oder über den Sicherungskasten oder einen Not-Aus-Schalter (falls vorhanden).

- Die Power-Taste für 4 s drücken.
Hierbei kann das Betriebssystem zumindest die wichtigsten Daten speichern und die Dateisysteme in einen konsistenten Zustand bringen.

- Mittels Magic SysRq key Poweroff.
Im einfachsten und schnellsten Fall nimmt man Alt-SysRq-o oder -b und für einem geordneten Shutdown mit zumindest dem Speichern der wichtigsten Daten und den Dateisystemen in einem konsistenten Zustand nimmt man Alt-SysRq-r|e|i|s|u|o, mit jeweils ca. 0,5 s Abstand.

Wichtig ist bei all diese Möglichkeiten, das man nicht eingeloggt sein muß, denn nur so ist sichergestellt das das Not-Aus immer funktioniert.

Man sollte die Benutzung trainieren, damit man Alt-SysRq-o oder -b im Notfall auch wirklich schnell beherrscht, innerhalb von ein bis maximal zwei Sekunden. Dazu fängt man am einfachsten mit einer nicht angeschlossenen Tastatatur oder einem ausgeschalteten Rechner an, nach dem Booten vor dem ersten Einloggen sowie nach jedem Absturz. Zum sehr schnellen Shutdown mit Alt-SysRq-b sollte man nicht viel mehr als eine Sekunde benötigen.

Daneben kann man ein Not-Aus oder auch ein Reboot von einer automatischen Überwachung der Sensor-Daten ausführen lassen kann, denn zu den Sensor-Daten gehört auch das Gehäuse (Chassis Intrusion Switch), vorausgesetzt das Mainboard hat einen entsprechenden Anschluß und das Gehäuse einen entsprechenden Schalter, der auch angeschlossen ist und der Rechner ist nicht ausgeschaltet. Gehäuse-Öffnungen zeigen sich dann im BIOS-Log, aber auch mit entsprechden Programmen wie Supero Doctor von Supermicro, das es für MS-Windows und Linux gibt. Beispiel mit geschlossenem Gehäuse:

> sdt 2>&1 | grep Intrusion
Chassis Intrusion Good

Entsprechend kann man es erweitern auf Rechner im Netzwerk, indem man deren ständige Anwesenheit überprüft mittels ping, arping oder ähnlichem.

Not-Aus mit Alarm

Bei einem Angriff wird neben dem Ausschalten meist auch ein Alarm benötigt, beispielsweise um den Werkschutz zu rufen. Dafür eignen sich Special Keypress (ALT-UpArrow) und CTRL-ALT-DEL, zu denen man in der /etc/inittab unterschiedliche Aktionen eintragen kann. Beispielsweise kann man ein kleines Skript eintragen, das eine kurze Email sendet und zum Schluß per poweroff ausschaltet.

Wie bei den obigen Möglichkeiten für ein einfaches Not-Aus muß man auch dafür nicht eingeloggt sein, denn ansonsten wäre es kein echtes Not-Aus.

Not-Aus mit Löschen

Wie beim Not-Aus mit Alarm kann man ALT-UpArrow oder CTRL-ALT-DEL benutzen um über ein Skript auch ein schnelles Not-Löschen durchzuführen. Das Not-Löschen ist natürlich nicht ein "Löschen aller Festplatten" wie man es in vielen schlechten Filmen sieht (und das in der Realität Stunden dauert), sondern nur das Löschen der Partition, in der sich das ERF befindet, indem der MBR ausgetauscht wird, wie im Kapitel "Dateisysteme zusätzlich verstecken" oben beschrieben.
In dem Skript kann man auch alles obige zum Not-Aus kombinieren, also Alarm, parallel Partition(en) löschen und zum Schluß per poweroff ausschalten. Dazu kann man auch ein zweites Passwort setzen, wie im nächsten Kapitel beschrieben.


Zweites Passwort/doppelt verschlüsseln

Man kann auch ein zweites Passwort verwenden und damit doppelt verschlüsseln (Two-factor authentication).
Wie oben zu enc.sh beschrieben kann man den Header/Anfang separat verschlüsseln, mit einem zweiten Passwort. Dazu gehört natürlich Brute-Force-Attacken zu blocken mit einem halbwegs sicheren Passwort, also nicht-trivial, mind. 20 Zeichen lang, mit Groß- u. Kleinschreibung, Ziffern, Sonderzeichen usw..
Den Anfang der Partition oder des Datenträger zu verschlüsseln reicht aus, weil die Verschlüsselung des ERF dort beginnt und nur dort angesetzt werden kann. Der Grund hierfür ist das Cipher Block Chaining (CBC) Aber selbst ohne CBC würde ein Verschlüsseln vom Anfang nicht einfach umgangen werden können, weil dort der Header des Dateisystems steht und ohne den hat man kein Dateisystem.

Zum Durchführen des XOR kann man viele Verschlüsselungs-Programme nehmen, man könnte es mit einem Bash-Skript machen und ich habe dafür mal das C-Programm exor.c gemacht.
Ähnliche findet man auf sourceforge.net mit der Suche nach XOR.
Ein einmaliges anwenden des XOR verschlüsselt, ein zweites entschlüsselt.
Für das Lesen/Schreiben am Partitionsanfang nimmt man ein Programm wie dd, denn den Programmen zum exklusiv-verodern kann man meist nicht angeben, wie viele Byte geodert werden sollen und terrabytegroße Partitionen exclusiv zu verodern dauert mehrere Stunden.

Etwas umständlich hierbei ist das man erstmal ein anderes System, z. B. ein Knoppix, booten muß und das XOR ausführen muß, aber dies macht viele Angriffe auf das ERF unwirksam.
Beispielsweise erfährt ein eingeschlepptes Rootkit nichts von dem zweiten Passwort.
Wegen diesem zusätzlchen Aufwand wird man daher in der Regel nur für im Vorhinein bekannte Angriffe treiben, oder wenn das ERF nur selten gebootet wird.

Diese Methode braucht man auch, wenn man Passwörter regelmäßig ändern möchte ohne neu zu Installieren, denn beim Loop-AES kann man das Passwort bisher nicht ändern.


Virtualisierung

Ein ERF kann man auch mit einer virtuellen Maschine wie beispielsweise VirtualBox verwenden und in einen Truecrypt-Container oder hidden Container oder einer verschlüsselten Partition installieren.
Damit hat man die komplette Verschlüsselung des virtualisierten Betriebssystems durch ein externes Programm.
Daneben hat man natürlich weiterhin die Möglichkeit das Betriebssystem mit Bordmitteln zu verschlüsseln, so wie ohne Virtualisierung.


Sicheres Umfeld

Zur Absicherung gehört auch ein sicheres Umfeld, beispielsweise damit niemand zur Passwort-Ausspähung über die Schulter sieht und damit niemand zur Passwort-Umgehung den noch eingeloggten Benutzer von der Tastatur wegreißen und dessen Account Übernehmen kann.
In der eigenen Wohnung ist das sichere Umfeld meist vorhanden, aber beispielsweise nicht mit dem Notebook draußen. Dagegen hilft ein sich häufig umsehen, aber das ist unpraktisch, lückhaft und sieht verdächtig aus, da es meist nur an besonderen Automaten wie Geldautomaten üblich ist. In der Sitaution hilft hier das, was unter anderem auch beim Autofahren gegen Gefahren von hinten hilft: Ein Rückspiegel. Den Rückspiegel gibt es als Software, indem man das Bild von der integrierten Webcam verwendet, und auch als Hardware, also sogenannten PC Rückspiegel oder Computer Rückspiegel. Diese Spiegel sind kleine konvexe Spiegel.
Es gibt kleine konvexe Rückspiegel auch zum Aufkleben auf einen großen Auto-Rückspiegel, zum permanenten Befestigen. Und da die Monitor-Ränder meist magnetisch sind, kann man diese aufklebbaren Spiegel auf eine Magnetscheibe kleben und zusammen damit kann man den Spiegel einfach und schnell am Monitorrahmen befestigen und auch wieder entfernen:
Rückspiegel

Eine integrierte Webcam als Rückspiegel zu benutzen ist aber deutlich unauffälliger und einfacher, mit dem Bild in einem Fenster auf dem Desktop und die verräterische Kontrollleuchte mit einem schwarzen Aufkleber verdeckt oder ausgelötet. Alternativ kann man meist einfach einen dünnen Magneten (Magnetscheibe) auflegen oder einfach mit einem schwarzen Permanentmarker, z. B. Edding 8300, übermalen. Für Webcams gibt es viele Anwendungen, beispielsweise Kopete, Luvcview, Guvcview, Camorama, Kamerka, Kamoso, Fswebcam, Mplayer und VLC. Allerdings zeigen die meisten Webcams a) eine erhebliche Trägheit und Latzenz im Berich hunderter Millisekunden und und b) das Bild seitenverkehrt, verglichen mit einem Spiegel. Deshalb muss man für die meisten Webcams das Programm mit Seitenverkehrung aufrufen um ein normales Bild zu erhalten. Den mplayer(2) beispielsweise so:

mplayer2 -nocache -vf mirror -tv device=/dev/video0 tv://
Durch die Option -nocache wird die Latenzzeit so gering wie möglich gehalten.
Die Spiegelung kann man auch optisch vornehmen, durch Aufsetzen eines Dove-Prismas, aber das ist so umständlich wie ein Spiegel.

Beim Notebook und allgemein bei Displays schützt zudem sogenannte Blickschutzfolie vor seitlichen Blicken auf das Display. Wie die Blickschutzfolie wirkt kann man an den meisten Geldautomaten gut sehen, wenn man bei einem Winkel von 45° versucht etwas zu lesen. Meist wirkt die Folie nur zur Seite und nicht nach oben oder unten.
Ein weiterer Tipp ist eine hohe Bildauflösung, mindestens Full HD (1080p HD), besser 4K UHD oder 8K UHD, zu verwenden und die Schriftgröße möglichst klein zu wählen. Mit einer Lesebrille kann man das sehr weit treiben und hat damit zudem den Vorteil das man auf dem Desktop viel mehr unterbringen kann. Damit können Informationen nur aus sehr kurzer Distanz ausgespäht werden.


Trollen/Honeypots

Trolle können das Spammen zum Trollen ausbauen um damit Angreifer zu provozieren, deren Resourcen zu binden und sie so zu kontrollieren. Früher oder später werden die Angreifer merken, das sie sinnlos beschäftigt wurden, von weiteren Angriffen absehen und sich ein leichtes Opfer suchen.
Hintergrund ist auch, das eine sichere Verschlüsselung nur durch eine korrekte Entschlüsselung wirklich nachgewiesen werden kann, das man aber Anzeichen für Verschlüsselung a) leicht vortäuschen (faken) kann und b) Anzeichen für tatsächliche Verschlüsselung nahezu unauffindbar sowie immer abstreitbar verstecken kann. Welche Anzeichen man vermeiden sollte, bzw. zum Spammen vortäuschen sollte, findet man in diversen Publikationen wie HTCIA 2006: Detecting and Collecting Whole Disk Encryption Media oder http://www.htcia-sd.org/Reference Documents/Detecting Whole Disk Encryption.pdf (anscheined ein ab 2010 toter Link, aber über Google sollte man die Datei auch heute noch finden).
Zum Vortäuschen/Faken mit dem Inhalt selber reicht es schon aus einen alten und möglicht nicht fehlerfreien Datenträger zu nehemen, ihn mit "badblocks -wsv -t random -c 65536 /dev/<device >" oder besser "dd conv=noerror if=/dev/urandom of=/dev/<device>" mit Datenmüll zu füllen und ihn mittels "dd if=luks.bin of=/dev/<device>" als LUKS-Verschlüsselt auszuweisen wie auch ein anschließendes "file -s /dev/<device>" zeigt. Hierbei kann <device> eine Partition oder der gesamte Datenträger sein, beim sogeannten Superfloppy-Format. Die Datei luks.bin hier stammt von einer ehemals verwendeten Partition und ist echt (kein Fake), aber es sind nur die ersten 512 Byte und damit ist alles dahinter Fake.

Ein weiterer Hintergrung ist das Menschen sehr häufig mit Vorurteilen arbeiten und beispielsweise vermuten das ein Dateiname etwas über den Dateiinhalt aussagt, aber tatsächlich ist das nur eine Vermutung, denn der Inhalt ist vom Namen völlig unabhängig, frei wählbar, und zudem sagt schon der Name wenig aus, ist nicht selten mehrdeutig oder gar missdeutend; beispielsweise faltet ein Zitronenfalter keine Zitronen.
Ein weiteres Beispiel ist das Vorurteil das sich auf einem privaten Computer Pornos befinden und daher ist ein Computer ohne Porno für Polizisten ungewöhnlich: http://www.heise.de/tp/blogs/5/149563. Fehlt Spam in Form von Pornos sind viele Angreifer richtig enttäuscht und der anwaltliche Rat vom RA Udo Vetter lautet daher "Wir halten also fest: Ein paar legale Pornos sollten stets auf der Festplatte eines Mannes sein - schon um die Kripo nicht ins Grübeln zu bringen.".
Am besten geeignet sind Polizei-Pornos, denn das macht den Computerbesitzer nicht nur unverdächtiger sondern auch sympathischer.


Zudem kann man mit Spam/Trollen/Honeypots sogar beweisenermaßen richtig behaupten, das die abstreitbare Verschlüsselung nur ein Trollen mit Datenmüll ist!
Jack Sparrow beschrieb dies im Film "Der Fluch der Karibik" so: "Man kann sich darauf verlassen, dass ein unehrlicher Mann immer unehrlich ist. Ehrlich.".
Juristisch gesehen handelt es sich beim Trollen/Spammen um ein Veralbern oder zum Narren halten ohne das damit zwingend ein materieller Nachteil verbunden sein muss. Juristen nennen dies Verarschen. Kombiniert man es mit einem materiellen Nachteil, handelt es sich um ein Bescheißen. Ausführlich nachlesen kann man dies beim Landgericht Frankfurt_am_Main, Beschluss v. 26.09.2008 - Az.: 3-11 O 63/05.

Zum Trollen reicht es schon aus, die nicht mehr benötigte alte Hardware, insbesondere Datenträger wie Festplatten, nicht einfach zu entsorgen oder für meist sehr wenig Geld zu verkaufen, sondern aufzuheben und als Honeypot zu verwenden, für proaktiven Datenschutz. Alternativ kann man alte Hardware für das Trollen für sehr wenig Geld z. B. auf Flohmärkten oder auf ebay kaufen oder auf Recyclinghöfen finden.
Wem das zu aufwendig ist, kann sie auch bei mir kaufen: Eine garantiert defekte und/oder mit Datenmüll gefüllte HDD ab 9,99 Euro (+Versand) und ein mit Datenmüll gefüllter und ein intakter PC, den man auch von USB-Stick booten kann, ab 99,99 Euro (+Versand).

Zum Trollen kann man die Datenträger nach der Randomisierung (s. o.) lustig beschriften.
Die Klassiker sind GEHEIM, STRENG GEHEIM, VS-VERTRAULICH, VS-NUR FÜR DEN DIENSTGEBRAUCH, bzw. in englisch Secret, Top secret, Confidential, Restricted, COSMIC Top Secret, NATO Secret, NATO Confidential oder NATO Restricted.
Andere Klassiker sind die Betreffzeilen lustiger Überweisungen, also:
Finanzierung geheimer Untergrundarmee
Unterstützung der Revolution
Rebellenführer-Lohn
Provision für Beseitigung der Leiche
Geldwaesche Januar, Schwarzgeld
Schwarzarbeit
Verschwörung
Ertrag aus Drogenhandel, Prostitution und Schutzgeld
illegale Parteispende
für sexuelle Gefälligkeiten
Kinderpornoring Trier West
Sonderangebot: Combo mit Sarin, Antrax, Plutonium und Zuendsaetzen
Hanfsamen, Mohnkuchen
Danke für die Warez-CDs
Auftragsmord am 20.11.
Blutgeld
Steuersünder-Datei Nr. 3
Bestechungsgeld Nr. 2
Amoklauf 2.3.
Schweigegeld
Schwarzbrennerei
Entführung
Al Quaida
Planung des dritten Weltkriegs
Kalaschnikow Semtex RAF AK47 Sarin Heroin Heil Hitler und Rot Front
Ertrag aus Drogenhandel, Prostitution und Schutzgeld
BIOWAFFEN,URAN,ANTHRAX / DANKE FÜR DIE PA!
SCHWEIGEGELD / JETZT SIND WIR QUIT!
KOKS UND NUTTEN
Sprengen und Sparen
Kokslieferung 09/10
Für terroristische Zwecke
Waffenlieferung 11/10
Osama
rosa marmelade
Nazi
Anna Ziegler

Weitere Quellen findet man u. A. bei Juristen: Beispielsweise Kurs-Namen wie "Tötung und Körperverletzung" (Kurs 5046 der Fernuni Hagen) und das Inhaltsverzeichnis vom Strafgesetzbuch. Dort findet man auch Varianten wie "Tötungsdelikt" statt Mord oder Totschlag oder §211 statt Mord.

Die Beschriftungen sollten wie üblich kurz (und damit unpräzise) sein und vor allem mehrdeutig, damit sie die Phantasie anregen, neugierig machen und anregen den Inhalt einzusehen.
Beispielsweise kann "Kokslieferung 09/10" für Daten zu einer Kokslieferung für eine Heizung oder einen Hochofen stehen, oder für Daten zu einer Kokainlieferung oder für Daten zu einer Ermittlung zu einer Kokslieferung oder ... Ohne eindeutige Beschreibung mit Datum, Ort und Anwesenden/Eingeladenen ist so eine Beschriftung nichtssagend, regt aber die Phantasie an.
Ein Beispist ist "Drogen und Sucht", zum dem die Such-Treffer bei Google zu über 90 % Seiten dagegen anzeigen und die gleichnamige Broschüre des Bund deutscher Kriminalbeamter enthält auch nichts dafür.
Ein anderes Beispiel ist "Sprengen und Sparen", denn das kann sparsamen Umgang mit Sprengstoff bedeuten, z. B. auf Truppenübungsplätzen oder beim Bergbau oder um Porto bei Briefbomben zu sparen, aber meist bedeutet es schlicht sparsame Bewässerung im Garten.

Zusätzlich zu der Randomisierung kann man auch eine verschlüsselte Partition vortäuschen, wie im Kapitel Verschlüsselungsverfahren beschrieben. Damit macht man die Datenträger interessanter für Angreifer und man macht ihnen damit eine (kurzzeitige) Freude, wie bei Honeypots üblich.

Um es Angreifern nicht zu leicht zu machen, sollte man zumindest einige der Festplatten mit einem Degausser oder einem billigen Todesmagneten behandeln, damit der Datenmüll nicht einfach und schnell sondern nur langsam und mit einem teuren Datenrettungs-Labor ausgelesen werden kann.

Alte Rechner sollte man mit reichlich unwichtigem Datenmüll betriebsbereit stehen lassen; falls ein Angreifer sie mitnimmt, macht man ihm damit eine (kurzfristige) Freude, er spart einem den Aufwand für die Entsorgung und nachdem der Angreifer merkt was er mitgenommen hat, wird er sich sicherlich ein anderes Opfer suchen.
Als Datemüll sollte man in den unverschlüsselten Partitionen nicht nur langweilige Zufallsbytes in uninteressanten Dateinamen nehmen, sondern abwechslungsreichen Datenmüll wie z. B.:

- Dateien mit den Namen, Größen und CRC32-Prüfsummen von (2009) bekannten Pornos und Dateien mit Datenmüll, aber lustigen Namen wie z. B. Anthrax_Powder_4.pdf. Dafür gibt es z. B. das Skript noscript in dem die zu erzeugenden Dateien eingetragen sind und das sich nach dem Erzeugen der Dateien natürlich selbst löscht, zusammen mit dem für die Prüfsummen benötigten fakecrc.

- Dateien, die auf den ersten Blick verschlüsselt aussehen, aber nachweisbar nur Datenmüll sind. Dafür gibt es z. B. das Skript pgpfake.sh, das PGP-Verschlüsselte Nachrichten fakt.

- Zip-Bomben und Sparse Files, die zwar nur Nullen enthalten, die aber virtuell so groß sind, das deren Durchsuchen mehrere Tage dauern würde. Beispiele sind die Zip-Bomben 42.zip und klein.bz2 sowie sparse Files wie z. B.:

dd if=/dev/zero bs=1M of=secret.img seek=1M count=0

Wobei diese Datei eine scheinbare Größe von 1 TiB bei einer tatsächlichen Größe (auf dem Datenträger) von 0 hat.

- Verzeichnisse die alle möglichen Dateinamen der Länge n enthalten. Hierfür gibt es das filescreate.c.
Es eignet sich auch um eine Partition zu 100 % zu füllen, indem man einfach n ausreichend groß wählt, wobei n=4 mit gut vier Milliarden Dateinamen meist ausreicht. Um möglichst wenig Platz zu verschwenden sollte man dazu ein Dateisystem mit Tail Packing / Block Suballocation verwenden.

Es gibt noch einigen anderen Datenmüll, den man nehmen kann; z. B. Link Loops und Direktory Loops.
Daneben gibt es noch als Klassiker das unter der Tastatur auf einem Aufkleber notierte Passwort und weil das geheim sein sollte, schreibt man darauf z. B. "Passwort: geheim".



Links

Comparison of disk encryption software.
Eine sehr umfangreiche und aktuelle Übersicht der Features verschiedener Programme zur Festplatten-Verschlüsselung.

Workshop: Rechner mit Luks und ZFS on Linux komplett verschlüsseln.
Ein Artikel des Linux-Magazin 01/13, S. 62-65, mit Gentoo und dem transparent komprimierendem Dateisystem ZFS, das mit LUKS verschlüsselt ist. Der Artikel zeigt auch das die Verschlüsselung die Performance meist nur minimal verschlechtert.



Sitemap