This article will cover an overview of securing the embedded systems. We will start from basic definition, then move to challenges in embedded security, some typical solutions, and what the missing puzzles are.
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:
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.
Embedded system security doesn’t get the attention it warrants. Here are a few reasons why:
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.
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.
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.
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.
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.
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.
In the following sections, we will look at some software and hardware characteristics of secure embedded systems.
A secure embedded system has:
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.
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, 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.
The following best practices should be kept in mind when building embedded software:
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.
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.
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.
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.
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.
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.
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.
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:
Building your device's defense at the application level involves:
Here’s a non-exhaustive list of tools that can help in securing embedded systems:
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.
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.
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!