SBSFU warning: Initialization with factory default values

[Moritz Diller]

Posted on July 15, 2018 at 09:26

Hi,

SBSFU gives me the warning 'SECURE ENGINE INITIALIZATION WITH FACTORY DEFAULT VALUES' on every new power-up of the microcontroller. Is this behavior normal after a power-cycle or is anything not configure correctly?

= [SBOOT] System Security Check successfully passed. Starting...

======================================================================

= (C) COPYRIGHT 2017 STMicroelectronics =

= =

= Secure Boot and Secure Firmware Update =

====================================================================== 

= [SBOOT] STATE: WARNING: SECURE ENGINE INITIALIZATION WITH FACTORY DEFAULT VALUES!

========= End of Execution ==========

= [SBOOT] System Security Check successfully passed. Starting...

======================================================================

= (C) COPYRIGHT 2017 STMicroelectronics =

= =

= Secure Boot and Secure Firmware Update =

====================================================================== 

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL

= [SBOOT] Waiting for USBD_STATE_CONFIGURED

= [SBOOT] MX_USB_DEVICE_Init end

= [SBOOT] STATE: CHECK STATUS ON RESET

INFO: A Reboot has been triggered by a Software reset!

Consecutive Boot on error counter = 0

INFO: Last execution detected error was:No error. Success.

= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD

= [SBOOT] STATE: DOWNLOAD NEW USER FIRMWARE

File> Transfer> YMODEM> Send

Many thanks to ST for providing the SBSFU code. Delivering such great resources for free gives you a big advantage over other competitors.

One last thing: I discovered a slight security issue in the post-build process. I use AES-CBC, which needs an initialization vector (IV). The IV is automatically created by the post-build tools and saved in iv.bin, but it is only generated once if the file doesn't exist. For safety reasons, it should be different for every single encryption. You can simply delete it before every build, so it is regenerated with a random number, but it would be better if the post-build tool did this automatically. Besides the convenience, you can easily forget to delete the file and make your firmware file more vulnerable than necessary.

Probably the same applies to nonce.bin, but I didn't test that.

Best regards,

Moritz

[Tesla DeLorean]

Can't help you, bumping you off my feed

[Jocelyn RICARD · Accepted solution]

Hello Moritz,

I'm sorry for this very long delay for answering. This is related to vacation period.

yes this message is normal after a power on reset.

The reason is that, after a power on reset, the secure engine lost its working data. These data are stored in RAM and protected by a CRC.

So there is nothing to worry about this message.

About this IV and nonce issue you raise, I agree this should be changed automatically. This point was already raised but the point here is not to provide a ready made solution but a base example on which you can build your system. Anyway I will ask again to dev team, just to make things cleaner!

I hope this answers to your questions

Best regards

Jocelyn

[Moritz Diller]

Hello Jocelyn,

thank you for your answer.

Regarding the IV/nonce issue, I think "not to provide a ready made solution" is just a lazy answer of your dev team. Why shouldn't you want to provide a ready-made solution?

I don't want to offend anyone, but if you look on popular cases in history where cryptographic applications have been broken, in most cases they have been broken because of very "small" faults in the implementation. Security issues which could have been closed with a single line of code.

The IV/nonce issue falls exactly in this category. Of course, in theory, everyone who uses the SBSFU library should know this, but in practice, it can be easily overlooked. 

If you can't convince your dev team anyway, at least put a big, red-colored, remark in the SBSFU user manual. ;)

Best regards

Moritz