dm-crypt / LUKS: Daten unter Linux sicher verschlüsseln

1. Sicheres BackupLinux-LUKS

Brand, Diebstahl, Hardwaredefekte, unangekündigte Hausdurchsuchungen oder der Transport sensibler Informationen – es gibt gute Gründe, wichtige Daten auf einen Datenträger (bspw. USB-Stick) zu kopieren und diesen an einem geeigneten Ort zu verwahren. Das Kopieren der Daten ist allerdings nur die halbe Miete – sollen die auf dem Datenträger abgelegten Daten zusätzlich vor neugierigen Blicken geschützt werden, empfiehlt sich eine Verschlüsselung.

Im vorliegenden Beitrag zeige ich euch, wie sich mit Linux-Boardmitteln bzw. mit dm-crypt (LUKS) ein USB-Stick vollständig verschlüsseln lässt und wie ihr einen verschlüsselten Container fester Größe auf einem Datenträger anlegt. Wenn ihr hingegen nach einer systemübergreifenden Lösung sucht, dann solltet ihr einen Blick in den Beitrag »VeraCrypt: Daten auf USB-Stick sicher verschlüsseln« werfen.

2. dm-crypt / LUKS

Seit der Linux-Kernelversion 2.6 ist das Kryptographie-Modul dm-crypt bzw. die Erweiterung Linux Unified Key Setup (LUKS) ein fester Bestandteil von Linux-Systemen – es zählt heute zum Standardverfahren zur Festplattenverschlüsselung. Die meisten Linux-Distributionen bieten mittlerweile eine Verschlüsselung der einzelnen Festplatten-Partitionen bereits als Teil der Systeminstallation an. Insbesondere bei mobilen Geräten wie Notebooks ist eine Festplattenverschlüsselung empfehlenswert, um die Daten gegen (Offline-)Diebstahl zu schützen.

Mit dm-crypt / LUKS könnt ihr ebenfalls (externe) Datenträger wie Festplatten oder USB-Sticks verschlüsseln oder einen Container fester Größe anlegen, in den ihr sensible Daten passwortgeschützt ablegen könnt.

Das Device-Mapper-Target dm-crypt ist Teil des Linux-Kernels und steht somit automatisch zur Verfügung. Für unseren Einsatzzweck greifen wir allerdings auf die Erweiterung LUKS zurück, die unter anderem die folgenden zwei Funktionen ergänzt:

  • Header: Crypto-Informationen, wie die Art der Verschlüsselung oder die einzelnen Key-Slots, werden im LUKS-Header abgelegt.
  • Schlüssel und Key-Slots: Vergabe von bis zu acht Schlüsseln, die in sogenannten Key-Slots gespeichert werden. Ein Schlüssel ist dabei entweder eine Passphrase (mit bis zu 512 Zeichen) oder ein Keyfile (maximal 8192 kiB). Die Schlüssel lassen sich ändern / löschen, ohne danach die verschlüsselten Daten umschreiben zu müssen. Beispiele für das Schlüsselmanagement könnt ihr im Beitrag »10 Linux cryptsetup Examples for LUKS Key Management« nachlesen.

Hinweis

Der LUKS-Header ist ein Informationsblock, der im Klartext geschrieben wird. Er beinhaltet unter anderem Informationen über den verwendeten Verschlüsselungs- und Hash-Algorithmus. Das Schutzziel der glaubhaften Abstreitbarkeit rückt damit in weite Ferne – was je nach Anwendungszweck allerdings vertretbar ist. Weitere Informationen zu den Unterschieden von dm-crypt und LUKS findet ihr hier.

Je nach Linux-Distribution müsst ihr noch weitere Pakete nachinstallieren, damit ihr die Erweiterung LUKS nutzen könnt. Auf Debian GNU/Linux (und Ablegern) müsst ihr folgendes Paket installieren:

apt-get install cryptsetup

RHEL / CentOS:

yum install cryptsetup-luks

usw.

3. USB-Stick verschlüsseln

3.1 Vorbereitung USB-Stick

Je nach Verwendungszweck bzw. benötigte Speicherkapazität solltet ihr einen ausreichend großen USB-Stick wählen. Im Grunde eignet sich jeder handelsübliche USB-Stick, um eine Verschlüsslung mit dm-crypt / LUKS vorzunehmen.

Im Laufe des Vorgangs werden alle Daten gelöscht, die sich auf dem USB-Stick befinden. Solltet ihr also Daten benötigen, die ihr auf dem USB-Stick zwischengelagert habt, dann wäre jetzt ein guter Zeitpunkt, die Daten zu sichern.

Hinweis

Bevor ihr den USB-Stick mit dm-crypt / LUKS verschlüsselt solltet ihr alle weiteren USB-Sticks oder Wechseldatenträger (bspw. externe Festplatte) entfernen, damit es zu keiner Verwechslung kommt.

3.2 USB-Stick mit cryptsetup verschlüsseln

Steckt den USB-Stick in einen freien USB-Port und prüft zunächst, welche Kennung dem Datenträger zugewiesen wurde:

lsblk -Sfo +size
Ausgabe:
NAME HCTL    TYPE VENDOR  MODEL   REV  TRAN NAME FSTYPE LABEL UUID MOUNTPOINT SIZE
sda  0:0:0:0 disk ATA     LITEONI 205  sata sda                               238,5G
sdb  3:0:0:0 disk SanDisk Ultra   1.00 usb  sdb                               115,7G

Im Beispiel wurde dem SanDisk USB-Stick (128 GB) die Laufwerkskennung sdb zugeteilt. Als nächstes arbeiten wir mit dem Tool cryptsetup. Hierbei wird der USB-Stick formatiert und mit einer von euch festgelegten Passphrase geschützt. Wählt bitte eine »sichere« Passphrase nach dem Diceware-Verfahren – 6 Wörter sind das Minimum:

cryptsetup --verify-passphrase -v luksFormat /dev/sdb
Ausgabe:
WARNING!
========
Hiermit werden die Daten auf »/dev/sdb« unwiderruflich überschrieben.

Are you sure? (Type uppercase yes): YES
Passphrase eingeben: EureDicewarePassphrase
Passphrase bestätigen: EureDicewarePassphrase
Befehl erfolgreich.

Hinweis

Mittels diverser Parametern (-cipher, –key-size, –hash etc.) lassen sich die gewünschten Crypto-Algorithmen selbst bestimmen. In der aktuellen Version von cryptsetup (1.7.0) werden folgende Einstellungen genutzt:
  • -cipher: aes-xts-plain64
  • –key-size: 256
  • –hash: sha256

Demnach kommt zur Verschlüsselung der AES-Algorithmus im XTS-Betriebsmodus mit einer AES-Schlüssellänge von 128 Bit zum Einsatz. Der Parameter –hash bestimmt letztendlich den Passwort-Hash-Algorithmus, den PBKDF2 verwendet, um von eurer Passphrase einen Schlüssel abzuleiten. Als Standard wird aktuell SHA256 verwendet. Solltet ihr keine speziellen Anforderungen haben, dann belasst es einfach bei den Standardvorgaben.

Damit ihr nun Daten auf dem USB-Stick ablegen könnt, muss der Stick zunächst virtuell gemappt (/dev/mapper/) werden:

cryptsetup luksOpen /dev/sdb usb_stick_luks
Ausgabe: 
Geben Sie die Passphrase für »/dev/sdb« ein: EureDicewarePassphrase

Prüfen wir mal kurz ob das Mapping angelegt wurde:

ls -l /dev/mapper/usb_stick_luks
Ausgabe:
lrwxrwxrwx 1 root root 1 Jan 0 12:00 /dev/mapper/usb_stick_luks -> ../dm-1

Zum Abschluss erstellen / formatieren wir den USB-Stick noch mit dem ext4-Dateisystem:

mkfs.ext4 /dev/mapper/usb_stick_luks
Ausgabe:
mke2fs 1.43.4 (31-Jan-2017)
Ein Dateisystems mit 491520 (4k) Blöcken und 123120 Inodes wird erzeugt.
[...]
erledigt

Nach diesem Vorgang ist der USB-Stick nun (fast) einsatzbereit. Da cryptsetup root-Rechte zur Einrichtung benötigt hat aktuell nur der User root Zugriff auf den USB-Stick. Das solltet ihr anpassen:

chown -R nutzer:nutzer /dev/mapper/usb_stick_luks

Bevor wir den USB-Stick nun verwenden, heben wir das Mapping auf und entfernen den USB-Stick aus dem Einschub:

cryptsetup luksClose /dev/mapper/usb_stick_luks

3.3 USB-Stick ein- bzw. ausbinden | verwenden

Auf jedem aktuellen Linux, an den ihr den USB-Stick anschließt, erscheint automatisch ein Dialog zum »Entsperren des Datenträgers«:

Entsperren

Sobald ihr die korrekte Passphrase eintippt, wird das Laufwerk automatisch unter »/media/[user]/[GeräteUUID]« gemountet. Euer Dateimanager sollte das betreffende Verzeichnis einbinden bzw. darstellen, damit ihr anschließend Daten auf den USB-Stick kopieren könnt.

Technisch korrektes Aushängen eines LUKS-verschlüsselten USB-Sticks erfolgt über folgenden Befehl:

cryptsetup luksClose /dev/mapper/luks-GeräteUUID

Nach meinem Verständnis genügt es allerdings den USB-Stick einfach wie gewohnt über Rechtsklick »Aushängen« zu entfernen. Dadurch wird der Mount und auch gleichzeitig das Mapping wieder entfernt.

4. LUKS-Container auf Datenträger anlegen

Einen USB-Stick mit dm-crypt / LUKS-Verschlüsselung haben wir nun erfolgreich erstellt. Ihr könnt für sensible Dateien aber auch einen LUKS-Container (bspw. externe Festplatte) anlegen.

4.1 Container mit dd anlegen

Zunächst wird mit dem Programm dd eine Container-Datei bzw. Image-Datei mit einer Größe von 4GB (count=4096) erstellt – diese wird dann im Anschluss mit LUKS verschlüsselt:

dd if=/dev/zero bs=1M count=4096 of=/pfad/container.luks
Ausgabe:
4096+0 Datensätze ein
4096+0 Datensätze aus
4294967296 Bytes (4,3 GB, 4,0 GiB) kopiert, 29,0623 s, 148 MB/s

Hinweis

dd kann bit-genau Festplatten, Partitionen oder Dateien kopieren. Mit dem Parameter »if« (Input-File) legen wir ein Gerät, Partition oder eine Datei fest, die wir als Quelle nutzen möchten. Als Ursprungsquelle wählen wir hier die virtuelle Gerätedatei /dev/zero, die unseren Container mit Null-Bytes (Nullzeichen) auffüllt. Als Ursprungsquelle könnten wir auch die virtuelle Gerätedatei /dev/random oder /dev/urandom wählen – dann wird unser Container mit Zufallszahlen befüllt, was die Güte der Verschlüsselung erhöhen kann. Allerdings dauert die Image-Erstellung mit den beiden letztgenannten Gerätedateien erheblich länger.

4.2 Container mit cryptsetup verschlüsseln

Nach der Erstellung des Containers erfolgt die LUKS-Formatierung inklusive Vergabe einer Passphrase. Wählt bitte eine »sichere« Passphrase nach dem Diceware-Verfahren – 6 Wörter sind das Minimum:

cryptsetup --verify-passphrase -v luksFormat /pfad/container.luks
Ausgabe:
WARNING!
========
Hiermit werden die Daten auf »/pfad/container.luks« unwiderruflich überschrieben.

Are you sure? (Type uppercase yes): YES
Passphrase eingeben: EureDicewarePassphrase
Passphrase bestätigen: EureDicewarePassphrase
Befehl erfolgreich.

Damit ihr nun Daten im Container ablegen könnt, muss dieser zunächst virtuell gemappt (/dev/mapper/) werden:

cryptsetup luksOpen /pfad/container.luks container_luks
Ausgabe: 
Geben Sie die Passphrase für »/pfad/container.luks« ein: EureDicewarePassphrase

Prüfen wir mal kurz ob das Mapping angelegt wurde:

ls -l /dev/mapper/container_luks
Ausgabe:
lrwxrwxrwx 1 root root 1 Jan 0 12:00 /dev/mapper/container_luks -> ../dm-0

Zum Abschluss erstellen / formatieren wir den Container noch mit dem ext4-Dateisystem:

mkfs.ext4 /dev/mapper/container_luks
Ausgabe:
mke2fs 1.43.4 (31-Jan-2017)
Ein Dateisystems mit 1048064 (4k) Blöcken und 262144 Inodes wird erzeugt.
[...]
erledigt

Nach diesem Vorgang ist der USB-Stick nun (fast) einsatzbereit. Da cryptsetup root-Rechte zur Einrichtung benötigt hat aktuell nur der User root Zugriff auf den USB-Stick. Das solltet ihr anpassen:

chown -R nutzer:nutzer /dev/mapper/container_luks

4.3 Container ein- bzw. ausbinden | verwenden

Euer Container ist bereits dem Device-Mapper bekannt und ihr könnt direkt einen Mountpoint (ein beliebiger Ordner im Dateisystem) festlegen, unter dem euer Container eingebunden wird:

mount /dev/mapper/container_luks /pfad/zum/mountpoint
chown -R nutzer:nutzer /pfad/zum/mountpoint

Über das Verzeichnis »/pfad/zum/mountpoint« könnt ihr nun auf euren Container zugreifen und diesen mit Daten befüllen. Sobald ihr eure Daten kopiert habt, müsst ihr den Container wieder aushängen:

umount /pfad/zum/mountpoint
cryptsetup luksClose container_luks

Analog dazu nochmal die Einbindung, damit ihr den Container verwenden könnt:

cryptsetup luksOpen /pfad/container.luks container_luks
mount /dev/mapper/container_luks /pfad/zum/mountpoint

Der Kuketz-Blog ist spendenfinanziert!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

4.4 LUKS-Header auslesen

Mit folgendem Befehl könnt ihr alle Crypto- und Schlüssel-Informationen aus dem LUKS-Header eures Containers auslesen:

cryptsetup luksDump /pfad/container.luks
Ausgabe:
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
[...]
Key Slot 0: ENABLED
   Iterations:          1917601
   Salt:                ec 0e 5d 4a b2 73 46 d6 48 ed 34 79 fb af ab 93 
                        8b 17 ee 74 58 ff 7e 5b 6a 0a bc fa 48 24 9b 93 
   Key material offset: 8
   AF stripes:          4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

5. Fazit

Für mich persönlich ist dm-crypt / LUKS die erste Wahl zur Verschlüsselung von sensiblen Daten, die ich transportieren möchte. Allerdings solltet ihr immer beachten, an welchem Linux-Rechner ihr den USB-Stick bzw. den Container einbindet. Schadsoftware macht auch vor Linux keinen Halt. Das bedeutet: Unter Umständen werden eure sensiblen Daten verändert oder das Passwort ausgespäht.

Bedenkt daher immer: Die Verschlüsselung schützt euch nur zu einem begrenzten Maß bzw. vor gewissen Angriffsszenarien. Ver- und entschlüsselt eure Daten daher nach Möglichkeit auch immer auf einem »vertrauenswürdigen« System.

Bildquellen:

Padlock: Pixel Buddha from www.flaticon.com is licensed by CC 3.0 BY

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

16 Ergänzungen zu “dm-crypt / LUKS: Daten unter Linux sicher verschlüsseln”

  1. Comment Avatar Roland Hummel sagt:

    Hi Mike,

    danke für den gut nachvollziehbaren Artikel. Könntest Du in diesem Zusammenhang vielleicht noch Deine Sicht auf das Konzept „Plausible Abstreitbarkeit“ darlegen und ggf. hinzufügen, wie man es mit dm-crypt / LUKS umsetzt?

    • Comment Avatar Dimitri R. sagt:

      @Roland Hummel
      Ich möchte dir diese Frage mal beantworten. Wenn du mit LUKS einen Container erstellst oder einen ganzen Datenträger (und das beinhaltet auch eine Partition) verwendest, dann wird immer ein Header geschrieben. Und anhand diesem Header kann man dann feststellen, dass auf dem Datenträger etwas mit LUKS drauf ist. Die restlichen Daten sehen aber randomisiert aus, als ob man /dev/urandom auf das Laufwerk geschrieben hat. Ob es z.B. Sinn macht, die Header-Information nicht an den Anfang des Laufwerks zu schreiben sondern einen Offset zu verwenden, muss jeder selbst wissen.

      TrueCrypt bzw. Veracrypt haben das Problem nicht. Da sehen die Daten auf dem Laufwerk tatsächlich randomisiert aus.

      Wenn man jetzt wieder zur „plausible deniability“ zurückkommt, wäre natürlich die frage, ob du tatsächlich sagen kannst, dass du einen USB-Stick oder Festplatte hast, auf der ein Bereich mit zufälligen Daten beschrieben ist.

      Aus diesem Grund hat TrueCrypt bzw. VeraCrypt die Möglichkeit einen hidden Container in einem Container zu verstecken. Du hast dann zwei Schlüssel. Mit einem Schlüssel kannst du z.B. auf dem USB-Stick ein Volume mounten, das im Worst Case alle sehen können. Und mit einem zweiten Schlüssel kannst du dann auf dem gleichen Container die geheimen Daten lesen. Wenn man allerdings das Volume mit den weniger geheimen Daten mountet und dann dort reinschreibt, überschreibt man die geheimen Daten.

      LG aus Karlsruhe nach Karlsruhe ;)

      • Comment Avatar Mike Kuketz sagt:

        Danke für die Erklärung Dimitri.

      • Comment Avatar Roland Hummel sagt:

        Hallo Dimitri R.,

        danke für Deine Antwort, allerdings beantwortet diese nicht wirklich meine Frage. Mir ist schon klar, was „plausible Abstreitbarkeit“ bedeutet. Mich hatte Mikes Einschätzung als Sicherheitsforscher interessiert, nach welchen Kriterien man beim Thema „Datenträgerverschlüsselung“ die Frage nach der Sinnhaftigekit plausibler Abstreitbarkeit klären sollte (nicht nur auf Clients, sondern auch auf Servern).

        Auch sagt der Beitrag nur „Das Schutzziel der glaubhaften Abstreitbarkeit rückt damit in weite Ferne“ – heißt das, dass es völlig unmöglich ist?
        Mich würden Perspektiven interessieren, wann das (ja schon als solches bezeichnete) „Schutzziel“ entsprechend Mikes Aussage „was je nach Anwendungszweck allerdings vertretbar ist“ unberücksichtigt bleiben kann und, falls es nicht unberücksichtigt bleiben kann und dm-crypt verwenden werden muss/will, wie es mit dm-crypt umzusetzen wäre (falls es möglich ist).

    • Comment Avatar Mike Kuketz sagt:

      Steht bereits im Beitrag in einer der Info-Boxen:

      Der LUKS-Header ist ein Informationsblock, der im Klartext geschrieben wird. Er beinhaltet unter anderem Informationen über den verwendeten Verschlüsselungs- und Hash-Algorithmus. Das Schutzziel der glaubhaften Abstreitbarkeit rückt damit in weite Ferne – was je nach Anwendungszweck allerdings vertretbar ist. Weitere Informationen zu den Unterschieden von dm-crypt und LUKS findet ihr hier.

      • Comment Avatar Roland Hummel sagt:

        Danke, aber wie bereits an Dimitri R. geschrieben:

        Für mich klärt die Infobox meine Frage nicht wirklich. Wenn es heißt „Das Schutzziel der glaubhaften Abstreitbarkeit rückt damit in weite Ferne“: Bedeutet dies, dass es völlig unmöglich ist?

        Mich würden Perspektiven interessieren, wann das (ja schon als solches bezeichnete) „Schutzziel“ entsprechend Deiner Aussage „was je nach Anwendungszweck allerdings vertretbar ist“ unberücksichtigt bleiben kann und, falls es nach entsprechender Evaluationy nicht unberücksichtigt bleiben kann und dm-crypt verwenden werden muss/will, wie es mit dm-crypt umzusetzen wäre (falls es möglich ist).

        • Comment Avatar Mike Kuketz sagt:

          Mit LUKS (allein) ist das Schutzziel nicht erreichbar. Mit VeraCrypt bswp. dagegen schon.

          Das Schutzziel an sich mag bswp. für Journalisten interessant sein. Je nach persönlichem Risikoprofil kommt dm-crypt/LUKS daher möglicherweise nicht in Frage.

  2. Comment Avatar Anonymous sagt:

    Wie an anderer Stelle vorgeschlagen, poste ich das hier als Kommentar:

    Für Anfänger bzw. Kommandozeilenverweigerer könnte zuluCrypt als Alternative mit grafischer Oberfläche interessant sein.

  3. Comment Avatar Klaus sagt:

    Ich benütze externe Datenträger (HDD & USB) mit LUKS unter Xubuntu seit etwa 6 Monaten.
    Zur Einrichtung habe ich „Disks“ verwendet, ein Ubuntu-GUI-Tool, das in Xubuntu standardmäßig installiert zu sein scheint (nutze Xubuntu seit 16.04 und jede höhere Version hatte es bisher auch). Disks aus 16.04 hatte bei mir Probleme externe USB-Datenträger zu erkennen. Erkennt aber automatisch dieselben USB-Datenträger, die ich unter 17.04 und 17.10 mit LUKS verschlüsselt habe.
    Habe die Entscheidung zur Verschlüsselung lange vor mir hergeschoben. Was wenn ich nicht mehr an meine Daten komme? PC erkennt Platte/Stick nicht, etc…
    Habe erst nur meine Arbeitslaufwerk verschlüsselt und meine Backups weiterhin auf unverschlüsselten Platten angelegt. Man weiß ja nie.
    Die Arbeitsplatte wurde aber immer von all meinen Xubuntu-Systemen erkannt. Meine Besorgnis erwies sich als unbegründet. (Kontrollverlust und so)
    Habe dann auch vor ein paar Monaten die externen Backup-Platten eine nach der anderen verschlüsselt. Macht ja sonst keinen Sinn.
    Läuft prima. Kann es empfehlen.
    Wer seine verschlüsselten Daten nicht auch noch auf anderen Betriebssystemen als Linux benötigt, für den ist LUKS eine prima Lösung, denke ich.

    @Mike
    Danke für die ausführliche Anleitung, wie man LUKS im Terminal einrichtet und bedient.
    War für mich bisher immer ein Punkt der Irritation, dass ich von einem GUI-Programm abhängig war.
    Danke!

  4. Comment Avatar merti sagt:

    Was ich immer noch suche ist eine universale Lösung die mobil ist und keine Adminrechte benötigt. Spätestens wenn man an einen Windows PC als nicht Admin kommt scheitern dir meisten Lösungen.
    Wären Hardware verschlüsselte USB Sticks nicht Steuer würde ich einen solchen einsetzen.

    • Comment Avatar Klaus sagt:

      Vielleicht verstehe ich dein Problembeschreibung falsch, aber ich sehe das Problem nicht.
      Ist schon wieder eine Weile her, dass ich mit DISKS (‚buntus‘) ein LUKS-Laufwerk angelegt habe, aber ich kann mich nicht erinnern, dass ich dafür Admin-Rechte benötigt hätte. Muss die Software erst installiert werden, ist es doch sinnvoll, dass man Admin-Rechte auf dem Rechner haben muss.
      Beim Gebrauch stellt sich das Problem mit Admin-Rechten nicht.
      LUKS-Laufwerk (Stick, Platte) anflanschen.
      Passphrase im aufpoppenden Dialog eingeben.
      Damit arbeiten.

  5. Comment Avatar Connect sagt:

    Hallo Mike, super Anleitung, vielen Dank. Ich habe allerdings ein Problem mit den Zugriffsrechten. Ich habe den Container mit Chown genau nach deiner Anleitung an den Benutzer übertragen. Wenn ich den Container allerdings mounte, habe ich nur Lesezugriff. Woran kann das liegen, bzw. welche Rechte muss ich noch zusätzlich setzen? Viele Grüße

  6. Comment Avatar fossonly sagt:

    Hallo

    Habe einen kleinen Fehler im Artikel entdeckt. Und zwar geht es um die Standardeinstellung des Cryptsetup, wo laut Artikel eine Schlüssellänge von 256 Bit, auch einer Schlüssellänge von AES entsprechen würden. Dem ist im Falle des Cryptsetup nicht so, zumal im XTS-Modus zwei Schlüssel zum Einsatz kommen. Demnach werden bei einer Schlüssellänge von 256 Bit, sowohl 128 Bit für AES als auch 128 Bit für den XTS-Key verwendet. Will man somit bspw. AES mit 256 Bit Schlüssellänge haben, muss die via Parameter angegebene Schlüssellänge 512 Bit betragen.

    Das lässt sich hiermit auch schnell überprüfen:

    dmsetup table –show-keys

    Darüber kann man sich alle aktuell genutzten Masterkeys für jedes Volume anzeigen lassen. Bei einer Schlüssellänge von 256 Bit, werden die in base64 kodierten Masterkeys 64 Bytes lang sein, bei 512 Bit haben diese eine Länge von 128 Bytes.

  7. Comment Avatar Stephan sagt:

    Hallo Mike,

    ich verstehe nicht, warum alle die passwortbasierten Verfahren auf dem Produktivsystem nutzen. Ich verwende ein Skript mit Verschlüsselung durch gpg auf dem Windowsclient, das die verschlüsselten Dateien auf einer unverschlüsselten Partition lagert. (Inkrementell, nur wenn sich die md5-Summe einer Datei geändert hat).

    Zum Übertragen auf die Backupplatte wird ein Live-Linux mit rsync Skript verwendet – so dass unsere Mitarbeiterin nur zum Kopieren die Platte einstecken muss und den PC einschalten.

    Hat folgende Vorteile:
    * Backupplatte hängt nie am Produktivsystem.
    * Keine Passwörter.
    * Änderungsverfolgung.
    * Trojaner zerschießt Dateien auf Windows Client –> Datei wird neu abgelegt, da neue md5 Summe.
    * Trojaner zerschießt Repository auf Windows Client –> Datei wird neu abgelegt, da rsync eine Veränderung erkennt.
    * Trojaner zerschießt Backup auf Platte –> Dateien werden neu abgelegt, da rsync eine Veränderung erkennt.

    Wenn wir ab Ende des Jahres zwangsweise am Internet hängen (Arztpraxis, also ist das sicher, denn das geht über einen sicheren Internet-Service :-) werde ich die Platten vielleicht durch einen Server zu Hause ersetzen.

    Nachteile sehe ich keine – aber man muss das „zu Fuß“ programmieren, ich kenne keine vergleichbare fertige Lösung. Kennst Du eine fertige Lösung?

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.