Zu dem
ERFH (Encrypted Root Filesystem Howto)
gibt es einige wichtige Anmerkungen/Updates, denn der letzte Stand ist von
Anfang 2005, also heute (2011) 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 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.
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
auch hierauf nicht ein.
Umgesetzt habe ich diese Ergänzungen u. A. bei einem PC und einem Notebook;
die Ergänzungen habe ich alle selbst getestet.
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.
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.
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 mit um 3 (32-Bit-Linux) bis 6 MByte/s (64-Bit-Linux) langsam:
Eine aktuell (Ende 2009) mittelgroße Festplatte mit einer Größe von 2 TB zu
Randomisieren dauert entsprechend eine halbe bis eine 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ß.
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:
Im ERFH wird auf dem Boot-Medium nur eine Boot-Partition und die nur für das
ERF verwendet, was natürlich sehr 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.
Daneben kann man die beiden Methoden auch kombinieren.
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/.
Mainstream ist aktuell (2011) dm-crpyt, das meist mit der Erweiterung
LUKS verwendet wird.
Der Nachteil 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 kontraproduktiv, 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).
Derzeitiger Stand mit Debian 5.0.3 (Sept. 2009)
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/
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.
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.
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 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.
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 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.
Allerdings sind versteckte Datenträger meist unpraktikabel
umständlich, auch weil sie nur dann sinnvoll sind, 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.
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.
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 zusätzlich unwahrscheinlicher zu machen und zumindest 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
das Boot-Medium manipuliert haben könnte.
Von der Zeitschrift c't gibt es etwas ähnliches, was allerdings
SHA1-Prüfsummen verwendet und daher nicht resistent gegenüber
Hash-Kollisionen ist:
Boot-Sicherung, Verschlüsselte Linux-Notebooks absichern,
Softlink dazu.
Man kann noch weiter gehen und zusätzlich z. B. 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.
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 oder Cold Boot Attack erfolgen.
Keylogger in Hardware können alle Tastatureingaben aufzeichnen und so auch die Passwörter
abhören um so die Verschlüsselung auszuhebeln.
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 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++.
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.
Unmittelbar vor einem Angriff sollte man den Rechner ausschalten,
um Angriffen wie Cold Boot Attacken, Viren, Trojanern u. A. 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 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.
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.
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.
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.
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, obwohl beide völlig unabhängig und
frei wählbar sind und zudem schon der Name wenig aussagt;
beispielsweise faltet ein Zitronenfalter keine Zitronen.
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".