Strange BEE Decryption on i.MX RT 1015 (and demo discrepancies)

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange BEE Decryption on i.MX RT 1015 (and demo discrepancies)

126 Views
Specialist V

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

pastedImage_2.png

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:

pastedImage_4.png

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

Labels (1)
Tags (3)
0 Kudos
5 Replies

5 Views
NXP TechSupport
NXP TechSupport

Hello Mark Butcher

  Thanks a lot for your valuable question.

   Could you please also tell me the detail step to reproduce your issues with evkmimxrt1015_bee project?

   Do you burn your key fuse on your side?

   Please let me know the detail steps to reproduce the issues, then I can reproduce it and check more details.

Thanks a lot for your understanding.

Best Regards,

Kerry

0 Kudos

5 Views
Specialist V

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

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

pastedImage_4.png

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.

0 Kudos

5 Views
NXP TechSupport
NXP TechSupport

Hi Mark Butcher,

   Does IV in the https://cryptii.com/pipes/aes-encryption  :

pastedImage_2.png

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.

  pastedImage_1.png

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

0 Kudos

5 Views
NXP TechSupport
NXP TechSupport

Hi Mark Butcher,

  I have BEE secured board MIMXRT1015-EVK, which already write the fuse like this:

pastedImage_1.png

pastedImage_2.png

pastedImage_3.png

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

0 Kudos

5 Views
Specialist V

Hello Kerry

Yes, the test is also possible when the BEE channel is changed from 0 to 1, in order to use a key loaded to the key register.

It is also possible when SW_GP2 is configured/used as long as the AES128 key is known. In this case the BEE_USE_USER_KEY option is disabled (since the AES128 key is already taken from SW_GP2) and the used key is inserted into the on-line AES128-CTR tool.

Regards

Mark

0 Kudos