Why end-to-end security is important for embedded systems

Embedded systems help deliver a lot of modern technology. From the adaptive cruise control on your car, to the Wifi on your smart fridge. With cyberattacks on the rise, securing these systems has become critical.

Embedded devices are prime targets for hacking, as a successful attack can give intruders access to the data produced, received, and processed by them. This can often have serious ramifications for the larger system being powered by the embedded device. E.g. shutting down an embedded device within the F-15 fighter jet, which collects data from various cameras and sensors, can significantly hamper the jet’s defenses.

We have written this article to cover everything you need to start developing secure embedded systems. Here’s what’s included: 

• What is embedded security?
• Challenges faced while implementing embedded security.
• What makes an embedded system “secure”?
• Why end-to-end security is important in an embedded ecosystem.
• Some embedded security tools.
• What do typical embedded solutions lack?
• Future of embedded security.

What is embedded security?

Embedded security provides the tools, processes, and best practices to secure the software and hardware of embedded devices. 

Because the hardware modules of embedded systems are small, they have various memory and storage limitations. Incorporating security measures into them thus becomes a massive design challenge. However, challenging as it may be, it’s a need-of-the-hour.

A lot of the gadgets and machines powered by embedded devices are also connected to the internet. This means that hackers can gain unauthorized access to them, and run any malicious code. 

A hack in an embedded device can often spread to other connected components, and/or cripple the entire system. For example, let’s suppose an attacker is able to gain control of an embedded device that allows drivers to put their car on auto-pilot. The hacker can then steer the car off-road, or into traffic, potentially causing a lot of damage.

Critical embedded system security challenges

Embedded system security doesn’t get the attention it warrants. Here are a few reasons why:

1. Lack of developer awareness:

Developers are usually unaware of the best practices for developing secure embedded devices. This is partly because of point#2, and partly because embedded applications are far more complicated than traditional software applications. Understanding their security implications, and writing safe, performant code for all use-cases, that too in a constrained, microcomputer environment, can be challenging. 

2. Lack of standardization:

There is a lack of cybersecurity standards for embedded systems. Even though the auto industry is slowly trying to change that. In the last few years, researchers have released quite a few publications that address cybersecurity considerations for smart vehicles. A few notable ones are SAE J3061, “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems:” and UNECE WP.29 Regulation on Cyber Security and Software Update Processes.

3. Use of third-party components

A lot of embedded devices required third-party hardware and software components to function. Often these components are used without being tested for any security flaws and vulnerabilities. 

4. Out-of-date software

An out-of-date firmware is typically ridden with bugs and potentially exploitable vulnerabilities. Even though it can be especially hard to periodically update firmware on a small, embedded device, it’s not something that can be ignored.

5. Direct internet connectivity

Many embedded systems and devices are directly connected to the internet. This means that they don’t have the protection of enterprise firewalls, which can detect and prevent network attacks. With resources at a premium, it becomes very hard to implement rigorous levels of security in such a constrained environment.

6. Attack at scale

Embedded devices are usually produced at scale. This means that a single vulnerability or flaw can affect millions of devices, sometimes worldwide. Containing the impacts of an embedded system attack can thus be a massive challenge.

What makes an embedded system secure?

In the following sections, we will look at some software and hardware characteristics of secure embedded systems.

Hardware security best practices

A secure embedded system has:

• A trusted execution environment

A trusted execution environment (TEE) allows for hardware-level isolation of security-critical operations. For example, user authentication may get executed in a segregated area, which enables better safeguarding of sensitive information.

• Appropriately partitioned hardware resources

Different hardware components like processor(s), cache, memory, and network interfaces etc. should be appropriately segregated, providing their functions as independently as possible. This helps in preventing an error in one component, propagating to other components.

• Executable space protection (ESP)

Executable space protection, or ESP, is the practice of marking certain memory regions as non-executable. If someone attempts to execute any code within these marked regions, an exception is thrown.

Software security best practices

The following best practices should be kept in mind when building embedded software:

• Use secure boot:

When an embedded device boots, the boot image gets verified using cryptographic algorithms. This ensures that the boot sequence is correct, and that the software (firmware and any other relevant data) has not been tampered with. 

• Use a microkernel OS

A microkernel OS is much smaller than a traditional OS, containing a subset of its features. The kernel space is tiny, and a lot of user services (like file system management etc.) are kept in a separate space, known as the userspace. Since there’s less code and operations being run in the kernel space, the attack surface is significantly reduced.

• Use properly packaged software applications

Any-and-all software applications should be self-contained, and properly packaged. E.g. if an application requires a third-party dependency, it should not be installed globally on the operating system. Rather, it should be part of the application package/container.

• Validate all inputs

Any-and-all data received from external and/or untrusted sources should be properly sanitized and validated, before being passed to critical software and/or hardware components. 

If an application fetches data from an external API integration, and toggles some setting based on it, the received data should be rigorously validated before the setting is changed.

• Protect data at rest:

All the sensitive software, data, configuration files, secure keys, and passwords etc. that are being stored on an embedded device, should be protected. This is usually done via encryption. The private keys used to encrypt the data must be stored in dedicated, purpose-built security hardware.

The security pyramid -- End to end security for embedded systems

Gone are the days when security used to be an afterthought. A non-functional requirement. Today, security needs to be intrinsic. Devices need to be secure by design. To that end, it’s essential to implement end-to-end security requirements in an embedded environment. This means: think about security while choosing your hardware, while defining your system architecture, while designing your system, and of course, while writing code.

Start at the hardware

No matter how robust your software security may be, if your hardware is lacking, you will be susceptible to attack. On-chip security techniques can allow secure boot, and efficient management of cryptographic functions and secrets. Some hardware components can also enable the operating system to offer various security features like system-call-anomaly detection, file system encryption, and access control policies.

A fault-tolerant system

There are numerous reasons to architect a fault-tolerant system, and avoiding differential fault analysis attacks is only one of them. In such an attack, a potential hacker can use fault injection techniques to try and produce errors in an embedded device. However, there are several possible ways to detect and protect against such faults:

• Replicate the most critical operations, so that different outputs can be compared, at any given time, to detect the injection of a fault.
• Fail by default: When handling multiple conditions (within an If condition or a switch block), always fail in the default case, i.e. when nothing else matches.
• Introduce random behavior: Adding small, random delays before crucial operations ensures that their timing is never predictable. This is key in intrusion detection, as it makes it very hard for hackers to determine patterns of operation, and perform timing attacks.
• Protective shields: Manufacturers should use shields to cover the most crucial components, protecting them from external manipulation.
• Detect abnormal fluctuations: Sense for abnormal fluctuations in voltage, current, or other values, and raise exceptions accordingly.

Secure your application… and operating system

Building your device's defense at the application level involves:

• Choosing tested, reputable third-party software and hardware components that can be regularly updated.
• Upskilling developers in the best practices concerning embedded system security.
• Use a microkernel operating system to ensure that a bare minimum number of operations get executed in the kernel space.
• Monitor and protect against software attacks including viruses, Trojan horses, and malware.
• Remove any-and-all unnecessary services. Your firmware should only have what you absolutely need. E.g. you may not need to transfer files, or capture packets, so you can disable file transfer protocols, and network packages like telnet.
• Use secure protocols like SFTP, IPsec, SSL, TLS, SSH, and DNSSEC.

Tools for embedded system security

Here’s a non-exhaustive list of tools that can help in securing embedded systems:

• Bus blaster: A high speed debugging platform that can interact with hardware debug ports.
• Salae: Decode various protocols like Serial, SPI, and I2C etc. You can use protocol analyzers built by the community, or build your own.
• Hydrabus: Open-source, multi-tool hardware that can be used in debugging, hacking, and/or penetration testing of embedded hardware.
• Exploit: An open-source Internet of things (IoT) security testing and exploitation framework.
• FACT (The Firmware Analysis and Comparison Tool): Framework used to automate firmware security analysis.
• Routersploit:  An open-source exploitation framework for embedded devices.
• Firmadyne: Open-source system for emulation and dynamic analysis of Linux-based embedded firmware.

Where are modern embedded security solutions lacking?

Even though there are various solutions available for debugging, exploiting, and pen-testing embedded solutions, they are not being readily used. A big focus remains on securing the device physically, but not enough efforts are made in protecting against software-related attacks. Even the simplest and easily avoidable application security risks and vulnerabilities are still common among modern embedded devices.  

A big reason for this is the developers’ lack of awareness of embedded security. According to a survey conducted by Tripwire, 68% of IT professionals believe that their workforce is not adequately aware of potential vulnerabilities.

Developers don’t know things like: which security protocols to choose, which frameworks to avoid, which hardware components to segregate, how to deal with sensitive data, and how to determine which encryption algorithm is the safest. This general lack of knowledge, and disregard for best practices, make applications running on embedded devices, susceptible to compromise.

Future of embedded security

A lot of work is being done in the embedded security market. Experts believe that the market’s compound annual growth rate (CAGR) can reach a figure of 5.5% during the 2021-2026 period. With more and more IoT devices being launched, we can expect new embedded security standards to get established.

The increasing adoption of wearable medical devices is also going to increase the demand for dependable embedded security solutions. For devices to contain and process sensitive medical data, they need to pass certain security checklists, and we hope that’s going to make vendors and engineers focus on security more.

In the future, we may also have solutions that allow for remote visibility, monitoring, and control of the main software and hardware components in embedded devices. This will truly be a game-changer in the world of embedded system security.

At the end of the day, digital signatures, encrypting data, adding firewalls, implementing access control, and randomizing operations can only take you so far. To build truly secure devices, developers need to be trained to write secure code. Identifying potential security risks, and mitigating them during the application design phase, goes a long way in making systems intrinsically secure. 

How Secure Code Warrior can help

Secure Code Warrior's flagship product - learning platform - has numerous interactive challenges, courses, and assessments that can help train developers to write secure C/C++ code. The content on the platform is framework-specific and highly engaging. Our C/C++:Embed coding challenges took inspirations from both MISRA C, AUTOSAR C++ (MISRA C++), and IEC.

Developers can embark on personalized learning journeys, where they identify C/C++-specific vulnerabilities and more importantly learn to fix those bugs. In this process, developers can keep track of their progress to identify their weaknesses, and even enjoy a friendly coding competitions with their peers. Find out more about how we help automotive and transportation industries with our solutions.

Want to find out how interactive and embed-focus our challenges are? Try some C/C++:Embed challenges on the learning platform today!