Help with eMMC inline encryption

Help with eMMC inline encryption

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help with eMMC inline encryption

[Eric Biggers]

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

Re: Help with eMMC inline encryption

[Maxime Ripard]

Hi Eric,

Thanks for your answer

On Wed, Mar 17, 2021 at 11:33:46AM -0700, Eric Biggers wrote:
> 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.

I've added the second part into the "salt" registers, and I'm still
getting the same result: the test generic/592 fails with a mismatch.

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

Thanks for the suggestion, however any combination of little/big endian
and natural/reverse order doesn't change the outcome.

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

Indeed, I somehow missed that you were setting the DUN in
cqhci_crypto_prep_task_desc, and I'm guessing that's where my issue
lies: it doesn't look like there's any field to set the DUN in the
controller, which doesn't make much sense to me.

The documentation is pretty short, but it looks like it might be
inferred from the MMC commands arguments (the Access Mode bit in the MMC
controller, page 517). Would that make sense?

Thanks
Maxime

Re: Help with eMMC inline encryption

[Eric Biggers]

On Mon, Mar 22, 2021 at 04:53:18PM +0100, Maxime Ripard wrote:
> 
> Indeed, I somehow missed that you were setting the DUN in
> cqhci_crypto_prep_task_desc, and I'm guessing that's where my issue
> lies: it doesn't look like there's any field to set the DUN in the
> controller, which doesn't make much sense to me.
> 
> The documentation is pretty short, but it looks like it might be
> inferred from the MMC commands arguments (the Access Mode bit in the MMC
> controller, page 517). Would that make sense?
> 

If your hardware has no way to specify a starting DUN (or starting IV) for each
request, then presumably it automatically chooses IVs based on the location of
the data on-disk.

This way of IV generation is problematic for several reasons, and it doesn't
match the UFS and eMMC standards.  So blk-crypto and fscrypt don't support this
type of hardware.

- Eric

Re: Help with eMMC inline encryption

[Maxime Ripard]

Hi Eric,

On Mon, Mar 22, 2021 at 10:02:52AM -0700, Eric Biggers wrote:
> On Mon, Mar 22, 2021 at 04:53:18PM +0100, Maxime Ripard wrote:
> > 
> > Indeed, I somehow missed that you were setting the DUN in
> > cqhci_crypto_prep_task_desc, and I'm guessing that's where my issue
> > lies: it doesn't look like there's any field to set the DUN in the
> > controller, which doesn't make much sense to me.
> > 
> > The documentation is pretty short, but it looks like it might be
> > inferred from the MMC commands arguments (the Access Mode bit in the MMC
> > controller, page 517). Would that make sense?
> > 
> 
> If your hardware has no way to specify a starting DUN (or starting IV) for each
> request, then presumably it automatically chooses IVs based on the location of
> the data on-disk.
> 
> This way of IV generation is problematic for several reasons, and it doesn't
> match the UFS and eMMC standards.  So blk-crypto and fscrypt don't support this
> type of hardware.

Too bad then :)

Thanks for your help

Maxime