Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Using Threat Models and Risk Assessments to Define Device Security Requirements
By: Dana Neustadter, Product Marketing Manager, Security IP
Introduction
The proliferation of attacks, breaches and malicious ransomware makes many designers realize they need to secure their products and ecosystems. This article describes the types of threats most common today, provides guidance on which ones are relevant by determining the threats and related risk, and suggests security measures to help prevent some of these attacks. Security implementations need to be designed into the heart of the product — the system on chip (SoC) — through a combination of software, hardware and physical design.
Types of Threats
Security threats can be classified into a few different categories. Threats can be remote or local non-invasive attacks, or physically invasive and even destructive. The purpose of these attacks is to acquire specific assets or to interrupt access to a service, enabling the attacker to gain notoriety, corporate/government intelligence or financial incentives. Figure 1 highlights the fact that threats range in cost and effort to attack and that there is a correlated cost in the effort to implement thorough security countermeasures.
Figure 1: Types of threats
Remote attacks are usually the starting point for attacking an ecosystems of devices. Using known vulnerabilities in specific implementations of protocols is also practical due to the use of easily accessible pre-written attack scripts. Attackers are able to monitor non-encrypted traffic to gain information about the system, allowing them to escalate the attack to get control of the device. Buffer overflows or poor authentication practices are the most common way of getting control of an individual device.
Once an attacker has access to a device, they are able to steal assets such as user data, cryptographic keys or intellectual property in the form of proprietary algorithms. Depending on the device and the assets gained, these 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 may become permanent if the regular firmware update procedure is leveraged where no secure boot authentication process was implemented in the SoC.
Figure 2: Threat assessment of non-invasive attacks
If the attacker has physical access to a device, another set of attacks can be performed. These can be non-invasive passive attacks, or very invasive, up to the point of destruction of the device. Non-invasive attacks include bus monitoring via JTAG or logic analyzer, port scanning, and GPIO manipulation. More advanced non-invasive attacks include side-channel attacks through power or timing analysis.
Another local and physically invasive attack is fault injection, resulting in a change of device state. This attack causes denial of service or unintended behavior of the device.
Invasive attacks are more costly since they require specialized equipment. These include de-capsulation of a chip, etching away layers of the semiconductor substrate, and electron microscope scanning to reveal cryptographic keys or design logic.
Threat Model
The first step in defining security requirements for an SoC is to understand the usage and threat model applied to the product. This is not an easy task because one SoC design can be used in many products that address different markets and therefore have various usage models. Designers are advised to go through a threat and risk assessment (TRA) for their SoC, device and ecosystem. There are published methodologies for performing this task, as well as specialized companies to walk through 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 will be classified to have one or more values related to their confidentiality, availability or integrity. The TRA process is not a means to an end, but is a continual process. Once started, it should be reviewed regularly to ensure that the protection mechanisms currently in place should adequately address the security requirements.
When evaluating the risk, the designers need to take into account the attacker's motivation to attack, the tools, equipment, skills, time, and money they need to break the system as well as the probability of success. Generally, if the cost to break the system is higher than the benefit, then an attacker will not attempt to break the system.
Sometimes, new attack models or new tools are invented or become general knowledge. In addition, the cost for attacks drops with reduction in the price of equipment and tools. Therefore, the classification of these threats can change over time, resulting in some devices with high tamper protection levels becoming easily compromised one day when a new, low-cost attack is found.
It is extremely difficult to measure or evaluate the damage impact of an attack from a system perspective. The damage can range from device failure, service interruption and monetary loss to brand damage. The designer of the system has to understand these impacts when assessing the potential damage.
Security Implementations
To determine the best way to mitigate the risks found during the threat assessment, each implementation must be considered for the cost-benefit tradeoff. The levels of response can be categorized into three general areas: software, hardware or enhanced hardware protection mechanisms.
Software implementations address many security threats. The use of approved cryptographic algorithms and tested protocol implementations provides basic protection. 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 introducing unwanted vulnerabilities. These methods are the easiest and cheapest to implement, as well as compromise.
Hardware implementations of cryptographic algorithms increase performance, but also increase the security. This is done by creating an isolated hardware environments that protects keys and data from observation. A full hardware secure module based on a root of trust with key laddering isolates all the critical assets from remote attacks. Hardware solutions take more silicon area to implement, but meet higher performance requirements.
Enhanced hardware security features provide resistance to the security threats including differential power analysis (DPA) 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 a high level architecture view of a SoC targeted at simple IoT devices. The callouts relate to various threats and attacks. The itemized list below describes these in more detail and suggests security responses to counteract the threat.
- Replace program memory with malicious boot loader, operating system or application
a. Implement a secure boot process to validate all executable code before execution. The initial boot code and the key used to perform these checks must not be modifiable. - Theft of software algorithms or other intellectual property from program memory
a. Implement a secure boot process to store the code encrypted and only decrypt the code into a local secure memory before execution. - Theft of user data from memory
a. Encrypt the user data or other assets with cryptographic algorithms implemented in software (or hardware for higher performance) to prevent attackers from reading the memory. - Read keys from system bus
a. Disable JTAG or other debug access ports by blowing fuses or programmatic control. Only re-enable via a secure process and destroy all critical security parameters before granting access. - Interception or replay of external communication
a. Encrypt network traffic with a tested and validated protocol such as TLS (Transport Layer Security) or something similar. Encryption prevents attackers from intercepting the data being transferred between endpoints. It is also important to generate random session keys with a TRNG (True Random Number Generator) so that packets cannot be replayed on the network. - Exploited code vulnerabilities gain access to other applications or assets
a. A CPU designed with separate regions of memory protection enables isolation of applications and data from rogue applications.
Figure 3: Threats and attacks on an IoT SoC
Synopsys provides a complete line of hardware security IP, software cryptography library and secure boot SDKs, along with pre-integrated subsystems that combine these components. Synopsys also has complete development and testing tools for implementing “secure by design” best practices into the development process.
Conclusion
Many security threats exist today and are continually evolving, creating disruption of services and theft of critical assets. Security and trust must be designed into the ecosystem; it can’t be bolted on later. Designing a secure ecosystem starts with securing individual devices, which is enabled 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.