Re: Help with eMMC inline encryption

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Mar 17, 2021 at 06:15:54PM +0100, Maxime Ripard wrote:
> Hi Eric,
> 
> I've followed your work to integrate fscrypt for an eMMC, and now that
> it's been merged started to write the support for the Allwinner H6 [1]
> that has an encryption / decryption engine (EMCE, page 332) for the eMMC
> controller (page 495).
> 
> I have some code that does most of the work to enable it and I'm at a
> point where I can run xfstests (so the accesses seem to go through the
> crypto engine, and they decrypt something), but the content of the files
> are off compared to the software implementation.
> 
> My first guess would be to check how the key is setup in the hardware,
> but it's where I'm not really sure what's going on. It looks from the
> cqhci driver that the AES-XTS key has twice the size, and it's written
> in two steps for some reason? [2]
> 
> Since the AES-XTS key size allegedly supported by the driver is 256 bits
> but the key size is 64 bytes, the comment makes sense, but I'm not
> really sure what is happening and what I'm supposed to be doing with
> that key.
> 
> Thanks!
> Maxime
> 
> 1: http://files.pine64.org/doc/datasheet/pine-h64/Allwinner_H6%20V200_User_Manual_V1.1.pdf
> 2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/cqhci-crypto.c#n92

An AES-256-XTS key is 64 bytes; however, internally, the XTS algorithm divides
it into two AES-256 keys.  AES-256-XTS implementations usually take the key as a
single 64-byte value; however, some require that users specify the two halves
separately.  Also, some implementations use incorrect naming, like calling the
first half of the AES-256-XTS key the "key" and the second half the "salt".

Looking at section 3.15.4 in the document you linked to, that looks to be the
case here.  You probably need to write the 64-byte AES-256-XTS key to
EMCE_KEY0..7 and EMCE_SALT0..7.

If the ciphertext still doesn't match, you'll need to check the other things
that you could be going wrong, including:

  * Endianness and order of the key words.  For example, if the hardware expects
    the key words in big endian byte order and/or the key words in reverse
    order, you'll need to take that into account when writing the registers so
    that the hardware understands the intended 64-byte AES-256-XTS key.

  * Mapping of DUN (data unit number) to IV.  It should be little endian.  For
    example DUN 1000 should result in the hardware using exactly the IV
    u8 iv[16] = {0xe8, 0x03, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}.

  * Data unit size.  The hardware must use exactly
    data_unit_size bytes for the AES-256-XTS message size, and it must increment
    the DUN by exactly 1 after each data_unit_size bytes encrypted/decrypted.
    Note, fscrypt uses 4096 bytes for data_unit_size.

- Eric