Using threat models and risk assessments to define device security requirements
The proliferation of attacks against embedded systems is making designers realize that they need to do more to secure their products and ecosystems.
The proliferation of attacks against embedded systems is making designers realize that they need to do more to secure their products and ecosystems. This article describes the most common threats, offers guidance on which are most important, and suggests security measures to help prevent these attacks. Security implementations need to be designed into the system-on-chip (SoC) through a combination of software, hardware, and physical design.
Types of threat
There are several types of security threats, including remote or local non-invasive; physically invasive; and destructive attacks. Destructive attacks usually try to acquire specific assets or to interrupt access to a service, enabling the attacker to gain notoriety, valuable intelligence or simply money. Figure 1 shows the relationship between the cost and effort of making an attack and the cost to implement countermeasures.
Figure 1 Types of threats (Source: Synopsys)
Remote attacks
Device ecosystems, such as home automation systems, are example targets for remote attacks. Attackers also often use easily obtained scripts to attack vulnerabilities in specific implementations of protocols. Attackers can monitor non-encrypted traffic to gain information about the system, enabling them to escalate the attack to take control of the device. The most common way of getting control of a device is through buffer overflows or poor authentication.
Once an attacker has access to a device they can steal assets such as user data, cryptographic keys, or intellectual property such as proprietary algorithms. The los of such assets can be catastrophic for the ecosystem.
A more advanced attack replaces the firmware on the system. This is usually temporary until the next boot cycle, but it can become permanent if the regular firmware update procedure is used and the SoC does not have a secure boot authentication process. Secure boot is the first step in securing a system by checking that it came out of reset in an expected state and that its firmware is intact and has not been tampered with. It should be considered as a foundational security feature in any device.
Figure 2 Threat assessment of non-invasive attacks (Source: Synopsys)
Physical attacks
If attackers have physical access to a device, they can attempt non-invasive passive attacks, or invasive attacks that can range in severity up to the point at which the device is destroyed.
Simple non-invasive attacks include bus monitoring via JTAG or logic analyzer, port scanning, and GPIO manipulation. More complex non-invasive attacks include side-channel attacks through power or timing analysis. Fault injection can also be used to cause denial of service or even unintended behavior in a device, resulting in a change of its state.
Invasive attacks are more costly because they require specialized equipment. These include de-capsulation of a chip, etching away layers of the semiconductor substrate, and electron microscopy to reveal cryptographic keys or design logic.
Threat models
The first step in defining security requirements for an SoC is to understand what assets it is important to protect, how the SoC is going to be used and how it could be threatened . This can be complex if SoCs have been designed to address multiple markets and be used in different ways.
Designers should do a threat and risk assessment for their SoC, device and ecosystem. There are published methodologies for performing this task, as well as consultancies that can help designers apply the process. Generally, there are four main steps:
- Establish the scope of assessment and identify assets
- Determine the threat to the assets and assess the impact and probability of occurrence
- Assess vulnerabilities based on the implemented protection and calculate the risks
- Implement additional protection to reduce the risks to acceptable levels
All assets are classified as having one or more values related to their confidentiality, availability and integrity. This process should continue throughout the usage lifetime of the device, to ensure that the protection mechanisms in place meet current security needs.
Evaluating risk
Designers need to take into account an attacker’s motivation, the tools, equipment, skills, time, and money they need to break into a system, and the probability of success in order to judge risk. Generally, if the cost to break into a system is greater than the benefit of doing so, then no one attacks it because there are no incentives.
Sometimes, new attack models or tools are developed or become available, altering this calculus. This means that devices that were once rated as to be highly tamper resistant suddenly become easily compromised when a new attack emerges.
Measuring or evaluating the damage impact of an attack from a system perspective can be extremely difficult. The damage can range from device failure, service interruption and monetary loss, to brand damage. The designer of the system must understand these impacts when assessing potential damage.
Security implementations
To reduce the risks revealed during the threat assessment, the cost/benefit tradeoff for each response must be considered. There are three broad categories of possible response, which are, in order of cost and vulnerability to compromise: software, hardware, and enhanced hardware protection mechanisms.
Software can address many security threats. Using approved cryptographic algorithms and tested protocol implementations can provide basic protections. A software-based secure boot process, started from ROM, creates a trusted environment to execute validated application code. Software development processes, such as implementing secure coding guidelines and fuzz testing, can help prevent the introduction of vulnerabilities.
Hardware implementations of cryptographic algorithms increase performance and security, by creating an isolated hardware environment that protects keys, data and operations from observation. A complete hardware security module, based on a root of trust and implementing a ladder of keys, isolates critical assets from remote attacks. Hardware solutions take more silicon area to implement, but meet higher performance requirements.
Enhanced hardware security features help resist security threats such as differential power analysis and timing attacks. Other enhanced features counter specialized fault injection techniques. These techniques are more difficult to implement and it is also difficult to validate the efficacy of the counter measure.
SoC design example
Figure 3 shows an architectural view of an SoC targeted at simple IoT devices. The callouts relate to various threats and attacks, and are listed below along with suggested responses to the threat.
1 – Attack: Replace program memory with malicious boot loader, operating system or application
Response: Implement a secure boot process to validate executable code before it runs. The initial boot code and the key used to perform these checks must not be modifiable.
2 – Attack: Theft of software algorithms or other intellectual property from program memory
Response: Implement a secure boot process to encrypt stored code and only decrypt it into a local secure memory before execution.
3 – Attack: Theft of user data from memory
Response: Encrypt the user data or other assets with cryptographic algorithms implemented in software (or hardware for higher performance).
4 – Attack: Read keys from system bus
Response: Disable JTAG and other debug access ports by blowing fuses or programmatic control. Only re-enable them using a secure process (e.g. certificate based identification and authentication). Destroy all critical security parameters before granting access.
5- Attack: Interception or replay of external communication
Response: Encrypt network traffic with a validated protocol such as TLS (Transport Layer Security) or similar. Encryption prevents attackers from intercepting the data being transferred between endpoints. Generate random session keys with a true random number generator so that packets cannot be replayed on the network
6 – Attack: Exploit code vulnerabilities gain access to other applications or assets
Response: A CPU designed with separate regions of memory protection can isolate applications and data from rogue applications.
Figure 3 Threats and attacks on an IoT SoC (Source: Synopsys)
Synopsys’ highly configurable security IP solutions include Root of Trust, content protection, cryptography, and security protocol accelerators for integration into SoCs. These integrated solutions enable the heart of many security standards, supporting confidentiality, data integrity, user/system authentication, non-repudiation, and positive authorization. Combined, Synopsys’ security IP solutions help prevent a wide range of evolving threats in connected devices such as theft, tampering, side channels attacks, malware and data breaches.
Conclusion
Security threats are evolving, threatening disrupted services and the loss of critical assets. Security and trust must be designed into an SoC and the ecosystem it serves, by including security features in the architecture of the controlling SoCs. Design engineers must manage the risk of the various attacks by selecting the appropriate levels of protection to build a cost effective and robust product.
Further information
Security vulnerability assessment overview
Security vulnerability assessment checklist
Author
Dana Neustadter is product marketing manager for security IP at Synopsys
