How to secure embedded systems

What is embedded memory used for?

An embedded system uses different types of memory for different purposes, and a governing factor will be what type of embedded system it is. For example, it could be a networked appliance (such as a ‘smart’ fridge), a mobile device or standalone embedded system (such as a standard fridge). Even a smart card is an embedded system.

As for where memory resides in an embedded system, below is an example architecture from an industrial electronics application:

Memory is essential part of the hardware foundation of an embedded system.

The memory is an essential part of an embedded system and can be thought of as a ‘sub-system’.

Another way of picturing where memory resides in an embedded system is to consider the interaction between software and hardware – see diagram.

Though not shown, the operating system will have a kernel, libraries, a filing system, communications software and device managers. This enables operating systems to perform memory management – a convenience but also a security weakness. Also not shown is that sometimes an embedded system has middleware, which can provide services the operating system cannot.

Memory management

Within an embedded system, memory must be managed. Multiple tasks/processes are likely to have read and/or write access to same memory space. If the sharing is not coordinated properly, the system may not perform as intended and might even crash.

The memory management must be efficient – i.e. it must be responsive but not an overhead – and secure.

The management is usually performed by the operating system (or rather a kernel at the heart of the OS) but many embedded system developers also like to develop their own solutions.

If the system does not have an OS, the memory management must be handcrafted. Alternatively, a dedicated memory management IC can be used.

Memory management involves

• Allocating and deallocating memory for use.
• Protecting areas of memory
• Managing the mapping between logical (physical) memory and task memory references.
• Determining which processes to load into the available memory space.
• Supporting memory allocation and deallocation of code requests (within a process), such as the C language “alloc” and “dealloc” functions, or specific buffer allocation and deallocation routines.
• Tracking the memory usage of system components.
• Ensuring cache coherency (for systems with cache).
• Ensuring process memory protection.

How might embedded memory be attacked?

Another way of posing the above question would have been ‘How might an embedded system be attacked?’, as memory is so crucial to the system’s operation.

Most embedded systems that get hacked are relatively high volume ‘smart’ consumer goods (e.g. IoT devices), games consoles and (generally lower volume) industrial devices such as programmable logic controllers (PLCs, which are often IIoT-enabled). They are attacked to give the hacker access to sensitive/valuable data on that system, to cause localised disruption and/or gain access to networks and other systems.

The nature of the attack is generally a software attack, spearhead through a communication from a remote and not easily traceable location. The communication is not flagged (by the targeted system) as out of the ordinary. It’s seemingly another device or user addressing it using its IP address and requesting access.

Hackers can gain access because of weaknesses in the system’s software, such as there being no mechanism in place to counter a ‘brute force’ attack which, when a password is requested, exhaustively tries to guess it. Not only might the hacker succeed in gaining access but while the attack is taking place legitimate users might be locked out, similar to the effects of a Distributed Denial of Service (DDoS) attack on a server.

Attacks can also be via USB ports. Reports of malware being introduced to computers via infected USB thumb drives frequently make the news, and many companies have made the possession of such devices a sackable offence.

Many embedded systems, such as industrial process monitoring and control systems, have USB ports for interfacing with a laptop or USB thumb drive so that data such as performance metrics and fault codes can be downloaded. The ports are also used for uploading program software and configuration settings.

Another problem is that virtually any embedded system can be reverse engineered. If it is a commercially available product, there is little to prevent a hacker purchasing one and, using just-as-accessible test and measurement equipment, discovering the inner workings of the device and establishing what kind of data is residing where in the memory.

Once a hacker knows how your device works and memory is partitioned – and how your system manages data (including software/firmware updates) – it is just a case of introducing malicious code. As mentioned, that might be via network, wirelessly or USB.

One of the most common forms of attack is the ‘memory buffer overflow’.

Memory buffer overflow attack

Memory buffer overflows can easily happen by accident, generally as a result of poor coding. When data is written to memory it goes to a specific address, for which space has been allocated in the memory map. If a larger volume of data is written to the location than can be accommodated, rather than simply not writing the excess it goes into the next available location and overwrites anything already present.

This can corrupt the behaviour of (and even crash) the system, which would of course be noticed. However, the goal of most buffer overflow attacks are far more strategic, and aim to alter the execution of the software such that it reveals sensitive data or grants access to other systems, without crashing or showing any outward signs of being compromised.

While you would think that the embedded code (or rather the design entry tool / complier) would recognise the issue of trying to write more data than there is room for, many memory addressing functions in C and C++ are unbounded. For example, the get(s) function in C reads data into a buffer (in memory). But there is no limit to the size of that data. Without additional code to validate or automatically crop the data before sending it the buffer there is no safeguard against buffer overflow.

Security challenges for embedded memory

Designing an embedded system is challenging at the best of times. It is not just about rising to the technical challenges of meeting the functional requirements (such as speed, performance, robustness and reliability) it is the fact that there are so many constraints placed on the designer. These include power (especially for battery-powered systems), volume, weight and, of course, cost.

The system that ultimately goes to market may well be feature-rich and versatile, but it will also be ‘just enough for the job’ – and the result of many compromises made during design, manufacture and test.

Such systems don’t tend to scale well so adding additional features, such as security measures not envisaged at the time of design (but recognised as needed now following an attack or identified weakness), is not an easy task.

Also, the designers (and here we are talking software, hardware and even systems engineers) of most embedded devices will be skilled at designing to meet the above requirements and within the constraints. They will have a very focused view of ‘their system’, its intended behaviour and the legitimate ways in which it will interface with networks and a ‘broader system’. Few, if any, are security experts, and it is difficult to envisage how attacks might be made.

How to secure embedded memory

The first line of defence is to prevent a hacker from gaining access to the memory. Weaknesses in network connectivity and access control must be recognised, understood and countered. For example, if you think a brute force attack is possible then use longer passwords and/or implement a function where, after so many incorrect guesses, the system ignores further communications from that source (user).

Above, we mentioned how memory buffer attacks are common. An effective counter to code in a more secure language (such as C# or Java).

Operating systems have mechanisms too. These include declaring some areas of memory as non-executable and allowing memory spaces used during runtime/execution to be given random locations. This last measure is particularly effective because a hacker planning a memory buffer overflow attack (with a view to altering the system’s behaviour in a specific way) needs to know exact addresses. But they are changing every time your system runs.

Strict hardware-enforced partitioning is useful too. The software stack will not have unrestricted access to physical memory.

Above, we also discussed vulnerabilities through USB. Leads and devices are freely available. A solution here is to use industrial form factor devices. Commercial USB leads and drives cannot physically interface with an industrial receptacle. Similarly, a removable industrial memory device cannot interface with a commercial receptacle.

Tamper proof memory

In addition to the fundamental memory types discussed in What is embedded memory? variants exist that have internal memory management that allow them to deliver hybrid functionality; in that data can be made read only once written.

So-called write once read many (WORM) memory ensures that data is protected. Once written, the data cannot be erased, modified or overwritten.

In WORM devices, in-built memory management monitors for illegal behaviour. If any action (such as an attempt to modify the data) is detected, the memory switches to a ‘write protect’ mode. Note: some memory solutions have that as the default mode.

WORM-based USB drives and SD (and SD micro) cards are used in legal professions and by law enforcement agencies where there is a need for a permanent, unalterable digital record of certain information. Their use is in lieu of burning a CD-R or DVD-R, which is not so easy to do these days because modern laptops no longer have the drives.

With a WORM device, you can of course continue writing until the drive is full, so the technology is making its way into embedded systems sector. For example, many safety-critical processes require strict data logging / monitoring – and the validity of that data should be questionable. A permanent, unalterable record is the surest way.

Common criteria evaluation assurance level

As with IT products, embedded systems can also be ranked in terms of their security. An evaluation assurance level (EAL) ranking is performed against the Common Criteria (CC) security evaluation, an internationally recognised standard.

An EAL ranking reflects how thoroughly a system’s (sub-system’s or even a chipset’s) intended security features have been verified, and products are declared as being Common Criteria Evaluation Assurance Level (CC EAL) n certified, where n ranges from 1 to 7.

The levels are:

In addition, the level can be augmented using a ‘+’ to reflect the testing exceeded those required for one level but did not meet the requirements of the next level.

For example, in May 2020, Samsung Electronics launched a standalone security solution comprising a Secure Element (SE) chip that is managed by enhanced security software. The chip provides, in Samsung’s words, a ‘dedicated tamper resistant strongbox’ that is separate from phones standard memory. This means PINs, passwords, credit card details are more secure. The chip, the S3FV9RR, has achieved CC EAL 6+ certification; the highest level attained by a mobile phone component.

As mentioned, the level reflects how well the intended security features were tested. In other words, one embedded system having a higher EAL than another does not always mean it is more secure than a system with a lower EAL; because the first system might have only a few security features that were thoroughly tested, whereas the second system might have more and better security features, that were not tested as thoroughly.