about secure boot of CSEc model

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

about secure boot of CSEc model

ソリューションへジャンプ
756件の閲覧回数
Keane
Contributor I

hi everyone

I have some questions about secure boot.

Keane_1-1673276587562.png

After the step 5, what will happened if the MAC is not matched? Should I do anything else to complete the sequence of secure boot?  

P.S.: I want to achieve the function that the bootloader won't start when MAC's verification fails. 

 

 

0 件の賞賛
返信
1 解決策
743件の閲覧回数
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Keane,

you can find this description two pages above in AN501:

lukaszadrapa_0-1673330572922.png

So, in case of sequential and parallel boot mode, the only consequence is that you won't be able to use boot protected keys.

In case of strict sequential boot mode, the device will stay in reset forever. There's no way to recover, the device must be replaced. Also once this mode is enabled, it cannot be changed anymore. So, my recommendation is to enable this feature once all your development is finished.

Don't be confused by note "or may execute ROM code". This is a general description taken from SHE specification, it does not apply to this device.

 

There are two additional commands: CMD_BOOT_OK and CMD_BOOT_FAILURE. It's not mandatory to use them but the commands can be used to check additional blocks after the autonomous secure boot finishes (i.e. you can create chain of trust).

For example: you can configure CSEc to cover a bootloader by autonomous secure boot. The bootloader then can initiate calculation of MAC over application. If the MAC is correct, the bootloader should execute CMD_BOOT_OK to confirm the secure boot (including this additional checking) was OK. If the MAC is wrong, it can execute CMD_BOOT_FAILURE which will finish this secure boot process and which will disable access to boot protected keys.

Notice that it's not important to execute CMD_BOOT_OK after successful autonomous secure boot. Boot protected keys will be available now anyway. But it's recommended. The commands can't be executed second time, so it helps to avoid hacker attack. 

Hope this helps.

Regards,

Lukas

 

 

 

元の投稿で解決策を見る

1 返信
744件の閲覧回数
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi Keane,

you can find this description two pages above in AN501:

lukaszadrapa_0-1673330572922.png

So, in case of sequential and parallel boot mode, the only consequence is that you won't be able to use boot protected keys.

In case of strict sequential boot mode, the device will stay in reset forever. There's no way to recover, the device must be replaced. Also once this mode is enabled, it cannot be changed anymore. So, my recommendation is to enable this feature once all your development is finished.

Don't be confused by note "or may execute ROM code". This is a general description taken from SHE specification, it does not apply to this device.

 

There are two additional commands: CMD_BOOT_OK and CMD_BOOT_FAILURE. It's not mandatory to use them but the commands can be used to check additional blocks after the autonomous secure boot finishes (i.e. you can create chain of trust).

For example: you can configure CSEc to cover a bootloader by autonomous secure boot. The bootloader then can initiate calculation of MAC over application. If the MAC is correct, the bootloader should execute CMD_BOOT_OK to confirm the secure boot (including this additional checking) was OK. If the MAC is wrong, it can execute CMD_BOOT_FAILURE which will finish this secure boot process and which will disable access to boot protected keys.

Notice that it's not important to execute CMD_BOOT_OK after successful autonomous secure boot. Boot protected keys will be available now anyway. But it's recommended. The commands can't be executed second time, so it helps to avoid hacker attack. 

Hope this helps.

Regards,

Lukas