Home > On-Demand Archives > Talks >
Secure Boot in Embedded Systems: Potential Impact and Weakness
Khalil Rashid - Watch Now - EOC 2025 - Duration: 24:35
Original embedded device manufacturers must implement security measures, with a major focus on Secure Boot. Secure Boot establishes a Chain of Trust, where each boot component verifies the signature of the next component before loading it. According to GSPR guidelines, Secure Boot will be mandatory for electronic products by December 13, 2024.
In this talk, we will break down GSPR regulations into a clear, step-by-step guide for implementing Secure Boot throughout each component of the boot process. Attendees will gain practical insights into building a secure, compliant boot sequence for embedded devices.
thanks for your feedback
Excellent presentation!
thanks for your feedback,, hope it was helpful!
Hi! Looking at your slides, the last two links don't seem to bring up posts they're supposed to. Are those papers available elsewhere? Links in question:
https://epteck.com/whitepaper/preparing-your-embedded-product-for-the-cyber-resilience-act/
https://epteck.com/whitepaper/secure-boot-best-practices-for-embedded-linux/
Sorry for inconvenience i have requested my team to get this fixed today. thanks
Hi Khalil, very nice talk on a very important topic, thank you! My only comment is that the small window where we could see you talking (that's quite nice by the way, being able to see you and not just the slides) was covering some of the presentation text/images, which made it a bit annoying some times. Otherwise there are a few details I'd like to talk to you about, regarding the implementation of the chain of trust and the number of keys allowed etc., but we can take it on another platform.
Very thankful for feedback and corrections, will make that small window better in future for sure;
please share your questions anyway here, this discussion will help others also to follow and to be shared, i will try my best to answer as simple possible;
which type of product you are working on? Microcontroller based or Application CPU, ROTS or Embedded Linux?
Right, so in a very detailed question then: what is in general regarded as best practice when it comes to the number of public keys (or hash of public keys) that are embedded in the device, be it for the bootloader or for the application. What I mean is: should there be multiple keys so that in case one of them is compromised, the device can still use the other(s), apparently after a remote update, to stay operational or this is not a good practice? That means of course that there should be a mechanism for the application to invalidate the compromised key. What I'm thinking is that if a third party gets hold of the key, then they can also invalidate the rest of the keys and thus anyway make the device unusable. Moreover, if the multiple key strategy is adopted, then should the PKIs behind them be stored in different locations, for example different HSMs? Because if one gets hold of one of the private keys, then if all the rest of the keys are stored together, they might as well be compromised at the same time.
To answer your question, we are working on a microcontroller based product that is using Zephyr RTOS and we are implementing a chain of trust including a ROM bootloader, a SW bootloader and the application image, with the private keys stored in an external HSM. But I suppose the strategies are a bit universal regardless of whether it is MCU based or Embedded Linux based and so on.
Hi Nikos,
Lets come straight to the point.
PKH in OTP memory, there are 4x slots, and reason for having multiple keys in OTP are also diverse. you can have multiple key as you dont want to relay on single algorithm, RSA, DECS etc you want different keys PKH. for flexiblity. 2nd reason if one is compromised then use second. but revoking mechanism must be developed very carefully. i had to develop this in multiple projects so far. its complex.
PKI, Private key protection can be done by HSM in cloud or physical HSM, there are many different strategies invented around it; SO Pin, multiple owners key matching to access HSM etc. from HSM never a private key could leave. there are more details we will stay connected anyway on linkedin.
It seems that the cybersecurity requirements of the GPRS and the EU CRA overlap quite a lot. Do you have a feeling how much the overlap is and where the two differ?
there is no easy answer but clearly they overlap around 30 to 50% depending of type of smart products: they could also be defined as GPSR requires safety in general, while CRA adds cybersecurity as a safety aspect.
it could be long debate about this topic! what you think?
| being bit lazy and got a chart from AI! but as i see its is representing right things:- | Area | GPSR | CRA | Overlap |
|---|---|---|---|---|
| Consumer Product Safety | ✔️ | ✖️ | Indirect | |
| Cybersecurity of Products | ✖️ | ✔️ | ✔️ (for smart products) | |
| Connected Devices (IoT) | ✔️ | ✔️ | ✔️ | |
| Manufacturer Obligations | ✔️ | ✔️ | ✔️ | |
| CE Marking | ✖️ | ✔️ | ✖️ | |
| Risk Assessment Requirements | ✔️ | ✔️ | ✔️ |
Very pedagogical - and very structured. Thanks!
Really appreciate the feedback; want to learn more details; please grab whitepaper from my website for step by learning! thanks
Hi Michael, if you need to implement Embedded IoT security in your projects??
thanks for your feedback, now is the right time learn and build device with Security perspective. that's why i have written 2x whitepapers and also sharing lot of knowledge on my linkedin page.
please check following links if you are interested:
https://epteck.com/whitepaper/preparing-your-embedded-product-for-the-cyber-resilience-act/
https://epteck.com/whitepaper/secure-boot-best-practices-for-embedded-linux
No questions, just a comment: this is a powerful presentation and really draws attention to an extremely important consideration for any embedded software architecture for a system with access to any sensitive data at all. At the very least, a software architecture should address the security aspect of the design and be able to answer why or why not these pillars of security are needed. This is a great starting point for that analysis.
Incredible talk!