AN12079 example: Why is the key source fixed to 0?

[rshipman]

Hi,

I have some questions regarding this document:

Document: AN12079.pdf

Section: 3.3.2. Generate SB file for FlexSPI NOR image encryption and programming

The bd file sets up the PRBD0 block like this:

#3 Prepare PRDB options

# 0xe0120000 is an option for PRDB contruction and image encryption

# bit[31:28] tag, fixed to 0x0E

# bit[27:24] Key source, fixed to 0 for A0 silicon

# bit[23:20] AES mode: 1 - CTR mode

# bit[19:16] Encrypted region count

# bit[15:00] reserved in A0

load 0xe0120000 > 0x4000;

# Region 0 start

load 0x60001000 > 0x4004;

# Region 0 length

load 0x00001000 > 0x4008;

# Region 1 start

load 0x60002000 > 0x400c;

# Region 1 length

load 0x0000e000 > 0x4010;

# Program PRDB0 based on option

enable flexspinor 0x4000;

Questions:

1. What does it mean by the line: ‘fixed to 0 for A0 silicon’
2. How do I use this file to set up PRDB1?

Thanks and regards,

Ronnie

[Sabina_Bruce]

Hello Ronnie,

Hope you are doing well.

1. The A0 silicone versions will have a fixed value of 0 for this section. Depending on which microcontroller you are using, you can check the errata to see how many versions there are at the moment. Usually A0 is the very first version that comes out. For example in the RT1050 errata you will see there are A0 and A1 versions. 

2. You can find more details in the Security Reference Manual (you will need access by same person who provided the above application note), as well as the MCUX Flashloader Reference Manual (within the doc folder) in section 9.2.1.

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

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

----------------------------------------------------------------------------------------------------------------------- 

[rshipman]

Thanks for your reply Sabina.

1. I actually knew what A0 means. It was the reason why the field is fixed to 0 in version A0 that I was interested in.

2. The document referred to does not reference PRDB1 at all, and PRDB0 only once. However there is this interesting sentence: “Be aware that Flashloader only supports image encryption and programming for the first encrypted region using OTPMK/SNVS key”.

So does that mean either:

1. Only PRDB0 is supported?
2. PRDB0 and PRDB1 are supported but can only use the OPTMK/SNVS key, and not the SW_GP2 key?
3. PRDB0 and PRDB1 are supported but only PRDB0 can use the OPTMK/SNVS key?

And is any of this a silicon limitation? Or is it just the flashloader that has this limitation, and the silicon can use PRDB0 and PRDB1 with OTPMK/SNVS or SW_GP2 in any combination?

Regards,

Ronnie

[Seif]

Hello rshipman,

I just would like to verify that you got access to the security reference manual (SRM), since my colleague Sabina mentioned it in the previous comment ? please tell me if you don't have it.

In the document you will see that both are mentioned and the difference is explained.

Another screenshot from the AN: 12079

I will let nxf51209 follow up with your questions.

Best regards

Seif

[rshipman]

Hi Seif, 

Thank you for your reply.

Yes I do have access to both those documents, even though they are for the RT1050. I am actually working on the RT1021 (RT1020-EVK) not the RT1050. I'm told most of what is in those documents applies, but there are features that the RT1050 supports that are not fixed on the RT1020 silicon.

So yes, the PRDB0/PRDB1 are optional, although you do need at least one to get XIP encryption working afaik.

PRDB1 takes precedence over PRDB0 - what does this mean exactly?

E.g. Does this only matter if there is overlap in the regions being encrypted? So if they do overlap they get decrypted twice?

I understand why you might need two PRDB blocks, one for different software providers. And so one would provision the flash with one PRDB region and the second would used the other PRDB.

I still don't understand how the XIP Encryption example in AN12079 works though. It sets BEE_KEY1_SEL to b11, but does not set up the PRDB1 block. It does set up the PRDB0 block and also sets BEE_KEY0_SEL to b10. Which makes sense if you are only interested in PRDB0, but why set BEE_KEY1_SEL to b11 as well, and not set up the PRDB1 block? If the RT1020 cannot find a valid PRDB1 block it should just generate a HAB error and stop. So what am I missing? One way this could work is if the RT1020 ROM interprets the SW_GP2 setting - which is zero - as 'ignore the PRDB1 block'.

Kind regards,

Ronnie

[rshipman]

I've had another look at the documentation:

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

3.6.2.5 Encrypted XIP Flow

If the PRDB is invalid it just ignores it.

However what happens if the KIB is invalid? I guess it will still decrypt it, end up with a garbage key and IV and then decrypt the PRDB which will also become garbage. So bottom line is, if the BEE_KEYn_SEL is set but the PRDB is invalid it is ignored. Can somebody please confirm my understanding.

So if my understanding is correct, (ie. if the PRDB is missing/invalid then it is ignored), that would explain why the example in AN12079.pdf works. So why did they set BEE_KEY1_SEL = b11?

However I have a situation where I have used BEE_KEY0_SEL = BEE_KEY1_SEL = b10 and that refuses to boot with just one PRDB. It does boot if I have two PRDBs, but does not observe the encrypted XIP setting (GPIO not fuse). Perhaps I've done something wrong. I will look again.

In the meantime, please confirm my understanding is correct, and also see if you can find out why they set BEE_KEY1_SEL = b11.

Many thanks.

[rshipman]

I figured out why the BEE_KEY0_SEL = BEE_KEY1_SEL = b10 failing case was failing. I had the BT_FUSE_SEL fuse set. So it was always reading the Encrypted XIP fuse and not the GPIO override. So I set the Encrypted XIP fuse and hey presto XIP encryption works on that board now. Great.

So I am left with these questions:

1. Please confirm my understanding: If the KIB is invalid/missing, the RT1020 will still attempt to boot, but it will be expecting everything in plaintext. This is the same as the case when the PRDB is invalid/missing. This is actually what I observe to be the case, I just would like it confirmed as the expected behaviour.

2. Why did they set BEE_KEY1_SEL = b11 in the example in AN12079.pdf, if they only set up PRDB0?

Many thanks and regards,

Ronnie

[Sabina_Bruce]

Hope you are well. I am confirming this  information internally. I will update you as soon as possible.

Best Regards,

Sabina