Über mich

Text? Mein Name ist Heiko, ich bin 33 Jahre alt und lebe im schönen Stralsund. Somit genieße ich mein Dasein als Informatiker in Meeresnähe. :)
Näheres findest du hier.

Neueste Kommentare

Beliebteste Artikel

Blogroll

Kategorien

Tag Cloud

Archiv

23.09.2011

Datensicherheit 2 – Verschlüsseltes System Reloaded

Eigentlich wollte ich in der Fortsetzung über Datensicherheit speziell auf Firewalls eingehen, aus aktuellem Anlass ist nun aber doch noch einmal ein Artikel über Festplattenverschlüsselung daraus geworden.

In Teil 1 sind wir darauf eingegangen, wie man Windows und Linux parallel verschlüsseln kann, das ist nach der hier vorgestellten Methode natürlich genauso möglich, jedoch werde ich hier nur auf eine reine Linux Installation eingehen. Ich möchte allerdings versuchen, dies möglichst auch einem Linuxeinsteiger verständlich zu ermöglichen. Im Zweifelsfall kann man hier nochmal Teil 1 finden: Datensicherheit 1 – Verschlüsseltes System.

Das Szenario

Das Szenario sieht vor, ein aktuelles Ubuntu 11.04 ähnlich wie in Teil 1 zu verschlüsseln, jedoch soll die Entschlüsselung des Systems automatisch per Schlüssel auf einem USB Device vonstatten gehen. Dies ist eigentlich nicht vorgesehen und bringt damit einige Schwierigkeiten mit sich, zu denen man stundenlang ohne Ergebnis googlen oder man-pages wälzen kann, nach einigem Trial&Error werde ich nun aber eine funktionierende Lösung anbieten. :)

Wir werden den Schlüssel hierbei so auf dem USB Stick platzieren, dass man diesen auch getrost mal formatieren kann und der Schlüssel nicht für jedermann sofort offensichtlich zu finden ist. Ich gehe von einer 3-Partitionen Installation aus (/dev/sda1-3), bei der sda1 den Mountpoint /boot bereitstellt, sda2 eine swap-Partition und sda3 die root-Partition, natürlich könnte letztere aber auch in weitere Mountpoints aufgeteilt oder als LVM benutzt werden. Verschlüsselt werden hierbei root und swap, boot bleibt wieder unverschlüsselt.

Ein Schlüssel ohne Schloss

Beginnen wir mit dem Vorbereiten unseres zukünftigen Schlüssels. Jeder x-beliebige USB Stick kann hierfür herhalten, befinden sich auf diesem Daten, so sollten diese vorher gesichert werden, da wir den Stick komplett überschreiben werden.
Unter Linux rufen wir nun den Befehl fdisk auf dem USB Stick auf (Sagen wir dieser wurde als /dev/sdb erkannt).

fdisk /dev/sdb

Mit dem Kommando “d” löschen wir nun alle Partitionen, die sich eventuell auf dem Stick befinden. Anschließend mit “n” eine neue Partition erstellen, hierbei geben wir nun als Startzylinder “2″ an und nicht, wie vorgeschlagen “1″, als Endzylinder kann die Vorgabe verwendet werden, um den maximalen Platz zu nutzen. Mit “w” speichern wir die Änderungen in der Partitionstabelle.
In meinem Fall weißt der Stick eine Blockgröße von 512Byte auf und eine Zylindergröße von 7688 Blöcken, wir haben nun also fast 4MB vor der Partition “verschenkt”. Viel Platz um sich einen mehr oder weniger zufälligen Ort für einen Schlüssel auszusuchen. :)
Eine zufällige Datenfolge, die als Schlüssel fungieren soll, würde nun beim auslesen dieses Bereichs eventuell auffallen, deshalb werden wir vorsorglich den kompletten USB-Stick mit Zufallsdaten überschreiben. Naja, den ersten Block (die ersten 512 Byte) belassen wir, wie er ist, denn hier befindet sich unser Masterbootrecord und damit auch die eben erzeugte Partitionstabelle.

dd if=/dev/urandom of=/dev/sdb bs=512 seek=1

Der Befehl “dd” führt ein bitweises Kopieren durch, als Quelle geben wir hier /dev/urandom an (ACHTUNG: Nicht /dev/random verwenden! Dieses erwartet regelmäßiges generieren von Zufallsdaten durch Nutzerinteraktion), als Ziel wird der USB Stick gewählt, hier /dev/sdb. Desweiteren definieren wir eine Blockgröße von 512 Byte und sagen dd mit “seek=1″, dass er den ersten Block des Zielgeräts (Also den MBR) überspringen soll.
Dieser Vorgang nimmt nun etwas Zeit in Anspruch, bei mir (4GB USB Stick) dauerte es ca. 1 Stunde.

Wann kommen wir nun endlich zum Schlüssel selbst?…
Wir haben ihn doch längst. :) Ein ganzer USB Stick voller Zufallsdaten, davon kann nun ein beliebiger Bereich zwischen den ersten 512 Byte und dem Beginn des 2. Zylinders sicher als Schlüssel verwendet werden.
Schlussendlich stecken wir den Stick nur noch in eine Windowsmaschine und formatieren die Partition mit der Option “Schnellformatierung” mit einem Fat32 Dateisystem, so legt Windows seine DOS-ID an und der Stick kann später sowohl unter Windows, als auch Linux als normaler Datenspeicher verwendet werden. (Ob ein Formatieren ohne die Option “Schnellformatierung” den Bereich vor der Partition unberührt lässt, habe ich nicht getestet, normalerweise sollte aber auch das funktionieren.)

Vorbereitungen für das Verschlüsseln

Als nächstes müssen wir, wie im Teil 1, unser installiertes System sichern. Entweder auf einer lokalen Partition oder einem externen Laufwerk (/dev/sdc sei unsere Backupplatte).
Wir booten erst einmal wieder mit einem Livesystem (z.B. der Installations-CD / Installations-USB-Stick von Ubuntu), hängen die Dateisysteme ein und sichern das System. Mit “sudo su” auf der Konsole werden wir zum root user.

mkdir /backup
mount /dev/sdc1 /backup
mount /dev/sda3 /mnt
mount /dev/sda1 /mnt/boot
tar -cvf /backup/system.tar -C /mnt/ ./
umount /mnt/boot
umount /mnt
umount /backup

Safty first

Der hier beschriebene Schritt ist optional, jedoch sehr zu empfehlen! Zwar dauert dies sehr lange (In meinem Fall, mit einer 160GB Festplatte, ca. 1 Tag), führt man diesen Schritt jedoch durch, erhöht sich die Sicherheit nochmals, da ein potentieller Angreifer so nicht einmal sagen kann, welche Datenblöcke überhaupt verwertbare, verschlüsselte Daten enthalten.
Wir löschen also die Festplatte gründlich.

dd if=/dev/urandom of=/dev/sda bs=512 seek=1 

Im Grunde das Gleiche, was wir bereits mit dem USB-Stick angestellt haben, wir überschreiben die gesamte Festplatte (hier /dev/sda), ausgenommen des MBR, mit Zufallsdaten.

ACHTUNG: Hat man neben der Linuxinstallation noch andere Systeme oder Daten auf der Platte, oder das Backup des Systems auf eine Partition dieser Platte geschrieben, so dürfen die hiervon betroffenen Partitionen natürlich nicht überschrieben werden!
Man könnte hier z.B. den Befehl für jede zu überschreibende Partition ausführen und dabei “/dev/sda” durch die entsprechende Laufwerksbezeichnung austauschen (In diesem Fall also “/dev/sda2″ und “/dev/sda3″), der Parameter “seek” entfällt dann.

Verschlüsseln der Partitionen

Das ist der leichte Part, das System will aber auch wieder entschlüsselt werden. ;)
Nun gut, eins nach dem anderen, verschlüsseln wir erstmal die entsprechenden Partitionen (root und swap).

dd if=/dev/sdb bs=512 count=4 skip=8 | cryptsetup \
luksFormat /dev/sda3 --key-file -
dd if=/dev/sdb bs=512 count=4 skip=8 | cryptsetup \
luksFormat /dev/sda2 --key-file -

Hier muss eventuell wieder cryptsetup installiert werden, auf der Installations-CD von Ubuntu ist dieses aber schon vorhanden.
Was wir hier machen ist Folgendes: Wir kopieren wieder bitweise mit dd, diesmal ist unser Quellgerät jedoch der USB-Stick, die Blockgröße beträgt wieder 512 Byte und wir kopieren insgesamt 4 Blöcke (count=4) ab dem 9. Block (skip=8 überspringt 8 Blöcke des Quellgeräts).
Unsere Schlüssellänge beträgt also 4 * 512Byte = 2kByte, das entspricht einem 2000-stelligem Passwort, eher noch etwas mehr, da nicht alle Bitkombinationen mit einem Klartextpasswort, das per Tastatur eingegeben wird, dargestellt werden können. Mit anderen Worten: “count=4″ ist mehr als ausreichend. Mit dem Parameter “skip” sagen wir “dd” wo es anfangen soll Blöcke zu lesen, “skip=8″ entspricht also 512 Byte * 8 = 4kB nach dem “Beginn” des USB Sticks. Die hier möglichen Angaben hängen unmittelbar von dem Beginn der 1. Partition ab. Mit anderen Worten: In meinem Fall (Zylindergröße=7688 Blöcke) ist alles von “skip=1″ (1.Block = MBR) bis “skip=7684″ (Zylindergröße – Schlüssellänge) denkbar.
Diesen 2kB großen Schlüssel übergeben wir nun “cryptsetup” um root und swap zu verschlüsseln.

Verschlüsselung mit System

Ah ja richtig, derzeit befindet sich ja gar kein System auf unserer Festplatte. Der richtige Zeitpunkt also, dieses zurückzuspielen.
Als erstes müssen wir natürlich die verschlüsselte root-Partition entschlüsseln.

dd if=/dev/sdb bs=512 count=4 skip=8 | cryptsetup \
luksOpen /dev/sda3 root --key-file -
dd if=/dev/sdb bs=512 count=4 skip=8 | cryptsetup \
luksOpen /dev/sda2 swap --key-file -

Hiermit öffnen wir die Partitionen und registrieren sie als “/dev/mapper/root” und “/dev/mapper/swap”. Als nächstes werden wir diese Partitionen und auch die (unverschlüsselte) boot-Partition mit einem Dateisystem formatieren.

mkfs.ext4 /dev/sda1
mkfs.ext4 /dev/mapper/root
mkswap /dev/mapper/swap

Man kann natürlich auch ein anderes Filesystem nehmen (ext3, reiserfs, …), je nach Belieben.

Nun mounten wir wieder alles und stellen das System wieder her. (sdc ist hier wieder unsere Backupplatte)

mount /dev/sdc1 /backup
mount /dev/mapper/root /mnt
mount /dev/sda1 /mnt/boot
tar -xvf /backup/system.tar -C /mnt/ ./

Wie schon in Teil 1, kommt nun der Part, an dem wir unserem System auf die Sprünge helfen, um mit der Verschlüsselung fertig zu werden. Wir wechseln wieder in eine chroot-Umgebung um das lokale System anzupassen.

umount /mnt/boot
cp /etc/resolv.conf /mnt/etc/
mount -o bind /dev /mnt/dev
mount -t proc none /mnt/proc
mount -t sysfs none /mnt/sys
chroot /mnt/
mount /boot

Ggf. noch ein “sudo su” um root user zu werden.
Zunächst installieren wir grub erneut hinter dem MBR. (Bei einer Multi-OS Istallation wie in Teil 1, auf der boot-Partition. Ob grub2 das mittlerweile mitmacht habe ich nicht getestet, da ich derzeit kein Windows installiert habe.)

grub-install /dev/sda

Dann installieren wir noch die benötigte Software nach.

apt-get update
apt-get install cryptsetup

In der /etc/crypttab tragen wir diesesmal nichts ein, das würde nicht funktionieren.
Aber die /etc/fstab muss nach wie vor angepasst werden. Wir öffnen diese in einem Editor und suchen die Einträge für root (/) und swap. Bei diesen ersetzen wir nun “UUID=kryptische ID” durch “/dev/mapper/root” bzw. “/dev/mapper/swap”.
Die /etc/initramfs-tools/modules erweitern wir wieder um die Module:

  • aes
  • dm-crypt
  • sha256

In der /etc/initramfs-tools/conf.d/resume ersetzen wir ebenfalls die UUID mit “/dev/mapper/swap”, um den Suspend-To-Disk nutzen zu können.

Mit einem “update-grub” könnten wir grub2 nun dazu veranlassen aus der fstab das neue Device für die root-Partition herauszufischen und ein “update-initramfs -k all -u” würde den Rest erledigen, damit wir nach Vorgehen aus Teil 1 fertig wären. Aaaaaaber…
…da unsere crypttab leer ist, würden unsere Partitionen nicht entschlüsselt. Eine root-Partition mit key-file in der crypttab würde aber zu Fehlern beim Bau des initramfs führen, also keine gute Idee.

Kommen wir nun also zum großen Finale

Der Ausweg aus unserer Misere heißt “initrd”. Das sind die Archive, die wir mit dem Befehl “update-initramfs” erzeugen und stellen das Pre-Root-Environment bereit, also die Umgebung, die Linux beim booten benötigt um alles für den Systemstart vorzubereiten.
Wir haben dieses bereits angepasst, als wir die Module und das Device für Suspend-To-Disk nachgetragen haben. Jetzt werden wir noch etwas tiefer in die Materie eintauchen. Glücklicherweise ist hier schon fast alles vorhanden was wir benötigen.

Das erste Problem, das wir lösen werden, ist die Namensgebung des USB Sticks. Je nachdem wie viele Sticks und Platten angeschlossen werden und in welcher Reihenfolge werden diese nämlich fortlaufend benannt. Wie soll eine automatisierte Lösung aber den Schlüssel finden, wenn wir ihr nicht sagen können wo sie ihn findet? Udev bietet hierfür eine gute Möglichkeit.

Nichts geht ohne Regeln

Bei eingestecktem USB Stick finden wir zunächst die Seriennummer des Geräts heraus, dafür auf der Konsole:

lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 045e:074f Microsoft Corp. 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 006: ID 0781:5567 SanDisk Corp. Cruszer Blade
Bus 001 Device 002: ID 13d3:5108 IMC Networks 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So wird in etwa die Ausgabe aussehen. Hier tauchen alle USB Geräte auf, haben wir unseren Stick erkannt, ist die hier fett markierte Ziffernfolge interessant, die ID des Herstellers und des Modells angeben. Nun rufen wir den Befehl nochmals wie folgt auf, um nähere Informationen zum Gerät zu erhalten.

lsusb -v -d 0781:5567
  ...
  iManufacturer           1 SanDisk
  iProduct                2 Cruzer Blade
  iSerial                 3 2005314591144A614074
  bNumConfigurations      1
  Configuration Descriptor:
  ...

Relativ weit oben in der Ausgabe sollte sich dieser Block finden, die hervorgehobene Zeile ist von näherem Interesse. Wir kopieren uns die Seriennummer und erstellen im Verzeichnis “/etc/udev/rules.d/” eine Datei namens “80-usbstick.rules” mit folgendem Inhalt:

KERNEL=="sd*", ATTRS{serial}=="Seriennummer", SYMLINK+="usbstick%n"

Das besagt: Immer wenn eine Platte mit “sd-irgendwas” registriert wird und deren Seriennummer der Angabe entspricht, nenne sie zusätzlich “/dev/usbstick”. (Die Partition auf dem Stick wird als /dev/usbstick1 registriert.)
Und so testen wir ob es funktioniert:

restart udev

Restarten des udev Systems. Anschließend ziehen wir den Stick ab und stecken ihn wieder ein.

ls /dev/usbstick

Erscheint die Ausgabe “/dev/usbstick”, hat alles geklappt, wenn etwas schief gelaufen ist, sollte eine Fehlermeldung erscheinen, dass die Datei nicht gefunden wurde.

Das Problem an der Geschichte ist nur, dass sich diese Regel nun auf dem System befindet, welches beim Start ja verschlüsselt ist. Wir müssen sie nun also irgendwie ins initramfs karren. Dazu erstellen wir im Verzeichnis “/etc/initramfs-tools/hooks/” eine Datei, der Name ist beliebig, der Inhalt sieht so aus:

#!/bin/sh
RULES="80-usbstick.rules"
for RULE in $RULES; do
   if   [ -e /etc/udev/rules.d/$RULE ]; then
      cp -p /etc/udev/rules.d/$RULE $DESTDIR/lib/udev/rules.d/
   elif [ -e /lib/udev/rules.d/$RULE ]; then
      cp -p /lib/udev/rules.d/$RULE $DESTDIR/lib/udev/rules.d/
   fi
done
chmod +x /etc/initramfs-tools/hooks/*

Der Befehl macht die Datei ausführbar.
In diesem Verzeichnis befinden sich Scripte, die beim Erstellen des initramfs ausgeführt werden und dieses damit beeinflussen können.
Unser Script sorgt dafür, dass alle udev-Regeln, welche in der Variablen RULES angegeben sind, mit in die Boot-Umgebung wandern. Die einzelnen Regeln werden hierbei mit einer Leerstelle getrennt hintereinander aufgezählt, hier haben wir aber nur eine angegeben, unsere USB-Stick Regel.

Es hört einfach nicht auf

Ein Problem beseitigt, weitere warten bereits. Das Schloss ist da, der Schlüssel auch, aber irgendwer muss ihn hineinstecken.

Auch dafür schreiben wir uns ein Script. Diesmal wandert das aber in das Verzeichnis “/etc/initramfs-tools/scripts/local-top/”. Der Name ist wieder frei wählbar, der Inhalt folgt nun.

#!/bin/sh

KEYDEVICE=/dev/usbstick
BLOCKSIZE=512
SKIPBLOCKS=8
READBLOCKS=4
CRYPTDEVICES="/dev/sda3:root /dev/sda2:swap"

PREREQ=""

prereqs()
{
  echo "$PREREQ"
}

unlockroot()
{
  echo "Looking for keydevice..."
  if [ -e $KEYDEVICE ]
  then
    echo "   Success"
    for ENTRY in $CRYPTDEVICES
    do
      DEVICE=`echo $ENTRY | sed 's/:[a-zA-Z0-9]*//'`
      MAPPING=`echo $ENTRY | sed 's/[/a-zA-Z0-9]*://'`
      echo "Unlocking $MAPPING partition..."
      dd if=$KEYDEVICE bs=$BLOCKSIZE skip=$SKIPBLOCKS \
       count=$READBLOCKS 2>/dev/null | cryptsetup luksOpen \
       $DEVICE $MAPPING --key-file -
      if [ $? -ne 0 ]
      then
        echo "   Failed"
        echo "Please reboot..."
        while [ true ]
        do
          sleep 1
        done
        exit 1
      fi
      echo "   Success"
    done
    echo "You can now remove the keydevice."
    echo "Returning to boot-process..."
    exit 0
  else
    echo "   Failed"
    echo "Please reboot..."
    while [ true ]
    do
      sleep 1
    done
    exit 1
  fi
}

case $1 in
  prereqs)
    prereqs
    exit 0
    ;;
  mountfail)
    unlockroot
    ;;
  *)
    . /scripts/functions
    add_mountroot_fail_hook
    exit 0
    ;;
esac

Im Verzeichnis “/etc/initramfs-tools/scripts/” landen Scripte, die nicht beim Bau des initramfs ausgeführt werden sollen, sondern mit in dieses aufgenommen werden und beim Systemstart laufen sollen. Die Unterverzeichnisse stehen für verschiedene Stadien des Systemstarts und bieten somit eine Möglichkeit grob festzulegen, an welcher Stelle des Starts das Script läuft. “local-top”-Scripte laufen unmittelbar vor dem Einbinden der root-Partition, also genau dann, wenn unser Script laufen soll, um root vorher aufzuschließen.
Wen es interessiert: Die man-page hierzu ist sehr informativ.

man initramfs-tools 8

Das Problem an der Geschichte ist, dass das Entschlüsseln stattfinden muss, nachdem der USB-Stick erkannt wurde, jedoch bevor versucht wird root einzubinden.
Der PREREQ-Mechanismus bietet eine Möglichkeit Scripte anzugeben, die unbedingt vor unserem Script laufen müssen, wie z.B. das Einbinden des USB-Sticks.
Doch auch hier liegen uns Steine im Weg: Beides wird von ein und demselben Script erledigt, also scheidet ein PREREQ auf dieses als Lösung schon einmal aus.
Die nächste Idee, welche am Ende auch funktionieren würde, werden wir nicht nutzen, da wir hierfür das entsprechende Originalscript anpassen müssten und unseren Code direkt dort hineinschreiben würden.
Machbar, aber keine schöne Lösung, zumal man damit rechnen müsste, dass ein Update der initramfs-tools auf eine neue Version unsere Änderungen möglicherweise wieder überschreibt.

Es gibt aber eine viel bessere Möglichkeit und diese haben wir im Script genutzt:
Mit “. /scripts/functions” laden wir den Inhalt der functions-Datei in unser Script, welche vordefinierte Routinen anbietet. Ein Aufruf von “add_mountroot_fail_hook” registriert unser Script nun als Fallbacklösung, für den Fall, dass die root-Partition nicht gefunden wird.
Dies wird zwangsläufig der Fall sein und damit unser Script erneut mit dem Parameter “mountfail” aufrufen. An dieser Stelle wird nun der eigentliche Code (Die Funktion “unlockroot”) ausgeführt und schließt alle Partitionen auf, die in der Variablen CRYPTDEVICES angegeben sind. Beendet sich unser Script mit dem Fehlerstatus 0, so geht der aufrufende Prozess davon aus, dass root nun vorhanden ist und versucht erneut diese Partition zu finden. Das sollte nun gelingen.

Einige Erklärungen zur “Konfiguration” des Scripts:
Wie erwähnt, definiert man die zu entschlüsselnden Partitionen in der Variablen CRYPTDEVICES. Wieder in Form einer durch Leerstellen getrennten Aufzählung. Jeder Eintrag ist dabei in der Form Zu-entschlüsselnde-Partition:Name-des-Mappings, also z.B. /dev/sda3:root um “/dev/sda3″ als “/dev/mapper/root” zu entschlüsseln.
Jede dieser Partitionen wird mit dem Schlüssel entsperrt, der sich auf dem Gerät KEYDEVICE befindet, wurde bei der udev-Regel der Name nicht geändert, so kann der Wert hier so belassen werden.
Die Parameter BLOCKSIZE , SKIPBLOCKS und READBLOCKS geben hierbei die Position und Länge des Schlüssels an. Auch diese Werte sind bereits auf die vorher beim “dd” benutzen Werte eingestellt. Hat man diese verändert, so müssen sie auch hier entsprechend gesetzt werden:
BLOCKSIZE=Wert von “bs”
SKIPBLOCKS=Wert von “skip”
READBLOCKS=Wert von “count”
Nun wieder das Script ausführbar machen:

chmod +x /etc/initramfs-tools/scripts/local-top/*

Die Mühen haben sich gelohnt

Wir sind fast am Ziel. :)
Wir passen nun noch die Datei /etc/default/grub (für grub2… /boot/grub/menu.lst, die auskommentierten Stellen, wie in Teil 1 beschrieben, für grub-legacy) an und ändern die Zeile

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

in

GRUB_CMDLINE_LINUX_DEFAULT="rootdelay=1 quiet splash"

Wir setzen damit die Zeit, die auf die root-Partition gewartet wird auf 1 Sekunde. Dies tun wir, da erst nach dieser Wartezeit die Fallbackscripte laufen und sich der Bootvorgang so unnötig in die Länge zieht.

Noch eben die Starteinträge von grub und das initramfs neu bauen:

update-grub
update-initramfs -k all -c

Have fun. :)

reboot

4 Kommentare »

  1. 1
    Heiko schrieb am 24. September 2011 um 11:08


    EDIT:
    Unter “Verschlüsselung mit System”, nachdem wir die chroot-Umgebung betreten haben, hatte ich noch vergessen zu erwähnen, dass grub wieder im MBR installiert werden muss. Dies wurde nun ergänzt. Shame on me! -.-

    TIPPS:
    An dieser Stelle werde ich noch etwas erwähnen, was ich im Artikel ebenfalls vergessen habe, für die grundlegende Installation ist dies aber nicht notwendig:
    Verliert man nämlich den USB Stick oder wird der Schlüssel dort versehentlich überschrieben, hat man nun keine Möglichkeit mehr, an seine Daten heranzukommen.
    Um hier Abhilfe zu schaffen, kann man mit folgendem Kommando den Schlüssel in einer Datei sichern. Die Datei sollte nun an einem sicheren Ort auf ihren Notfalleinsatz warten.

    dd if=USB-Stick of=/Pfad/zu/Datei bs=512 skip=8 count=4
    

    Die Werte sind wieder entsprechend anzupassen. Unter einem Livelinux kann root nun mit dem gleichen Befehl entschlüsselt werden, mit dem wir das bei der Installation gemacht haben. Nur für “if” muss nun “/Pfad/zu/Datei” angegeben werden, statt des USB-Sticks, “skip” und “count” entfallen ganz.
    Es kann auch ein neuer USB-Stick wie im Artikel beschrieben vorbereitet werden und anschließend der Schlüssel platziert werden:

    dd if=/Pfad/zu/Datei of=neuer-Stick bs=512 seek=8
    

    Man beachte das “seek” anstelle von “skip”, da wir hier nun die 8 Blöcke nicht beim Quell- sondern Zielgerät überspringen.
    Auch muss nun die udev-Regel angepasst werden, indem die neue Seriennummer eingetragen wird. Anschließend ein

    update-initramfs -k all -c
    

    und weiter gehts. :)

  2. 2
    Heiko schrieb am 3. November 2011 um 02:07


    In einer E-Mail, die mich zu diesem Artikel erreichte, ging es darum, dass man statt der Seriennummer des USB Sticks die Hersteller- und Modellnummer verwenden könnte. So könnte man dann den Key auf einen neuen Stick transferieren, ohne die UDEV-Regel anpassen zu müssen.
    Natürlich ist dies problemlos möglich, jedoch muss jeder selbst wissen, welche Variante er bevorzugen möchte.

    Wir haben unseren Schlüssel inmitten eines Zufallsdatenwulstes auf dem Stick versteckt, selbst wenn wir jemandem Zugang zu diesem Stick gewähren, der weiß, dass sich der Key auf diesem Stick befindet, dürfte es einen ziemlichen Aufwand darstellen herauszufinden, welche Stelle genau als Schlüssel herhält.
    Mit vorgeschlagener Lösung müsste derjenige jedoch nur einen baugleichen USB Stick besitzen und den kompletten Bereich auf diesen übertragen, unser System würde den Stick als validen Schlüssel erkennen und sich dann die richtige Stelle selbst suchen.

    Außerdem könnte es Probleme verursachen, wenn bei Systemstart zwei baugleiche Sticks (einer davon der Schlüssel) am System hängen, zugegeben vllt eher ein unwahrscheinliches Szenario aber so oft sollte man seinen Systemschlüssel auch nicht verlieren, man sollte den zusätzlichen Aufwand also nicht scheuen.

  3. 3
    Heiko schrieb am 25. November 2011 um 22:30


    Bezugnehmend auf die Fragen von Cristian (Gästebuch), hier ein kurzes update.

    Selbstverständlich ist es möglich weitere verschlüsselte Platten ins System einzubinden. Auch diese wird dann mit dem Befehl

    dd if=/dev/sdb bs=512 count=4 skip=8 | cryptsetup \
    luksOpen Zielplatte data --key-file -
    

    verschlüsselt, wie wir es schon mit den anderen Partitionen gemacht haben.
    Im Anschluss muss im Entschlüsselungsscript, wie oben beschrieben, die Zeile

    CRYPTDEVICES="/dev/sda3:root /dev/sda2:swap"
    

    um die neue Platte erweitert werden, beispielsweise so:

    CRYPTDEVICES="/dev/sda3:root /dev/sda2:swap /dev/sdb1:data"
    

    Nun wird die zweite Platte, welche als /dev/sdb(1) erkannt wird, als “/dev/mapper/data” entschlüsselt, welches nun an beliebige Stelle gemountet werden kann.
    Letztendlich muss nur noch ein

    update-initramfs -k all -c
    

    ausgeführt werden, um die neue Version des Entschlüsselungsscriptes ins initramfs zu packen.

    Auch den Schlüssel auf mehreren Sticks zu halten ist möglich, was bereits Thema des vorherigen Posts war. Man passt hierzu die udev-Regel an so, dass sie auf alle Keydevices matched. Handelt es sich immer um baugleiche USB Sticks bietet sich beispielsweise an, statt der Seriennummer Herstellerid und Modellnummer zu prüfen. Ist dies nicht der Fall, muss die Regel eventuell noch weiter gelockert werden, damit sie zB auf alle USB Sticks matched. Tutorials zu udev-Regeln finden sich im Netz zuhauf. Anschließend wieder das initramfs neu bauen.

    Die letzte Frage ist ziemlich interessant, wenn ich auch keine genaue Antwort darauf liefern kann.
    Grundsätzlich sollte es jedoch auch möglich sein zB einen NFS-Mount im initramfs zu realisieren, welcher den Schlüssel bereitstellt. Dazu müsste man nochmal weiter recherchieren.
    Es entzieht sich mir jedoch etwas das Verständnis was du damit genau realisieren möchtest. Das entschlüsseln findet ja beim Systemstart statt, startest du den Server denn per Wake-On-Lan?
    Die Verschlüsselung schützt deine Daten ja nur solange der PC aus ist, ist er an, ist das System ja entschlüsselt und somit grundsätzlich der physikalische Zugriff bzw. Zugriff über ein Netzwerk möglich. Hier würden dann ja eher andere Schutzmechanismen greifen, beispielsweise eine Firewall oder eine sichere Authentifizierung, Beschränkung von Netzwerkfilesystemen auf fest vorgegebene IPs etc.

  4. 4
    LycaKnight schrieb am 21. May 2013 um 19:38


    Hallo,
    Erstmal vielen Dank für die tolle Anleitung, nur leider funktioniert sie bei mir wie die achtausend und eins Anleitungen vorher auch nicht :(
    Ich habe alles nach Anleitung durchgeführt es kam auch bei keinem Schritt zu einer Fehlermeldung oder sonstiges alles perfekt funktioniert, bis zum neustart. Hier bekomme ich nur einen schwarzen Bildschirm sonst nichts, keine Fehlermeldung und nichts passiert. Wissen Sie evtl, woran das liegen kann?
    Ich benutze LinuxMint 14 und grub1.
    Würde mich über eine Antwort freuen, da ich bis jetzt schon min. 10 verschiedene Tutorials durchgewälzt habe, aber bisher hat keine funktioniert.
    G

Kommentar schreiben:

XHTML: Erlaubte Tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Blogverzeichnis - Blog Verzeichnis bloggerei.de    © 2011 – Powered by WordPress – Theme Papyrus 1.0 designed by Leonardo da Finchi