* Help with eMMC inline encryption @ 2021-03-17 17:15 Maxime Ripard 2021-03-17 18:33 ` Eric Biggers 0 siblings, 1 reply; 5+ messages in thread From: Maxime Ripard @ 2021-03-17 17:15 UTC (permalink / raw) To: Eric Biggers; +Cc: linux-mmc, Ulf Hansson [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with eMMC inline encryption 2021-03-17 17:15 Help with eMMC inline encryption Maxime Ripard @ 2021-03-17 18:33 ` Eric Biggers 2021-03-22 15:53 ` Maxime Ripard 0 siblings, 1 reply; 5+ messages in thread From: Eric Biggers @ 2021-03-17 18:33 UTC (permalink / raw) To: Maxime Ripard; +Cc: linux-mmc, Ulf Hansson 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with eMMC inline encryption 2021-03-17 18:33 ` Eric Biggers @ 2021-03-22 15:53 ` Maxime Ripard 2021-03-22 17:02 ` Eric Biggers 0 siblings, 1 reply; 5+ messages in thread From: Maxime Ripard @ 2021-03-22 15:53 UTC (permalink / raw) To: Eric Biggers; +Cc: linux-mmc, Ulf Hansson 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with eMMC inline encryption 2021-03-22 15:53 ` Maxime Ripard @ 2021-03-22 17:02 ` Eric Biggers 2021-03-23 10:53 ` Maxime Ripard 0 siblings, 1 reply; 5+ messages in thread From: Eric Biggers @ 2021-03-22 17:02 UTC (permalink / raw) To: Maxime Ripard; +Cc: linux-mmc, Ulf Hansson 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Help with eMMC inline encryption 2021-03-22 17:02 ` Eric Biggers @ 2021-03-23 10:53 ` Maxime Ripard 0 siblings, 0 replies; 5+ messages in thread From: Maxime Ripard @ 2021-03-23 10:53 UTC (permalink / raw) To: Eric Biggers; +Cc: linux-mmc, Ulf Hansson 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-23 10:54 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-17 17:15 Help with eMMC inline encryption Maxime Ripard 2021-03-17 18:33 ` Eric Biggers 2021-03-22 15:53 ` Maxime Ripard 2021-03-22 17:02 ` Eric Biggers 2021-03-23 10:53 ` Maxime Ripard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).