Enhancing Device Security beyond Firmware Encryption

In today’s fast-paced digital world, securing embedded devices have become increasingly important. The firmware of a device is one of its most critical components, as it provides the basic instructions for the device to operate. Unfortunately, it's also an attractive target for hackers, who can exploit firmware vulnerabilities to take control of a device, so protecting it is a key element in firmware security engineering. If you are new to firmware security, we recommend you check out this article where we covered 7 questions and answers about firmware.

What is Firmware Encryption?

Firmware encryption is a method of protecting the firmware of a device from unauthorized access. We take the final compiled firmware image that is in readable plain text format and use an encryption algorithm (e.g RSA) to transform it into a so-called ciphertext. Ciphertext refers to encrypted data or text that has been transformed into a form that is unreadable without the appropriate decryption key or password.

By encrypting the firmware, a device's manufacturer can ensure that malicious adversaries are not able to access the firmware and make changes to it.

Security Claims about Firmware Encryption

Many IoT (Internet of Things) manufacturers claim that their firmware is encrypted on the persistent storage of their devices, and actively rely on this information in their value proposition.

In many cases, these vendors also claim that users don’t have to worry about firmware security threats because of this, since the used cryptographic algorithms are strong enough to hide the (potentially vulnerable) code from attackers. In this article, we will attempt to demonstrate that this assumption is false, and that firmware encryption is not a sufficient solution that magically solves all IoT security-related problems.

In the sections below, we’ll walk you through common firmware hacking techniques that adversaries may use to bypass firmware encryption.

Firmware Encryption Hardware Hacking Techniques

These techniques are all relatively easy, fast, and cheap to execute. All you need is an oscilloscope and a soldering iron. We used to call these “under-one-hour” attacks during our days as pentesters.

The firmware readout process typically involves connecting the IoT device to a computer or another device and using software tools to extract the firmware from the device's non-volatile memory. An adversary will start with the easiest method.

Firmware Readout via UART

First, the attacker identifies the UART port using an oscilloscope and solders pins to it. Some tools can connect to this port without soldering, but the point is that this is not time-consuming in any way, using a special connector or soldering a few pins can be done in a matter of minutes. If the manufacturer has not restricted access to the UART port, it might present a shell and allow an attacker to gain access to the device's underlying system, including sensitive data and system files, or to execute malicious code or manipulate the device's behavior.

They might also use it to dump the entire firmware from the device using a simple utility such as ‘dd’ or a similar command provided by the bootloader. (Such a dump could actually also include configuration partition data as well that in turn could lead to other interesting attack vectors that we won’t investigate here.)

Let’s assume the firmware is encrypted at rest. In case of system shells or bootloader command line access, parts of plaintext system software will still be available via software interfaces, since the CPU requires it to be decrypted for execution. One notable exception is when the system features some kind of TEE and normal world/secure world separation. In that case, the bootloader or rich OS that we have access to via UART might only provide access to the code that it naturally has access to given its privilege level. Unfortunately, many applications don’t utilize technologies such as ARM TrustZone to protect the necessary assets, even if it is supported on the platform, and a large chunk of the firmware, potentially including sensitive cryptographic material will be available through readouts this way.

Firmware Readout via JTAG

The second attack vector is the JTAG interface. If a manufacturer didn't close the JTAG port on an IoT device, it could also result in a security vulnerability or the attacker can read out the firmware.

Just like with an open UART port, an attacker could use an open JTAG port to gain access to the device's underlying system. Similarly, the adversary will be able to read out plaintext firmware from your device most of the time, although performing this would probably require her to look up datasheets on the SoC and/or acquire the necessary interface dongles, drivers, and supporting software. In practice, there is an extensive amount of information present online for many SoC platforms sharing the same debug tooling, including previous research done by others available on GitHub, including scripts, offset information, workarounds on certain problems, etc.

Now, let’s assume these two ports are closed properly.

Flash Direct Readout

The next possible way to gain access to the firmware is to read out the data contents of the Flash or EEPROM chip directly. The difficulty of the read-out is increasing with the type of chip packaging. If the packaging is SOT, SOP, or TSOP, the readout can be done via $30 devices in a couple of minutes and the probability of bricking the devices is pretty low.

On the other hand, if the chip packaging is BGA (Ball Grid Array), dumping the flash is much harder and more time-consuming (a couple of hours and $1000 worth of equipment might be necessary). The possibility of bricking the device is increased accordingly.

If all information on the flash was encrypted, dumping contents in itself would not lead to the compromise of the confidentiality of the asset. However, based on our experience, there are often problems with how this is actually implemented. Even if the vendor uses strong cryptography, such as AES in a sufficiently secure mode (and not something obscure and senseless like XOR’ing with a 16-bit constant), the confidentiality of the resulting encrypted image will be compromised if the corresponding key is compromised. Key management will therefore be crucial for these systems, however, provisioning device unique keys is non-trivial for many designs, and to properly protect encryption keys, one must also implement a proper boot trust chain and rely on the hardware root of trust capabilities of the SoC, when present. Keys hardcoded into bootloader binaries or image header structures will definitely not do the trick.

Manufacturers have generally focused on reducing time-to-market delays and on cost-effectiveness, but hardware security measures are often overlooked and not budgeted for. Therefore, vendors tend to choose the cheapest PCB design available for them. When we say cheap design, what we really mean is that the number of layers used is two.

Since the data is “traveling” in the traces found on the upper or the bottom layer of the PCB, adversaries can easily identify these and they can use “bus snooping” or “bus sniffing” techniques. The method is simple. They download the memory chip’s datasheet and identify each data pin on it (for example TDI, TDO, and TCK pins). After that, they simply scratch the solder mask layer and solder a thin wire to each trace and sniff the communication between the CPU and the RAM. With this method, they can read out the decrypted plain firmware. However, this method requires more precise and more expensive equipment

Firmware Readout via Runtime Vulnerabilities

Compromising the software integrity of the running device will almost surely compromise the confidentiality of the firmware image as well, even if it is encrypted at rest. A buffer overflow, a command injection, or another code execution vector will enable attackers to get hold of memory contents or software interfaces (for example, a dm-crypt block device) that will allow them to dump plaintext data. It is often the case that these can be found and exploited in a black-box manner, just by auditing an available web interface or fuzzing a networking service listening on the device.

Assuming that attackers will not be able to find vulnerabilities in a device without access to plaintext firmware and reverse engineering methods is simply wrong, and relying on that is harmful.

Adopting such a threat model is essentially relying on security by obscurity. It could easily lead to neglecting firmware security altogether and runtime compromises in that case will actually have a tenfold risk impact on the security posture of the device. This practice is strongly discouraged by security practitioners and standards bodies alike, for instance, the National Institute of Standards and Technology (NIST) in the United States recommends against this practice: "System security should not depend on the secrecy of the implementation or its components.”

If it sounds like a too complicated and time-consuming attack, let us assure you - it is not. We once visited a conference where a provider was absolutely certain about the protection their encryption method provides. As pentesters, we could not refrain from the challenge, and going back to our hotel room, we managed to extract the firmware within a few minutes, without any big equipment.

IoT device firmware should be resilient against attacks even if the attacker has access to plaintext firmware, a requirement that should be verified by executing grey-box embedded systems penetration tests or checking that firmware analysis and other code analysis tools report no practical vulnerabilities.

How Can You Mitigate Firmware Exposure Risks?

The attack scenarios above can be mitigated and IoT systems can be hardened against a range of potential misuse cases.

There are upcoming regulations that demand different countermeasures in addition to firmware encryption. One example is the ETSI baseline (EN 303 645-v2.1.1) which is becoming a central certification scheme in the EU that contains relevant requirements such as:

Provision 5.4-1 Sensitive security parameters in persistent storage shall be stored securely by the device.

In this section, we provide a few mitigation techniques that you can use in your own embedded systems designs.

UART port countermeasures

Let’s review countermeasures, from most secure to least secure.

1. Disable the UART interface through OTP fuses (internal bits of the chip that, once programmed, can no longer be changed). This is the most secure way.
2. Encrypt data transmitted over the UART interface: This can help prevent eavesdropping or tampering with the data being transmitted
3. Do not expose a serial console on UART ports.
4. Implement secure boot: Ensure that the system's firmware and software are secure, and prevent unauthorized modifications to the system.
5. Implement access control: Limit access to the UART port to only trusted users or devices. This can be achieved through authentication mechanisms, such as passwords or digital certificates.
6. Disable the UART port when it is not in use: This can be done by physically disconnecting the UART connection or by disabling the UART interface in the software.

JTAG countermeasures

1. Completely disable the JTAG interface through some OTP fuses.
2. Reconfiguration of the JTAG pins in software.
3. Obfuscation (cutting tracks, removing resistors, etc.) Not a strong countermeasure, however, it could increase the attack complexity.

It is interesting to note that in principle, it is still possible to re-enable the JTAG interface with techniques such as a silicon die attack. This, however, requires super expensive equipment such as a gamma-ray laser, special knowledge, and experience, so it will most likely not be a commonly exploited weakness.

Firmware Readout Countermeasures

Firmware encryption itself is of course a necessary measure to protect the confidentiality of software. However, the system can be further hardened if we select BGA-packaged memories or on-chip NVMs. If the product is cost sensitive, we can use special security glues. If an attacker wants to remove the glue from the PCB it will destroy the traces and other passive components as well. This method is also a good countermeasure for bus sniffing; however, we highly recommend using at least 4-layer PCBs and re-organizing the data traces into the inner layers.

Our Verdict about Firmware Encryption

In conclusion, although firmware encryption is not at all a sufficient measure for IoT device security by itself, it is a crucial step in securing digital devices and protecting them from unauthorized access. It provides an added layer of security and privacy and helps organizations meet compliance requirements.

However, relying only on firmware encryption is essentially „security by obscurity”, a practice that is discouraged by the security community and cybersecurity standards bodies alike. And we agree with this opinion wholeheartedly.