Cryptosat: The Incarnation of the trusted party
Origins of a trusted party
Cryptography is fundamental in our day to day. It is one of the enablers of modern communications, blockchain technologies (yes, NFTs will not work without cryptography), the internet and much more.
When designing a cryptographic protocol, we can use the following simple mental model to define its security: imagine we have a certain entity that everyone in the world trusts. Call it a trusted party. This party knows exactly which function we want to compute securely. At first stage the trusted party will collect inputs from all other participants and at second and final stage it will output the result to all. In designing a protocol, we want to compare it to this “ideal world” such that an attacker on the real protocol has no extra power over an attacker in the ideal world.
This mental model is actually how security is proven in many many cryptographic protocols, and it is especially relevant when we have multiple participants.
But let me ask you this: what if we would actually have a “trusted party” to use in the real world? How confusing is that ! The simple answer is that in such a case, all these cryptographic protocols could just be replaced with their “ideal” counterparts. This will make life really easy.
Real world case study
Some time ago I was asked to lead a red team, reviewing a protocol that was designed to compute the public part of an RSA key, i.e. the modulus N, without anyone being able to learn the private part of the RSA key (i.e. the two prime factors). Why have such a protocol to begin with? Well. The modulus defines a group of unknown order, which is crucial to the security of Verifiable Delay Function (VDF) that is intended to play a critical role in eth2.0. In short, although RSA itself has existed for decades now, designing a secure distributed RSA modulus generation protocol is extremely challenging. While such protocols are discussed in the literature, coming up with a real-world ready protocol that meets Ethereum standards requires novelty and massive layers of complexity. The end of the story is that Ethereum dropped the project because of the high level of risk (catch up my RWC talk to learn more).
What if ?
But what if we had a trusted party? Some kind of an oracle in the sky that can run computations in a secure environment. We could have just replaced all of the complexity with a simple oracle request for RSA public key, knowing that it is guaranteed no one will ever know the private key. In addition, we can just repeat the request and refresh the public key once in a while. This is the simplest, most elegant possible solution there is.
More importantly, Many other complex constructions in cryptography can be simplified in the same way, unlocking an abundance of protocols that were deemed impractical so far, especially in fields such as Multiparty computation (MPC). Sweet!
How would a world with a trusted party look like ?
Assume we do have such a trusted party. Here is a partial list of stuff we can do with it.
- Uncorrupted root of trust: We can replace / enhance PKI systems by providing a certificate authority that once defined can never be compromised
- Source of randomness: Unbiased source of random numbers gets us an infinite supply of fresh random numbers that can be verified by all. This can replace random beacon protocols for example.
- Event ordering: The trusted party can order any set of elements according to any rule: it can be for example temporal (FIFO) or fully random. One use case is in fighting MEV.
- Eliminate “toxic waste” -e.g. The trusted party replaces trusted setups in zk-snarks. Or as in the RSA example above: generates a group of unknown order.
- Manage Decryption rights : play “god” in functional encryption schemes. That is, the trusted party produces a secret master key and spin private keys for specific functionalities.
Pretty awesome, right? (And if you don’t get it all, that’s OK, this is a topic for another blog)
Obviously open environments (e.g. the entire population) where there is no clear centralized authority can benefit the most from the introduction of a trusted party.
The radiating elephant in the room
So far our discussion was purely theoretical, taking an ideal framework from the literature and imagining what it would be like if it was for real. In practice, however, constructing a device to manifest such an ideal trusted party is hard. Side channels for once seem inevitable. Timing, acoustic, electromagnetic emanations and many more, all reveal to an outside observer with some physical access to the device, information about its inner workings, current state and memory.
While Trusted Execution Environments are implemented in modern CPUs (Intel SGX, AMD SEV, etc.), they can still be prone to side-channel attacks given physical control of the machine.
Intro to satellites
Sometimes great solutions come from the place where you least expect them to come from. Taking a small detour in the flow of this article, let us learn a bit about satellites.
Satellites in our context are man-made objects that are launched into space and stay there while travelling at a predictable orbit (speed + location). A single satellite can provide coverage for large parts of earth in each single moment. Some satellites (GEO) will have a fixed position over earth while others will circle earth several times a day (e.g. LEO) . Some examples are in place:
(1) Communication Satellites can provide connectivity to anywhere in the world. Alternatively, they can broadcast transmissions from some ground station to a broad area.
(2) GPS satellites provide accurate location and time anywhere on earth.
Commercial satellites can be ridiculously miniature — CubeSat form factor is 10 cubic cm. There are now even open source hw and sw for satellites.
Crypto Satellite
Here is the idea, as you might have figured out already. We launch a satellite to orbit. The satellite will run cryptography protocols: boom, trusted party.
Pause, Rewind
We will now unpack the idea step by step. One of the nice things in satellites that play in our favor is that they can be seen from anywhere on earth. Boarders do not apply here. More importantly, physical tampering with a satellite is as of now impossible, and even if attempted, is detectable from anywhere — you cannot just reach a satellite without being observed by multiple independent monitoring agencies (there are stealthy ways to destroy a satellite but that does not impact security). This puts us in an excellent position combating side channels of any sort — one simply cannot gain the necessary physical access.
There is another concern however — a supply chain attack. Maybe a back door is introduced as part of assembling the satellite by some part manufacturer. More generally, we need to make sure at no point in time the satellite is exposed to corruption — constructing the hw, writing the sw, before and during launch. A great help towards meeting this goal is via open source hardware and software. A multi-vendor approach, in which no part is coming from a single vendor, can reduce such attacks as well.
For the satellite to provide us any value it needs to be able to transmit information. Here again, cryptography applications benefit from the fact that all communication link is public: the existence of a message sent from the satellite, meta-data for encrypted messages and full content for messages intended to all. Even if somehow corruption is introduced — it will be detected shortly after the satellite sends the first malformed message — at which point — this satellite will just not be trusted anymore !
Can we make it happen?
This is what Cryptosat is for. Challenges are not negligible as we briefly mentioned above — but nothing in life is easy.
- hardened processes for the supply chain: each and every part is accounted for, open source all the way.
- Cubesat satellites let us be efficient in terms of costs vs computing power we can put in space.
You can read more technical details in the paper.
Eventually we plan to put a network of crypto satellites into orbit: if you thought one trusted party is a killer, imagine what multiple can do!
We operate the ground stations and provide an easy to use API for developers to integrate cryptography into their day to day applications.
In the next blogs we will go deeper into (1) the potential applications of Cryptosats and (2) the security engineering behind. Meanwhile, to get a taste of how it all works together, go ahead and play with the Cryptosat simulator.
