RT1020/RT1050 - Why is the PRDB encrypted differently to the KIB and app?

[rshipman]

Hi.

I am using the RT1020, but I am told this document applies:

Security Reference Manual for the i.MX RT1050 Processor, Rev. 1, 04/2018

Regarding the following notes found in this section:

Section 3.6.2.3 Key Info Block, pages 78-80

“

NOTE

• KIB1 is encrypted to EKIB1 using BEE_KEY1 provisioned in eFUSE

• KIB0 is encrypted to EKIB0 using BEE_KEY0 provisioned in eFUSE

“

“

NOTE

• PRDB0 is encrypted using AES_KEY and IV in EKIB0, while the encrypted region defined in PRDB0 is encrypted by the key source specified in BEE_KEY0_SEL.

• PRDB1 is encrypted using AES_KEY and IV in EKIB1, while the encrypted region defined in PRDB1 is encrypted by the key source specified in BEE_KEY1_SEL.

”

Questions:

1. So first of all does BEE_KEY1 = BEE_KEY1_SEL and BEE_KEY0 = BEE_KEY0_SEL?
2. Why is the PRDB block encrypted with the key and iv in the KIB blocks, when everything else is encrypted using the BEE_KEYn_SEL keys? Why not just use BEE_KEYn_SEL for everything?

Many thanks and kind regards,

Ronnie

[Ric10]

Hi,

I enter the discussion by asking politely you for clarification.

the PRDB block is encrypted using AES KEY and IV provided in a Key Info Block (KIB). I red the security reference manual and the AN12079 but i don't understand  who provide AES KEY and IV in KIB. 

I am using MCU Boot Utility to generate the encrypted boot image. Who populates these informations in KIB. Can i specify these keys with command lines?

Thanks in advance

[mjbcswitzerland]

Hi

The uTasker project also provides tools for generating the encrypted image:
https://www.utasker.com/forum/index.php?topic=1445.0

uTaskerConvert.exe plainCode.bin aes128_coded_XiP.bin E=128B-60020400 "aes128 secret key"  "initial vector"

encrypts the input plainCode.bin with the AES128 key and vector (here passed as strings, which are popular since they are easier to handle than hex numbers).

Output aes128_coded_XiP.bin is linked to 0x60020400 (to work with OTA uploading and a boot loader) but 0x60000000 would be used to link to a standalone XiP application (04 0x70000000 on i.MX RT 1064)
When working with OTFAD E=128 (without the B - for BEE) is used.
E=256 will encrypt with AES256 for higher security and other techniques that don't directly use the on-the-fly decryption engine.

I have never had access to the security documents but managed to reverse engineer the technique from tidbits in older documents of similar modules and some educated guessing (and a bit of trial -and-error) for the BEE module and also the OTFAD module.

The uTasker project includes BEE and OTFAD simulators which allow the internal process to be verified and also testing of all encryption/decryption steps in the process (with warning when things are not set up correctly, etc.). This allows full understanding of the working and where the keys and vectors are taken from, as well as how the nonce is generated in the addressing process.

https://youtu.be/o7hQbOqhJoc show the complete process being tested/verified on an i.MX RT 1062.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1062.html

[jeremyzhou]

Hi ,

Thank you for your interest in NXP Semiconductor products and

for the opportunity to serve you.
1) So first of all does BEE_KEY1 = BEE_KEY1_SEL and BEE_KEY0 = BEE_KEY0_SEL?
-- Yes.
2) Why is the PRDB block encrypted with the key and iv in the KIB blocks, when everything else is encrypted using the BEE_KEYn_SEL keys? Why not just use BEE_KEYn_SEL for everything?
-- Enhancing the security level for the encrypted XIP boot.

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

[rshipman]

Thanks for your reply Jeremy.

Sorry I had not absorbed that the PRDBs contain the nonce/counter used to encrypt the application using AES-CTR.

So:

• A KIBn is encrypted uing AES-ECB, with the key from BEE_KEYn_SEL.
• A PRDBn is encrypted using AES-CBC, with the key and IV from KIBn.
• A data region is encrypted using AES-CTR, with the key from BEE_KEYn_SEL and a nonce/counter from the PRDBn FAC info.

Questions:

1. Please can you confirm this is correct?
2. In the FAC info block, is the field called 'counter' (0x10 - 0x1F) the input Nonce?
3. What does it mean by "During encryption and decryption, the nonce is as show in Table 3-15 ("FAC Regions" table)." The table shows that the 'FAC Region Start [31:4]' is in the bits we need to set to 0. What is the purpose of this?
4. Also will the bits 'Counter [127:32]' always equal the input Nonce we have configured, i.e. nothing changes it?
5. Do the bits 'FAC Region Start [31:4]' revert to zero after the encryption/decryption operation?

Many thanks and kind regards,

Ronnie

[jeremyzhou]

Hi Ronnie,

Thanks for your reply.
1) In the FAC info block, is the field called 'counter' (0x10 - 0x1F) the input Nonce?
-- The 'counter' contains the input Nonce.
2) What does it mean by "During encryption and decryption, the nonce is as show in Table 3-15 ("FAC Regions" table)." The table shows that the 'FAC Region Start [31:4]' is in the bits we need to set to 0. What is the purpose of this?
-- The FAC Region Start [31:4] can replace the zero-in bits: [27:0]
3) Also will the bits 'Counter [127:32]' always equal the input Nonce we have configured, i.e. nothing changes it?
-- Yes.
4) Do the bits 'FAC Region Start [31:4]' revert to zero after the encryption/decryption operation?
-- Yes, I think so.

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