Security Starts With A Threat Assessment

Developing the security architecture for an electronic device begins with building a threat model wherein we ask these questions:

• What is the operational environment in which the device needs to function?
• What type of attacks can be identified?
• What level of access does a potential attacker have to the device?
• What possible attack paths can an attacker exploit?
• What resources (money, time), expertise and specialized equipment would a potential attacker be willing to expend given the value of assets at risk?
• What would be the damage incurred if an attacker successfully obtained control over a device or its data?

Based on the threat assessment, security architects can define the right level of security for their device and how it is to be implemented and maintained. In this blog, let’s take that second question and consider the kinds of attacks that we could expect.

First, let’s consider remote attacks. These are attacks that do not require ‘physical proximity’ of the attacker and the device being attacked. Attacks through a network interface that target rogue software execution on the device processor (e.g., buffer overflow attacks) could enable an attacker to:

• Exploit by execution of non-trusted or 3rd-party code
• Steal data being sent to or from a device
• Attempt to corrupt or replay data in transit

Remote attacks tend to be cheap to perform and scale very well, allowing attacks on other identical devices.

Often, to identify an exploitable vulnerability, an attacker may purchase multiple devices and attempt to reverse engineer or extract the software running on the device in a more forceful way, potentially damaging or destroying a few devices, to find remotely exploitable vulnerabilities. In addition, if the software used to drive the network stack is well known (e.g., Linux) then the attacker may already have identified vulnerabilities through other means.

If an attacker can gain physical access to the device, this opens new avenues for exploitation. These “local access” attacks are often categorized into three rough groups, with increasing attack complexity and cost:

• Board-level attacks. These attacks can be mounted using simple tools like a screwdriver, a soldering iron, or a JTAG-based debugging tool, replacing components or connecting to the board or chip debug infrastructure. Examples: Flash chip replacement; debug interface access; scan chain/test logic access; inter-chip bus monitoring.
• Chip-level non-invasive attacks. This type of attack targets the chip itself while it is in operation without damaging the chip. Attacks of this type typically require the chip to be connected to an oscilloscope and/or dedicated hardware for measuring, capturing, and analyzing electrical behavior of the chip. Side channel attacks such as differential power analysis are well known non-invasive attacks that can successfully reveal used key materials in unprotected implementations.
• Chip-level invasive attacks. This class of attacks actually “open up” the chip by removing its packaging, exposing the die to allow direct access to the wiring and memory structures within the chip. To perform an attack like this requires the use of specialized or bespoke equipment that is expensive and complex to operate. Such equipment can sometimes be rented from universities or companies specialized in reverse engineering of chips, but nevertheless, will require a larger investment from the attacker to get to the information sought.

A third major category of attacks, which we can refer to as “logical attacks,” are those that exploit weak security implementations. Most applications use cryptographic algorithms to protect the valuable data assets. The security provided by a cryptographic algorithm, in turn, relies on the ability of the application to keep the required key material secure and unpredictable to an attacker. Unfortunately, and quite frequently, cryptographically protected applications are compromised because a cryptographic operation or protocol is implemented in an insecure manner. This tends to be a weakness of “home grown” security solutions.

An example of the above is the weak implementation of the source of randomness. Cryptographic operations and protocols require a good quality random number generator to ensure truly random data. Among other things, random data is used in key generation and to provide an unpredictable component (nonce) in signature operations to protect the private key. A low quality or poorly implemented random number generator will result in the generation of data that is predictable to an attacker. Other examples of weak implementations are using outdated cipher algorithms, insufficient key strengths, and improper use of keys. The improper use of keys include: using immutable keys directly instead of using keys derived from the immutable keys in a secure way; storing keys in insecure locations, say in off-chip memory in unencrypted form; or storing keys in on-chip locations that are accessible by software leading to key misuse or leakage.

Beyond the categories of direct attacks on the device, one must also consider attacks on its supporting infrastructure. During a device’s lifecycle, it may:

• Require software or firmware updates
• Receive key material (new or updated) or other security sensitive assets
• Require other types of maintenance access

The security of the infrastructure providing these updates is critical to the security of all devices in the ecosystem.

Rather than attacking the device directly, an attacker may try to find a vulnerability in the infrastructure that creates and distributes these updates.

The upshot is the analysis of possible threats which feeds into the development of the threat model can itself be a very daunting task. Find additional resources below.

Additional resources:

• Website: Rambus Root of Trust Solutions
• Website: Rambus Secure Protocol Engines
• Website: Rambus Provisioning and Key Management