Security in microcontrollers means protecting embedded firmware, data, and the system functionality. The need for data protection is greatest in the case of cryptographic keys or personal data.
The firmware code is also an important asset. If an attacker gains access to the binary, they can reverse-engineer the program in an attempt to find further vulnerabilities, bypass licensing, and software restrictions. The attacker can copy any custom algorithms, or even use it to flash a clone of the hardware. Even in the case of open-source software, it makes sense to attest that the code is authentic, and not replaced by malicious firmware.
Denial-of-service attack (DoS attack) is another major threat when considering protection systems (such as environmental: gas, fire, or intrusion), detection alarms or surveillance cameras. The system functionality must be robust and reliable.
The requirement for security must not be underestimated even if it adds more complexity to the system. Today, systems built around microcontrollers become potential targets for more and more skilled attackers who expect financial gains. These gains can be very high, especially if the attack can be propagated to a large scale, as in the context of the IoT. Even if no system is completely secure, it is possible to make the attack more expensive.
Indeed IoT, or smart devices, have increased the requirement for security. Connected devices are very attractive for hackers because they are remotely accessible. The connectivity offers an angle-of-attack through protocol vulnerabilities. In the case of a successful attack, a single compromised device can jeopardize the integrity of an entire network (see the figure below).Figure 1. Corrupted connected device threat
What must be protected
Security cannot be limited to a certain target or asset. It is difficult to protect data if the code binary is exposed. However, it is still useful to summarize the assets and risks.
The table below presents a non-exhaustive list of assets targeted by attackers.
Table 3. Assets to be protected
Target
Assets
Risks
Data
Sensor data (such as healthcare data or log of positions)
User data (such as ID, PIN, password, or accounts)
Transactions logs
Cryptographic keys
Unauthorized sale of personal data
Usurpation
Spying
Blackmail
Control of device (bootloader, malicious application)
Device correct functionality
Device/user identity
Denial of service
Attacks on service providers
Fraudulent access to service (cloud)
User code
Device hardware architecture/design
Software patent/architecture
Technology patents
Device counterfeit
Software counterfeit
Software modification
Access to secure areas
Vulnerability, threat, and attack
Protection mechanisms have to deal with different threats. The objective is to remove vulnerabilities that could be exploited in an attack. An overview of main attack types is presented in Attack types, from the basic ones to the most advanced ones.
The following specific wording is used around security:
Asset: what needs to be protected
Threat: what the device/user need to be protected against
Vulnerability: weakness or gap in a protection mechanism
In summary, an attack is the realization of a threat that exploits a system vulnerability to access an asset.
Attack types
This section presents the different types of attack that a microcontroller in finished product may have to face, from the most basic ones to very sophisticated and expensive ones. The last part presents typical examples of attacks targeting an IoT system.
Attacks on microcontroller are classified in one of the following types:
Software attack: exploits software vulnerabilities (such as bug or protocol weaknesses).
Hardware non-invasive attack: focuses on MCU interfaces and environment information.
Hardware invasive attack: destructive attack with direct access to silicon.
Separate category would be an attempt to compromise manufacturing security, where ST is helping by providing SFI (secure firmware install).
Introduction to attack types
A key rule in security is that a successful attack is always possible.
First, there is no absolute protection against unexpected attack. Whatever the security measures taken to protect a system, it is possible that a security breach is found and exploited during the device lifetime. This last point makes it necessary to consider how the device firmware is updated to increase its security (see Secure firmware update (SFU)).
Secondly, in laboratory conditions with proper equipment, it is possible to retrieve microcontroller content, or even its design architecture details. These techniques are briefly presented in Hardware attacks.
From an attacker's point of view, an attack is most profitable if the ratio expected revenue/attack cost is as high as possible. The revenue depends on the stolen asset value, and on the repeatability of the attack. The cost depends on time, the acquisition of the necessary skills by the attacker, and on money (equipment) spent to succeed.
Attack types
While there are more detailed groups and categories of attack, the basic categories are the following ones:
Software attacks are carried by exploiting bugs, protocol weaknesses, or untrusted pieces of code among others. Attacks on communication channels (interception or usurpation) are part of this category. Software attacks represent the vast majority of cases. Their cost may be very low. They can be widely spread and repeated with huge damage. It is not necessary to have a physical access to the device. The attack can be executed remotely.
Hardware attacks need physical access to the device. The most obvious one exploits the debug port, if it is not protected. However, in general, hardware attacks are sophisticated and can be very expensive. They are carried out with specific materials and require electronics engineering skills. A distinction is made between noninvasive attacks (carried out at board or chip level without device destruction), and invasive attacks (carried out at device-silicon level with package destruction). In most cases, such an attack is only profitable if it reveals information that leads to a new and widely applicable remote attack.
The table below gives an overview of the cost and techniques used for each type of attack.
Table 4. Attacks types and costs
Attacks types
Non-invasive
Semi–invasive
Invasive
-
Scope
Remote or local
Local board and device level
Local device level
Techniques
Software bugs
Protocol weaknesses
Trojan horse
Eavesdropping
Debug port
Power glitches
Fault injection
Side-channels analysis
Probing
Laser
FIB
Reverse engineering
Cost/expertise
From very low to high, depending on the security failure targeted
Quite low cost. Need only moderately sophisticated equipment and knowledge to implement.
Very expensive. Need dedicated equipment and very specific skills.
Objectives
Access to confidential assets (code and data).
Usurpation
Denial of service
Access to secret data or device internal behavior (algorithm).
Reverse engineering of the device (silicon intellectual property)
Access to hidden hardware and software secrets (flash memory access)
Software attacks
Software attacks are carried out on the system by executing a piece of code, named a malware, by the CPU. The malware takes control of the device in order to get access to any resources of the system (such as ID, RAM, and flash memory content or peripheral registers), or to modify its functionality.
This type of attack represents most of device threats for the following reasons:
The attack cost is low since it does not need specific equipment but a personal computer.
Many hackers can put their effort together, sharing their expertise and tricks, so that a successful attack is likely to happen if a security breach exists. Furthermore, in case of success, the attack protocol may spread very quickly through the web.
The malware can be injected into the device or can already be present (insider threat) in main application firmware through a nonverified or untrustworthy library for example. Malwares are of many types and they can be very small and easy to hide.
Here are examples of what a malware can do:
Modify device configuration (such as option bytes or memory attributes).
Disable protections.
Read memory and dump its content for firmware and data cloning.
Trace or log device data.
Access to cryptographic items.
Open communication channel/interface.
Modify or block the device functionality.
Unless user application is fully trusted, bug-free, and isolated, without any means to communicate with external world, software attacks must be considered.
Malware injection
There are various methods to inject a piece of code inside the system. The size of the malware depends on the target but may be very small (few tens of bytes). To be executed, the malware must be injected in the device memory (RAM or flash memory). Once injected, the challenge is to have it executed by the CPU, which means that the PC (program counter) must branch to it.
Methods of injecting malware can be categorized as follows:
basics device access/"open doors”:
Debug port: JTAG or SWD interface.
Bootloader: if accessible, can be used to read/write memory content through any available interface.
Execution from external memory.
These malware injections are easy to counter with simple hardware mechanisms that are described in Device protections.
Application download:
Firmware update procedure: a malware can be transferred instead of a new FW.
OS with capability to download new applications.
This category countermeasure is based on authentication between the device and the server or directly with code authentication. Authentication relies on cryptography algorithms.
Weaknesses of communication ports and bugs exploitation:
Execution of data. Sometimes it is possible to sneak the malware in as data, and to exploit incorrect boundary check to execute it.
This third category is by definition difficult to circumvent. Most embedded system applications are coded using low-level languages such as C/C++. These languages are considered unsafe because they can lead to memory management errors leveraged by attackers (such as stack, heap, or buffers overflow). The general idea is to reduce as much as possible what is called the attack surface, by minimizing the untrusted or unverified part of firmware. One solution consists in isolating the execution and the resources of the different processes. For example, the TF-M includes such a mechanism.
Use of untrusted libraries with device back door:
This last category is an intentional malware introduction that facilitates device corruption. Today, lot of firmware developments rely on software shared on the web and complex ones can hide Trojan horses. As in previous category, the way to countermeasure this threat is to reduce the surface attack by isolating as much as possible the process execution and protecting the critical code and data.
Brute forcing
This type of attack targets the authentication based on a shared secret. A secure device may require a session authentication before accessing services (in the cloud for example) and a human machine interface (HMI) can be exploited with an automatic process in order to try successive passwords exhaustively.
Interesting countermeasures are listed below:
Limit the number of login trials with a monotonic counter (implemented with a timer, or if possible, with a backup domain).
Increase the delay between consecutive login attempts.
Add a challenge-response mechanism to break automatic trials.
