Browse the glossary using this index

Special | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | ALL

H

Picture of Yee Wei Law

Hardware Trojan

by Yee Wei Law - Wednesday, 5 April 2023, 10:46 AM
 

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].

Definition 1: Hardware Trojan [RKK14, BDF+22]

Hardware that has been modified with a malicious functionality hidden from the user.

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].

💡 It is easier to produce a proof-of-concept for academic publications or demonstrations than executing a real-world attack that has to be robust to diverse usage scenarios.

👩‍🎓 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.
Fig. 1: The IOMMU translates I/O virtual addresses to physical addresses and applies access control, similar to how the MMU translates virtual addresses from processes [MRG+19, Fig. 2].

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.
Fig. 2: Alleged steps of The Big Hack [MLP+20, Fig. 3].
  • 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.

      Fig. 3: Physical reverse engineering flow: an attacker can de-package, de-layer an IC, and leverage image processing techniques to reconstruct the circuit layout [SLP+19, Fig. 2]. The gate-level netlist can subsequently be extracted.

      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.

      Fig. 4: Vertical structure of a sample IC showing metal layers (M1 to MX), and vias (V1 to VX-1) connecting adjacent metal layers [PP20, Figure 2]. FEOL layers contain transistors, fabrication of which require a high-end foundry.

      Fig. 5: Examples of logic obfuscation [SLP+19, Fig. 1]: (a) IC camouflaging, where a camouflaging cell that from the top view appears to implement either a NAND or a NOR gate as a substitute for the original gate ; (b) logic locking, where correct key bit at is required to unlock gate . While a key bit has only two possible values, many key bits distributed throughout a circuit can constitute a key of a significant size.

      IC camouflaging requires the fixed obfuscated layout structure to be disclosed to the foundry for fabrication, so IC camouflaging only applies to end-user adversaries.

  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.

      Fig. 6: Classification of optical testing methods in terms of imaging modality [HAT21, Fig. 4].
      Fig. 7: Workflow and experimental setup [ATW+22, Fig. 3]: (a) Pseudo-flowchart of a QDM magnetic imaging experiment for Trojan detection. (b) Schematic of the experimental components, where a nitrogen-vacancy diamond is placed directly on a field-programmable gate array (FPGA) containing hardware Trojans at the register transfer level. A 532-nm laser is shone at the diamond at a shallow angle and the resultant red fluorescence is captured on a CMOS camera. The nitrogen vacancies are controlled through the application of external microwaves (MW) and a DC bias magnetic field.
      Fig. 8: The “Neural Network Analysis” block in Fig. 7 can be instantiated as a convolutional autoencoder to perform clustering of image features, for the detection of Trojans [ATW+22, Fig. 1].
  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 I2C 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].

      Fig. 9: High-level structure of ConFirm [WKMK15, Fig. 2]. The ConFirm core consists of three components in write-protected non-volatile memory: 1️⃣ an insertion module that inserts checkpoints into the monitored firmware, 2️⃣ an HPC handler that drives the HPCs, and 3️⃣ a database that stores valid HPC-based signatures.

      When an execution checkpoint is reached, the control flow is redirected to the core module. The HPC handler compares the event counts for the previous check window with the corresponding signatures in the database. The HPCs are then reset for the next check window and the execution of the monitored firmware continues until the next checkpoint is reached.

      Fig. 10: Computational path analysis with HPCs [WKMK15, Fig. 1]. The execution of the valid paths and in a monitored subroutine generates HPC vectors and encoding occurrence counts of hardware events. A malicious execution could for example go through path , generating an aberrant vector that is distinguishable from and .

      ARM V8 Cortex-A53 for example has 4 HPCs, and can count 62 types of events.

References

[ATW+22] M. Ashok, M. J. Turner, R. L. Walsworth, E. V. Levine, and A. P. Chandrakasan, Hardware trojan detection using unsupervised deep learning on quantum diamond microscope magnetic field images, J. Emerg. Technol. Comput. Syst. 18 no. 4 (2022). https://doi.org/10.1145/3531010.
[BDF+22] J. C. Booth, M. L. Dowell, A. D. Feldman, P. D. Hale, M. M. Midzor, and N. D. Orloff, 5G Hardware Supply Chain Security Through Physical Measurements, NIST Special Publication 1278, May 2022. https://doi.org/10.6028/NIST.SP.1278.
[FSK+17] M. Fyrbiak, S. Strauß, C. Kison, S. Wallat, M. Elson, N. Rummel, and C. Paar, Hardware reverse engineering: Overview and open challenges, in 2017 IEEE 2nd International Verification and Security Workshop (IVSW), 2017, pp. 88–94. https://doi.org/10.1109/IVSW.2017.8031550.
[HAT21] J. Harrison, N. Asadizanjani, and M. Tehranipoor, On malicious implants in PCBs throughout the supply chain, Integration 79 (2021), 12–22. https://doi.org/10.1016/j.vlsi.2021.03.002.
[LFH+18] P. Lifshits, R. Forte, Y. Hoshen, M. Halpern, M. Philipose, M. Tiwari, and M. Silberstein, Power to peep-all: Inference attacks by malicious batteries on mobile devices, in Proc. Priv. Enhancing Technol., 2018, 2018, pp. 141–158. https://doi.org/10.1515/popets-2018-0036.
[MRG+19] A. T. Markettos, C. Rothwell, B. F. Gutstein, A. Pearce, P. G. Neumann, S. W. Moore, and R. N. M. Watson, Thunderclap: Exploring vulnerabilities in operating system IOMMU protection via DMA from untrustworthy peripherals, in Proceedings of the Network and Distributed Systems Security Symposium (NDSS), February 2019, more information at http://thunderclap.io/. Available at https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_05A-1_Markettos_paper.pdf.
[MLP+20] D. Mehta, H. Lu, O. P. Paradis, M. A. M. S., M. T. Rahman, Y. Iskander, P. Chawla, D. L. Woodard, M. Tehranipoor, and N. Asadizanjani, The Big Hack Explained: Detection and Prevention of PCB Supply Chain Implants, J. Emerg. Technol. Comput. Syst. 16 no. 4 (2020). https://doi.org/10.1145/3401980.
[PP20] T. D. Perez and S. Pagliarini, A survey on split manufacturing: Attacks, defenses, and challenges, IEEE Access 8 (2020), 184013–184035. https://doi.org/10.1109/ACCESS.2020.3029339.
[RKK14] M. Rostami, F. Koushanfar, and R. Karri, A primer on hardware security: Models, methods, and metrics, Proceedings of the IEEE 102 no. 8 (2014), 1283–1295. https://doi.org/10.1109/JPROC.2014.2335155.
[SLP+19] K. Shamsi, M. Li, K. Plaks, S. Fazzari, D. Z. Pan, and Y. Jin, Ip protection and supply chain security through logic obfuscation: A systematic overview, ACM Trans. Des. Autom. Electron. Syst. 24 no. 6 (2019). https://doi.org/10.1145/3342099.
[SCSO17] O. Shwartz, A. Cohen, A. Shabtai, and Y. Oren, Shattered trust: When replacement smartphone components attack, in 11th USENIX Workshop on Offensive Technologies (WOOT), 2017. Available at https://www.usenix.org/system/files/conference/woot17/woot17-paper-shwartz.pdf.
[WKMK15] X. Wang, C. Konstantinou, M. Maniatakos, and R. Karri, ConFirm: Detecting firmware modifications in embedded systems using Hardware Performance Counters, in 2015 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 2015, pp. 544–551. https://doi.org/10.1109/ICCAD.2015.7372617.

Picture of Yee Wei Law

Hash functions

by Yee Wei Law - Monday, 21 October 2024, 12:32 PM
 
See 👇 attachment.
Tags:

Picture of Yee Wei Law

Homodyne vs heterodyne detection

by Yee Wei Law - Wednesday, 8 February 2023, 11:42 AM
 

Homodyne detection = method of detecting a weak frequency-modulated signal through mixing with a strong reference frequency-modulated signal (so-called local oscillator).

References

[ETS18] ETSI, Quantum Key Distribution (QKD); Vocabulary, Group Report ETSI GR QKD 007 v1.1.1, December 2018. Available at https://www.etsi.org/deliver/etsi_gr/QKD/001_099/007/01.01.01_60/gr_qkd007v010101p.pdf.