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.
OTFAT set with
encryptionConfig.key = 0x0d0e0f10;
encryptionConfig.key = 0x090a0b0c;
encryptionConfig.key = 0x0x060708;
encryptionConfig.key = 0x01020304;
encryptionConfig.counter = 0xccddeeff;
encryptionConfig.counter = 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
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??