2

I am trying to set up an encrypted volume to store files securely. This is done on a NextThingCo pocketchip, but the OS is based on debian so I guessed I would give it a try here first, as my question is more related to dmcrypt than the platform itself (or so I think).

The recipe that I built so far is the following (may be incorrect or overly complicated):

  1. Create a file
  2. Set it up as a loop device.
  3. Do the crypsetup for formatting and open. "abc" is the password, fed through stdin (is this assumption correct?).
  4. Make a filesystem
  5. Mount

So it looks like this:

 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

Now, all this seems to work fine and dandy, that is until I used the --debug parameter (I wanted to try other parameters as well e.g. key-size). And I realized the following messages:

# 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

I tried running the benchmark too:

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

Here is some additional info about the platform and OS:

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

I understand that I would need to recompile the kernel after I set CONFIG_CRYPTO_USER_API_SKCIPHER so the userspace crypto API becomes available. I don't think there is a way around that, is there?

I LuksDump the information about the storage file:

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

However, I have a few questions about the current situation:

  • Is the partition actually encrypted? If so, with which scheme?
    • How to check this on the command line? Trying to dump information about the partition tells me that "there is a LUKS header", but that does not tell me whether the data is encrypted or not.
  • How to solve the ''resource busy'' situation, which would let me use a key size of 512?

Thank you for reading all the way here. Any pointers will be greatly appreciated.

EDIT (08/12/17): - Last lines of 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
Paco
  • 23

1 Answers1

0

Looks like your kernel doesn't support 512-bit keys with aes-xts-plain64, and doesn't do aes mode cbc at all:

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

but that just stops the benchmark, xts is preferred over cbc anyway. I think you could get more modes available by rebuilding/getting a new kernel (or maybe modprobeing, I'm not 100% sure).

There's a little conflicting info about aes with 512-bit keys, this Q on crypto.SE says Why we can't implement AES 512 key size? and concludes it's just not defined/supported, but using --cipher aes-xts-plain64 --key-size 512 works fine for my cryptsetup (v1.7.3) and my /proc/crypto has an xts(aes) entry supporting keysizes 32-64 bytes.

  • Anyway, from luksDump the ./encrypted.volume file looks encrypted with aes in mode xts-plain64 (aes-xts-plain64). At least anything written to it would be encrypted, it'll be untouched if you haven't luksOpen-ed and written to it.
  • ./encrypted.volume is not a separate disk partition, it's just a file/container.

  • You'll use up lots of your entropy using dd to take 100M (512*200?) out of /dev/urandom, and it's unnecessary. Creating the container file using zeros is fine (or just fallocate). Once it's luksFormatted then you fill it with zeros which will get encrypted & written to disk.

  • What's the last 10 lines or so of cryptsetup --help? It'll say what the defaults are.
  • What's in /proc/crypto? It'll show you the available encryption methods.
  • Also recent cryptsetup's handle loop files themselves, so you can skip losetup and let cryptsetup handle it.
  • If your shell saves the history, your passphrase ("abc") could be stored in plaintext, that's not great. It might be visible from ps too, if it lists full command lines. Using another way to get the passphrase to stdin may be safer, or use a keyfile on a secure medium (external USB/device) or in ramfs, etc. See 2.14 in the FAQ.
Xen2050
  • 14,391