Dr David Long - Doulos Principal Member Technical Staff
Creating a secure embedded system for first time is daunting! This article is intended as a tutorial to help you get started. In it, we will focus on a "small embedded" system built around a microcontroller (such as an Arm Cortex-M MPU) and firmware running "Bare metal" or with a Real-Time Operating System (RTOS). However, a lot of the points covered are equally applicable to "large embedded" systems based around one or more application-processors and operating systems such as embedded Linux, Android or iOS.
Until quite recently, most "small embedded" systems were effectively isolated from the outside world. Their interfaces might have included to a few sensors, actuators, buttons, LEDs, perhaps even a touch screen or memory card, but that was about it. Security for such systems (if considered at all) might have just required putting it in a box that could not be easily opened! Today, that is no longer the case – it is common for embedded systems to be connected to a network, perhaps even multiple types of network. That is certainly the case for Internet-of-Things (IoT) devices. Connected embedded systems are susceptible to external attack: The embedded system developers must include appropriate security features to provide protection from such attacks.
Firstly, it is very important that security is considered right from the start of a new product development so that security features become part of the design requirements. Attempting to retrofit security once the design is complete is not recommended! It is usually expensive (since changes may be required to the hardware or software), may delay the product launch and might not meet all of the security requirements. Of course, sometimes developers need to reuse existing hardware and software on new projects, in which case it is important not to underestimate the effort that might be required to make the reused parts secure!
Remember – "Security by Design" requires changes to the traditional development process.
Software developers working on applications for personal computers and servers have needed to address security threats for many years, so it is not surprising that recommendations for a secure software design process have existed for a similar period. One of the best known is the Microsoft Security Development Lifecycle (SDL), originally published in 2006. This splits the software development into the sequence of phases shown here:
Notice that the phases have associated activities – the SDL defines what tasks are performed in each phase and what is required to move to the next phase. More recently, security development lifecycles that fit into Agile development methodologies have also been created (for example the Cloud Security Alliance "DevSecOps Delivery Pipeline").
Also note that the very first phase of the SDL is "Training" - every team member is expected to have security training before starting work on a secure project. However, the Microsoft SDL does not specify precisely what each team member must learn within this training – it may depend on their role in the project and the application being developed.
The development of a secure embedded system is also likely to include activities that are hardware related: deciding whether tasks such as cryptographic functions will be performed in hardware or software; selecting components with enhanced security features; providing a mechanism for securely updating firmware after the device has been commissioned; and so on. A Security Development Lifecycle for an embedded system will also include these additional activities (together with the software-only ones):
A Security Development Lifecycle identifies the phases that will be required to develop a secure embedded product. However, it still leaves many questions unanswered about what is required within each phase and how are the requirements going to be met. Developers will need further guidance to address security requirements, especially if they do not have prior experience of creating secure embedded systems. Fortunately, there are some initiatives that can help. We will take a look at the Arm Platform Security Architecture (PSA) Certified Framework and the IoT Security Foundation (IoTSF) Security Assurance Framework. Depending on the type of secure product you wish to create, you may find that other frameworks are a better fit. Some examples are the ioXt Alliance "ioXt Security Pledge" and NIST Cybersecurity Framework
Arm Platform Security Architecture (PSA) Certified offers recommended security requirements, which if implemented to a satisfactory level, are assumed to be formally secure. There are three levels of security which are certified by an independent security evaluation. A key element is the requirement for additional process isolation which is possible for Armv8-M based MCUs using TrustZone but also possible for multi-core Armv7-M based systems too. The PSA Certified Framework (often simplified to just "PSA") breaks down the security design and implementation in to a simple four-step process. PSA Threat Models and Security Analysis (TMSA) is based on the Common Criteria approach of a Protection Profile that establishes a set of Security Functional Requirements (SFRs) for the Target of Evaluation (TOE).
The notation used by the Common Criteria is harder to understand than less formal threat modeling approaches such as Microsoft STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Evaluation of privilege) but enables the security to be evaluated for PSA Certified qualification.
One of the Arm PSA Certified documents defines a Platform Security Model with 10 goals needed to secure and establish the trust that is required to create a secure device (DEN 0128, available from https://developer.arm.com/architectures/architecture-security-features/platform-security). Note that the term "device" could be used to represent a connected embedded system or individual hardware and software components that are used within it.
The 10 PSA Certified Security Goals
1. Unique Identification
To interact with a specific device instance, the instance must have a unique and attestable identity. The attestation must be verifiable to prove the device identity (see Goal 3).
2. Security Lifecycle.
The security state of a device within its security lifecycle depends on software versions, run-time measurements, hardware configuration, status of debug ports and product lifecycle phase. Each security state defines the security properties of the device and may impact access to bound data (see Goal 9). The security state must be attestable (see Goal 3).
3. Attestation
Attestation proves the identity (see Goal 1) and security state (see Goal 2) to establish the trustworthiness of a device. The device identification and attestation data are part of a device verification process, run by a trusted entity.
4. Only execute authorized software (Secure Boot)
Secure boot and secure loading processes ensure that only authorized software can be executed on the device. Unauthorized software is only acceptable if it cannot compromise the security of the device.
5. Secure Update.
Device software, credentials and programmable hardware configuration must be updateable to resolve security issues or to provide feature updates. Updates must be authenticated and must not compromise the device security. Updated software must be authorized to execute on the device (see Goal 4).
6. Anti-Rollback
Updates are necessary to resolve known security issues and provide feature updates (see Goal 5). Anti-Rollback prevents reversion to a previous version with a known (and subsequently fixed) vulnerability and is essential. An authorized rollback for recovery purposes may be allowed.
7. Isolation
Isolation of a trustworthy service from less trusted or untrusted services protects its integrity. Isolation boundaries aim to prevent one service from compromising other services.
8. Interaction over Isolation Boundaries.
Interaction over isolation boundaries is necessary for interaction of isolated services. Such interaction must not be able to compromise services or the device (see Goal 7). Data exchanged across an isolation boundary must be validated and its confidentiality and integrity preserved.
9. Unique binding of sensitive data to a device (Secure Storage).
Sensitive data (such as user or service credentials) and secret keys must be bound to a device to prevent disclosure. This requires some form of secure storage. Where binding relies on cryptography and keys (see Goal 10) the keys must also be bound to the device or the data owner. Data might also be bound to a security lifecycle state, for example to enable access during debug (see Goal 2).
10. Trusted services and cryptographic operations
A minimal set of trusted services to support critical functions such as configuration of the hardware to support the security lifecycle (see Goal 2) or isolation (see Goal 7). Cryptographic operations might use secret keys to support attestation (see Goal 3), secure boot (see Goal 4) and binding of data (see Goal 9).
This security framework contains a comprehensive set of guidelines. It consists of over 270 requirements covering all stages of an IoT product lifecycle from conception, through design, manufacture, production, testing and customer use to repair and final disposal. It is available free of charge from the IoTSF.
The IoTSF Security Assurance Framework is applicable to any IoT device, ranging from those with multi-core processors running powerful operating systems such as Android or embedded Linux down to microcontroller-based products running a real-time operating system (RTOS) or even "bare metal". Many of its guidelines are also applicable to other types of connected embedded systems too, such as Industrial controllers, automotive, medical, marine and so on.
Trying to make sense of all of the guidelines within the IoTSF Security Assurance Framework is quite challenging, especially for anyone who does not have a background in security. To make it easier to follow we have created a mind map to identify where each requirement in the IoTSF Security Assurance Framework might fit into the development of a secure small embedded application. We have also added cross-references to some other security frameworks and standards such as Arm's Platform Security Architecture (PSA) and Microsoft SDL Practices.
Let's start by taking a look at the main branches of our mind map. These do not correspond exactly to the SDL shown earlier – we have combined some of the phases to make it easier to explain.
The Secure Design & Architecture branch corresponds to the Requirements and Design SDL phases and determines the Security Requirements. This can be broken down into several child branches. The first two child branches are concerned with identifying what needs protection and what the security threats might be – this process is generally referred to as "Threat Modeling". The IoTSF Security Assurance Framework requires threat modeling but does not specify the approach that should be taken. The Security Requirements also depend on the market constraints – if the security solution is too expensive, then a product is not commercially viable!
The next child branch Risk Assessment relates to how the security level of the product is to be evaluated. This needs to be determined at the start of the project because it impacts the security measures that will be implemented. The PSA Certified 10 Security Goals appear here.
The Defences and countermeasures branch is split into three child branches to represent requirements at a company, application and platform level. This highlights that development of a secure embedded system requires a business environment with a well-defined security policy, an understanding and commitment to follow relevant security standards and regulations and a secure supply chain. An organization developing secure products will include stakeholders with various roles:
Management will need to define best practice and ensure it is adopted. There should be a documented Security Policy that defines the responsibilities of key security personnel; how issues such as vulnerability reporting and security updates are managed; the duration of support services and how a Software Bill Of Materials (SBOM - required for security audits) is maintained.
The IoTSF Security Assurance Framework provides a comprehensive and detailed set of requirements that cover these business requirements as can be seen in the mind map.
Other security requirements determined at a company level the start of a project are the standards to be applied and how a secure supply chain and production environment will be managed. Developers and engineers will need to follow the security policy requirements and ensure their code complies with applicable standards and regulations. Supply chain managers will need to audit the security practices and ensure requirements for certification are met.
There are many requirements that need to be considered at an application level. Most of these are included in the IoTSF Security Assurance Framework. The most significant child branches shown here relate to software authentication and secure data communications.
The application level branches relating to Permissions & Privileges, key management, configuration parameters and secure update have been expanded here. The requirement for no default passwords is also a feature of security standards such as EN 303 645.
The final branch of Defences and countermeasures is the Platform level. This is split into Secure SW Architecture and Secure HW Architecture child branches. Notice the overlap between IoTSF Security Assurance Framework and PSA Certified requirements for the software architecture.
The Secure HW Branch also contains overlapping requirements from IoTSF Security Assurance Framework and PSA Certified.
The Implementation branch of the mind map corresponds to the SDL Implementation phase. It is much smaller than the Secure Design & Architecture branch since most of the security requirements have already been considered. In this phase, software engineering best practice is applied, such as following secure coding standards and use of static analysis tools. Any steps necessary to secure the platform and interfaces (e.g. JTAG) should also be performed here.
The verification branch of the mind map corresponds to the SDL verification phase. Again, it is quite simple since the only requirements are to use "standard" execution test techniques to ensure correct operation of the embedded system, including in the presence of malicious inputs.
The Release branch of the mind map corresponds to the SDL Release phase. This is more complex than the previous branches since it includes the Final Security Review (ensuring the security requirements have been implemented), secure manufacture and certification against the chosen security standards (done by an external testing house).
The Runtime Defence & Monitoring branch corresponds to the SDL Response phase. It specifies how the device will respond to unexpected attacks and how updates and repairs will be provided.
The final branch of the mind map is Secure Disposal/Transfer of Ownership. This does not have a matching phase in the SDL but is still a necessary requirement for many secure embedded systems, particularly if they are for IoT applications. It specifies how sensitive information should be protected if a customer decides to sell their device to someone else or when the device reaches the end of its operational lifetime. Protection of personal information is a legal requirement in many countries that have regulations such as GDPR – overlooking these requirements could have expensive repercussions!
That's it! We have taken you through all of the phases in the Security Development Lifecycle for a small embedded system, showing where Arm PSA Certified and the IoTSF Security Assurance Framework fit in. Further details are freely available on the PSA Certified and IoT Security Foundation web sites.
Do you remember the first phase of the Security Development Lifecycle? It was "Training"! If you need to start working on a real secure embedded system development project, we strongly encourage you to take some training. The Doulos course Embedded System Security for C/C++ Developers provides an ideal introduction to many of the topics that we have covered here, including Arm PSA Certified and requirements that are part of the IoTSF Security Assurance Framework. If you are working on a secure embedded Linux project, we also have a Practical Embedded Linux Security course that might help you.
Finally, if you would like to see the complete mind map linking the Secure Development Lifecycle phases to the IoTSF Security Assurance Framework and Arm PSA Certified, please click on button below - it will open in a new browser window. We have also added icons that represent each section of our Embedded System Security for C/C++ Developers course to the branches, to give you a better idea of what to expect on the course.
If you would like to read this KnowHow article offline, we have prepared an e-book (EPUB format) document that you can download and open using a free reader such as Calibre or Freda. Click here to download this article in EPUB format. In exchange, we will ask you to enter some personal details. To read about how we use your details, click here. On the registration form, you will be asked whether you want us to send you further information concerning other Doulos products and services in the subject area concerned.
