Hi All
I am doing the same as here: How can I create encrypted data for i.MX-RT 1050's BEE ?
but with the 1015.
My tests are based on the "evkmimxrt1015_bee" SDK example.
There are a couple of issues which are worth mentioning.
1. The AES128 key is not loaded normally in the demo and it explains it so:
/* Set AES user key for region0. BEE_KEY0_SEL fuse must be set to SW-GP2 to be able to use this feature. */
However this seems wrong since if SW-GP2 is used it no longer allows the register value to be used so I removed this and then I could set the AES128 key using the function that was otherwise disabled. It looks to be inverted.
2. The Nonce used in the example is 0xff, 0xee, 0xdd, 0xcc, 0xbb, 0xaa, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00 but, as also pointed out in the link above, the first 4 bytes need to be set to 0x00 in order for the BEE decryption to work as expected. With the demo values it decrypts but what it is actually using to decrypt is unknown - the decoding start address is used in these locations (shifted by 4 as also noted in the link above) and when they are not 0 it somehow mixes up the address and the values but I could work out how (eg. XOR, which it isn't though)
Then I get the big problem.
This is how it decrypts the content of the QSPI from address 0x60000000 (when its content is all 0xffs).
Using software libraries (like Open SSL as in the link) and checking with on-line tools (which agree with each other) the actual decryption using this AES28 key in CTR mode and the nonce (with the start address substituted as explained in the above link) is:
The yellow values match but in between they are off.
I get identical results using MCUXpresso debugger (also stepping and refreshing the values remain stable) or if I copy them in code to a RAM buffer for checking later. I also add delays between reading each value to the buffer to ensure there is no race state involved when reading following bytes/words (displaying a bytes or words makes no difference to the values).
Normally an off-bit in the key or nonce causes "everything" to look random but in this case half of the values are correct and half are not. How can this be explained and what can be done to make the decryption match the real AES128-CTL result?
Regards
Mark
Hi Kerry
To reproduce the 'problem':
1. Import the "evkmimxrt1015_bee" example
2. Change the first 4 bytes of the aesNonce[] from 0xff, 0xee, '0xdd, 0xcc to 0x00, 0x00, 0x00, 0x00
You need a board that still has the BEE_KEY0_SEL eFUSE set to its default value (b00).
Erase its QSPI flash - at least so that the start (0x60000000) is blank (eg. using NXP-MCUBootUtility)
3. Enable the code that sets the AES128 key (BEE_USE_USER_KEY)
4. Set a break point at the line BEE_Deinit(BEE);
and run to it.
5. Now look at the memory at 0x60000000 (Monitor Memory) and you will see
6. Go to the https://cryptii.com/pipes/aes-encryption
and set the AES128-CTR decode setting:
Input "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff "
KEY "0102030405060708090a0b0c0d0e0f10"
IV "00112233445566778899aabb06000000" <-----(0x600000 >> 4) see link!
Which will decrypt the input to
It is seen that the decrypted content is correct for every 2 long words and not for all.
Regards
Mark
P.S. Note that on 1011 (with OTFAD) it is possible to see the expected decrypted content using a similar technique although the OTFAD accepts only 64 bits for the Nonce. The Complete Nonce uses by the decryptor is made up of the 2 Nonce registers concatenated with the XOR of the two Nonce registers and then concatenated with the QSPI access address. In the case of the BEE (see other link) the complete Nonce is 3 of the Nonce registers concatenated with the access address (0x60000000 in test case) shifted by 4 bits.
The OTFAD operation is documented in documents that I have found for the Kinetis family and the link that I have quoted is where I found the 4 bits address shift.
Hi Mark Butcher,
Does IV in the https://cryptii.com/pipes/aes-encryption :
is the aesNonce data?
static const uint8_t aesNonce[] __attribute__((aligned)) = {0x00, 0x00, 0x00, 0x00, 0xbb, 0xaa, 0x99, 0x88,
0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00};
If yes, why the IV set 00112233445566778899aabb06000000, but aesNonce is:0x00, 0x00, 0x00, 0x00, 0xbb, 0xaa, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00
Now, on my side, the key is select user key, not the master key, and I also burn the fuse which is used key engine 0, not 1. Do you have any detailed step with my situation to reproduce your issues?
My swGp2 fuse area is also burned, just like the MCUBootUtility tool user key data.
Whether this user key data 16 bytes is the aeskey？
static const uint8_t aesKey[] __attribute__((aligned)) = {0x10, 0x0f, 0x0e, 0x0d, 0x0c, 0x0b, 0x0a, 0x09,
0x08, 0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01};
Sorry about it, about the detail knowledge, I am still learning, in the previous time, I just do the BEE application.
Or, if I find new MIMXRT1015-EVK board, without burn any fuse, can I test your required BEE function directly? We don't have too many board to do the fuse burning. Now my side, have a MIMXRT1015-EVK board which already burn the user key, normally do the BEE app download and testing.
If your original issue can be tested without any fuse burning, then I will find a new board to test it, just discard to use my BEE secured board to test your issues.
Best Regards,
Kerry
Hi Mark Butcher,
I have BEE secured board MIMXRT1015-EVK, which already write the fuse like this:
Can I also do your desired testing without other fuse modification?
These days, I will test your situation on my side.
Sorry for the delayed reply, because recently, really a lot of cases need to do the testing.
Thanks a lot for your understanding.
Best Regards,
Kerry
