Secure Boot Overview

[@wfliu7609]

Very clear description for Secure BOOOT with HSM, Thanks MacroChip :)

[@imtiyajshaikh9854]

Very helpful. Simple and lucid explaination

[@wwolfram33]

@9:10 Some steps here might be helpful to understand - For example: the Public Key is applied to the HASH to create a signature, and this signature is compared to the signature created by the Private Key of the HSM (I assumed a trusted device)? That does not seem correct. Rather, it seems that the signature created by the HSM (using its private key) needs to be 'decrypted' by the public key then compared to the HASH calculated from the desired FW to be run. If these are equal, then we know the FW has integrity and can be trusted.

[@MicrochipDeveloperHelp]

Hi there, thanks for your comment! In secure boot, the private key in the HSM creates the signature. The public key is then used on the device to verify it. The public key "decrypts" the signature to get the original hash that was signed. The system compares this hash with the one it generates from the firmware. If both hashes match, it means the firmware is authentic and safe to run. The public key doesn’t create the signature-it checks that the signature is valid by revealing the original hash. This ensures the firmware hasn't been tampered with. Hope this helps!

[@wwolfram33]

@@MicrochipDeveloperHelp Thanks!

[@mallninja9805]

@1:30 "Secureboot ensures that only trusted and authentic firmware runs on the embedded system" - trusted by whom? By what definition of "authentic"?

[@hatman-rc2vc]

not only firmware, it also check integrity of kernel and other components using hash values, and not only what runs on "embedded system", but the entire "system".

[@DrInfiniteExplorer]

Does Microchip have a statement or philosophy or similar about secureboot and the right to repair (for example)? It's not uncommon for IoT connected devices to only operate if they are allowed to phone home to a cloud operated server, and all instructions/reports to/from the device needs to go through said server. And it's not uncommon for such companies to go out of business and/or pull their services, which leaves customers with essentially bricked expensive devices. Has Microchip thought about these scenarios? Are there any guidelines one can follow to deal with this sort of things, either from the perspective of a service provider, or from the perspective of a consumer? Are the two concerns mutually exclusive by nature?

[@edwardmacnab354]

I see that they had no reply--very concerning

[@mikeTheH]

​@@edwardmacnab354little late to the game here I know. At this point no answer is your answer. Assume the worst. I know I have.