Plausible Verschlüsselungs-Abstreitbarkeit unter Linux mit Cryptsetup LUKS
Plausible Verschlüsselungs-Abstreitbarkeit unter Linux mit cryptsetup LUKS: Wie man USB-Sticks, externe Festplatten und andere Speichermedien verschlüsselt
Plausible Verschlüsselungs-Abstreitbarkeit unter Linux mit cryptsetup LUKS: Wie man USB-Sticks, externe Festplatten und andere Speichermedien verschlüsselt
Dieser Blogpost wurde von einer Maschine aus dem Englischen übersetzt. Die Originalversion finden Sie hier: Plausible Encryption Deniability on Linux with Cryptsetup LUKS
Bitte kontaktieren Sie uns , wenn etwas nicht eindeutig beschrieben ist, nicht funktioniert, falsch erscheint oder wenn Sie Unterstützung benötigen.
Dieser Blogbeitrag bietet eine klare und unkomplizierte Anleitung zur Verschlüsselung verschiedener Speichergeräte - einschließlich USB-Sticks, externer Festplatten und interner Speicher - für plausible Abstreitbarkeit der Verschlüsselung unter Linux. Er konzentriert sich auf die Verwendung des cryptsetup-Tools mit LUKS-Verschlüsselung, das standardmäßig auf den meisten gängigen Linux-Distributionen wie Ubuntu installiert ist. Der Artikel beschreibt detailliert, wie ein abgetrennter LUKS-Header konfiguriert wird, wodurch es für Angreifer unmöglich wird, die Existenz verschlüsselter Daten nachzuweisen.
Plausible Verschlüsselungsabstreitbarkeit ist die Fähigkeit, das Vorhandensein verschlüsselter Daten auf einem Gerät überzeugend abzustreiten. Sie stellt sicher, dass eine Person selbst unter Zwang plausibel behaupten kann, dass keine verschlüsselten Daten über das bereits Offenbarte hinaus existieren. Dies geschieht, indem ein Speichergerät, das verschlüsselte Daten enthält, identisch aussieht wie ein Speichergerät, das zum Zweck des sicheren Löschens der zuvor darauf gespeicherten Daten mit Zufallsdaten überschrieben wurde.
In der IT ist es üblich, Speichergeräte wie USB-Sticks, SD-Karten, Solid-State-Laufwerke oder Festplatten vor der Wiederverwendung mehrmals mit Zufallsdaten zu überschreiben. Dies stellt sicher, dass die alten Daten darauf nicht mehr wiederhergestellt werden können. Danach kann das Speichergerät für die Speicherung anderer Daten wiederverwendet oder entsorgt werden.
Sie können jedes Speichergerät, wie einen USB-Stick oder eine externe Festplatte, mit dem Linux-Tool dd, das auf den meisten Debian-basierten Distributionen standardmäßig installiert ist, mit dem folgenden Befehl mit Zufallsdaten überschreiben:
sudo dd if=/dev/urandom of=/dev/sdX status=progress
Die “Daten” auf dem USB-Stick werden dann von dd mit zufälligen Einsen und Nullen überschrieben. Das Ziel der plausiblen Verschlüsselungsabstreitbarkeit besteht darin, ein verschlüsseltes Speichermedium genau so aussehen zu lassen, als wäre es zur Wiederverwendung oder sicheren Entsorgung mit Zufallsdaten überschrieben worden.
Wenn Sie ein beliebiges Verschlüsselungstool verwenden, um ein beliebiges Speichermedium zu verschlüsseln, muss dieses Verschlüsselungstool, genau wie cryptsetup, mindestens eine kleine Menge an Klartextdaten irgendwohin schreiben. Bei cryptsetup ist dies der sogenannte LUKS-Header. Bei der regulären Verwendung des cryptsetup-Tools werden diese LUKS-Header-Informationen direkt auf dem verschlüsselten Speichergerät gespeichert. Er ist für die Überprüfung des Verschlüsselungspassworts und das “Öffnen” oder Entschlüsseln des Geräts verantwortlich. Wenn diese LUKS-Header-Informationen direkt auf dem verschlüsselten Gerät gespeichert sind, ist es leicht zu erkennen, dass das Speichermedium verschlüsselt ist.
Durch das Speichern dieses “LUKS-Headers” auf einem anderen Speichergerät, nicht dem, das die verschlüsselten Daten enthält, verbleiben auf dem tatsächlich verschlüsselten Speichergerät nur die verschlüsselten Daten, die nicht von den durch den obigen dd-Befehl erzeugten Zufallsdaten unterschieden werden können.
Technisch nicht versierte Personen überschreiben Speichergeräte üblicherweise nicht mit Zufallsdaten. Wenn überhaupt, “partitionieren” sie die Geräte, was bedeutet, dass das Dateisystem gelöscht und ein neues erstellt wird. Sie können sich das vorstellen wie die Verwendung von Korrekturflüssigkeit oder Tipp-Ex, um das Inhaltsverzeichnis in einem Buch zu löschen. Danach erstellen Sie ein “frisches” Inhaltsverzeichnis. Das bedeutet nicht, dass Sie jede Seite des Buches übermalt haben und die “Seiten” (oder Daten) sind nicht gelöscht, indem Sie ein neues Dateisystem auf dem Speichergerät erstellen, löschen wir einfach alle Referenzpunkte darauf, wo die Daten gespeichert sind. Mit Datenforensik-Tools wie https://www.cgsecurity.org/wiki/TestDisk, die mit Betriebssystemen für solche Zwecke wie https://www.caine-live.net/ geliefert werden, können diese Daten leicht wiederhergestellt werden.
Das einfache Formatieren eines USB-Sticks löscht die Daten darauf nicht. Nur das Überschreiben jedes Bytes des Speichergeräts (vorzugsweise mehrmals) macht die Daten tatsächlich unwiederbringlich.
Hier sind einige gute Ausreden Gründe, warum Sie Speichergeräte besitzen könnten, die mit Zufallsdaten überschrieben wurden:
Wie Sie sehen, ist jeder Ansatz ein wenig zwielichtig, und die plausible Verschlüsselungsabstreitbarkeit ist möglicherweise nicht so plausibel, je nachdem, wie Sie die Existenz sicher gelöschter Datenspeichergeräte erklären.
Die Erstellung eines Speichergeräts für die Verwendung mit plausibler Verschlüsselungsabstreitbarkeit unter Linux mit cryptsetup kann durch Befolgen der folgenden Beispiele erreicht werden.
Schließen Sie das Speichergerät, das Sie verschlüsseln möchten, an Ihren Laptop an, auf dem Linux läuft. Führen Sie dann den folgenden Befehl aus:
lsblk --nodeps --exclude 7,11 --output NAME,PATH,MOUNTPOINTS
NAME PATH MOUNTPOINTS
sda /dev/sda /media/user/95eb4cb1-f2c8-4180-805a-d1c830a5c34f
mmcblk0 /dev/mmcblk0
nvme0n1 /dev/nvme0n1
Wie Sie sehen, hat mein Laptop drei physische Geräte angeschlossen: einen USB-Stick /dev/sda, eine SD-Karte /dev/mmcblk0 und die interne NVMe-SSD des Laptops /dev/nvme0n1. Weitere Informationen zum Befehl finden Sie in man lsblk.
Stellen Sie sicher, dass die dritte Spalte (MOUNTPOINTS) leer ist. Wenn dies nicht der Fall ist, wie im obigen Beispiel, wo /media/user/95eb4cb1-f2c8-4180-805a-d1c830a5c34f angezeigt wird, ist Ihr Gerät gemountet und Sie müssen es zuerst aushängen:
sudo umount --verbose /dev/sda
umount: /mnt (/dev/sda) unmounted
Wenn Sie sich nicht sicher sind, welches Gerät das richtige ist, verwenden Sie den folgenden Befehl:
# USB-Stick
udevadm info --query=property /dev/sda
[...]
ID_MODEL=DataTraveler_3.0
[...]
# SD-Karte
udevadm info --query=property /dev/mmcblk0
[...]
MMC_TYPE=SD
[...]
# Interne NVMe-SSD des Laptops
udevadm info --query=property /dev/nvme0n1
[...]
ID_MODEL=K53DVL01YA04 TOSHIBA
[...]
Weitere Informationen zum Befehl finden Sie in man udevadm.
Ein anderer Ansatz besteht darin, den folgenden Befehl auszuführen, bevor Sie das Speichergerät an Ihren Laptop anschließen, sich die Ausgabe anzusehen und das Gerät dann anzuschließen. Im folgenden Beispiel wird der USB-Stick an den Laptop angeschlossen und die Gerätedatei /dev/sda erstellt:
sudo dmesg --human --color --follow
[...]
[Tue May 21 20:10:16 2024] usb 1-6: new high-speed USB device number 15 using xhci_hcd
[Tue May 21 20:10:16 2024] usb 2-6: new SuperSpeed USB device number 10 using xhci_hcd
[Tue May 21 20:10:17 2024] usb 2-6: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.00
[Tue May 21 20:10:17 2024] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue May 21 20:10:17 2024] usb 2-6: Product: DataTraveler 3.0
[Tue May 21 20:10:17 2024] usb 2-6: Manufacturer: Kingston
[Tue May 21 20:10:17 2024] usb 2-6: SerialNumber: NREOLTEEBGL1VMBRKDTTCMZG
[Tue May 21 20:10:17 2024] usb-storage 2-6:1.0: USB Mass Storage device detected
[Tue May 21 20:10:17 2024] scsi host0: usb-storage 2-6:1.0
[Tue May 21 20:10:18 2024] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[Tue May 21 20:10:18 2024] sd 0:0:0:0: Attached scsi generic sg0 type 0
[Tue May 21 20:10:18 2024] sd 0:0:0:0: [sda] 30720000 512-byte logical blocks: (15.7 GB/14.6 GiB)
[Tue May 21 20:10:18 2024] sd 0:0:0:0: [sda] Write Protect is off
[Tue May 21 20:10:18 2024] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[Tue May 21 20:10:18 2024] sd 0:0:0:0: [sda] No Caching mode page found
[Tue May 21 20:10:18 2024] sd 0:0:0:0: [sda] Assuming drive cache: write through
[Tue May 21 20:10:18 2024] sd 0:0:0:0: [sda] Attached SCSI removable disk
Verwenden Sie den folgenden Befehl, um das Speichergerät mit Zufallsdaten zu überschreiben. Ersetzen Sie “sda” durch den korrekten Gerätenamen! Seien Sie hierbei sehr vorsichtig! Es ist nicht möglich, die auf diesem Gerät gespeicherten Daten danach wiederherzustellen! Beachten Sie, dass das Überschreiben des Geräts mit Zufallsdaten je nach Größe des Speichergeräts mehrere Minuten bis mehrere Stunden dauern kann. Das einmalige Überschreiben des Speichergeräts reicht für den Zweck der plausiblen Verschlüsselungsabstreitbarkeit aus.
time sudo dd if=/dev/urandom of=/dev/sda status=progress
15727428096 bytes (16 GB, 15 GiB) copied, 1923 s, 8,2 MB/s
dd: writing to '/dev/sda': No space left on device
30720001+0 records in
30720000+0 records out
15728640000 bytes (16 GB, 15 GiB) copied, 1952,6 s, 8,1 MB/s
real 32m33,017s
user 0m0,028s
sys 0m0,077s
Wie Sie in der drittletzten Zeile sehen können, dauerte das Überschreiben meines (sehr alten) 16-GB-USB-Sticks mit Zufallsdaten etwa 32 Minuten. Die Fehlermeldung dd: writing to '/dev/sda': No space left on device wird erwartet, da wir bis zum Ende der Kapazität des Speichergeräts geschrieben haben.
Während Sie darauf warten, dass Ihr Speichergerät mit Zufallsdaten überschrieben wird, hier der Grund, warum Sie das tun. Wie Sie vielleicht beim Erstellen neuer Dateisysteme in der Vergangenheit bemerkt haben, ist das Erstellen eines Dateisystems (oder das Einrichten der Verschlüsselung für ein Speichergerät mit cryptsetup) viel schneller als das Überschreiben mit Zufallsdaten. Dies liegt daran, dass beim Erstellen eines Dateisystems wie vFAT, NTFS oder ext4 nur eine “Inhaltsverzeichnis”-ähnliche Struktur auf dem Speichergerät erstellt wird. Es wird nicht jedes mögliche Byte auf dem Gerät überschrieben.
Wenn Sie ein neues Speichergerät kaufen, ist es üblicherweise mit Nullen überschrieben. Wenn Sie jetzt ein reguläres oder verschlüsseltes Dateisystem erstellen und einige Daten darauf speichern, bis es zu 10 % gefüllt ist, werden 10 % des Geräts Daten enthalten und die anderen 90 % des Geräts werden immer noch nur Nullen sein.
Dasselbe gilt, wenn Sie ein Gerät verschlüsseln - wenn Sie ein Speichergerät mit cryptsetup unter Verwendung der Standardmethode verschlüsseln, schreibt es nur den LUKS-Header an den Anfang des Geräts - oder, wenn Sie diesem Artikel folgen, auf ein zweites, anderes Speichergerät (nicht das, das Sie tatsächlich verschlüsseln möchten). Der Rest des Speicherplatzes bleibt unberührt. Wenn Sie jetzt weniger Daten als 100 % seiner Kapazität hinzufügen, enthält das Gerät einen bestimmten Prozentsatz scheinbar zufälliger Daten (das sind die verschlüsselten Daten) und der Rest werden nur Nullen sein. In diesem Fall ist es vernünftiger anzunehmen, dass Sie Verschlüsselung verwenden, da es keinen logischen Grund gibt, warum nur die Hälfte des Geräts mit Zufallsdaten überschrieben würde und nicht auch der Rest.
Sie haben vielleicht bemerkt, dass neuere Linux-Distributionen während der Erstinstallation Root-Disk-Verschlüsselung anbieten, und dass diese Installer fragen, ob Sie die Festplatte Ihres Laptops mit Zufallsdaten überschreiben möchten - das ist genau für diesen Zweck.
Idealerweise sollten Sie die folgenden Schritte in einem Ubuntu Linux Live-System ausführen, um keine digitalen Fußabdrücke über das Verschlüsseln, Entschlüsseln und Arbeiten mit dem Speichergerät zu hinterlassen. Wenn Sie die folgenden Befehle auf Ihrer regulären Linux-Installation Ihres Computers ausführen, werden Informationen über die von Ihnen angeschlossenen Geräte und die von Ihnen ausgeführten Befehle in die Logdateien geschrieben, die auf der internen Festplatte Ihres Computers gespeichert werden.
Um einen Ubuntu Live-USB-Stick zu erstellen, folgen Sie einfach dem offiziellen Ubuntu-Tutorial .
Wenn Sie einen solchen USB-Stick booten, können Sie Ubuntu “ausprobieren” sowie installieren. Ausprobieren bedeutet in diesem Kontext, ein Live-Ubuntu-Linux-System auf Ihrem Computer auszuführen, das keine Daten dauerhaft auf der internen Festplatte des Computers oder dem USB-Stick selbst speichert. Alle Daten, die Sie speichern, zusammen mit Logdateien, die das System schreibt, wenn Sie Speichermedien anschließen oder Befehle ausführen, werden nur im RAM Ihres Computers gespeichert und gehen verloren, wenn Sie den Computer herunterfahren.
Um das Speichergerät mit cryptsetup LUKS zu verschlüsseln, verwenden Sie den folgenden Befehl. Stellen Sie sicher, dass Sie /dev/sda durch die korrekte Gerätedatei ersetzen. Beachten Sie, dass wir die Datei “luksheader.img” in das Verzeichnis “/dev/shm/” schreiben - dies ist ein gemountetes Linux tmpfs
, was bedeutet, dass Dateien in diesem Verzeichnis nur im RAM gespeichert werden. Dies stellt absolut sicher, dass die Datei nicht auf eine physische Festplatte geschrieben wird.
Beantworten Sie die Frage des folgenden Befehls “Are you sure?” mit großgeschriebenem “YES”. Geben Sie danach Ihr Passwort ein und bestätigen Sie es. Hier sind einige Richtlinien zur Auswahl eines sicheren Passworts .
sudo cryptsetup luksFormat /dev/sda --header /dev/shm/luksheader.img
WARNING!
========
Header file does not exist, do you want to create it?
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for luksheader.img:
Verify passphrase:
Wie Sie mit dem folgenden Befehl sehen können, haben wir jetzt eine Datei namens “luksheader.img”, die 16 MB groß ist:
ls -lah /dev/shm/luksheader.img
-rw------- 1 root root 16M Apr 23 10:27 /dev/shm/luksheader.img
Speichern Sie diese Datei dauerhaft an einem sicheren Ort, z. B. durch Hochladen auf einen vertrauenswürdigen Remote-Server per SSH. Wenn Sie diese Datei bei sich tragen, während Ihre verschlüsselten Speichergeräte überprüft werden, ist Ihre Verschlüsselung nicht plausibel. Obwohl es keine Möglichkeit gibt, zu bestimmen, zu welchem physischen Speichergerät die luksheader.img-Datei gehört, ohne das Passwort dafür zu haben, ist der Besitz einer solchen Datei offensichtlich ein Beweis dafür, dass Sie versuchen, plausible Abstreitbarkeit der Verschlüsselung zu implementieren.
Wenn Sie diese Datei verlieren, sind Ihre Daten verloren, und es gibt nichts, was Sie dagegen tun können. Weitere Informationen finden Sie im cryptsetup-Projekt-Wiki .
Um das Speichergerät mit dem abgetrennten LUKS-Header zu entschlüsseln, verwenden Sie den folgenden Befehl:
sudo cryptsetup --verbose luksOpen /dev/sda my-secret-storage --header=/dev/shm/luksheader.img
No usable token is available.
Enter passphrase for /dev/sda:
Key slot 0 unlocked.
Command successful.
Die Warnmeldung “No usable token is available.” kann ignoriert werden, wie Sie aus der letzten Zeile lesen können, war die Entschlüsselung erfolgreich.
Wir haben jetzt eine neue, entschlüsselte Speichergerätedatei unter /dev/mapper/my-secret-storage erstellt. Dieses Gerät enthält noch kein Dateisystem. Wir können jedes beliebige Dateisystem wählen, um das entschlüsselte Gerät zu formatieren, in diesem Fall ext4:
sudo mkfs.ext4 /dev/mapper/my-secret-storage
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 3840000 4k blocks and 960992 inodes
Filesystem UUID: 1e1c9470-711d-4986-b1b5-8d84f3a06c79
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
Wir können jetzt das neue Dateisystem mounten, damit wir mit dem Speichern von Daten darauf beginnen können:
sudo mount -v /dev/mapper/my-secret-storage /mnt
mount: /dev/mapper/my-secret-storage mounted on /mnt.
Wir sollten die Berechtigungen dieses Verzeichnisses ändern, damit der reguläre Linux-Benutzer, der Ihre grafische Desktop-Umgebung ausführt, Daten darauf speichern kann:
sudo chown --recursive $USER:$USER /mnt
Sie können jetzt Ihre Daten im Verzeichnis “/mnt/” speichern, das sie verschlüsselt auf “/dev/sda” schreiben wird.
Beim Schreiben Ihrer Daten auf das entschlüsselte Speichergerät werden einige dieser Daten von Linux zwischengespeichert, um die Schreibgeschwindigkeit zu verbessern, und nicht sofort auf die Festplatte geschrieben. Bevor Sie (externe) Speichergeräte von Ihrem Linux-Computer entfernen, müssen Sie sie zuerst unmounten:
sudo umount -v /mnt
umount: /mnt unmounted
Danach müssen Sie die cryptsetup LUKS-Verschlüsselung “schließen” - das bedeutet, dass das Gerät nicht mehr entschlüsselt ist und Sie sowohl die Datei “luksheader.img” als auch das Passwort benötigen, um es erneut zu entschlüsseln.
sudo cryptsetup --verbose luksClose /dev/mapper/my-secret-storage
Command successful.
Es ist gleichermaßen sicher, das Ubuntu-Live-System einfach herunterzufahren, anstatt das verschlüsselte Laufwerk zu unmounten und luksClose auszuführen. Während des Herunterfahrvorgangs kümmert sich das Live-Ubuntu um das Unmounten und Schließen der LUKS-Verschlüsselung für Sie. Sie sollten vorzugsweise nicht einfach “ausschalten”, indem Sie die Stromversorgung des Computers entfernen, da dies zu Datenbeschädigungen bei den Dateien führen kann, mit denen Sie gearbeitet haben, während der Computer lief. Das einfache Trennen der Stromversorgung oder das Gedrückthalten der Einschalttaste, bis sich der Computer ausschaltet, stellt jedoch kein Risiko für die Stärke und Wirksamkeit der Verschlüsselung dar.
Beachten Sie, dass wir, da wir den LUKS-Header in einer zusätzlichen Datei anstatt direkt auf dem von uns verschlüsselten Speichergerät speichern, jedes andere Speichergerät nehmen und es erfolgreich mit diesem Header “öffnen” können. Im folgenden Beispiel verwende ich eine SD-Karte, die ich frisch mit Zufallsdaten überschrieben habe. Ich werde dasselbe Passwort eingeben, das ich zum Verschlüsseln des USB-Sticks aus den obigen Beispielen verwendet habe.
sudo dd if=/dev/urandom of=/dev/mmcblk0 status=progress
[...]
sudo cryptsetup --verbose luksOpen /dev/mmcblk0 my-secret-storage --header=/dev/shm/luksheader.img
No usable token is available.
Enter passphrase for /dev/mmcblk0:
Key slot 0 unlocked.
Command successful.
Wie Sie sehen können, war der Befehl erfolgreich, was bedeutet, dass es jetzt auch eine Gerätedatei “/dev/mapper/my-secret-storage” gibt. Da dies nicht der USB-Stick ist, mit dem ich in den vorherigen Beispielen gearbeitet habe, gibt es offensichtlich auch keine der Daten, die ich zuvor darauf gespeichert habe. Dies beweist, dass das Speichergerät selbst für den Entschlüsselungsvorgang irrelevant ist. Alle Informationen, die wir benötigen, um DIE DATEN auf dem USB-Stick zu entschlüsseln, den ich oben erstellt habe, sind in der Datei “luksheader.img” gespeichert. Cryptsetup selbst hat kein Verständnis davon, was diese Daten genau sind. Sie können sich cryptsetup in Kombination mit der “luksheader.img” als eine Art Rohr vorstellen, in das Sie Daten auf der einen Seite stecken und auf der anderen Seite (das physische Speichergerät) “verschlüsselte Daten” ausgegeben werden. Es gibt keine Möglichkeit zu bestimmen, ob diese Daten verschlüsselte Daten oder Zufallsdaten sind, die durch Überschreiben des Speichergeräts mit Zufallsdaten erzeugt wurden.
Lassen Sie uns den USB-Stick, den wir zum Speichern verschlüsselter Daten in den obigen Beispielen verwendet haben, genau untersuchen.
Die Überprüfung des USB-Sticks auf eine Dateisignatur, auch Magic-File-Header genannt , zeigt nur “data” als Ausgabe:
sudo file --special-files --keep-going /dev/sda
/dev/sda: data
Zum Vergleich, hier ist derselbe Befehl für eine Festplatte, die mit cryptsetup ohne Abtrennung des LUKS-Headers verschlüsselt ist. Beachten Sie, dass die Ausgabe des Befehls am Ende abgeschnitten ist… Ich habe leider keine Option in man file gefunden, um dies zu verhindern.
sudo file --special-files --keep-going /dev/nvme0n1
/dev/nvme0n1p3: LUKS encrypted file, ver 2, header size 16384, ID 3, algo sha256, salt 0x7aijqgdczmhftkkxc..., UUID: 07821642-7aa5-47bb-a84a-8e195eba5b0b, crc 0xzkadqosdmifby2evn..., at 0x1000 {"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offse
Die Überprüfung des verschlüsselten USB-Sticks auf eine Partitionstabelle ergibt nichts:
sudo fdisk -l /dev/sda
Disk /dev/sda: 14,65 GiB, 15728640000 bytes, 30720000 sectors
Disk model: DataTraveler 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
sudo parted -l /dev/sda
Error: /dev/sda: unrecognised disk label
Model: Kingston DataTraveler 3.0 (scsi)
Disk /dev/sda: 15,7GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
sudo lsblk /dev/sda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 14,6G 0 disk
Selbst die Überprüfung, ob das Speichergerät mit dem Befehl cryptsetup verschlüsselt ist, gibt false zurück, da wir den LUKS-Header nicht auf dem Speichergerät selbst gespeichert haben:
sudo cryptsetup isLuks /dev/sda --debug
# cryptsetup 2.6.1 processing "cryptsetup isLuks /dev/sda --debug"
# Verifying parameters for command isLuks.
# Running command isLuks.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/sda.
# Trying to open and read device /dev/sda with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/sda.
# Crypto backend (OpenSSL 3.0.8 7 Feb 2023 [default][legacy]) initialized in cryptsetup library version 2.6.1.
# Detected kernel Linux 6.2.0-39-generic x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device /dev/sda.
# Opening lock resource file /run/cryptsetup/L_8:0
# Verifying lock handle for /dev/sda.
# Device /dev/sda READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/sda
# Verifying locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x8000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x10000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x20000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x40000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x80000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x100000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x200000.
# Reusing open ro fd on device /dev/sda
# Trying to read secondary LUKS2 header at offset 0x400000.
# Reusing open ro fd on device /dev/sda
# LUKS2 header read failed (-22).
# Device /dev/sda READ lock released.
# Releasing crypt device /dev/sda context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/sda.
Command failed with code -1 (wrong or missing parameters).
Nur wenn wir den Befehl cryptsetup isLuks auf der “luksheader.img” selbst ausführen, gibt cryptsetup zurück, dass es cryptsetup-Verschlüsselung verwendet - beachten Sie die letzte Zeile der Ausgabe des obigen und folgenden Befehls.
sudo cryptsetup isLuks /dev/shm/luksheader.img --debug
# cryptsetup 2.6.1 processing "cryptsetup isLuks /dev/shm/luksheader.img --debug"
# Verifying parameters for command isLuks.
# Running command isLuks.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/shm/luksheader.img.
# Trying to open and read device /dev/shm/luksheader.img with direct-io.
# Trying to open device /dev/shm/luksheader.img without direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/shm/luksheader.img.
# Crypto backend (OpenSSL 3.0.8 7 Feb 2023 [default][legacy]) initialized in cryptsetup library version 2.6.1.
# Detected kernel Linux 6.2.0-39-generic x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device /dev/shm/luksheader.img.
# Verifying lock handle for /dev/shm/luksheader.img.
# Device /dev/shm/luksheader.img READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/shm/luksheader.img
# Verifying locked device handle (regular file)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:18b1b8177a99f265a633dd87f4486673ba2f392979e4b9b1a87f5d3c3738d1d6 (on-disk)
# Checksum:18b1b8177a99f265a633dd87f4486673ba2f392979e4b9b1a87f5d3c3738d1d6 (in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device /dev/shm/luksheader.img
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:3b1dd3ed097221b7c35e82c25f03680efca776d5847456a64c4e07fc7fc081e3 (on-disk)
# Checksum:3b1dd3ed097221b7c35e82c25f03680efca776d5847456a64c4e07fc7fc081e3 (in-memory)
# Device size 16777216, offset 16777216.
# Device /dev/shm/luksheader.img READ lock released.
# PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# Releasing crypt device /dev/shm/luksheader.img context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/shm/luksheader.img.
Command successful.
Stellen Sie sicher, dass Sie die folgenden Sicherheitsrichtlinien befolgen, wenn Sie mit Speichergeräten umgehen, die auf die in diesem Blogbeitrag beschriebene Weise verschlüsselt sind.
Abgesehen davon, dass Sie nicht mit Ihrem verschlüsselten Gerät auf dem auf der internen Festplatte Ihres Computers installierten Betriebssystem interagieren sollten - wenn zusätzliche Verschlüsselungstools wie VeraCrypt auf der internen Festplatte Ihres Computers installiert sind und Sie gezwungen werden, den Laptop zu entschlüsseln, wird das Vorhandensein solcher zusätzlichen Tools verdächtig erscheinen. Cryptsetup ist standardmäßig auf den meisten neueren Linux-Distributionen wie Ubuntu installiert, und die Verschlüsselung der internen Festplatte Ihres Computers ist üblich, da es ein (optionaler) Teil der Standardinstallation ist.
Wenn Sie ein Speichergerät mit einer regulären Ubuntu-Installation anschließen, entschlüsseln und verwenden, werden Protokolle darüber auf die Festplatte geschrieben. Um solche digitalen Fußabdrücke zu vermeiden, booten Sie von einem regulären Ubuntu Live-USB-Stick, um auf das verschlüsselte Gerät zuzugreifen. Jeder Ubuntu-Installer bootet zuerst in ein normales Live-System, von dem aus Sie “Ubuntu ausprobieren können, bevor Sie sich entscheiden, es zu installieren oder nicht”.
Vermeiden Sie es, die internen Festplatten Ihres Computers von diesem USB-Stick aus zu mounten, da dies nachweisbare Spuren im Dateisystem der Laptop-Festplatte hinterlassen könnte. Wenn Sie paranoid sein möchten, entfernen Sie die interne Festplatte Ihres Laptops physisch, bevor Sie den USB-Live-Stick booten. Ubuntu könnte versuchen, die interne Festplatte des Laptops während der regulären Verwendung automatisch zu mounten.
Es gibt auf digitale Forensik fokussierte Linux-Distributionen wie caine-live , aber das Herumtragen auf einem bootfähigen USB-Stick wird verdächtig aussehen. Der Besitz eines Ubuntu-Live-USB-Sticks, der die Standardmethode zur Installation von Ubuntu enthält, kann einfach durch ein “manchmal langsames und regelmäßig abstürzendes System” und den Wunsch nach einer baldigen Neuinstallation erklärt werden.
Tragen Sie den LUKS-Header nicht bei sich. Laden Sie ihn stattdessen mit SSH auf einen vertrauenswürdigen Server hoch und merken Sie sich das SSH-Passwort. Diese Strategie vermeidet die Notwendigkeit, einen SSH-Private-Key irgendwo zu speichern und ihn bei sich zu tragen, was auch verdächtig aussehen könnte. Speichern Sie keinen SSH-Private-Key auf der internen Festplatte Ihres Computers und greifen Sie vom Live-System darauf zu - das Mounten der internen Festplatte Ihres Computers vom Live-System aus kann digitale Fußabdrücke hinterlassen.
Suchen Sie
Linux Notfallunterstützung,
Linux-Beratung für Projekte,
Linux Managed Hosting,
Qubes OS Beratung und Support oder
Online- und Vor-Ort-Schulungen?