Dein Computer klappert und quitscht? Du brauchst Hilfe mit einem Linux-System? Du möchtest mehr über Dein Arbeitsgerät wissen?
Komm rum...

Du oder Deine Gruppe möchtet Eure e-mails lieber verschlüsselt verschicken...? Oder gleich lieber die ganze Platte sicher machen...? Wir zeigen Euch wie's geht...

Du willst wissen was sich hinter TKÜ verbirgt? Oder warum Windows böse und Linux besser ist? In unseren Texten findest Du Antworten...

Was ist Festplattenverschlüsselung

Allgemeines

Zielsetzung

Verschlüsselung eines Speichermediums schützt vor Offenlegung der Daten bei unmittelbarem Verlust des Mediums. Sie schützt auch vor unbemerkter und unauthorisierter Modifikation der Daten auf dem Medium, was allerdings nur ein Nebeneffekt ist. Folgende wichtige Sicherheitaspekte werden vorerst nicht bearbeitet:

  • Sicherheit vor vorbereitenden Täuschungsaktivitäten des Angreifers, die zur aktiven Herausgabe des Schlüssels oder der Daten durch die Angegriffene führen.
  • ``plausible deniability'', ``hidden volumes'' - die Möglichkeit, glaubhaft (z.B. vor Gericht) abzustreiten, dass auf dem Medium überhaupt verschlüsselte Daten vorliegen

Allgemeines zu dm-crypt/luks

dm-crypt/luks

  • verschlüsselt transparent: Der Schlüssel wird nur beim Einbinden des Dateisystems eingegeben. Danach startet jedes Schreiben/Lesen von Dateien automatisch die Ver-/Entschlüsselung.
  • baut auf dem device-mapper und dem ``linux unified key setup'' auf, deren Kernbestandteile im Linux-Kernel sind.
  • lässt sich demnach auf Linux-Systemen sehr bequem verwenden und warten
  • lässt sich per pam-mount in die Anmelderoutine itegrieren (nur ein Passwort angeben)
  • ist nur begrenzt portabel, da speziell für Linux geschrieben. Verschlüsselte Medien können trotzdem unter Windows mit FreeOFTE gelesen werden.

Architektur von dm-crypt/luks

 

Image architektur
http://www.linux-magazin.de/heft_abo/ausgaben/2006/10/loechriger_kaese/

benötigte Software

Neben dem Linux-Kernel, der hoffentlich schon vorhanden ist, werden zwei kleine Hilfsprogramme zur Verwaltung der verschlüsselten Pertitionen gebraucht:

  • dmsetup: zum Konfigurieren des device-mappers
  • cryptsetup: zum Arbeiten mit den verschlüsselten Partitionen

Auf Debian oder Ubuntu können diese Programme mit folgender Befehlszeile installiert werden:

apt-get install dmsetup cryptsetup

Welche Teile des Systems sind wie zu schützen?

 

zugriffsbeschränkte Systemverzeichnisse

 

Was sind Systemverzeichnisse

  • /: Wurzel des Verzeichnisbaums
  • /bin: essentielle, beim Booten benötigte Programme
  • /boot: Boot Loader und Hilfsdateien
  • /dev, /proc, /sys: Geräte, Systemzustand
  • /etc: systemweite Einstellungen
  • /home, /root: Nutzer- und root-Verzeichnisse
  • /lib: essentielle, beim Booten benötigte Bibliotheken
  • /media und /mnt: Mount points für zusätzliche Dateisysteme
  • /sbin: essentielle Systemprogramme
  • /tmp: temporäre Dateien
  • /usr: nicht boot-essentielle Anwendungen, Bibliotheken, usw
  • /var: variable Daten verschiedener Prozesse

 

Grundproblem

 

  • Zugriffsbeschränkte Systemverzeichnisse, also /, /usr, /etc und alles was im Weiteren nicht explizit erwähnt wird, enthalten normalerweise keine sensiblen Daten, da unprivilegierte Nutzer hier nichts ablegen dürfen.
  • Aber: hier befindet sich essentielle Systemsoftware. Wer diese verändern (z.B. einen Webserver installieren) kann, kann die Nutzerdaten später, nach der Entschlüsselung, offenlegen.
  • Verschlüsselung bietet indirekten Schutz davor, da ein Angreifer zwar auf den Datenträger schreiben, aber nicht korrekt verschlüsseln kann.
  • Aber: Es ist unmöglich sämtliche Systemsoftware verschlüsselt zu halten, da die Entschlüsselung selbst von Software geleistet werden muss.

 

Lösung1: Keine Verschlüsselung der Systemverzeichnisse

Annahme: Ein physischer Angriff auf den Rechner bleibt nicht unbemerkt.

  • Sind nur die Nutzerdaten verschlüsselt so kann eine Angreiferin durch ``lesenden'' physischen Zugriff keine Daten entwenden, sie muss vielmehr dem Nutzer ein korrumpiertes System mit den verschlüsselten Daten unterschieben, ohne dass dieser es merkt.
  • Gehen wir davon aus, dass dies nicht passieren kann (indem der entsprechende Rechner beispielsweise rund um die Uhr beobachtet wird), so müssen wir die zugriffsbeschränkten Systemverzeichnisse nicht verschlüsseln.

 

Lösung2: Verschlüsselung aller Systemverzeichnisse, bis auf /boot

Annahme: Die Angreiferin kann zwar verschiedene Programme unbemerkt modifizieren, wenn sie zugänglich sind, nicht aber den Kernel oder den frühen Boot-Prozess.

  • Die Verschlüsselung der Systemverzeichnisse dient dazu, eine Modifikation zu unterbinden.
  • Die unverschlüsselte /boot-Partition ist aus der Not geboren, dass die Software, die die Ver-/Entschlüsselung selbst vornimmt nicht verschlüsselt sein kann.
  • Nachdem diese Software allerdings notwendigerweise mit den höchsten Privilegien läuft, wäre es natürlich möglich die Modifikation hier schon anzusiedeln und somit den Schutz zu umgehen.

Dieses Verfahren ist zwar sehr verbreitet, beruht aber auf einer offensichtlich inkonsistenten Annahme.

 

Lösung3: Verschlüsselung aller Systemverzeichnisse der Platte, /boot wird auf einem externen Medium gehalten

Annahme: Der Angreifer kann zwar die internen Medien des Rechners modifizieren, das externe Medium aber weder modifizieren noch austauschen und auch keine Zusatzhardware unbemerkt in den Rechner einbauen.

  • Durch Modifikation der Festplatte ist hier kein Angriff möglich.
  • Das externe boot-Medium wird hier nur zum Booten mit dem Rechner verbunden und allgemein besser als dieser bewacht.
  • Hardware-Modifikationen (z.B. ein Keylogger an der Tastatur) können diesen Schutz leicht umgehen.

Diese Annahme ist zwar konsistenter als die vorige, die Umsetzung ist allerdings umständlich und der Sicherheitsgewinn relativ klein.

 

Nutzerverzeichnisse

/home - Getrennte home-Partitionen für alle Nutzerinnen?

 

  • Diese Frage erübrigt sich, wenn der Rechner nur von einer Person genutzt wird.
  • Wird der Rechner von mehreren Leuten genutzt, so kann es von Vorteil sein, deren Daten unabhängig von einander zu verschlüsseln.
  • Ein Angriff auf einen Nutzer führt dann nicht automatisch zur Offenlegung der Daten aller anderen.
  • Um alle Daten zu erhalten muss die Angreiferin so jedem der Nutzer unbemerkt ein korrumpiertes System unterschieben.
  • Sind hingegen alle Daten gemeinsam verschlüsselt, so reicht es, eine Nutzerin zu täuschen.
  • Mehr Partitionen sind allerdings mit höherem Verwaltungsaufwand und ``Verschnitt'' verbunden.

 

/media - externe Speichermedien

 

 

  • Speichermedien, die mit dm-crypt/luks verschlüsselt sind, können nur mit dm-crypt/luks wieder gelesen werden.
  • dm-crypt/luks läuft nur unter Linux, daher können diese Medien unter Windows nur mit Zusatzsoftware (FreeOFTE), unter Mac OS (soweit ich weiß) nicht gelesen werden.
  • Die Verschlüsselung bietet sich trotzdem beispielsweise für Backup-Medien an, die nur an einer begrenzten Menge von Rechnern verwendet werden.

 

veränderliche Systemverzeichnisse

/var - variable Dateien

 

  • In /var befinden sich veränderliche Dateien für verschiedene Anwendungen.
  • z.B. /var/spool für Druckaufträge, /var/lib/emacsen-common für temporäre Dateien von emacs
  • In /var/tmp können Anwendungen beliebige temporäre Dateien ablegen, die über Reboots hinweg erhalten bleiben
  • /var sollte also unbedingt verschlüsselt werden
  • Da /var auch von verschiedenen Systemdiensten genutzt wird, muss die Ver-/Entschüsselung schon früh im Bootprozess geschehen

 

/tmp - temporäre Dateien

 

  • In /tmp kann jede Nutzerin beliebige Daten ablegen.
  • /tmp wird bei jedem Neustart (oberflächlich) gelöscht.
  • Diese Eigenschaften werden von vielen Programmen genutzt. So wird OpenOffice beispielsweise regelmäßig Kopien des momentan bearbeiteten Dokuments dort ablegen.
  • Es gibt die Möglichkeit /tmp komplett im Hauptspeicher zu halten. Dadurch wird das Sicherheitsrisiko durch Spuren in /tmp aufgehoben.
  • /tmp im Hauptspeicher führt jedoch dazu, dass vermehrt Hauptspeicher benutzt wird, der knapp sein könnte.
  • Falls /tmp auf der Festplatte gehalten wird, sollte es auf jeden Fall verschlüsselt werden. Hier kann bei jedem Start ein neuer zufälliger Schlüssel verwendet werden.

 

swap - der Auslagerungsspeicher

 

  • Der Auslagerungsspeicher wird als ``Ersatz'' für Hauptspeicher genutzt, wenn der Hauptspeicher knapp ist.
  • Der Auslagerungsspeicher wird bei jedem Neustart neu initialisiert und als ``leer'' angesehen aber nie wirklich gelöscht.
  • Hier werden also gegebenenfalls interne Daten der Programme abgelegt, die der Nutzer verwendet.
  • Wer den Auslagerungsspeicher lesen kann, kann also Spuren der Nutzerdaten dort vorfinden.
  • Der Auslagerungsspeicher sollte also auf jeden Fall verschlüsselt werden; dazu kann bei jedem Start neuer, zufälliger, Schlüssel verwendet werden.

 

Fazit

Aus den bisherigen Feststellungen ergibt sich nun Folgendes:

  1. /home, /tmp, /var und swap müssen verschlüsselt werden
  2. /tmp und swap können bei jedem Start neu initialisiert werden, brauchen also keinen festen Schlüssel
  3. Über / und /usr kann man sich streiten
  4. Der Einfachheit halber wird empfohlen, mittels Neuinstallation (Debian, Ubuntu ``alternative installer'') die gesamte Festplatte zu verschlüsseln. Dabei werden mit aus einem großen verschlüsselten Plattenbereich mit LVM ``logical volumes'' gebildet.
  5. Im Folgenden wird die Verschlüsselung einer einzelnen Partition und der Umgang mit verschlüsselten Partitionen demonstriert

 

verbleibende Angriffsmöglichkeiten

Image angriffsvektoren
frei nach http://www.linuxjournal.com/article/7743

 

Vorgehen

 

Verschlüsseln einer Partition

Als Erstes werden alle Daten gesichert! Anschließend werden folgende Kommandos als root ausgeführt, wobei ``hdaX'' durch die zu verschlüsselnde Partition ersetzt wird:

umount /dev/hdaX
dd if=/dev/urandom of=/dev/hdaX bs=8M
cryptsetup luksFormat /dev/hdaX
cryptsetup luksOpen /dev/hdaX crypt-hdaX
mkfs.ext3 /dev/mapper/crypt-hdaX

Achtung: Zeile 2 überschreibt die Partition mit Zufallszahlen. Das dauert. Alternativ funkioniert es mit auch ``if=/dev/zero'', dann werden Nullen verwendet und es ist später sichtbar, wo Daten liegen. ``cryptSetup luksFormat'' fragt nach Erlaubnis (``YES'') und dem Schlüssel für die Initialisierung der Partition.

Bisher kann die Partition nicht automatisch beim Booten eingebunden werden. Daher sollte in /etc/fstab die bisherige Zeile für /dev/hdaX gelöscht werden. Wenn die Partition zunächst beim Booten eingebunden werden soll, muss die Datei /etc/crypttab mit folgender Zeile versehen werden:

crypt-hdaX /dev/hdaX none luks,retry=1

 

In /etc/fstab muss in diesem Fall folgende Zeile angelegt werden:

/dev/mapper/crypt-hdaX <mnt> ext3 defaults 0 2

 

Damit wird beim Booten der Schlüssel abgefragt und an <mnt> eingebunden. Für <mnt> würde z.B. /home eingetragen, wenn es sich um die Partition mit den Home-Verzeichnissen handelt

Schlüssel verwalten

 

Prinzip

  • Mit dm-crypt können mehrere gleichberechtigte Schlüssel für eine Partition festgelegt werden.
  • Schlüssel können beliebig entfernt oder hinzugefügt werden, solange danach immer mindestens einer und höchstens 8 vorhanden sind.
  • Damit können z.B. kompromittierte Schlüssel wieder zurückgezogen oder weiteren Benutzern der Zugriff erlaubt werden, ohne Schlüssel offenzulegen.
  • Intern wird ein ``Hauptschlüssel'' mit jedem der Benutzerschlüssel verschlüsselt und in je einem der ``Key Slots'' abgelegt. Der Hauptschlüssel wird also nicht im Klartext gespeichert, sondern muss vor der Verwendung mit einem Benutzerschlüssel entschlüsselt werden.

 

Umsetzung

Zur Authentifikation wird bei Schlüsseloperationen ein Schlüssel abgefragt, der von der momentanen Operation unberührt bleibt.

Schlüssel hinzufügen:

cryptsetup luksAddKey /dev/hdaX

 

alle Schlüssel(-Slots) anzeigen:

cryptsetup luksDump /dev/hdaX

 

Schlüssel zurückziehen:

cryptsetup luksDelKey /dev/hdaX <index>

<index> muss hier durch die Nummer des zu löschenden Schlüssels ersetzt werden. Diese wird bei bei jeder Benutzung des Schlüssels angezeigt.

 

cryptsetup luksDump /dev/hdaX

 

LUKS header information for /dev/hdaX

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 1032
MK bits: 128
MK digest: [...]
MK salt: [...]
MK iterations: 10
UUID: 7377356f-7ecf-4f54-9066-66a346406d44

Key Slot 0: ENABLED

  Iterations: 347664
  Salt: [...]

 

Backups

 

Problem

Zusätzlich zu den üblichen Problemen beim Backup von Daten ergeben sich bei sensiblen, verschlüsselten Daten weitere Herausforderungen:

  • Beim Backup wird unweigerlich eine Kopie der Daten hergestellt (der Sinn der Sache)
  • Wird diese Kopie korrumpiert, so ist das ebenso schlimm wie eine Korrumpierung des Originals
  • Die meisten Backupsysteme können keinen vollständig verschlüsselten Arbeitsablauf garantieren
  • Es gibt kein Standard-Backupsystem, auf das hier näher eingegangen werden könnte

Angesichts dieser Tatsachen werden zwei einfache manuelle Verfahren demonstriert, die die Integrität der Daten erhalten.

 

Mit GnuPG verschlüsselte Dateien auf Backup-Medien

Wer GnuPG sowieso schon zur Verschlüsselung von Emails benutzt kann es hier weiterverwenden, um Backups zu verschlüsseln, die dann beispielsweise auf CD gebrannt werden. Zu beachten ist:

  • Zu sichernde Dateien sollten das verschlüsselte Medium erst verlassen, wenn sie mit GnuPG verschlüsselt sind
  • Der eigene private Schlüssel kann auf diese Art nicht gesichert werden
  • Es gibt grafische Frontends für GnuPG, z.B. Seahorse, ein Plugin für den Gnome-Dateimanager Nautilus

 

Backup auf externe ebenfalls verschlüsselte Festplatte

Dies ist die offensichtliche Lösung, die jedoch nur mit einer zusätzlichen externen Festplatte machbar ist. Das Vorgehen sollte klar sein:

  • Die externe Festplatte verschlüsseln, wie oben beschrieben. Das Device könnte z.B. /dev/sdb heißen
  • Es muss kein spezieller Mount Point in /etc/fstab und kein Eintrag in /etc/crypttab angelegt werden, denn ...
  • Gnome erkennt die verschlüsselte Platte, wenn sie angeschlossen wird, fragt selbstständig nach dem Schlüssel und mountet sie
  • Anschließend können beliebige Daten kopiert werden.

Dieses Vorgehen könnte auch mit einigen Backupsystemen kompatibel sein, die sich darauf beschränken, Backup-Dateien auf einem les- und schreibbaren Datenträger zu verwalten.