dmcrypt: Was passiert, wenn der Crypto-Wrapper für den Benutzerraum nicht vorhanden ist?

787
Paco

Ich versuche, ein verschlüsseltes Volume einzurichten, um Dateien sicher zu speichern. Dies geschieht auf einem NextThingCo-Pocketchip, aber das Betriebssystem basiert auf Debian. Ich denke, ich würde es zuerst hier versuchen, da meine Frage eher mit dmcrypt als mit der Plattform selbst zusammenhängt (oder so denke ich).

Das Rezept, das ich bisher gebaut habe, ist folgendes (möglicherweise falsch oder zu kompliziert):

  1. Erstellen Sie eine Datei
  2. Richten Sie es als Loop-Gerät ein.
  3. Führen Sie das Crypsetup zum Formatieren und Öffnen aus. "abc" ist das Passwort, das durch stdin eingegeben wird (ist diese Annahme richtig?).
  4. Erstellen Sie ein Dateisystem
  5. Montieren

So sieht es so aus:

 sudo dd if=/dev/urandom of=./encrypted.volume bs=512K count=200 sudo losetup /dev/loop0 ./encrypted.volume  echo "abc" | sudo cryptsetup luksFormat /dev/loop0 echo "abc" | sudo cryptsetup open /dev/loop0 vault sudo mkfs /dev/mapper/vault sudo mount /dev/mapper/vault /mnt/vault

Nun, das scheint alles gut zu funktionieren, bis ich den --debug -Parameter verwendet habe (ich wollte andere Parameter ausprobieren, zB die Schlüsselgröße). Und ich habe die folgenden Nachrichten erkannt:

# cryptsetup 1.7.0 processing "cryptsetup -v --debug --cipher aes-xts-plain64 --key-size  512 --hash sha512 --iter-time 5000 --timeout 10 --use-random luksFormat /dev/loop0" # Running command luksFormat. ... # Userspace crypto wrapper cannot use aes-xts-plain64 (-95). ... device-mapper: remove ioctl on temporary-cryptsetup-6661 failed: Device or resource busy <------ appears when I change the --key-size to 512 i.s.o. default 256 ... device-mapper: remove ioctl on temporary-cryptsetup-6698 failed: Device or resource busy

Ich habe auch versucht, den Benchmark zu laufen:

chip@chip:~/data/run$ sudo cryptsetup --debug benchmark [sudo] password for chip: # cryptsetup 1.7.0 processing "cryptsetup --debug benchmark" # Running command benchmark. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Tests are approximate using memory only (no storage IO). # Crypto backend (gcrypt 1.6.4) initialized in cryptsetup library version 1.7.0. # Detected kernel Linux 4.4.13-ntc-mlc armv7l. # KDF pbkdf2, hash sha1: 59041 iterations per second (256-bits key). PBKDF2-sha1 59041 iterations per second for 256-bit key # KDF pbkdf2, hash sha256: 79437 iterations per second (256-bits key). PBKDF2-sha256 79437 iterations per second for 256-bit key # KDF pbkdf2, hash sha512: 40705 iterations per second (256-bits key). PBKDF2-sha512 40705 iterations per second for 256-bit key # KDF pbkdf2, hash ripemd160: 50412 iterations per second (256-bits key). PBKDF2-ripemd160 50412 iterations per second for 256-bit key # KDF pbkdf2, hash whirlpool: 7481 iterations per second (256-bits key). PBKDF2-whirlpool 7481 iterations per second for 256-bit key # Cannot initialise cipher aes, mode cbc. Required kernel crypto interface not available. Command failed with code 95: Operation not supported

Hier einige zusätzliche Informationen zu Plattform und Betriebssystem:

chip@chip:~/data/run$ uname -r 4.4.13-ntc-mlc chip@chip:~/data/run$ cat /boot/config-4.4.13-ntc-mlc | grep CRYPTO_USER_API_SKCIPHER # CONFIG_CRYPTO_USER_API_SKCIPHER is not set

Ich verstehe, dass ich den Kernel neu kompilieren muss, nachdem ich CONFIG_CRYPTO_USER_API_SKCIPHER gesetzt habe, damit die Crypto-API des Userspace verfügbar wird. Ich glaube nicht, dass es einen Ausweg gibt, oder?

Ich LuksDump die Informationen über die Speicherdatei:

chip@chip:~/data/run$ sudo cryptsetup luksDump ./encrypted.volume  LUKS header information for ./encrypted.volume  Version: 1 Cipher name: aes <------- ??? Cipher mode: xts-plain64 <------- ??? Hash spec: sha256  Payload offset: 4096 MK bits: 256 MK digest: ee f8 8d ad 9b 67 d9 7d cb 20 fe a9 25 a3 8b a5 c2 65 56 dd MK salt: 38 74 e8 9d 77 6a 93 b5 03 41 cb 3e ce 79 b4 00 55 f3 98 8f c5 a7 14 05 25 9c 4e 91 68 1a 53 37 MK iterations: 18500 UUID: 36912ea4-9adb-4d1f-b9f2-f6a09a258833  Key Slot 0: ENABLED Iterations: 150587 Salt: e8 4f f3 c1 07 1a 2b 2d d2 d9 f4 55 0f b3 13 28 2a 69 06 aa a0 94 4a 05 5d 5f e9 28 9b 91 39 94 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

Ich habe jedoch einige Fragen zur aktuellen Situation:

  • Ist die Partition tatsächlich verschlüsselt? Wenn ja, mit welchem ​​Schema?
    • Wie kann ich das in der Kommandozeile überprüfen? Beim Versuch, Informationen über die Partition zu sichern, erfahren Sie, dass "es gibt einen LUKS-Header", aber das sagt mir nicht, ob die Daten verschlüsselt sind oder nicht.
  • Wie löse ich die Situation mit "Ressourcen beschäftigt", wodurch ich eine Schlüsselgröße von 512 verwenden könnte?

Danke, dass Sie den ganzen Weg hier gelesen haben. Alle Hinweise werden sehr geschätzt.

EDIT (08/12/17): - Letzte Zeilen von crypsetup --help:

<name> is the device to create under /dev/mapper <device> is the encrypted device <key slot> is the LUKS key slot number to modify <key file> optional key file for the new key for luksAddKey action  Default compiled-in key and passphrase parameters: Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters) Default PBKDF2 iteration time for LUKS: 2000 (ms)  Default compiled-in device cipher parameters: loop-AES: aes, Key 256 bits plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160 LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
2

1 Antwort auf die Frage

0
Xen2050

Sieht so aus, als ob Ihr Kernel keine 512-Bit-Schlüssel mit aes-xts-plain64 unterstützt und überhaupt nicht im aes-Modus cbc:

# Cannot initialise cipher aes, mode cbc. Required kernel crypto interface not available. Command failed with code 95: Operation not supported

aber das stoppt den Benchmark einfach, xts wird ohnehin dem cbc vorgezogen. Ich denke, Sie könnten mehr Modi zur Verfügung haben, indem Sie einen neuen Kernel umbauen (oder vielleicht Modprobeing, ich bin mir nicht 100% sicher).

Es gibt ein paar widersprüchliche Informationen über aes mit 512-Bit-Schlüsseln. Dieses Q on crypto.SE sagt, warum wir keine AES 512-Schlüsselgröße implementieren können. und schlussfolgert, dass es einfach nicht definiert / unterstützt wird, aber es --cipher aes-xts-plain64 --key-size 512funktioniert gut für mein Cryptsetup (v1.7.3) und mein / proc / crypto hat einen xts (aes) -Eintrag, der Schlüsselgrößen von 32 bis 64 Bytes unterstützt.

  • Von luksDump aus sieht die ./encrypted.volumeDatei im Modus xts-plain64 (aes-xts-plain64) jedoch mit aes verschlüsselt aus. Zumindest alles, was darin geschrieben wurde, würde verschlüsselt werden, es bleibt davon unberührt, wenn Sie nicht bereits geöffnet und geschrieben haben.
  • ./encrypted.volume ist keine separate Festplattenpartition, sondern nur eine Datei / ein Container.

  • Sie brauchen viel Entropie dd, um 100M (512 * 200?) Aus / dev / urandom zu entfernen, und das ist unnötig. Das Erstellen der Container-Datei mit Nullen ist in Ordnung (oder einfach fallocate). Sobald es luksFormatted ist, füllen Sie es mit Nullen, die verschlüsselt und auf die Festplatte geschrieben werden.

  • Was sind die letzten 10 Zeilen oder so cryptsetup --help? Es wird sagen, was die Standardeinstellungen sind.
  • Was ist in /proc/crypto? Es zeigt Ihnen die verfügbaren Verschlüsselungsmethoden.
  • Auch die aktuellen Loop-Dateien von cryptsetup selbst, also können Sie das Losetup überspringen und cryptsetup damit umgehen lassen.
  • Wenn Ihre Shell den Verlauf speichert, könnte Ihre Passphrase ("abc") im Klartext gespeichert werden. Das ist nicht besonders gut. Es kann auch von sichtbar pssein, wenn es vollständige Befehlszeilen auflistet. Die Verwendung einer anderen Methode, um die Passphrase für stdin zu verwenden, ist möglicherweise sicherer. Sie können auch eine Schlüsseldatei auf einem sicheren Medium (externes USB-Gerät / Gerät) oder in Ramfs usw. verwenden. Siehe Abschnitt 2.14 in den häufig gestellten Fragen.
Danke für die Hinweise. Ich füge die Informationen in meinem ursprünglichen Beitrag hinzu. Mit Ihrem ersten Punkt: `Jedenfalls sieht die Datei ./encrypted.volume in luksDump im Modus xts-plain64 (aes-xts-plain64) mit aes verschlüsselt aus. Zumindest alles, was darin geschrieben wurde, wäre verschlüsselt, es bleibt unangetastet, wenn Sie nicht luksOpen-ed und geschrieben geschrieben haben. "Meinen Sie damit, dass encrypted.volume tatsächlich verschlüsselt ist, obwohl es keine API gibt? Ich mache mir Sorgen, dass der Luks-Header eine Sache sagt, aber der Zugriff auf die Daten bewirkt etwas anderes. zB Klartext r / w Paco vor 6 Jahren 0
Nachdem ich die Links gelesen hatte, änderte ich das Rezept wie folgt: Sudo dd if = / dev / zero von = quick.volume bs = 512K count = 100 sudo losetup -f sudo losetup / dev / loop0 quick.volume echo "abc" | sudo cryptsetup --debug luksFormat / dev / loop0 echo "abc" | sudo cryptsetup --debug open / dev / loop0 quick sudo dd wenn = / dev / zero von = / dev / mapper / quick echo "abc" | sudo cryptsetup --debug close quick hexdump quick.volume` Beim Lesen des Hexdumps sehe ich verstümmelte Daten nach 2 MB. Also ich denke es ist eigentlich verschlüsselt aber mit welcher Chiffre? Sollte ich glauben, dass luksDump xts-plain64 auch ohne Userspace-API sagt? Paco vor 6 Jahren 0
2 MB ist normalerweise die Größe des LUKS-Headers, und die verschlüsselten Daten beginnen nach, sodass die verstümmelten Daten wie verschlüsselt klingen, OK. Ich glaube, der luksDump von cryptsetup, oder während es geöffnet ist, könnten Sie auch `dmsetup` überprüfen, es wird sogar der tatsächliche Verschlüsselungsschlüssel angezeigt ([fyi könnte eine neue Passphrase * hinzufügen, ohne einen vorhandenen zu kennen)] (https: // superuser). com / questions / 1277948 / how-to-find-my-luks-Verschlüsselung-Passphrase-entschlüsseltes-Dateisystem / 1278023 # 1278023)). Sieht so aus, als würde die [Crypto-API des Kernels] (https://www.kernel.org/doc/html/latest/crypto/index.html) gut funktionieren, Cryptsetup ist in Ordnung, nur kein aes-cbc Xen2050 vor 6 Jahren 0
Schließlich habe ich `dmsetup` verwendet, um die verschlüsselte Datei zu überprüfen. Das Ergebnis war folgendes: `chip @ chip: ~ $ sudo dmsetup-Tabelle --showkeys / dev / mapper / quick 0 98304 crypt aes-xts-plain64 <32BYTENUMBER> 0 7: 0 4096` Ich bin jetzt mehr zuversichtlich, dass meine Informationen dies sind ist verschlüsselt. Danke für all die Hilfe! Paco vor 6 Jahren 0
Willkommen :) Ich hatte eine andere Idee, Sie könnten einen kleinen LUKS-Container auf einem anderen Computer erstellen und sehen, ob er auf diesem System gelesen und beschrieben wurde. Bringen Sie ihn dann auf den anderen Computer zurück und überprüfen Sie die neuen Informationen oder umgekehrt. Xen2050 vor 6 Jahren 0

Verwandte Probleme