1. Sicheres Backup
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
Du kannst den Blog aktiv unterstützen!
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.
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«:
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
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
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
16 Ergänzungen zu “dm-crypt / LUKS: Daten unter Linux sicher verschlüsseln”
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-ForumAbschließ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.
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?
@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 ;)
Danke für die Erklärung Dimitri.
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).
Steht bereits im Beitrag in einer der Info-Boxen:
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).
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.
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.
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!
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.
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.
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
Hast du user:user auch mit deinem Usernamen ersetzt?
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.
Danke dir, das war mir entgangen.
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?