The Ethereum community has recently launched a multi-party trusted setup we dub the Perpetual Powers of Tau Ceremony. You have a great explanation of what it is in the linked article, but I will try to make an informal explanation here:

There are broadly three types of zero-knowledge proofs categorized by their setups: 1) STARKS do not require trusted setup, at the cost of a greater size proof. 2) SONIC and PLONK need an universal trusted setup but no specific setups per circuit, at the trade off of proof computations being longer. And 3) SNARKs, which require a universal trusted setup + a specific setup per circuit. The smaller and shorter proofs are traded for the need for both universal and specific setups. We are going to focus on the SNARK technology and what is described below can be applied in both the universal and the specific setups.

zk-SNARK circuits require what is called a “trusted setup” in order to be deployed with a proving key and a verifying key. The generation of such keys produces a series of numbers that must be destroyed because they would allow anyone to produce fake proofs. Since this would defy the security purpose of zk-SNARKS, these numbers are called “toxic waste” and must be eliminated. We call the process “trusted” because we are trusting whoever generated the circuit to have eliminated these numbers and for nobody else to have acquired them.

To minimize this security concerns, the Perpetual Powers of Tau Ceremony allows multiple participants to perform a trusted setup sequentially, and adding their results to a public transcript so the protocol can be entirely verified, creating a “chain of trusted setups” that can be used as a circuit itself as a whole. If only one of the participants has successfully eliminated the toxic waste, the whole protocol can be considered secure even if all other participants coordinate to attack the system or are compromised by an attacker.

Again, decentralization and variety of approaches is the name of the game: the more people participate using a variety of countermeasures to secure the elimination of toxic waste, the more likely the protocol can be used safely, because it becomes harder to attack everyone successfully or to maliciously coordinate with everyone in an open ceremony that anyone can join without disclosing who they are.

In order to provide for another layer of security and another method to protect the toxic waste from “leaking” from the trusted setup, we are going to use the Intel Secure Guard eXtensions (SGX) in order to generate the proof and eliminate the toxic waste, all inside a secure enclave of memory that nobody, not even the initiator of the ceremony, can access. Since the toxic waste never leaves the enclave and gets eliminated immediately after the generation, we have a high degree of security that it won’t be compromised.

Also briefly, SGX is a set of security-related instruction codes built into modern Intel CPUs. They allow the creation of “enclaves”, private regions of memory that cannot be read or saved by any process outside of the enclave itself, no matter the privilege level. It uses encryption by the CPU, which is decrypted on the fly within the CPU and only for code within the enclave itself. All processes outside of the enclave are considered hostile and therefore cannot access the memory.

We can’t assure that an execution inside an enclave it’s completely secure, as it is well known that the Intel SGX has been broken several times over the last few years, but it significantly reduces the attack surface in this particular case. We can understand the Intel SGX as an extra layer of security.

Please check https://www.intel.com/content/www/us/en/security-center/default.html for the latest Intel CPU security vulnerabilities found.

Using this implementation means that to obtain and store the toxic values, an attacker you perform an attack to the SGX during the generation of the response. If we assume the initiator of the ceremony is not at the same time the attacker and that other security measures are taken (running the ceremony offline, for example), we can assume that this implementation is harder to attack than the default implementation, since it’s run inside protected memory.

The perks of this method:

The powers of tau MPC (Multi Party Computation) can benefit from the execution on an enclave at 3 different levels.

Generation of a keypair inside an enclave

SGX Random generator

Intel Attestation process

Generation of a keypair inside an enclave

All the computation related to the private key (toxic waste) happens inside of an enclave without the possibility of getting this toxic waste form the outside in anyway (unless whoever runs the application also performs a successful SGX attack at the same time). This is a pretty good guarantee that we got rid of toxic waste after generation.

SGX Random Generation

Another very important point on the powers of tau ceremony is to provide as much entropy as possible from sources which are truly hard to replicate. The libc in SGX doesn’t support rand(), and instead provides the function sgx_read_rand; This function calls the hardware-based pseudorandom generator (PRNG) available in Intel CPUs through the RDRAND instruction. This random generator is then combined with the user’s input entropy, making it more resilient.

Intel Attestation process

You can generate a response inside an enclave, but if you can’t prove that it was indeed generated inside of it, why would anyone trust you? To provide this extra layer of trust, the person running the binary is going to get a quote. This quote allows them to get an Intel signed proof that the particular response was generated inside an enclave signed by 0KIMS association (IDEN3), and also that this response was generated according to Intel security standards. In this quote, the 64 bytes of the `report_data` field are filled with the sha256 hash of the proving/verification key used to generate the report and the sha256 hash of the blake2b of the previous response. This means that this quote is only valid for that specific public key and challenge.

The building process

The Rust SGX SDK was used because it helps writing Intel SGX applications in Rust. Since the current implementation of the ceremony is also implemented in Rust, using this SDK made possible the reuse of most of the code of the original implementation, making it easy to audit or compare it. As a bonus, like this we still have benefit from the multithread capabilities of the current implementation.

The first part was migrating ff_ce (Finite Fields) and pairing_ce Rust libraries from the current powers of tau implementation to make them compatible with rust-sgx (it was also needed to port byteorder since rust-sgx has its own std libraries sgx_tstd). So now, if you want, you can use them to implement other zero knowledge applications inside an SGX enclave.

After having all the libraries ready to run within SGX, it was necessary to move all the random generation inside the enclave so the toxic waste is protected and not even whoever executes it can access it. The only thing that can be obtained externally through an ecall call is the proving/verification key (public key) that identifies the toxic waste.

Finally, the binary generated is needed to ensure that you are running the enclave from the source code that the repository has, and you must be able to verify it. For that you can follow the instructions from the repository, but as a summary, since it’s a reproducible build you can get the MR_ENCLAVE value and check that it’s the same as the provided binary.

You can review all the work done on the PowersOfTauSGX repository. If you would like to be part of this MPC you have a public mailing list where interested parties can coordinate to schedule their involvement. The attestations and participation instructions can be found on this Github repository. Interested members of the community should join the mailing list to get involved.

The result

Recently, I had the opportunity to participate in the ceremony contributing to it with the result generated by this implementation as the participant number 20.

As a result of the `compute_constrained_sgx` execution, in addition to the response file necessary for the ceremony, a file with the quote is generated. This JSON file allows us to verify the execution and generation of the proving/verification key within the enclave by calling the Intel Attestation services.

X-IASReport-Signature: G9mOXkfiIbK3m5v… X-IASReport-Signing-Certificate: — — -BEGIN%20CERTIFICATE — — - {“id”:”204955653670173282863145566959457621871",”timestamp”:”2020–01–28T12:20:20.947848",”version”:3,”isvEnclaveQuoteStatus”:”OK”,”isvEnclaveQuoteBody”:”AgAAAIYLAAAKAAkAAAAAAODpGN28hJIVaOQDutDJ/Ah17UYs7+opWcNky9jY4V16AgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAAAAAADAAAAAAAAAFezT7RffLAzldx+6OtJPKYG0p1OtHfZ92R5aJyM/rvqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw56oBvWVB3AC6ZGkHrQLUnWvkTcvZllW8HAzyCD0ZOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC9/XWWRh64ji3oG5Bx3J8jX33ExQkpMJhutfOjzaxfTAR1fRt1sRSWNBRrBauzj655gRAkNpHhynhAe9mjB0fi”}

After calling the Intel Attestation service we get an “OK” on the “isvEnclaveQuoteStatus” object from the json response (you can check on the official response the full results) which validates the content of the “isvEnclaveQuoteBody”. On the other hand Intel signs the response provided by using the “X-IASReport-Signature” and “X-IASReport-Signing-Certificate” headers.

The “isvEnclaveQuoteBody” allow us to discover the proving/verification key (public key) generated on that enclave and the Blake2b hash from the previous participant.

In this case the “report_data” from the “isvEnclaveQuoteBody” is:

bdfd7596461eb88e2de81b9071dc9f235f7dc4c5092930986eb5f3a3cdac5f4c04757d1b75b1149634146b05abb38fae798110243691e1ca78407bd9a30747e2

Where its first part is the public part of the keypair used to generate the response (the proving/verification key is written at the end of the response and has a size of 768 bytes):

$ shasum -a 256 <(xxd -s -768 -ps response | tr -d

) bdfd7596461eb88e2de81b9071dc9f235f7dc4c5092930986eb5f3a3cdac5f4c

and the second one is the sha256 of the previous blake2b challenge hash:

$ echo -n “5bfc69715a5f57d29170410c04cfb19db079de9da94f9b81770d7cfd6cfb7b14d05e3268596722a6546a40b679194ce9682d395623a664a9a7d836c967a41d7d” | shasum -a 256 04757d1b75b1149634146b05abb38fae798110243691e1ca78407bd9a30747e2 -

As a conclusion we can say that we were able to have a signed Intel Attestation proof that the toxic waste has been generated within an enclave with the sole purpose of generating a response using the hash corresponding to the previous participant.

The next steps in this work are to provide a SGX binary that allows the generation of the necessary material for the Phase II. This will help to projects that wish to demonstrate that they have used the Perpetual Power of Tau ceremony to generate their circuit and that they have been carried out within a SGX enclave, which offers a high degree of confidence to their users.

For more information, please check the repo here and the Powers of Tau ceremony here.