dmcrypt: Что происходит, когда отсутствует пользовательская криптооболочка?

693
Paco

Я пытаюсь настроить зашифрованный том для безопасного хранения файлов. Это делается с помощью карманного чипа NextThingCo, но ОС основана на debian, поэтому я догадался, что сначала попробую, так как мой вопрос больше связан с dmcrypt, чем с самой платформой (или я так думаю).

Рецепт, который я построил до сих пор, следующий (может быть неправильным или слишком сложным):

  1. Создать файл
  2. Установите это как устройство петли.
  3. Сделайте crypsetup для форматирования и откройте. «abc» - пароль, передаваемый через стандартный ввод (верно ли это предположение?).
  4. Сделать файловую систему
  5. гора

Так это выглядит так:

 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 

Теперь все это работает нормально, пока я не использовал параметр --debug (я хотел попробовать и другие параметры, например, размер ключа). И я понял следующие сообщения:

# 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 

Я тоже попробовал запустить тест:

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 

Вот дополнительная информация о платформе и ОС:

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 

Я понимаю, что мне нужно будет перекомпилировать ядро ​​после установки CONFIG_CRYPTO_USER_API_SKCIPHER, чтобы крипто API пользовательского пространства стал доступен. Я не думаю, что есть способ обойти это, не так ли?

У меня LuksDump информация о файле хранилища:

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 

Однако у меня есть несколько вопросов о текущей ситуации:

  • Действительно ли раздел зашифрован? Если да, то по какой схеме?
    • Как проверить это в командной строке? Попытка вывести информацию о разделе говорит мне, что «есть заголовок LUKS», но это не говорит мне, зашифрованы ли данные или нет.
  • Как решить ситуацию с 'ресурсом занятым', который позволил бы мне использовать размер ключа 512?

Спасибо, что прочитали весь путь здесь. Любые указатели будут с благодарностью.

РЕДАКТИРОВАТЬ (08/12/17): - Последние строки 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 ответ на вопрос

0
Xen2050

Похоже, ваше ядро ​​не поддерживает 512-битные ключи с помощью aes-xts-plain64 и вообще не поддерживает режим aes в режиме cbc:

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

но это просто останавливает тест, в любом случае xts предпочтительнее, чем cbc. Я думаю, что вы могли бы получить больше режимов, перестраивая / получая новое ядро ​​(или, возможно, modprobeing, я не уверен на 100%).

Есть небольшая противоречивая информация об aes с 512-битными ключами, этот вопрос на crypto.SE говорит, почему мы не можем реализовать размер ключа AES 512? и приходит к выводу, что он просто не определен / не поддерживается, но использование --cipher aes-xts-plain64 --key-size 512отлично работает для моего cryptsetup (v1.7.3), и в моем / proc / crypto есть запись xts (aes), поддерживающая размеры ключей 32-64 байта.

  • В любом случае, из luksDump ./encrypted.volumeфайл выглядит зашифрованным с помощью aes в режиме xts-plain64 (aes-xts-plain64). По крайней мере все, что записано в него, будет зашифровано, оно не будет затронуто, если вы не сделали luksOpen-ed и не записали в него.
  • ./encrypted.volume это не отдельный раздел диска, это просто файл / контейнер.
  • Вы будете использовать большую часть своей энтропии, ddчтобы взять 100M (512 * 200?) Из / dev / urandom, и это не нужно. Создание файла контейнера с использованием нулей - это хорошо (или просто fallocate). После того, как это luksFormatted то вы заполнить его нулями, которые будут получать зашифрованные и записаны на диск.

  • Что за последние 10 строк или около того cryptsetup --help? Это скажет, что по умолчанию.
  • Что внутри /proc/crypto? Он покажет вам доступные методы шифрования.
  • Кроме того, последние файлы cryptsetup обрабатывают сами циклические файлы, так что вы можете пропустить losttup и позволить cryptsetup обработать его.
  • Если ваша оболочка сохраняет историю, ваша фраза-пароль («abc») может храниться в незашифрованном виде, это не здорово. Это может быть видно psтакже, если в нем перечислены полные командные строки. Использование другого способа передачи ключевой фразы в stdin может быть более безопасным, или использовать файл ключа на защищенном носителе (внешнем USB / устройстве) или в ramfs и т. Д. См. 2.14 в FAQ.
Спасибо за указатели. Я добавлю информацию в мой оригинальный пост. С первым сообщением: `Во всяком случае, из luksDump файл ./encrypted.volume выглядит зашифрованным с помощью aes в режиме xts-plain64 (aes-xts-plain64). По крайней мере все, что записано в него, будет зашифровано, оно не будет затронуто, если вы не сделали luksOpen-ed и не записали в него. Вы имеете в виду, что encrypted.volume действительно зашифровано, несмотря на отсутствие API пользовательского пространства? Я обеспокоен тем, что заголовок Luks говорит об одном, но доступ к данным делает что-то другое; например, открытый текст Paco 6 лет назад 0
Прочитав ссылки, я изменил рецепт следующим образом: `sudo dd if = / dev / zero of = quick.volume bs = 512K count = 100 sudo losttup -f sudo losttup / dev / loop0 quick.volume echo" abc "| supt cryptsetup --debug luksFormat / dev / loop0 echo "abc" | supt cryptsetup - отладка open / dev / loop0 quick sudo dd if = / dev / zero of = / dev / mapper / quick echo "abc" | sudo cryptsetup --debug close quick hexdump quick.volume` Читая hexdump, я вижу искаженные данные после 2 МБ. Так что я думаю, что он на самом деле зашифрован, но каким шифром? Стоит ли верить luksDump, говоря xts-plain64, даже без API пользовательского пространства? Paco 6 лет назад 0
2 МБ - это обычно размер заголовка LUKS, зашифрованные данные начинаются после, поэтому искаженные данные звучат так, как будто они зашифрованы. Я бы поверил в luksDump cryptsetup, или пока он открыт, вы также можете проверить `dmsetup`, он даже покажет фактический ключ шифрования ([fyi может добавить новую фразу-пароль *, не зная * существующего] (https: // superuser. ком / вопросы / 1277948 / как к найти-мои-Люкс-шифрования ключевая фраза-внутри-расшифрованы-файловая система / 1278023 # 1278023)). Похоже, что [crypto API ядра] (https://www.kernel.org/doc/html/latest/crypto/index.html) работает нормально, cryptsetup в порядке, просто нет aes-cbc Xen2050 6 лет назад 0
Наконец, я использовал `dmsetup` для проверки зашифрованного файла. В результате получилось следующее: `chip @ chip: ~ $ sudo dmsetup table --showkeys / dev / mapper / quick 0 98304 crypt aes-xts-plain64 <32BYTENUMBER> 0 7: 0 4096` Теперь я увереннее, что моя информация зашифрован Спасибо за помощь! Paco 6 лет назад 0
Добро пожаловать :) У меня была другая идея, вы могли бы создать небольшой контейнер LUKS на другом компьютере и посмотреть, можно ли на нем читать и записывать в этой системе, затем вернуть его на другой компьютер и проверить новую информацию, или наоборот. Xen2050 6 лет назад 0

Похожие вопросы