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.
Additional Resources
