There is a common philosophical debate regarding whether open source software contributes to more secure embedded systems; whereas proprietary or closed source software hinders attacks by making reverse engineering more difficult. Contradictory, highly utilized open source software benefits from the use of many developers. For active community software projects the unsolicited reviews by all types of users and subsequent bug fixes which are made contribute to the quality of the final software. The opportunity for more robust implementations is there.
It was great to see the participation, questions and feedback in our recent security webinar series where we leveraged open source components to implement a secure boot. As with open source software, the feedback shared by all webinar participants will benefit all developers. So, in this blog, we will review and address the questions and comments made during our most recent webinar (Designing Secure IoT Devices Starts with a Secure Boot) to provide a path for stronger security implementations for IoT edge nodes.
Webinar Survey Feedback
At the end of the webinar, attendees were given the opportunity to provide their feedback, and for those who did – thank you very much! The predominant feedback was that the content should focus more on the architecture and theory, than on the specific product level details.
- One topic raised was about the types of threats the IoT edge node will face. A great resource for understanding how an embedded system will be attacked is a knowledge of how different security standards determine resistance of an end device. This is measured by performing an attack potential. Not every device will need the security levels provided by smart cards as an example, but the framework for calculating attack potential shows how time, expertise, knowledge of the design, tools, and access to the device are part of assessing the attack on a device. Within the standards there are points systems which show the spectrum of tools and methods used giving the reader an idea of a range of threats to embedded designs. Regardless of the threat, the protection provided by a secure boot offers the strong basis for the protection. For more information on the theory and architecture, please see the resources section below.
- From a few attendees, there was a request for more demonstration and implementation details. For the upcoming NXP Technology Event day in Irvine, California, we have a hands-on class based on our secure card reader solution that will cover the secure boot implementation. As security integration becomes more broadly adopted, there will be opportunities to attend similar trainings.
Live Webinar Questions
During the webinar, there were more than 30 questions asked. We, unfortunately, didn’t have time to address all of them, but we appreciate the real-time feedback! Let’s have a look at a couple of topics raised that were not part of the recording.
- There were request for a comparison of the secure boot implementation to Trusted Platform Modules and Secure Elements. These devices use similar methods as was discussed on our webinar, but differ in a couple of ways. They provide a predefined set of application services and furthermore are certified as meeting specific standards by third party lab analysis. Unlike standard microcontroller which comes as a blank device, these devices are pre-loaded with application level data and functionality. Mentioned in webinar 1 in a key management options section, the secure boot implementation could utilize such a device to perform the key management and cryptography related to the secure boot process. For IoT edge nodes, the level of security certification and the application specific needs for performance, power and memory, can vary wildly. The concept of the webinar is that the resources of the IoT edge node microcontroller itself can be used to greatly increase the resistance to security threats with the secure boot.
- There were also questions about updating the application code and the trusted secure boot code. These are very important topics that require more in depth discussion. What has been presented so far provides a solid foundation for adding over the air update and revision controls with fall back protection, but these are incremental components. For some devices, like the Kinetis K28F microcontroller , the hardware supports external serial flash interface with a QuadSPI memory peripheral. The plan for updates is to leverage this external flash memory to support a safe update flow. New firmware will always be placed in data memory space in this external flash. There the authenticity can be checked before it is placed in executable space. Stay tuned for future collateral to support this use case.
For additional questions or comments, please feel free to email me, or post a comment on this blog to share your questions with others.