Military Embedded system cyber threats, vulnerabilities and security

An embedded system is a combination of embedded devices that are located within a larger system in order to perform a dedicated function.

For more thorough treatment please visit:  Cybersecurity for Embedded Devices: A Guide to Threats, Vulnerabilities and Solutions

Such a system is dedicated to executing one specific task, which sets it apart from any other system of devices. An embedded system is typically some combination of hardware and software, either fixed in function or programmable. An embedded system could be designed to support a specific function, or specific functions with-in a larger system.

The monetary value of data, the ability to cause serious harm, and the interoperability and connectivity of modern embedded systems, including mission-critical systems, make embedded systems popular targets. Examples of Cyberattacks on embedded systems are disabling vehicle anti-theft devices and degrading the performance of control systems to directing printers to send copies of documents to the hacker and accessing a smartphone’s data.

A vulnerability is a weakness that can be exploited by a threat actor to perform unauthorized actions within an embedded system or computer. A vulnerability in embedded system security provides hackers a chance to gain access to confidential information, use an embedded system as a platform to execute further attacks, and even cause physical damage to devices that can potentially lead to human harm.

The most common examples of embedded system exploits are hacks of consumer electronics such as GPS devices, video cards, Wi-Fi routers, and gaming devices. These hacks are usually possible because manufacturers don’t protect their firmware. As a result, almost anyone with a little technical knowledge can gain access to premium features or overclock a device.

Many embedded systems perform mission-critical or safety-critical functions vital to a system’s intended function and surrounding environment. Embedded systems security is relevant to all industries, from aerospace and defense to household appliances. 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.

Modern embedded systems are starting to become interconnected by the Internet of Things (IoT), which creates additional attack vectors. 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.

Embedded system vulnerabilities

Taking into account that embedded systems are components of extremely expensive and valuable machines, the possibility to hack these systems lures lots of hackers. That’s why securing embedded systems is extremely important.

Like computers, many embedded systems have security vulnerabilities that can provide a way for a threat actor to gain access to the system. Typically, there is a time lag between the discovery of a specific vulnerability—such as a CVE, misconfiguration, or weak or missing encryption—and the availability and application of a patch or other remediation. Meanwhile, vulnerable systems are at risk.

Malware: An attacker can try to infect an embedded device with a malicious software (malware).
There are different types of malware. A common characteristic is that they all have unwanted,
potentially harmful functionality that they add to the infected system. A malware that infects an
embedded device may modify the behaviour of the device, which may have consequences beyond
the cyber domain.

Hardware attacks

Memory and bus attacks: If the hardware is physically available and insufficiently protected, it may be possible just to read the contents of memory directly from an external programmable readonly memory (PROM) or external RAM memory chip, or by probing the connecting bus. It is
generally good practice, and not that difficult, to encrypt and authenticate all static data such as
firmware stored in PROMs.

Cold Boot Attack is a memory attack where the memory (a bank of DRAM chips, for example), is chilled, quickly removed, and read on another system controlled by the attacker. The cold chips
hold remnants of the data even during the short interval where they are unpowered. Thus, it is best not to store critical secrets such as cryptographic keys in off-chip memory. In cases where higher levels of security are justified, external volatile memory may be encrypted.

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.

In 2018, ethical hackers found Meltdown and Spectre hardware vulnerabilities that affect all Intel x86 and some AMD processors. Both vulnerabilities mess up isolation between user applications, giving applications access to sensitive data and expanding the attack surface. Both Linux and Windows developers have issued patches for their operating systems that partially protect devices from Meltdown and Spectre. However, lots of devices (especially old ones) running on vulnerable processors are still unprotected.

Side-Channel Analysis Attacks in Embedded System Devices: – Side-channel analysis attacks exploit a device under attack hardware characteristics leakage (power dissipation, computation time, electromagnetic emission etc.) to extract information about the processed data and use them to deduce sensitive information (cryptographic keys, messages etc.). An attacker does not tamper with the device under attack in any way and needs only make appropriate observations to mount a successful attack. Such observation can be done remotely or physically through appropriate tools. Depending on the observed leakage, the most widely used SCAs are microarchitectural/cache, timing, power dissipation, electromagnetic emission attacks.

Software vulnerabilities and attacks

Today majority of software attacks comprise of code injection attacks. The malicious code can be introduced remotely via the network. Some of the attacks include stack-based buffer overflows, heap-based buffer overflows, exploitation of double-free vulnerability, integer errors, and the exploitation of format string vulnerabilities. The  most common types of software vulnerabilities in embedded systems are as follows:

Network-based attacks

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. This type of attack exploits network infrastructure vulnerabilities and can also be performed remotely. Using these vulnerabilities, hackers can listen for, intercept, and modify traffic transmitted by embedded systems.

Control hijacking attacks: These types of attacks divert the normal control flow of the programs running on the embedded device, which typically results in executing code injected by the attacker. An MITM attack is used to intercept or alter data transmitted by an embedded system. To execute it, hackers change the connection parameters of two devices in order to place a third one between them. If hackers can obtain or alter the cryptographic keys used by both devices, they can eavesdrop in a way that’s very hard to detect as it causes no disruption in the network.

An MITM attack can be prevented or stopped by encrypting transmitted data and using the Internet Protocol Security (IPsec) to securely transmit keys and data.

Injecting crafted packets or input: Injection of crafted packets is an attack method against
protocols used by embedded devices. A similar type of attack is the manipulation of the input to a
program running on an embedded device. Both packet and input crafting attacks exploit parsing
vulnerabilities in protocol implementations or other programs. In addition, replaying previously
observed packets or packet fragments can be considered as a special form of packet crafting, which can be an effective method to cause protocol failures.

Eavesdropping: While packet crafting is an active attack, eavesdropping (or sniffing) is a passive attack method whereby an attacker only observes the messages sent and received by an embedded device. Those messages may contain sensitive information that is weakly protected or not protected at all by cryptographic means. In addition, eavesdropped information can be used in packet crafting attacks (e.g. in replay type of attacks)

Reverse engineering: Often, an attacker can obtain sensitive information (e.g., an access
credential) by analysing the software (firmware or application) in an embedded device. This process is called reverse engineering. By using reverse engineering techniques, the attacker can find vulnerabilities in the code (e.g., input parsing errors) that may be exploited by other attack methods.

Military embedded systems

Military Embedded systems,  typically are deployed in the field. They tend to be much more rugged and much more tightly integrated than enterprise systems, and commonly undergo more rigorous certification and verification processes. hey also are much more closely integrated, perhaps using interfaces that are less common in commercial architectures, such as MIL-STD-1553.

Department of Defense (DoD) systems, e.g., computer networks, are increasingly the targets of deliberate, sophisticated cyber attacks. Many DoD systems require the use of embedded computing. Military equipment also can suffer from attacks on embedded systems. For example, hackers could shut down the Trusted Aircraft Information Download Station on the F-15 fighter jet. This embedded device collects data from video cameras and sensors during the flight, giving pilots navigation data.

Domestic issues such as CAN bus hacking have recently highlighted the growing importance of embedded systems security, but during military operations when real lives are at stake, the need for robust and reliable security measures for embedded systems is even greater. Embedded systems in military applications may be used to collect and transmit classified, mission-critical and top-secret data that should be protected from interception or attack at all costs.

To meet application-specific requirements while also reducing technology costs and development time, developers have started to use open-systems architectures (OSA). Because OSAs use nonproprietary system architectural standards in which various payloads can be shared among various platforms, technology upgrades are easy to access and implement. The DoD has thus directed all DoD agencies to adopt OSA in electronic systems. However, adding security to OSA could interfere with its openness.

Embedded systems security is a cybersecurity field focused on preventing malicious access to and use of embedded systems. Embedded security provides the tools, processes, and best practices to secure the software and hardware of embedded devices. Embedded systems security provides mechanisms to protect a system from all types of malicious behavior.

The CIA triad is defined for embedded systems as follows:
• Confidentiality ensures that an embedded system’s critical information, such as application code and surveillance data, cannot be disclosed to unauthorized entities.
• Integrity ensures that adversaries cannot alter system operation.
• Availability assures that mission objectives cannot be disrupted.

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.   Cybersecurity specialists work with systems design teams to ensure the embedded system has the necessary security mechanisms in place to mitigate the damage from these attacks.

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.

End-to-end security for embedded systems

All elements of the hardware and software architecture need to be secure. Each of the components of embedded system architecture creates an attack surface, from the firmware and embedded operating system (OS) to middleware and user applications. The embedded OS, a foundational piece of embedded systems security, plays the leading role as the backbone of security for an embedded system.

It’s essential to implement end-to-end security requirements in an embedded environment. This means: think about security while choosing your hardware, defining your system architecture, designing your system, and of course, 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.

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.

Network Security

Ideally, all network communication is authenticated and encrypted using well-established protocols such as TLS. A public key infrastructure (PKI) can be used by both remote endpoint devices (clients) and servers to ensure that only communications from properly enrolled systems are accepted by the parties to the communication. A strong hardware root of trust can provide this secure “identity” for the system, providing unique-per-device keys linked to the hardware and certified in the user’s PKI.

Multilayered approach to security

System hardening and the use of additional layers of security—such as a managed security service, firewall or intrusion detection and prevention system (IDPS)—reduce the risk that a threat actor will successfully exploit the vulnerability.

What the industry needs, say industry experts, is a stepped, multilayered approach to security for embedded intelligent systems. Layered defense-security architectures can ensure a “strength-in-depth” approach by adding redundancy to countermeasures.

A single layer “can never protect against all threats or patch all vulnerabilities,” says Wind River Security’s Thompson. “Multiple layers of security, known as defense-in-depth, cover far more threats and vulnerabilities. If any single layer is defeated, the attacker still has to move through multiple other layers of defenses to achieve their objective,” he says.

“It forces them to be knowledgeable about many types of vulnerabilities, attacks, and attack tools. It can help increase the time to defeat significant – giving the developer more time to update the embedded system after a new vulnerability or attack is discovered.”

Military embedded system security

To assure successful missions, military systems must be secured to perform their intended functions, prevent attacks, and operate while under attack. The DoD has further directed that cyber security technology must be integrated into systems because it is too expensive and impractical to secure a system after it has been designed

The design of security for an embedded system is challenging because security requirements are rarely accurately identified at the start of the design process. As a result, embedded systems’
engineers tend to focus on well-understood functional capabilities rather than on stringent security requirements.

An ideal design for an embedded system optimizes performance, e.g., small form factor, low power consumption, and high throughput, while providing the specific functionality demanded by the system’s purpose, i.e., its mission. In addition, engineers must provide security that causes minimal impacts on a system’s size, weight, and power (SWaP), usability, cost, and development schedule.

DoD operates numerous embedded systems, ranging from intelligence, surveillance, and reconnaissance sensors to electronic warfare and electronic signals intelligence systems. Depending on their CONOPS, embedded systems have different security requirements.

Developers must also determine the embedded system’s security requirements according to mission objectives and a concept of operations (CONOPS). Methodologies for securing embedded systems must be customizable to meet CONOPS needs.

Embedded system CONOPS are developed from mission objectives and are used to derive both functional and security requirements. Researchers create, evaluate, and implement an initial system design, codeveloping functionality and security while minimizing security interference during functionality testing by decoupling security and functionality requirements.

Secure embedded devices are self-encrypting, with many using the Advanced Encryption Standard (AES) 256-bit in XTS block cipher mode to codify and store data. A two-layer approach is also possible, with encryption on a solid-state drive acting as the first layer and file encryption acting as the outer layer. The use of multiple layers of encryption mitigates against the possibility that a single vulnerability or exploit could be used to penetrate both layers of encryption.

The need for secure real-time operating system software and embedded computing security software for use in military embedded systems continues to rise due to increasing security concerns and threats.

With increasing demands for security features, sensors, and processing power within embedded products that face size, weight, and power constraints, embedded engineers are creating innovative new methods of designing and building products for military applications. Many engineers are using ball grid arrays in place of traditional dual in-line or flat surface-mount packaging for their designs. Ball grid arrays provide more interconnection pins than the alternatives, facilitating 3D hardware-stacking that saves space while delivering the same speed and performance.

Military procurement departments will look to source products manufactured in secure, domestic environments to further mitigate the security risks associated with embedded systems in the battlefield.

Apart from IPsec and MACsec, there are encryption standards like transport layer security that work at the application level. These require less support from the network infrastructure, but consume more processor overhead and encrypt even less, because they exist at the highest layers of the network stack.

The security executives also believe that formal specification of hardware interfaces will become more important as embedded systems become more complex, if only to keep the engineering of such systems manageable.

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.

References and Resources also include:

https://www.apriorit.com/dev-blog/690-embedded-systems-attacks#:~:text=A%20vulnerability%20in%20embedded%20system,potentially%20lead%20to%20human%20harm.

https://blackberry.qnx.com/en/ultimate-guides/embedded-system-security#:~:text=Embedded%20systems%20security%20is%20a,all%20types%20of%20malicious%20behavior.

https://militaryembedded.com/cyber/cybersecurity/securing-military-embedded-systems-is-a-giant-challenge

https://www.ll.mit.edu/sites/default/files/page/doc/2018-05/22_1_9_Vai.pdf

https://www.securecodewarrior.com/blog/embedded-systems-security