Secure Embedded Systems - Common Approaches and Challenges

The topic of embedded system security is an important part of many of our projects regardless of the industry or field of the customer – be it because of the GDPR (EU General Data Protection Regulation), cloud connectivity, safety requirements or application-specific requirements and regulations. Based on a recent project, this article aims to show how a security concept can be implemented and gives examples of typical and recurring pitfalls and challenges.

One of our customers approached us in need for our security expertise because they wanted to add cloud connectivity and establish a security roadmap for their medical device portfolio consisting of existing and planned medical devices. Soon, it became clear that three solutions were necessary as is often the case when there are existing devices or machines already in the field.

a retrofittable secure connectivity gateway for their existing devices,
an integrated secure connectivity module for devices where integration is easily possible and
a holistic security approach for new products

This desired new functionality was to be able to transmit data from the device to a cloud service. Moreover, the transmitted data did not only include personalized medical data, but also other sensitive data, e.g. server credentials. This data certainly required protection, but it was also important to safeguard the system against attacks from the outside over the network and locally to prevent harm to the user or patient.

Therefore, cyber-security was of utmost importance for the customer. They asked for our technical and process expertise because the adding of security in embedded systems was a new challenge for them.

Following the design process outlined in this article, the exact security scope and the applicable standards (e.g. AAMI TIR 57 for medical devices) were identified and agreed on with the customer and certifying authorities. It was decided that the system should be in accordance with a security level 3 (following IEC 62443-4-2, SL3).

Mission Embedded developed a single concept to address all three necessary solutions and provide new as well as existing devices with the relevant security capabilities (e.g. secure storage, secure communication).

This approach provided the benefit that all other elements in the overall system architecture, user, and operator manuals as well as certification artifacts could be reused without modification.

In the following chapter, we will take a more detailed look at the security concept, also showing why and how it was implemented.

Risk Assessment

According to the ME security management process, a risk assessment was conducted first. Together with the customer, approximately 50 risks have been identified and categorized. This number of risks is not uncommon for such projects. Below, you find an excerpt of risks that we often encounter in our projects, especially when working with legacy systems:

Risk 1 Due to weak password management and authentication, a user or attacker can access the system and misconfigure the device and its settings. (At a glance, this might not seem like the top risk of the system. However, due to its high probability of occurrence, as well as the devastating impact it might have when looking at a medical device, it was categorized as a risk that absolutely needed to be mitigated.)

Risk 2 Due to unprotected plain text storage, data manipulation is possible, which might then also be transmitted to the server. Thus, wrong data is stored on the server, which may compromise the integrity and authenticity of all records stored on the server.

Risk 3 Due to a missing secure storage, the keys, certificates, and other sensitive information are stored in “plain text” on the unencrypted file system.

Risk 4 Due to an unsecured communication channel, backend or due to vulnerabilities in the application itself, code execution via malformed data can be achieved, i.e., a buffer overflow attack, ROP (return-oriented programming), etc. Due to the possible code execution, the entire system can be compromised. This means that also unencrypted data might be retrieved from the system.

Risk 5 Due to a lack of OS hardening (e.g., firewall), the system might be discoverable, and spoofing and denial of service attacks are possible. Moreover, if unsecured or weakly secured interfaces are open and are listening to connections, system access with high impact is possible due to a potential root exploit.

Risk 6 An unprotected debug interface allows access to the entire system and its data, i.e., done by an insider (standard password), or due to weak password policies, etc. As a consequence, wrong data might be displayed, algorithms manipulated, etc.

Risk 7 A malformed firmware image can be booted/installed from the SD card by a third party. Due to missing code signatures and other checks, the entire system is compromised, not visible to the operator or user. Thus, there is a threat of manipulation of data and algorithms, etc.

Objectives

Based on the identified and categorized risks, the objectives for the system are determined. Each objective is assigned to one or several identified risks which allows mapping between risks and objectives. The following image and list include common objectives that need to be tackled in many cases:

Secure Boot:

To prevent the system from entering a tampered state, it has to ensure that only a firmware is booted, which has been authenticated and provides integrity, i.e., through the use of code signatures validating the origin of the firmware from a trusted source during the boot procedure.

Secure Interfaces/HW:

To limit the attack surface of the system, unused interfaces shall be disabled and/or adequately protected (i.e., passwords).

Secure OS:

To protect the system from outside attacks, the operating system needs to be hardened. This includes settings regarding firewalls, disabling not required services, malware detection, integrity verification, mandatory access control systems to limit users and applications, configuration of login interfaces to prevent brute force attacks and more.

Secure Storage:

To be able to reasonable secure secrets, such as certificates, encryption keys, and server credentials, as well as measurement logs, secure storage needs to be implemented/available on the system, i.e., through file system encryption based upon secure hardware.

Secure Communication:

To ensure that data is securely transmitted from the system to the server, confidentiality, integrity, and authenticity need to be ensured for the communication channel. Hence, message encryption and signing must be provided, and the used channel needs to be authenticated.

Secure Update:

To prevent the system from entering a tampered state, updates need to be able to be securely installed. This includes code signatures and verifications before the update is applied.

In the following subsection, we provide a more detailed look on how each objective was realized in this specific project.

Implementation

To fulfil these objectives, we need to establish a chain of trust, as explained in this article. In the given project the following chain of trust was implemented, using the mechanism in the specific system architecture (Linux + NXP i.MX SoC). The root of trust constitutes the foundation upon which all further mechanisms are built, in this specific project the CAAM (Cryptographic Accelerator and Assurance Module). In other projects, we are using Trusted Platform Modules (TPM) for example.

Secure Boot

The used processing platform provides a hardware root of trust through one-time programmable keys. If fused and enforced, the ROM bootloader, supporting High Assurance Boot (HAB), validates the second stage bootloader through the validation of a code signature on boot. The system only continues to boot if the signature was verified, otherwise it stalls. Hence, the second stage bootloader can be fully trusted as this stage and is only reachable from a valid source. In this specific case, the second stage bootloader is a custom modified and enhanced U-Boot.

U-Boot continuous to validate the Linux Kernel (e.g. zImage), thus ensuring that all deployed security related Kernel Modules are in place. Moreover, U-Boot validates the initRamFS (initRD) and the rootFS signature. The latter two components are required by a Kernel security extension, which was used to ensure that the Root filesystem has not been tampered with. This extension calculates and compares the authenticity of the rootFS (rootFS signature). Hence, no manipulated firmware, etc. will be executed.

Secure Interfaces

All interfaces have been protected with strong password policies satisfying the current NIST (National Institute of Standards and Technology) guidelines. Moreover, debug interfaces have been set into a mode which also requires a preceding authentication. Moreover, USB interfaces are restricted allowing only a limited set of device classes. System access via USB is protected through authentication.

Secure OS

To protect the OS, numerous measures have been deployed. First and foremost, password policies are enforced, firewalls are configured and set, only the required services and applications are running (i.e. disabled telnet, etc.), and applications run with the minimum required permissions to hinder root exploits.

Additionally, the system also keeps audit logs. To protect these logs and limit the possibilities of root exploits, a MAC (mandatory access control) system was deployed and configured. As a result, even the root user is confined, preventing, for instance, deletion of the audit log by root. Correctly configuring the MAC was probably the most difficult part.

What makes MAC difficult to configure is that every system is unique and requires an adapted policy to some extent. Hence, choosing the right MAC system for the right purpose is important to find a good trade-off between cost, benefit, and complexity.

Secure Storage

In order to implement a secure storage, the hardware of the SoC must support the possibility to encrypt and decrypt data through processor unique encryption. This feature was, for example, used in combination with the system extensions mentioned above to encrypt the data partitions. To achieve this, the CAAM (Cryptographic Accelerator and Assurance Module) of the SoC was used. Using this secure storage and further encryption mechanics, sensitive data such as keys/certificates are protected. Secure storage is critical for the key management on the device, as it protects the keys from unauthorized access (manipulation and disclosure). In order to give each device its unique identity, the key generation capabilities of the device are used in combination with a PKI (public key infrastructure) to get signed certificates for each device that can be used for the secured communication.

Secure Communication

In order to protect data in transmission, a two-way authentication ensures that the device only communicates with a valid server and that the server can verify that it communicates with the correct device.

Secure Update

To ensure that firmware and data can be securely updated unattended, Mission Embedded integrated a proven-in-flied secure update mechanism. A dual boot failsafe extension was also integrated into the secure update mechanism to prevent the system getting bricked through an update.

Test and Validate

Penetration tests typically consist of port scans, sniffing, replay attacks, brute force dictionary attacks, probing, firmware upgrade/downgrade, installation of manipulated firmware, etc. Altogether, these tests verify the correct functioning of the implemented mechanisms and guarantee the specified goal and security level of the system. All deployed mechanisms were verified according to predefined test cases in-house. We also support our customers mastering the certification process with a notified body.

Conclusion

This article provides an overview of how device security can be implemented on a modern SoC platform for a mobile medical device, including secure boot, secure storage, secure communication, secure update, and other mechanisms.

This project was an excellent example for integrating our Yocto Security Layers in a customer project. These layers add security functionalities to the Bootloader and the Kernel / OS, e.g., the base configuration of the firewall, password policies, secure update mechanisms, and security related Kernel modules. Those basic layers, continuously refined and extended, provide the fundamentals for future security projects and applications.

3 Mission Embedded Security Solutions – One Security Concept:

ME Secure Gateway for already deployed systems
Integrable ME Secure Connectivity Module for already existing products
Joint product development with a holistic security approach for new products