How to secure embedded systems
Securing your Embedded Memory
Embedded memory must be secured to protect data from unauthorised access, made by hackers with the intent of stealing or corrupting it.
In the case of data corruption, and in the industrial electronics sector, for example, the hack is made with a view to disrupting a process. Safety can be compromised too. Hacks of consumer goods such as ‘smart’ appliances tend to be with a view to getting onto the home network and accessing personal information such as passwords, PINs and bank details.
IN THIS GUIDE:
- What is embedded memory?
- What is embedded memory used for?
- Memory management
- How might embedded memory be attacked?
- Memory buffer overflow attack
- Security challenges for embedded memory
- How to secure embedded memory
- Tamper proof memory
- Common criteria evaluation assurance level
- Download our free guide ‘Securing your Embedded Memory’
What is embedded memory?
Before discussing why securing embedded memory is so important – and providing some guidance on how to do it – we must touch on what types of memory are available and what the memory is used for. To not start here would be like trying to spec a house alarm without knowing anything about the property or its contents.
Techopedia defines an embedded system as follows:
“An embedded system is a dedicated computer system designed for one or two specific functions. This system is embedded as a part of a complete device system that includes hardware, such as electrical and mechanical components. The embedded system is unlike the general-purpose computer, which is engineered to manage a wide range of processing tasks. Because an embedded system is engineered to perform certain tasks only, design engineers may optimize size, cost, power consumption, reliability and performance. Embedded systems are typically produced on broad scales and share functionalities across a variety of environments and applications.”
The above definition is a great one, particularly the second half. A designer’s choice of memory is usually constrained by the overall optimization goals, and the priorities will change depending on the application and volumes (of product) likely to be manufactured. The implementation of security measures will be limited, in part, by having to meet the optimization goals.
For embedded systems, the memory is typically a solid-state memory (SSM). Also, for the purpose of this guide, we shall be discussing standalone memory ICs, cards, modules and solid-state drives (SSDs); because memory also resides inside microcontrollers and system-on-chip (SoC) devices too for example.
Memory falls into two categories, volatile memory and non-volatile memory (NVM):
- Volatile. This requires the memory to be powered and is used for the temporary storage of data. Two types are used in embedded systems, static random-access memory (SRAM) and dynamic random-access memory (DRAM). There are cost versus speed trade-offs between the two technologies as SRAM is faster but more expensive. Also, DRAM needs to be refreshed (even when powered) a few times every second.
- Non-volatile. This retains data once power is removed. Within this category there are two sub-categories:
- One time programmable (OTP). Examples include masked read only memory (ROM – written to at the point of manufacture), programmable ROM (PROM – which is manufactured blank, and the user can write to it just the once), and erasable PROM (EPROM – which can be written to again if is first erased using UV light).
- Read-write. Examples include electrically erasable PROM (EEPROM, sometime E2PROM) and Flash, which technically is a form of EEPROM. It is just architecturally different.
Your security considerations start right here. For example, where NVM is concerned, if you don’t envisage needing to revise data in the field, you can go down the non-volatile OTP route. Your data might be accessible – physically via a comms port or remotely via wireless – but it cannot be altered.
As for the physical form factor of the embedded memory, there are many types. The most common are chips/ICs.
Smaller memory capacity ICs are available in plastic dual in-line package (PDIP) and small outline IC (SOIC) package form factors, and are soldered onto the PCB; thus a permanent fixture. Larger capacity memory ICs, such as DRAM, packaging forms include thin small outline package (TSOP), chip-scale packaging (CSP), low-profile quad flat pack (LQFP) and ball grid array (BGA). Again, they can be soldered to a PCB as a permanent fixture.
If there is likelihood of needing to change / upgrade the memory, then cards and modules are available; and the PCB will have a card slot or connector.
Removable memory formats also include USB devices (e.g. memory sticks / thumb drives) and SD / microSD cards. Though capacities might not be as large, they are sufficient for most 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:
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 is essential part of the hardware foundation of an embedded system.
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.
BACK TO INDEX
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:
| Level | Description |
|---|---|
| CC EAL 1 | Functionally Tested |
| CC EAL 2 | Structurally Tested |
| CC EAL 3 | Methodically Tested and Checked |
| CC EAL 4 | Methodically Designed, Tested, and Reviewed |
| CC EAL 5 | Semi-formally Designed and Tested |
| CC EAL 6 | Semi-formally Verified Design and Tested |
| CC EAL 7 | Formally Verified Design and Tested |
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.