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
- nQrux® Root of Trust IP
- AXI to UCIe Bridge IP
- UCIe 2.x Controller IP
- SWI3S (SoundWire I3S Interface) Peripheral Controller Core IP
- OpenTitan-based RISC-V Secure Element
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
- Automated Pre-Silicon Verification of High-Speed DDR5 and LPDDR5/6 Memory Controllers: Closed-Loop Timing, Mode Register, and PHY Synchronization in UVM
- U-Sonic: An Open-Source 8-Channel Ultrasound Transmit IP in a 130 nm RISC-V SoC
- S-ALSA: Co-Design of Adiabatic Logic-based Sensing and Balanced Bit-Cells for Secure and Energy-Efficient MRAM
- MEGATRON: a 28nm Analog PCM CiM/Digital System-on-Chip for Edge GenAI at 57.5 TOPS/W and 1.52 Mparam/mm²
- Peregrino: A Full-Hardware Accelerator for the Complete Falcon Post-Quantum Digital Signature Scheme on Resource-Constrained Edge Devices