Many embedded systems today must be secure. Many of these devices also have complex timing requirements that also require an RTOS. In this course, we will explore the capabilities of modern secure microcontrollers and how to select them. We will explore their hardware isolation mechanisms, and software stacks like trusted firmware for cortex-m. In addition, we will explore how to keep applications secure by exploring secure real-time operating systems and how they fit into the secure system ecosystem.
There are no hardware requirements for this course.
Registration and Playback are located here (May require login to access)
May 26 – Day 1 – Threat Model Security Analysis (TMSA)
The selection of secure microcontrollers and RTOSs depends on the security requirements of the system being designed. Teams will often jump to part and software stack selection before fully understanding their security requirements which can put the quality of their security solution in jeopardy. In this session, we will explore how to analyze the security needs of a system using a technique known as a Threat Model Security Analysis (TMSA).
May 27 – Day 2 – Secure Microcontroller Solutions
There are a wide variety of hardware solutions developers can leverage to secure their embedded systems. In this session, we will explore secure microcontroller technologies such as memory protection units, secure and unsecure memory and processing, secure peripherals, multicore solutions, and more.
May 28 – Day 3 – Arm TrustZone
A common solution for securing microcontroller applications is to use Arm TrustZone. In this session, we will explore how to configure TrustZone and design secure applications. Attendees will learn how TrustZone works, how to configure secure and non-secure memory, peripherals, and actions developers can take if a security incident is detected by the processor.
May 29 – Day 4 – Secure Boot and Firmware Updates
A key component in securing an embedded system is securely booting the system and performing secure updates. In this session, we will explore the secure boot boot and update process. Attendees will learn the various techniques that can be used to securely boot their system, gain insights into open source solutions, and other techniques they can apply to their own designs.
May 30- Day 5 – Secure RTOSes
Secure products that use a microcontroller often still require deterministic real-time behaviors. In some applications, a standard RTOS might do, but a secure RTOS can make a big difference. In this session, we will explore the capabilities of secure real-time operating systems and the role they play in secure embedded systems.
Jacob’s General Embedded Software Resources
- Sign-Up for the Embedded Bytes Newsletter here
- Book: Embedded Software Design here
- Developing Reusable Firmware – A Practical Guide to API’s, HAL’s and Drivers here
- MicroPython Projects Book here
- Jacob’s YouTube Channel – here
Just on the project involving secure firmware. The SW is Open Source but the HW docs comes with NDAs so really I am muzzled about details, unfortunately.
My impression is that the crypto and security specialists in most part should be forbidden from writing any code or writing the user documentation. The situation somewhat improved from the times of SSL debacle (where you could find a macro called “n” :-/ .. among other “flowers” ), but not that much considering the sizes of libraries exploded with the proliferation of the embedded system targets.
The build system concept and implementation is just ridiculous and awful, this opinion is shared across the team, which is compromised both with internal (us, as contractors) and external (client personnel) engineers, so you cannot blame the team/company cultural bias.
The code is full of comments where the code is documenting itself sufficiently, and lacking any comments where they actually would be helpful.
The HW documentation should be “decrypted” by some bona fide technical writers, unfortunately I think this profession is dying on the false assumption that Doxygen and HW engineers technical notes are good enough (they ARE NOT).
Of course all these problems will be solved soon by the AI so why worry … (BTW: AI == Artificial Idiocy).