Hardware components may embed malicious circuitry.

Cryptographic Hardware
from Untrusted Components

University College London / Enigmabridge / Masaryk University

In a Nutshell

For the first time, we introduce a high-level architecture that can tolerate multiple, colluding malicious hardware components, and a new approach for managing the risk of compromises in cryptographic hardware modules.

Existing high-assurance systems cannot reliably maintain their security properties in the presence of compromised hardware components. In this work, we challenge this perception and demonstrate how trusted, high-assurance hardware can be built from untrusted and potentially malicious components.

For more information, please refer to our whitepaper or our other publications.


What's an untrusted component?
Any kind of hardware component (e.g., Integrated Circuit) who doesn't come with 100% guarantee for the integrity of its supply chain. This is often the case with components that are produced in facilities overseas. Even if a single part of the supply chain is not closely monitored then malicious circuitry may be introduced.
Isn't existing cryptographic hardware already secure against this known problem?
It depends on the capabilities of the adversary assumed by the hardware designers. In principle, commercially available hardware is not secure against an adversary (e.g., a national goverment) that has access to fabrication facilities (or other parts of the supply chain) and can influence them to include backdoors or errors in the chip manufactured. While this is true for many use cases, there have been incidents where state-level adversaries breached parts of the supply chain to load trojans or backdoors in the hardware.
Can't hardware vendors just test the chips they use?
In the last decade, the problem of manufacturing errors became increasingly prominent, as more vendors opt to outsource the fabrication of their integrated circuit designs, in facilities overseas. For this reason, vendors run post-fabrication tests that automatically weed out deficient and faulty chips. However, such tests are not effective against two very damaging error classes: 1) subtle unintentional errors (e.g., malfunctioning RNGs) and 2) malicious circuitry (e.g., stealthy Hardware Trojans). Such errors are very hard to detect and require constant upgrades of expensive forensics equipment, which contradicts the motives of fabrication outsourcing.
What about colluding malicious hardware components?
In the case of colluding components, our proposed architecture remains secure as long as at least one of the components is not compromised. Alternatively, if there are two or more adversaries that managed to compromise 100% of the components, the system retains its security proprerties as long as they adversaries do not collude.
Is your architecture secure against all types of errors and attacks?
Existing cryptographic hardware is not tolerant to hardware errors and even one compromised component is enough to breach the security of the whole system. In contrast, our architecture is tolerant to both unintentional and intentional errors:
  • Unintentional errors usually occur in ICs with fabrication deficiences (e.g., broken Random Number Generators).
  • Intentional errors are usually "hardware trojan horses" or "backdoors" put in place by an adversary residing in the IC supply chain.
However, it should be noted that if all hardware components are compromised then the security properties of Myst are also breached.
Myst: Our secure cyrptographic hardware prototype.
Myst: Our secure cryptographic hardware prototype.
How do you compare with previously proposed mitigation techniques (e.g., split-manufacturing)?
Such techniques are very useful and actually necessary for the security of our system. By using multiple chips (i.e., Integrated Circuits) featuring different hardware trojan mitigation techniques we can increase the trojan resilience. This is because, as long as one of the chips resists the attack the whole system retains its security properties.

Who we are

Vasilios Mavroudis, @mavroudisv
University College London (UCL)
Petr Svenda, @rngsec
Masaryk University
Andrea Cerulli
University College London (UCL)
Dan Cvrcek, @dancvrcek
Dusan Klinec, @ph4r05
George Danezis, @gdanezis
University College London (UCL)

Contact us


Vasilios Mavroudis, Andrea Cerulli, Petr Svenda, Dan Cvrcek, Dusan Klinec, George Danezis. A Touch of Evil: High-Assurance Cryptographic Hardware from Untrusted Components. 24th ACM Conference on Computer and Communications Security, Dallas, TX, Oct 30th-Nov 3rd 2017.

Vasilios Mavroudis Cryptographic Hardware from Untrusted Components October 2017. [PDF]

Vasilios Mavroudis, Andrea Cerulli, Petr Svenda, Dan Cvrcek, Dusan Klinec, George Danezis. A Touch of Evil: High-Assurance Cryptographic Hardware from Untrusted Components. arXiv:1709.03817. [PDF]

Vasilios Mavroudis, Dan Cvrcek. Trojan-Tolerant Hardware & Supply Chain Security in Practice. Defcon 25, Las Vegas, US, 27-30 July 2017. [Slides]

Please use the following bibtex entry to cite our work:

 author = {Mavroudis, Vasilios and Cerulli, Andrea and Svenda, Petr and Cvrcek, Dan and Klinec, Dusan and Danezis, George},
 title = {A Touch of Evil: High-Assurance Cryptographic Hardware from Untrusted Components},
 booktitle = {Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security},
 series = {CCS '17},
 year = {2017},
 isbn = {978-1-4503-4946-8},
 location = {Dallas, Texas, USA},
 pages = {1583--1600},
 numpages = {18},
 url = {http://doi.acm.org/10.1145/3133956.3133961},
 doi = {10.1145/3133956.3133961},
 acmid = {3133961},
 publisher = {ACM},
 address = {New York, NY, USA},
 keywords = {backdoor-tolerance, cryptographic hardware, hardware trojans, secure architecture},



This section includes all supporting software (all released under the MIT license):

  • Myst: Secure Multiparty Key Generation, Signature and Decryption [Applet] [Host App]
  • JCMathLib: Implementation of mathematical operations with big numbers and elliptic curve points for JavaCards. [Source Code]

Feedback, ideas and source code contributions are very welcome!

Supported by

This work was supported by the European Commission through the H2020-DS-2014-653497 PANORAMIX project and the European Research Council via the European Union’s Seventh Framework Programme (FP/2007-2013) / ERC Grant Agreement n. 307937, and the Czech Science Foundation under project GA16-08565S.