LPC55 CMPA BLOCK_SET_KEY and SB2

[kamii]

I'm using the 1B version of LPC55S69.

When setting the BLOCK_SET_KEY to 01b (Disable PUF Key Code generation) of the SECURE_BOOT_CFG in the CMPA, blhost's receive-sb-file can't work with aborting.

If we'd like to use receive-sb-file, do we have to set the BLOCK_SET_KEY to 00b (Allow PUF Key Code generation)?

In my testing, when setting BLOCK_SET_KEY=00b and BLOCK_ENROLL=01b, SEC_BOOT_EN=01b, then receive-sb-file is working fine. However when setting BLOCK_SET_KEY=01b and BLOCK_ENROLL=01b, SEC_BOOT_EN=01b, then receive-sb-file failes with Abort Error.

Why does receive-sb-file need BLOCK_SET_KEY=00b? 

[kamii]

Thanks for your help.

I've tried writing CMPA with the elftosb-gui via UART, and the result was the same.

The parameters for elftosb-gui are below.

 Connection : UART

 Port : COM4

 Baud rate : 115200

 Secure Boot : Boot signed images

 Watch Dog : Disabled

 Lock device on boot fail : checked

 Disable sensitive ISP commands : Checked

 Disable PUF enrollment : Checked

  Disable PUF key code generation : Checked

 TZ-M mode : From image header

 Disable DICE calculation : Checked

 Customer factory area in DICE calculation : Un-checked

 NXP area in DICE calcuration : Un-checked

 Accept RSA4096 keys only : Un-checked

 RKTH : Our 32bytes ASCII data bytes

After writing the above CMPA, without re-powering the LPC55S69, receive-sb-file worked fine, but after then re-powering the LPC55S69, receive-sb-file couldn't work with the following error.

>blhost -p COM4,115200 receive-sb-file LPC55S69.sb2
Ping responded in 1 attempt(s)
Inject command 'receive-sb-file'
Preparing to send 198400 (0x30700) bytes to the target.
Successful generic response to command 'receive-sb-file'
(1/1) 0%Data phase write aborted by status 0x2712 kStatus_AbortDataPhase
Possible JUMP or RESET command received.
Response status = 1 (0x1) Failure.
Wrote 1536 of 198400 bytes.

When we change the above parameter "Disable PUF key code generation" to "Un-checked" and write this CMPA to LPC55S69, recieve-sb-file worked fine with and without re-powering LPC55S69.

For your reference, our configuration steps before writing CMPA are below.

(1) Key Enroll

(2) Set SB Key

(3) Set User Key

(4) Set PRINCE 0 Key

(5) Write Key Non-volatile

(6) Write CFPA (ROTKH_REVOKE)

(7) Configure PRINCE 0

Best Regards,

[Sabina_Bruce]

Hello ,

Hope you are doing well.

Could you please check the following post, to the last answer that Tomas provides(the one marked correct answer). Verify this is also done on your end and that is not the issue. 

LPC55S69 Secure Boot Failing 

After writing the above CMPA, without re-powering the LPC55S69, receive-sb-file worked fine, but after then re-powering the LPC55S69, receive-sb-file couldn't work with the following error.

Before retrying to reload the sb file are you in secure boot? Did it successfully load when you did it without re powering?

In addition, I will be checking with our team what is the proper procedure to successfully disable the key code gen.

Best Regards,

Sabina

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

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

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

[kamii]

Hi Sabina,

>Could you please check the following post, to the last answer that Tomas provides(the one marked correct answer). >Verify this is also done on your end and that is not the issue.

>LPC55S69 Secure Boot Failing

I've verifyed the post, and I think there's no problem in our secure boot configurations and sb2. Our signed boot image (sb2.1) boots successfully.

>>After writing the above CMPA, without re-powering the LPC55S69, receive-sb-file worked fine, but after then re->>powering the LPC55S69, receive-sb-file couldn't work with the following error. 

>Before retrying to reload the sb file are you in secure boot? Did it successfully load when you did it without re powering?

I'm sorry, what do you mean "are you in secure boot"?  When I wrote CMPA and then I executed receive-sb-file without resetting LPC55S69, this receive-sb-file completed successfully. After then I reset LPC55S69, our signed image written by receive-sb-file booted successfully. However after LPC55S69 resetting, I executed receive-sb-file again, this receive-sb-file failed with kStatus_AbortDataPhase Error.

>In addition, I will be checking with our team what is the proper procedure to successfully disable the key code gen.

I've found that this issue should have some relations with PRINCE. We use PRINCE 0 for our signed boot image protection, and the receive-sb-file's loaded area is in this PRINCE 0 region. Experimentally I tried disabling our PRINCE 0 configuration, receive-sb-file worked without error even if the BLOCK_SET_KEY was enabled. 

Could you check if receive-sb-file needs BLOCK_SET_KEY disabling when we uses PRINCE?

Thasnk in advance.

[Sabina_Bruce]

I am currently waiting for our team's update on this matter. I will let you know as soon as I receive a response.

Best Regards,

Sabina

[kamii]

Thanks! We need your help and are waiting for your response of this matter.

Best Regards,

[Sabina_Bruce]

Thanks in advance for your patience. Our team is still working on this, I will update you as soon as I can.

Best Regards,

Sabina

[kamii]

Did you reproduce the issue?

I'm wondering our provisioning step has something wrong or that's LPC55S69's limitation.

We have to fix our CMPA configuration soon, so could you tell me your team's progress for this issue?

Thanks in advance,

[Sabina_Bruce]

Hello ,

Hope you are doing well.

I did attempt several ways which now I am unable to recover the board at the moment. The feedback I received form our application team is the following:

If you follow AN12283, it will config the CMPA by using elftosb-gui like you mentioned, and then loaded the SBKEK(sb key for sb file decryption) to device. SBKEK provisioning is depending on PUF, it needs PUF to generate key code for SBKEK.

So if disable PUF key code generation before, then provision SBKEK, this will cause the key provisioning to fail. 

After each reset, ROM will config PUF based on PFR settings.

 

For LPC55S69, it has ONE bit in PUF configuration register to block enroll AND set key, as shown above.We should provision the key that the ROM needs first, then block the PUF as needed.

Best Regards,

Sabina

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

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

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

[kamii]

Hello,

>If you follow AN12283, it will config the CMPA by using elftosb-gui like you mentioned, and then loaded the >SBKEK(sb key for sb file decryption) to device. SBKEK provisioning is depending on PUF,

>it needs PUF to generate key code for SBKEK.

As mentioned before, I did PUF and SBKEK provisioning before CMPA configuration, so our key provisioning didn't fail. 

The following is the detail of our configuration step, and Step 0 to 8 were completed successfully without failure. Only the Step 9 reseive-sb-file was failed by setting BLOCK_SET_KEY in CMPA.

(0) Zero Clear CFPA and CMPA, and Clear Key Store and Write Key Store to Non-volatile, and then reboot LPC55S69 for transition to the initial non-secure and none-PRINCE state. 

(1) Write CFPA with Version field increment and ROTKH_REVOKE field setting

   blhost.exe -n -p COM4 -- write-memory 0x9de00 "CFPA_ROTKH_REVOKE.bin"

(2) Key Enroll

   blhost.exe -n -p COM4 -- key-provisioning enroll 

(3) Set SB Key

   blhost.exe -n -p COM4-- key-provisioning set_user_key 3 "device_sbkek.bin"

(4) Set PRINCE 0 Key

   blhost.exe -n -p COM4 -- key-provisioning set_key 7 16

(5) Write Key Non-volatile

   blhost.exe -n -p COM4 -- key-provisioning write_key_nonvolatile 0
(6) Configure PRINCE 0 (Our FW binary is loaded to Addr=00000 to 2FFFFh)

   blhost.exe -n -p COM4 -- fill-memory 0x20034000 4 0x50000000
   blhost.exe -n -p COM4 -- fill-memory 0x20034004 4 0x00000000
   blhost.exe -n -p COM4 -- fill-memory 0x20034008 4 0x00030000
   blhost.exe -n -p COM4 -- configure-memory 0 0x20034000

(7) Write CPMA by elftosb-gui with the following parameters

 Secure Boot : Boot signed images

 Watch Dog : Disabled

 Lock device on boot fail : checked

 Disable sensitive ISP commands : Checked

 Disable PUF enrollment : Checked

  Disable PUF key code generation : Checked

 TZ-M mode : From image header

 Disable DICE calculation : Checked

 Customer factory area in DICE calculation : Un-checked

 NXP area in DICE calculation : Un-checked

 Accept RSA4096 keys only : Un-checked

 RKTH : Our 32bytes ASCII data bytes

(8) Reboot LPC55S69

   blhost.exe -n -p COM4 -- reset

(9) Download FW and the result was failed

   blhost.exe -n -p COM4 -- receive-sb-file "lpc55s69.sb2"

Ping responded in 1 attempt(s)
Inject command 'receive-sb-file'
Preparing to send 198400 (0x30700) bytes to the target.
Successful generic response to command 'receive-sb-file'
(1/1) 0%Data phase write aborted by status 0x2712 kStatus_AbortDataPhase
Possible JUMP or RESET command received.
Response status = 1 (0x1) Failure.
Wrote 1536 of 198400 bytes.

If possible, could you build successful PRINCE and SB2 environment first for your reproducing the issue?

On the receive-sb-file workable environment, we change to the BLOCK_SET_KEY configuration in CMPA enabled , and then receive-sb-file become un-workable.

Best Regards,

[Sabina_Bruce]

Thank you for your detailed response. We are working on this, I will update you as soon as possible

Best Regards,

Sabina

[Sabina_Bruce]

Here is a further update:

The root cause is not PUF. It is because the PRINCE has been enabled, but doesn't follow the flash operation rule mentioned in AN12283.

We also have AN12527 for PRINCE.

The whole flash region covered by PRINCE should be erased and programmed. "receive-sb-file" command doesn't guarantee that this rule is met.

The problem is that both applications note run the PUF enrollment (-- key-provisioning enroll). But this command must be called only once because the activation code gets re-write; either the SBKEK or PRINCE key is invalid. Therefore, the device cannot get out of the ROM boot.

[kamii]

Could you please answer my questions?

Best Regards,

[Sabina_Bruce]

Hope you are well. I apologize for the delayed response. However, I am waiting for further feedback from our application team. As soon as I have an update I will provide it for you.

Best Regards,

Sabina

[kamii]

Sabina,

I'd like to know if you can reproduce the issue. Or could you execute receive-sb-file operation to the PRINCE region successfully?

I didn't get any information about this issue for two months. I'd like to know what you're doing about this issue.

[Sabina_Bruce]

Hope you are well. At the moment I am relying on our application's team test and details regarding this issue. Unfortunately, I do not have access to another board at the moment working from home. I did make initial tests but have not been able to recover the current board I am working with. 

The information received is that they were able to follow the steps you have taken without any problem. In addition, it is a must to do flash-erase-all before using the receive-sb-file command. When you issue this command, the intent is to do an update of all the software image.  Therefore, you need to start from scratch. 

A similar concept applies to PRINCE. Every time there's an image update, new PRINCE IVs are generated, making the data already saved invalid. A workaround for not losing information is to use the ping-pong data, get the old IVs to recover information, then re-encrypt with the new IVs.

Best Regards,

Sabina

[kamii]

Thank you for the answer.

>The information received is that they were able to follow the steps you have taken without any problem. In addition, it is >a must to do flash-erase-all before using the receive-sb-file command.

After CMPA is sealed, we can't do flash-erase-all operation by blhost. How can we do flash-erase-all before using the receive-sb-file command? As mentioned before, when we applied the "erase all" statement in the commandFile.bd for sb2, the receive-sb-file command worked without error. Is this "erase all" statement equivalent to your flash-erase-all suggestion?

You said that doing flash-erase-all before receive-sb-file is necessary, but is this requirement only in PRINCE and BLOCK_SET_KEY environment?

In my testing, when BLOCK_SET_KEY was disabled, flash-erase-all ("erase all") was not needed before the receive-sb-file and the PRINCE IVs in CFPA didn't be changed by receive-sb-file.

I'd like to confirm that when BLOCK_SET_KEY=00b are using, flash-erase-all is not necessary, and flash-erase-region to the whole PRINCE region is enough for receive-sb-file operation.

Best Regards,

[kamii]

Sorry, there're some errors in my answer, and I'd like to correct it.  

You said that doing flash-erase-all before receive-sb-file is necessary, but is this requirement needed only in PRINCE and BLOCK_SET_KEY environment?

In my testing, when BLOCK_SET_KEY was disabled, flash-erase-all ("erase all") was not needed before the receive-sb-file. After successful receive-sb-file operation ("erase 0..0x30000" and "load inputfile > 0"), the PRINCE IVs in CFPA was changed and the PRINCE KEK in the Key Store was not changed.

Best Regard,

[kamii]

Hi,

Experimentally, I've changed the Erase statement "erase 0x0..0x30000" to "erase all", and then there's no error on receive-sb-flle operation with BLOCK_SET_KEY=11b.

However "erase all" statement erases all flash area and that's not our requirement. We'd like to erase only the PRINCE region.

Could you confirm the difference of receive-sb-file's operation between "erase all" and "erase 0x0..0x30000" with BLOCK_SET_KEY=11b?

Thanks in advance

[kamii]

Hi,

By more testing, I found this issue is caused by an Erase statement in the commandFile.bd for SB2. 

When deleting the Erase statement in my commandFile.bd, this receive-sb-file aborting error (Response Status = 1) didn't happen.

But this deleting an erase statement causes kStatusMemoryCumlativeWrite error on the next Load statement.

The following is my testing commandFile.bd file section. Is there any problem in my commandFile.bd?

section (0)
{
   erase 0x0..0x30000;
   load inputFile > 0x0;
}

I'd like to know two things.

(1) In the ISP's receive-sb-file operation, to executing an erase statement for erasing the PRINCE region , is BLOCK_SET_KEY=00b configuration needed?

(2) Is there any way to erase the PRINCE region with BLOCK_SET_KEY=11b configuration? 

Best Regards

[kamii]

Hello

Thanks for your help, but I think that's beside the point.

Basically, we have succeeded in receive-sb-file operation on the PRINCE region. So I think we can follow the flash operation rule and key-provisioning steps you mentioned. When we set BLOCK_SET_KEY=00b, then we can do receive-sb-file operation successfully and the uploaded image can be booted successfully. If we would have any errors or mistakes on the flash operation rule or key provisioning steps, we couldn't do them.

In my testing, only the changing BLOCK_SET_KEY=00b to 11b in the CMPA, it seems to cause receive-sb-file operation failed on the above successful environment. I don't think that the receive-sb-file operation on the Boot code needs set key operation, so I asked the question.

Did you have the testing result of receive-sb-file operaiotn on the PRINCE environment with BLOCK_SET_KEY=11b?