The whys and hows of secure boot
Nathan Padoin, ByteSnap Design
embedded.com (August 10, 2017)
With the proliferation of Internet of Things (IoT) devices, which now span just about every walk of life, from smart cities to wireless jewellery, the need to prioritize security in IoT-style embedded systems has never been greater. The secure boot process is a vital first step in securing any embedded system, a necessary part of your application’s anti-malware fortress. Let’s take a look at the pros and cons, with a focus on one of the most popular processors in electronics – the i.MX6.
What is secure boot?
Secure boot is a process where your OS boot images and code are authenticated against the hardware before they are allowed to be used in the boot process. The hardware is set up beforehand in such a way that it only authenticates code generated using security credentials you trust. In short, it ensures that the boot and OS software is the intended manufacturer version and hasn’t been tampered with by malware or malicious third parties.
Secure boot is applicable for any single-use device, a good example being an e-reader, a popular use of the i.MX6 processor (the i.MX6 Solo and DualLite have an integrated E-Ink display controller, for example), which is intended for specifically reading e-books, rather than general computing. Having a locked-down Linux environment at boot is useful in this case.
Other situations, such as an Android phone, may have trade-offs. Using secure boot would restrict end users from running custom ROMs, for example. Being able to do this may be a feature, or may be desirable based on product placement or security requirements. Essentially, a good time to use secure boot is any case where you don’t want another party to load an operating system or a different bootloader onto your device.
For more integrated systems such as IP cameras running Linux, you would be well advised to use secure boot, as any malicious boot code or operating system software could lead to a situation where the device is made part of a botnet. Or potentially the feed from the camera could be publicly uploaded onto the Internet or otherwise altered so that the feed does not contain the footage wanted by the owner.
To read the full article, click here
Related Semiconductor IP
- Band-Gap Voltage Reference with dual 2µA Current Source - X-FAB XT018
- 250nA-88μA Current Reference - X-FAB XT018-0.18μm BCD-on-SOI CMOS
- UCIe D2D Adapter & PHY Integrated IP
- Low Dropout (LDO) Regulator
- 16-Bit xSPI PSRAM PHY
Related Articles
- Securing the IoT: Part 2 - Secure boot as root of trust
- Implementing Secure Boot in Your Next Design
- How to design secure SoCs, Part III: Secure Boot
- Lockdown! Random Numbers Secure Network SoC Designs
Latest Articles
- SCENIC: Stream Computation-Enhanced SmartNIC
- Agentic AI-based Coverage Closure for Formal Verification
- Microarchitectural Co-Optimization for Sustained Throughput of RISC-V Multi-Lane Chaining Vector Processors
- RISC-V Functional Safety for Autonomous Automotive Systems: An Analytical Framework and Research Roadmap for ML-Assisted Certification
- Emulation-based System-on-Chip Security Verification: Challenges and Opportunities