Bluetooth low energy v5.4 Baseband Controller, Protocol Software Stack and Profiles IP
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.
E-mail This Article | Printer-Friendly Page |
Related Articles
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Synthesis Methodology & Netlist Qualification
- Streamlining SoC Design with IDS-Integrate™