I'd like to implement disk encryption on an i.MX6-based device. I've tried TrueCrypt, dm-crypt/LUKS, and ecryptfs(passphrase) under Ubuntu, but there's a huge performance with all of them even with the MX6Q. Is there a way to use the MX6's AES acceleration to provide a fast disk encryption solution?
I'm using Yocto v1.7 and cryptsetup doesn't take any CAAM accelerated encryption cipher, such as cbc(aes).
cryptsetup --cipher="cbc(aes)" create blahfs /media/flash/blah
Enter passphrase: ********
device-mapper: reload ioctl on failed: Invalid argument
device-mapper: table: 254:0: crypt: Bad cipher specification
device-mapper: ioctl: error adding target to table
Your suggestion doesn't guarantee that it uses the CAAM. So, the question is still unsanswered? I tried to find out and it actually didnt work.
There are other things that are to be considered
I hope it helps.
I'm using dm-crypt with default (so I'm using XTS mode) on imx6UL. I made several tests on writing speed on the encrypted partition. I tried several different supports (sd-card...NFS folder... tmpfs) and I always obtained a writing speed of 5.5 MB/s. With cryptsetup benchmark i obtain a useful encryption speed of 9MB/s. This can be related to a wrong setting or it's a common loss of speed due to other operations different from the simple AES-sencryption. (I just ask you if you have tried this before and have observed something similar).
Then I don't understand how can I set the usage of HP instead of LP CAAM, and how can I check what dm-crypt is really using now? Thanks
Ideal hardware enabled build chain:
cryptsetup --> OpenSSL --> cryptodev (facilitates hardware engines to be used)
* HP CAAM or LP CAAM
You cannot set them. It's a hardware feature. Read the Security Reference manual of your CPU. Mine is iMX6q and it has Low Power CAAM. Low Power CAAM doesn't support XTS cipher code which is the default of cryptsetup's Linux Unified Key Setup (LUKS). If you modify this to use other cipher modes than XTS than there is a chance of using the hardware CAAM.
* OpenSSl vs. gCrypt
gCrypt wasn't written with hardware acceleration in mind (The author of gCrypt said this). It supports hardware acceleration now but not special hardware modules like CAAM. It supports hardware acceleration through seperate "instruction sets" like Intel's AES-NI or ARM's NEON.
On the other hand, OpenSSL supports hardware acceleration through hardware modules like CAAM. These are called engines and for this OpenSSL has to be build with Cryptodev.
* cryptsetup benchmarks
It depend on how cryptsetup is build. Is it build with OpenSSL or with gCrypt? Build it with OpenSSL and test it with the one build with gCrypt. You will have different benchmarks. I remember doing it few years ago.
If you are using default XTS mode and have a LP CAAM or HP CAAM but didn't use cryptodev then you are not using hardware acceleration. I can confirm you that
In these weeks I tried to change kernel, now I'm sure to have the cryptodev working.
I tested it with: "openssl speed -evp aes-128-cbc -engine cryptodev" and I can see the difference with the same command without the cryptodev.
engine "cryptodev" set.
Doing aes-128-cbc for 3s on 16 size blocks: 44868 aes-128-cbc's in 0.16s
Doing aes-128-cbc for 3s on 64 size blocks: 44355 aes-128-cbc's in 0.19s
Doing aes-128-cbc for 3s on 256 size blocks: 35367 aes-128-cbc's in 0.35s
Doing aes-128-cbc for 3s on 1024 size blocks: 30326 aes-128-cbc's in 0.15s
Doing aes-128-cbc for 3s on 8192 size blocks: 10236 aes-128-cbc's in 0.04s
OpenSSL 1.0.2h 3 May 2016
I'm also sure that the created disk uses as backend openssl with:
"cryptsetup luksDump <your luks device> --debug | grep backend"
# Initialising device-mapper backend library.
# Crypto backend (OpenSSL 1.0.2h 3 May 2016) initialized in cryptsetup library
But also if openSSL seems to work fine cryptsetup benchmark achieves same results as before, and also testing the writing speed with
time dd bs=50MB count=1 if=/dev/zero of=/home/encryptroot/provaNF conv=fsync
I obtain always around a speed of 5/6 MB/s.
Do you know if there are other thing that I can change (I'm pretty sure that the writing is still not using caam).
It is very important to know that /dev/zero is a software (kernel based) zero generator.
CAAM FIPS-140 certified Random Number Generator:
If you have CAAM random number generator enabled in your kernel then it is available as /dev/hwrng (or something like that, I don't remember it anymore. Please check it. CAAM was causing problems for us and so, we disabled it.). LUKS by default uses /dev/urandom. So, one has to force cryptsetup to use /dev/hwrng and then the creation of an encrypted block device is hardware accelerated. Currently cryptsetup only supports /dev/random (--use-random) which is very slow and /dev/urandom which is faster. Therefore, if you want to use the CAAM's /devhwrng, then you have to change the configuration of cryptsetup and introduce changes to enable other random number providers and build you own cryptsetup. This is the only way you can use CAAM's /dev/hwrng. This will tremondously increase the speed of creation of a LUKS partition.
This is just one step. I will update this later. These steps would include how to use to CAAM hardware acceleration.
You could try to use the CAAM I guess. Right now (and if I am not wrong) applications (like OpenSSL) are not able to take advantage of it so you could try the performance with some C code. But that's not an easy thing to do for the moment, waiting a full support of CAAM is a better option in my opinion.
I don't know how disk encryption works, does it encrypt the full disk like one archive or every single file ? If that's the latter SW encryption should be definitely the better option anyway.
After some experimentation, I found out that CAAM causes cryptsetup/LUKS
to break -- creating the filesystem hangs indefinitely. After I disable
CAAM in the kernel, LUKS encryption works beautifully -- though it slows
my file system performance from ~150 MB/s to ~20 MB/s.
I am also having this problem. If I set CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API in my system and then try to create an encrypted disk, my system hangs. If I don't set this (in which case I assume the software implementation goes into effect), everything works fine. Although I must admit it's not really noticeably slow either, so for now I am going to limp along with the software encryption.
I have applied the suggested kernel patches (although maybe someone could give me the list of patches applicable to this just to make sure?).
I'm using the 3.0.101 LTIB kernel from the 3.0.101-4.1.1 distro.
I am also interested if that has been any movement on this issue as we would like to use the CAAM for dmCrypt/LUKS to encrypt sensitive data on a i.MX6 system?
I've used TrueCrypt successfully. LUKS (using cryptsetup) seems to work
on small partitions, but on larger ones, mkfs hangs up, so something
isn't working right there. With respect to CAAM, it does seem like it's
not well integrated yet.
Different encryption solutions work differently. TrueCrypt and LUKS
encrypt the entire device using device-mapper to provide the interface
to the encrypted device. There's also ecryptfs which is a layered file
system that encrypts file contents (though it can be set up to also
encrypt file system metadata).
If anyone has found a good solution for this, let me know!
I have reproduced the same scenario using aes-ecb with the command below
cryptsetup -v --cipher aes-ecb --key-size 256 --hash sha256 --iter-time 2000 --use-urandom --verify-passphrase luksFormat test_file
Have you made any follow-up regarding this issue or have you find any fix?