i.MX RT 1011 OTFAD key/counter confusion

[mjbcswitzerland]

Hi All

I need to be able to check some data stored in QSPI that is being decrypted (on-the-fly) using the OTFAD. To do the check I need to use the OpenSSL AES128-CTR method in software on  a copy of  the same un-encryped data at a different location.

The confusion is in how the AES128 key and its nonce/counter value is actually stored in the OTFAD registers so that they correctly relate to the OpenSSL format.

Example:
OTFAT set with

    encryptionConfig.key[0] = 0x0d0e0f10;
    encryptionConfig.key[1] = 0x090a0b0c;
    encryptionConfig.key[2] = 0x0x060708;
    encryptionConfig.key[3] = 0x01020304;

    encryptionConfig.counter[0] = 0xccddeeff;
    encryptionConfig.counter[1] = 0x8899aabb;

That means that the AES128 key is (in byte format as needed by OpenSSL)

0x10, 0x0f, 0x0e, 0x0d, 0x0c, 0x0b, 0x0a, 0x09, 0x08, 0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01

according to comments in the OTFAT code reference.

AES128-CTR uses a 128 bit (16 byte) nonce + counter (normally the nonce is the upper 64 bits and the counter the lower 64 bits) but the OTFAT only accepts 64 bits (counter). Therefore I have tried setting the nonce (upper 64 bits) to all zeros but the OpenSSL method (which otherwise matches with reference) doesn't give the same value as the OTFAD.

For example if the OTFAD is enabled and decrypts the QSPI content starting at 0x60000000 (start of area) and the QSPI contains all 0xffffffff the decrypted content is

The OpenSSL method using the same key and nonce/counter set to
0xff, 0xee, 0xdd, 0xcc, 0xbb 0xaa 0x99, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

gives

which matches exactly with on-line AES128-CTR calculators (eg. https://cryptii.com/pipes/aes-encryption)

This suggest that the upper 64 bits (nonce) may be set to a fixed value that is not 0, or that there is some different ordering of the key or counter.

Does anyone know more details or have been able to match up the OTFAD method with firmware methods??

Regards

Mark

[jeremyzhou]

Hi  Mark Butcher ,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you refer to the otfad_decryp demo in the SDK library.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[mjbcswitzerland]

Hi Jeremy

I was referencing the decrypt demo in the SDK but it doesn't contain any of the necessary information.

However I found that there is documentation in the Kinetis K82 (that contains a very similar OTFAD) user manual which allowed me to resolve the issue:

The 128 bit nonce/counter is generated internally to the OTFAD by concatenating the two 32 bit counter register values with an XOR of the same two to give 96 bits and then it further concatenates also the QSPI flash access address (long word aligned address) to give the full 128 bits. The endian ordering is a little mixed up (not the same between the address and the registers) which is not correctly displayed in the manual but with a little trial and error the correct setup was found so that I can now do the same AES128-CTR decryption and encryption in firmware and via OTFAD.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]