George Danezis (a professor of security and privacy at UCL) and his PhD student Vasilios Mavroudis have reached out to me (and Enigma Bridge) with a project proposition last summer. They have designed a set of multi-party signing and encryption protocols, and wondered if they could be verified on commercial hardware. We had the hardware, so I immediately said “let’s do it”.
We keep talking about unbreakable encryption. There is one such scheme – one-time pad. While theoretically unbreakable, it was practically broken many times. We use computers for encryption and one needs hardware processors as well as the software to do it. We assumed that any encryption could be broken. The question is – can we protect ourselves against rogue hardware? Can we create a practical unbreakable encryption system?
A project premise was that the threat of introducing undocumented functionality into processors themselves (and computer chips in general) were real. There were several publicly documented cases where hardware chips contained functionality classified as a backdoor or a trojan horse. To make the situation worse, those cases affected high-confidentiality and integrity applications.
- Breakthrough silicon scanning discovers backdoor in military chip;
- Photos of an NSA “upgrade” factory show Cisco router getting implant; or
- Hardware Trojans in Wireless Cryptographic ICs.
In all these cases, the errors were eventually attributed to honest design or fabrication mistakes, but the systems were left vulnerable to attacks regardless. Malicious attacks or human errors, who discovers them first can sell the knowledge or exploit it themselves.
Detection techniques help prevent introduction of these “bugs” but they can hardly be effective against malicious attackers as their introduction into manufacturing processes takes time. While attackers can quickly bypass any such mechanisms.
Our approach is quite the opposite. We assume, there are hardware bugs and backdoors, and trojans. We combine mathematics (theoretically secure encryption) with engineering (robust implementation of equations) with a team, which understands both sides of the resulting system to prevent issues on the boundary.
We built a high-assurance hardware from these untrusted components and as long as at least one of them is not compromised, we are safe. The encrypted data is still protected.
This diversification of the components reduces the probability of all of them being compromised, and if they are, the adversaries wouldn’t help each other (especially if their general policy is to spy on each other).
To achieve that, we deploy distributed cryptographic schemes on top of an N-variant system architecture, and build a trusted platform that supports a wide-range of commonly used cryptographic operations (e.g., random number and key generation, decryption, signing).
Theoretical Security: These schemes provide formal proofs that none of the parties can compromise computations as long as at least one behaves. The adversary has full control over communication (to watch, stop, replace, inject messages). They can use any other side-channel that a Trojan has been programmed to emit on — such as RF or channels.
Practical Security: We also need the participating chips to be physically located in at least two antagonistic superpowers or geopolitical regions to make exploitation of any backdoors or hardware bugs impossible. One thing is to make Russia, USA, India, China, Brazil talk to each other, another thing is to make them confess they use hardware backdoors for cyber spying.
We have successfully implemented the cryptographic system, including a RESTful interface, and used it to collect a number of measurements. I will focus on some highlights. The first one is about improvements we made during the project and the second covers results for multi-party signing (256b elliptic curve signatures). First of all though, a few words about the implementation. We used smartcards to implement the protocol – for several reasons. We can potentially use smartcards from several big vendors across geopolitical regions (based in South Asia, Europe, Africa), without a need to rewrite the implementation. We also have a production hardware platform allowing us to run experiments with hundreds of smartcards without any internal communication bottleneck. And last but not least, smartcards provide very high physical security (measured by FIPS140-2 standard at the highest level, Level 4).
The first implementation was highly experimental as we were testing different approaches and cryptographic libraries. While we did get valid results, a single signing operation took around 18,000 milliseconds. Petr Svenda then started optimizing the protocols and you can see results in the chart on the left. Needless to say, the timings made the implementation a strong candidate for commercial use.
The second step was to verify the practicality with actual protocol runs and also to find out how the system behaves for increasing numbers of cooperating parties – i.e., with increasing number of processors needed to sign (or decrypt) documents. These results are on the right. As you can see, the increase in the time needed for a single signature is linear with small increases. (and Petr still has up his sleeve a trick significantly reducing the processing times).
When you think about it, it takes just above 2 seconds to sign a document where 10 parties (laptops, secure processors, cloudHSM, mobile phones, etc.) have to do their bit.
I should also note that while I focus on signing, distributed decryption achieves much faster speed!
How to use it
Digital signing is used in a number of applications – from code-signing to signing of legal documents (especially in the EU) or bitcoin operations and blockchain (each block-chain update is technically a digital signature).
We are really excited about the potential for code-signing, i.e., to verify the origin of software. This is a mandatory technique for all mobile phone apps, but it is also important for secure distribution of packages for servers and desktop computers.
The simplest implementation would involve just two parties:
- computer of the developer (or whoever is responsible for signing new apps’ versions); and
- cloud-based (on-premise or in public cloud) service.
The developer controls the signing process and requests the cloud service to contribute its part of the computation. The cloud service logs all uses of its secure processors (smartcards with physical security), and provides these logs to managers, who are responsible for correct use of code-signing keys. The cloud service can also be used to introduce “release time-windows”, remove developer’s rights to sign new software versions, if his/her laptop is stolen, taken over by malware or similar situations.
We have submitted full results for peer-reviews and we will publish them in due course.