Hardware accelerated disk encryption

[kguilbert]

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?

Thanks!

[rmsaad]

Just leaving this comment so no one else has to spend as much time as I did trying to get this to work.

This is not possible on newer versions of the Linux Kernel. The CAAM drivers have the CRYPTO_ALG_ALLOCATES_MEMORY flag which will prevent dm-crypt from using them.

source: https://github.com/torvalds/linux/commit/cd74693870fb748d812867ba49af733d689a3604

[bernardo]

Hi,

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

Any idea?

Thanks,

Bernardo

[deanmatsen]

Try --cipher="aes-cbc-plain"

[satyadamarla]

Hello Dean,

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.  

EDIT1: 

There are other things that are to be considered

1. cryptsetup backend: OpenSSL or gCrypt
   • Through OpenSSL, Hardware acceleration (CAAM) is possible only through cryptodev (/dev/crypto) module. This module has to be compiled seperately for the kernel.
   • gCrypt has some hardware accelration but doesn't use CAAM, it uses NEON or ARMv8 (64-bit) crypto modules which are part of the processor.
   • It is important to note that CAAM is a special hardware whereas NEON, etc are part of the processor with different instruction sets (This is what I understood from my research and the way it works. Correct me if I am wrong)
   • Also OpenSSL backend is faster than gCrypt. I can guarantee this as I made tests. gCrypt is the default backend for cryptsetup but if you want a faster one please use OpenSSL over gCrypt. 
2. Device Encryption: 
   
   • AES uses two cipher modes CBC or XTS for device encryption.
   • There are two types of CAAM: Low Power CAAM and High Power CAAM. My device iMX6 Quad has is LP CAAM. It doesn't provide support to XTS and only CBC cipher mode is supported. HP CAAM does provide support XTS cipher mode.
   • LUKS uses XTS cipher mode by default but can be forced to use CBC cipher mode through "--cipher or -c" in cryptsetup. LUKS is the best for cryptsetup. So, if you have LP CAAM then your hardware acceleration for cryptsetup isn't of any use here.

I hope it helps.

Greets,

Satya

[giuliodominutti]

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

[satyadamarla]

Ideal hardware enabled build chain:

cryptsetup  --> OpenSSL  --> cryptodev (facilitates hardware engines to be used)

Answers:

* 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.

* cryptodev

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

Greets,

Satya

[giuliodominutti]

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
version 1.7.0.

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).

[satyadamarla]

Hello,

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.

Good Luck,

Satya

[varsha_a]

Hi

Is there any further update on this ?

I have similar requirement and looking for solution.

Thanks and regards

Varsha

[Yuri]

Hello,

  Please create request to get more information about disk encryption,

using CAAM-accelerated dm-crypt.

Regards,

Yuri.

[ofer_livny]

Hi

Did any of you guys make some progress on this matter?

I would really like to use CAAM with cryptsetup. Is this doable?

Thanks,

Ofer

[AlbertT]

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.

Best regards,

Jocelyn

[kguilbert]

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.

-Kyle

[deanmatsen]

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.

Regards,

Dean

[davidwilliams]

Hi,

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?

David

[kguilbert]

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!

-Kyle

[catalinneagu]

Hi Kyle,

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?

Thank you,
Catalin