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?
Assumptions
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 the 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.
Robust Approach
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 cryptographic schemes 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: While the participating chips have FIPS 140-2 Level 4 validation for physical security, we also need them to be physically located in and under control of at least two different geopolitical regions.
Practical Results
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 the 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 the 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.
Great concept, I’m looking forward to reading the technical details.
Can you make any observations about the possibility and/or usefulness of denial of service attacks originating from one of the cooperating nodes? E.g. to target and sabotage a channel or to selectively weaken the protocol?
Thanks! While a rogue node can’t compromise security (view of mathematicians), it can certainly try to do a denial of service. The protocol itself if a “threshold” scheme, so it is possible to define e.g., 6-of-10 to make it robust against DoS attacks by cooperating parties.