The old way of delivering a product to market was to reuse as much IP as possible and verify that the correct functionality has been achieved. Todays secure systems such as smart cards and embedded systems can no longer rely on this design method.
Throughout the supply chain, it is vulnerable to deliberate attacks and design faults.   When manufacturers moved to a re-use model of IC design, this plug and play concept reduced design times, risk and time to market. IP could be used that was already proven in silicon. However, this model of production, especially when the IP is delivered from outside of the organisation, can be vulnerable to trojan attacks. When IP is delivered from an external source, it should be verified for not only its functionality but also its security features. This is especially true of secure IP which may, for example, form part of a cryptographic engine. There may also be vulnerabilities from internal IP. Malicious insiders (who could range from disgruntled employees to state actors) could insert small amounts of circuitry that either change the functionality of the device, destroy it or leak valuable information such as encryption keys. Security breaches can also be caused through non-malicious actions. Assumptions made about circuitry interfaced to secure IP blocks can also cause an issue if its assumed that certain secure functionality is provided by interconnected blocks and this functionality is not available. A special design flow is needed to ensure that private information does not move from a secure environment to a less secure environment without being encrypted and that less secure environments do not have direct access to highly sensitive information.   During the early part of the year 2000, many semiconductor companies either outsourced their manufacturing or joined forces to share fabs. This model worked before trojans were found in military products destined for the States and caused the US government and others to re-think what happens to designs when they are sent for fabrication. Now, the supply chain was seen to be vulnerable. Many fabs have instigated procedures to prove they are secure such as RFID labeling of devices and people working within the fab and also forensic tracing of devices and people.

ATTACKING EMBEDDED HARDWARE

rootoftrust training provides the skills to counteract attacks

OVERVIEW

The old way of delivering a product to market was to reuse as much IP as possible and verify that the correct functionality has been achieved. Todays secure systems such as smart cards and embedded systems can no longer rely on this design method.

 

ATTACK VECTORS

When manufacturers moved to a re-use model of IC design, this plug and play concept reduced design times, risk and time to market. IP could be used that was already proven in silicon. However, this model of production, especially when the IP is delivered from outside of the organisation, can be vulnerable to trojan attacks. Malicious insiders (who could range from disgruntled employees to state actors) could insert small amounts of circuitry that either change the functionality of the device, destroy it or leak valuable information. Hardware trojans are covered in our article.

Power analysis was the most simple of attacks to be discovered and could be carried out for relatively little cost by attackers of medium skill level. One of the first attacks carried out used a resistor coupled to a power and ground pin to measure the current flow during computations. Recording and then analysing the traces showed clear patterns of when a bit changed from 0 to 1 or from 1 to 0. The more simple attacks now have countermeasures and more complex attacks such as differential power analysis and the use of machine learning are required.

Fault attacks rely on disrupting the normal operation of the device under attack. This can be achieved by sending voltage or clock glitches to underpower the device or disturb timing through an extra clock edge. The ability to cause an error in computation allows the attacker to undertake a differential fault attack. The attacker tries to encrypt the same message (plaintext) a number of times to produce a number of ciphertexts. In principle, the ciphertexts should be the same, however, if the attacker is able to induce a fault in the latter stages of computation, he or she can learn information about the key used by comparing the different ciphertext values.

Timing attacks are one of the oldest attacks to be developed and concentrate on the differences in time taken for certain computations. In hardware, all computation is carried out in binary. Safeguards had to be put into place to check for an attempt to divide a number by zero. This usually involved creating a branch condition in assembly code which created an additional delay in the computation as the processor jumped to another position in the code. It was therefore feasible to determine whether or not a bit involved in the computation was a 1 or 0. The timing taken to perform computations is therefore dependent on its inputs. More modern attacks look at the architecture of the device and the use of resources such as processor, memory and cache. Memory and cache attacks are described below.

Modern computers are built with a hierarchy of memory due to the structural (von Nuemann) problem. Expensive memory with relatively quicker access times are situated close to the processor whilst cheaper memory with longer access times are situated further away from the processor. For cache memories, which sit closest to the processor, this hierarchy is demonstrated with the labels, L1, L2 and L3 which represents the closeness of the memory to the processor. For example, L1 memory is the closest to the processor and L3 is the furthest away. When instructions are loaded into a cache, it is done so under the locality principle which generally means that in normal program flow, the required instructions are usually located in memory addresses close to the current one being processed. Therefore, the cache is loaded from a number of sequential addresses. If the next instruction to be executed is not in the cache, it has to be flushed and re-packed with the relevant code. This causes a timing delay and from mapping the timing, an attacker can deduce when a cryptographic computation is being carried out

Risks In The Supply And Manufacturing Chain

protect IP
Hardware Security
ablackett

Securing IC Design

SECURING IC DESIGN OVERVIEW The old way of delivering a product to market was to reuse as much IP as possible and verify that the

Read More »
automotive security and privacy
ablackett

Cyber Security In Cars

Its now common to see electronics in cars controlling all aspects of driving; door entry, steering, braking and safety equipment such as onboard cameras and

Read More »
cyber security
ablackett

Cyber Physical Security

CYBER CRITICAL INFRASTRUCTURE OVERVIEW As governments and national authorities come to grips with cyber warfare, attention has turned to critical infrastructure; so-called because a successful

Read More »
Hardware Security
ablackett

Automotive Security

AUTOMOTIVE SECURITY OVERVIEW The automotive industry has seen a dramatic increase in security measures uptake as manufacturers come to terms with the implications of having

Read More »
protect IP
Hardware Security
ablackett

Secure IC Design

The old way of delivering a product to market was to reuse as much IP as possible and verify that the correct functionality has been

Read More »
blockchain relies on cryptography
Cryptography
ablackett

Financial Cryptography

FINANCIAL CRYPTOGRAPHY OVERVIEW The use of cryptographic currency and smart contracts (scripts residing on the blockchain that allow the automation of complex transactions) will revolutionise

Read More »