Phala claims that both, the contract state and all interactions are encrypted and only accessable by the contract itself. How is this implemented? Unfortunately I find very little docs touching that topic. It would be really interesting to know which parties and which keys are involved and how they are handled. Who do I need to trust if anybody? I guess intel guarantees for the actual program+input=output validation using the trusted execution environment, but are there other entities that could either break confidentially or operation of a contract?

Given the hypothetical case that a contracts would hold a private key that would have access to a very large amount of funds, what would be attack vectors?

Thanks in advance!

1 Answer 1


A short answer: you only need to trust the Secure Enclave hardware, thus the only attack vector is to compromise the hardware.

Before all, the programs in Secure Enclave are different in that the hardware owners can neither see their memory value nor affect their execution. This is the meaning of "enclave": they own the computer but not the programs in it. So in the following when I say the Worker knows the key, only the program knows but not the human operator.

Every entity in Phala blockchain has its own sr25519 key pair: each Worker has its WorkerKey to show the identity and encrypt its traffic, and each contract has the ContractKey to encrypt the traffic and its state stored on-chain. They all follow the same schema: the public key is released on-chain so you can verify the identity and use it to encrypt your request, and the secret key never leaves the Secure Enclave hardware in plain text.

Among all the Workers, some are elected as Gatekeepers. The only difference is that Gatekeepers need to generate and manage the MasterKey, which is the basis of all the ContractKey: we do not store the contract secret keys on-chain, they are generated on-the-fly by deriving the MasterKey given the metadata of the contract.

By compromising a Gatekeeper and leaking the MasterKey you can generate any ContractKey and see their states. It is so important that we need to protect the Gatekeepers well: the Gatekeeper computers must be in the 1 or 2 confidence level so they are immune to all the known attacks against Secure Enclave, and their IP addresses are not public to prevent direct access.

When a contract is deployed to a Worker, the Gatekeeper will share its ContractKey to the Worker (with end-to-end encryption of course) so the Worker can decrypt the traffic and states of the contract for execution. By compromising a single Worker, the attackers can learn the ContractKeys that have been shared with it. You can choose the Workers with high confidence levels to deploy your contract and hide them behind a gateway to enjoy the similar security promise of Gatekeepers.

Comments on Intel SGX Security

The SGX provides the promise of confidentiality and execution integrity. Until now, to crack the execution integrity and control the programs in SGX is impossible (unless the program itself has vulnerabilities, and Rust can help mitigate this).

Another problem is privacy leakage which is usually based on the side channel attacks on Spectre and Meltdown vulnerabilities and their variants. My comment on this is that although there are many successful attacks in the lab, it's hard to remotely leak the data: these attacks rely on high-frequency repeated attempts with no crash and a high-resolution timer, and both are not available in our environment.

  • Does "compromising the gatekeeper" mean compromising the gatekeepers SGX or would physical access to the unprotected memory of the gatekeeper be enough?
    – Tino Rusch
    Commented Aug 31, 2022 at 6:40
  • Compromising the SGX (and our runtime in it). Gatekeepers are in the SGX so there is no meaning to access the unprotected memory. Commented Aug 31, 2022 at 6:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.