Kocher et al. [KJJ99] pioneered the method of differential power analysis (DPA).

A power trace is a set of power consumption measurements taken over a cryptographic operation; see Fig. 1 for an example.

Let us define simple power analysis (SPA) before we get into DPA. SPA is the interpretation of direct power consumption measurements of cryptographic operations like Fig. 1.

Watch a demonstration of SPA:

Most hard-wired hardware implementations of symmetric cryptographic algorithms have sufficiently small power consumption variations that SPA cannot reveal any key bit.

Unlike SPA, DPA is the interpretation of the difference between two sets of power traces.

More precisely, this difference is defined as

where

• $m$ is the number of traces;
• $j$ is the time index;
• $D(C_i,b,K_s)$ is the selection function which for the DES (see Figs. 2-3) is defined as the value of bit $b$ ($0\leq b\leq 31$) of the DES intermediate $L$ (see input to block E in Fig. 3) at the beginning of the 16th round for ciphertext $C_i$ when $K_s$ is the 6-bit subkey entering the S-box corresponding to bit $b$;
• $\vec{T}_i[j]$ is the $i$th power trace (vector of power values).

Note each trace is associated with a different ciphertext.

DPA uses power consumption measurements to determine whether a key block guess $K_s$ is correct.

• There are only $2^6=64$ possible values of $K_s$.
• When the attacker’s guess of $K_s$ is incorrect, the attacker’s value of $D$ differs from the actual target bit for about half of the ciphertexts $C_i$; equivalently, the selection function $D(C_i,b,K_s)$ is uncorrelated to what was actually computed by the target device, i.e., $\lim_{m\to\infty}\Delta_m[j] = 0$.

• When the attacker’s guess of $K_s$ is correct, $D$ is correlated to the value of the bit manipulated in the 16th round, i.e.,

  • $\Delta_m[j_b]$ approaches the effect of the target bit on the power consumption as $m\to\infty$, where $j_b$ is the time index corresponding to when $b$  is involved in computation;
  • $\Delta_m[j]$ approaches zero for all the times when $b$ is not involved in computation.
• Fig. 4 shows four sample power traces (1 simple, 3 differential).

The Diffie-Hellman (D-H) key agreement (often called “key exchange”) protocol is standardised in NIST SP 800-56A [BCR+18].

The protocol originated in the seminal 1976 paper by Whitfield Diffie and Martin Hellman [DH76], both recipients of the 2016 Turing Award (their contribution took 40 years to be recognised).

Protocol between 👩 Alice and 🧔 Bob [KL21, CONSTRUCTION 11.2] in Fig. 1:

1. On input of security parameter $1^n$, 👩 Alice runs probabilistic polynomial-time (PPT) algorithm to obtain the domain parameters $(\mathbb{G}, q, g)$, where $\mathbb{G}$ is a cyclic group of prime order $q$, and $g$ is a generator of $\mathbb{G}$.

   The bit-length of $q$ = the security parameter $n$.

   The domain parameters can be pre-distributed.

2. 👩 Alice chooses $x\in\mathbb{Z}_q$, $0\lt x\lt q$, uniformly at random, and computes $h_A \gets g^x$.

   $\mathbb{Z}_q$ is the (cyclic) group of integers modulo $q$.

   👩 Alice’s (ephemeral) private key and public key are $x$ and $g^x$ respectively.

3. 👩 Alice sends $(\mathbb{G}, q, g, h_A)$ to 🧔 Bob.

4. 🧔 Bob chooses $y\in\mathbb{Z}_q$, $0\lt y\lt q$,  uniformly at random, and computes $h_B \gets g^y$.

   🧔 Bob’s (ephemeral) private key and public key are $y$ and $g^y$ respectively.

5. 🧔 Bob sends $h_B$ to 👩 Alice and outputs $k_B \gets h_A^y$.
6. 👩 Alice computes $k_A \gets h_B^x$.

Successful completion of the protocol results in the session key $k_A = k_B = g^{xy}$.

A necessary condition for preventing a probabilistic polynomial-time (PPT) eavesdropper from computing the session key is that the computational Diffie-Hellman (CDH) problem is hard:

However, the hardness of the CDH problem is not sufficient.

Just as indistinguishability plays an essential role in symmetric-key encryption, indistinguishability is key here: if the session key $g^{xy}$ is indistinguishable from an element chosen uniformly at random from $\mathbb{G}$, then we have a sufficient condition for preventing a PPT eavesdropper from computing the session key [KL21, pp. 393-394].

The indistinguishability condition is equivalent to the assumption that the decisional Diffie-Hellman (DDH) problem is hard:

The DDH problem is readily reducible to the CDH problem, since any algorithm that solves the CDH can compute $g^{xy}$ and compare it with $g^z$; implying the DDH problem is no harder than the CDH problem.

In turn, the CDH problem is reducible to the discrete logarithm problem (DLP, see Definition 3), since any algorithm that solves the DLP can compute $x$ from $g^x$, $y$ from $g^y$, and hence $g^{xy}$; implying the CDH problem is no harder than the DLP problem.

In other words, the DDH problem can be reduced to the CDH problem, which in turn can be reduced to the DLP; solving the DLP breaks the D-H key agreement protocol.

The D-H key agreement protocol is used in the Internet Key Exchange (IKE) protocol, which is currently at version 2 [KHN+14].

A hardware Trojan (see Definition 1) may control, modify, disable, or monitor the contents and communications of the device it is embedded in [RKK14, Sec. II].

Hardware Trojans provide a means to bypass traditional software and cryptographic-based protections, allowing a malicious actor to control or manipulate device/system software, 1️⃣ getting access to sensitive information, and/or 2️⃣ causing denial-of-service to legitimate users by causing device/system failures or simply by turning the device/system off [BDF+22].

Examples of hardware Trojans are aplenty within academia and outside of academia [HAT21].

👩‍🎓 Examples from within academia

Smartphones often break, but replacing broken components provides an opportunity for malicious actors to implant hardware Trojans.

One of the most frequently replaced components is the touchscreen; more than 50% of smartphone owners have damaged their screen at least once [SCSO17].

Steps of the “Shattered Trust” attack [SCSO17]:

1. A Trojan screen with an embedded microcontroller is installed.
2. Rogue microcontroller downloads and installs a Trojan app from the Google Play store 🎦.
3. Trojan app exploits the buffer flow vulnerability CVE-2017-0650 of the Synaptics S3718 device driver, elevating its own privileges to root, disabling SELinux protection and exfiltrating user data including authentication tokens 🎦.
4. Attacker creates a remote root shell (through ncat for example) to the compromised phone 🎦.

Another frequently replaced component is the phone battery [LFH+18] 🎦.

On a larger scale, computer peripherals can serve as hardware Trojans that exploit the vulnerabilities in Input-Output Memory Management Units (IOMMUs) [MRG+19].

• An IOMMU is an MMU component that connects a DMA-capable I/O bus to system memory, and maps device-visible virtual addresses to physical addresses; see Fig. 1.

Watch Christof Paar’s overview lecture:

👩‍💻 Examples from outside academia

In 2018, Bloomberg Businessweek made the sensational claim entitled “The Big Hack” that China’s PLA launched a supply chain attack by implanting a tiny Trojan chip in motherboards made by Super Micro Computer Inc. (“Supermicro” for short)  [MLP+20] 🎦.

• Supermicro specialises in servers, storage, networking devices, and server management software for data centers and cloud computing.
• Supermicro motherboards were manufactured by contractors in China, facilitating The Big Hack; see Fig. 2. Supermicro now manufactures motherboards for the US market in the US.

• Elemental Technologies (now AWS Elemental, “Elemental” for short) specialised in developing software to compress large video files (e.g., from the International Space Station, from drones) into formats suitable for handheld devices. This technology attracted partnership from the CIA and Amazon.
• Elemental used Supermicro’s servers in their data centres.
• Amazon used Supermicro’s servers in their China-based data centres.
• Amazon’s security team discovered Trojan chips embedded in the fibreglass layers (upon which other components were attached) with access to the baseboard management controller (BMC), which is the component that enables remote administration.
• X-ray images captured by Amazon’s security team revealed variations in Trojan chip design, but all resemble signal conditioning couplers.
• The code in the Trojan chips was small, but it could execute two major tasks: 1️⃣ command the motherboard to communicate with external computers, and 2️⃣ command the operating system to accept new code from said computers.
• Initial Bloomberg report was met with scepticism, but proofs-of-concept started surfacing soon after.

Trojan detection is challenging because [RKK14, Sec. II]:

1. The inherent opaqueness of device internals hampers detection of modified components. Reverse engineering is typically resource-intensive and in the worst case destructive.
2. Technology scaling to the limits of device physics and mask imprecisions cause nondeterminism in a device’s characteristics, rendering distinction between process variations and Trojans challenging.
3. The infeasibility of characterising the entire behavioural space of a device permits stealthy implantation of Trojans.

Countermeasures

Four main defence strategies can be identified [HAT21, Sec. 4]:

1. Design for security: Integrating security right from the beginning is a no-brainer. Three main strategies are identifiable:

   • Secure inter-component communications: While it is impractical to demand all inter-component communications to be encrypted and authenticated, critical processes such as booting should be locked down.

     For example, OpenBMC is a Linux distribution for BMCs used in servers, top-of-rack switches, etc. Since the early 2020s, OpenBMC has been supporting secure boot 🎦.

   • Secure test infrastructure: Lock down the JTAG interface to mitigate the risks of attackers accessing sensitive information and/or compromising system functionality.

     Practicality necessitates a lightweight cryptographic protocol (not TLS). Physical unclonable functions (PUFs) provide a lightweight authentication mechanism.

   • Obfuscation and anti-reverse engineering: Attackers need to understand how a device works before they can implant their hardware Trojan.

     Professional attackers resort to a wide range of reverse engineering techniques [FSK+17, SLP+19]:

     A professional foundry attacker has full knowledge of the circuit layout and hence can extract the transistor-level design directly.

     A professional end-user attacker can de-package, de-layer and image an IC, as per Fig. 3. Further processing of these images can facilitate the reconstruction of the circuit layout.

     The process of layout reconstruction and netlist extraction is referred to as physical reverse engineering.

     Reverse engineering also facilitates IP theft.

     Anti-reverse engineering (anti-RE) techniques include [SLP+19, PP20, HAT21]:

     At the very least, use 1️⃣ more routing layers (especially for sensitive signals) in internal PCB layers, 2️⃣ ICs with ball-grid-array connections, and 3️⃣ extraneous traces, vias and components to confuse adversaries.

     Split manufacturing: Front End of Line (FEOL) layers (transistors and lower metal layers) are fabricated at an untrusted high-end foundry, while the Back End of Line (BEOL) layers (higher metal layers) are manufactured at a trusted low-end foundry; see Fig. 4. This approach hides the BEOL connections from the untrusted foundry.

     IC camouflaging: Using fabrication-level techniques to build circuits whose functionality cannot be easily deduced using nanoscale microscopy and other known physical reverse engineering techniques; see Fig. 5.

     Logic locking: Adding some form of programmability to the design and ensuring that the circuit cannot function properly without the circuit being programmed with a secret string of configuration data referred to as the “key”; see Fig. 5.

     Both IC camouflaging and logic locking are examples of logic obfuscation.

2. Manufacturing tests: PCB manufacturers have traditionally relied on electrical, functional, and automated optical testing for quality control.

   While manufacturing tests may detect Trojans with payloads that resemble defects, they are not generally useful for detecting modifications by intelligent adversaries.

   Optical inspection of PCBs uses computer vision and machine learning techniques to identify manufacturing defects on both bare-boards and PCB assemblies:

   • Optical inspection machines are commercially available today, complete with proprietary algorithms that are well-tuned to identifying specific board-level defects such as solder bridging or component misalignment.
   • More advanced optical inspection systems use multiple cameras to construct 3D images of boards to identify problems like lifted leads.
   • X-ray solutions have also been developed to enable inspection of inner-layers of PCB routing.
   • While traditional inspection algorithms are well-tuned to identify defects, these algorithms are not adaptable to identifying Trojan modifications.
   • Developing algorithms suitable for PCB assurance is nontrivial.

3. Board-level Trojan detection: Going beyond manufacturing tests, specific Trojan detection techniques include:

   • Offline side-channel verification: Similar to ICs, circuit boards have unique signatures that depend on the implemented circuit as well as manufacturing variations.

     Malicious modification to PCB substrate, routing, or components could disrupt these side-channel fingerprints.

     Side-channel disruptions such as resonant frequency and delay patterns of PCB traces can be measured either statically or at run time to identify modified or counterfeit PCBs.

   • Advanced optical inspection: This combines information from multiple imaging modalities to verify components and identify illegitimate modifications.

     Imaging modalities can be classified as per Fig. 6.

     Multi-modal optical inspection is a potentially powerful tool for PCB assurance, and research is evolving quickly.

     Not included in Fig. 6 is quantum diamond microscopy [ATW+22]; see Figs. 7-8.

4. Run-time monitoring: Run-time monitoring employs additional hardware to ensure device security in the field.

   • Run-time side-channel verification: Side-channel information such as power consumption of clusters of authentic components on a PCB relative to the total power consumed by the PCB can serve as an indicator of Trojan activity — specifically discrepancies outside a certain tolerance might be worth flagging.

   • Policy engines: A policy engine is an IP block that 1️⃣ monitors bus traffic, 2️⃣ searches for traffic that violates a pre-determined rule or model, and 3️⃣ in case of violation, raises an alert or takes a corrective action.

     On PCBs, a policy engine chip can be installed on buses like PCI and I²C to identify denial-of-service attacks or illegitimate messages.

     For example, the validation tool called ConFirm in Fig. 9 performs computational path analysis with hardware performance counters (HPCs), which are special-purpose registers built into the performance monitoring unit of a modern microprocessor for storing information about hardware events [WKMK15].