2024-08-28 18:56:36 +00:00
|
|
|
# How It Works
|
|
|
|
|
2024-09-29 04:55:04 +00:00
|
|
|
Quartz establishes a secure light-client based session between a smart
|
|
|
|
contract and a TEE via a handshake protocol. This registers the TEE with the
|
|
|
|
contract and the contract with the TEE. Data can then be encrypted to the TEE and
|
|
|
|
submitted to the contract, and the contract can control when the TEE runs and on
|
|
|
|
what data. All communication with the TEE is done via
|
|
|
|
a light-client based round-trip with the blockchain.
|
2024-08-28 18:56:36 +00:00
|
|
|
|
2024-09-29 04:55:04 +00:00
|
|
|
The main goal is to prevent grinding or replay attacks on the TEE - the ability
|
|
|
|
for an operator to re-run execution many times on the same data, in an effort to
|
|
|
|
leak information. The basic idea is that all execution on the
|
|
|
|
TEE is gated by verifying light client proofs from the blockchain that give the
|
|
|
|
enclave permission to execute.
|
|
|
|
|
|
|
|
To do this, the contract must be able to verify that specific code is running on the TEE,
|
|
|
|
that a specific TEE instance is running (with that code), and that that TEE instance
|
|
|
|
generated a specific decryption key. This is all achieved by the Quartz
|
|
|
|
Handshake.
|
|
|
|
|
|
|
|
Following the handshake, app-specific execution can proceed in the enclave in a
|
|
|
|
controlled manner.
|
|
|
|
|
|
|
|
First, some basic concepts.
|
|
|
|
|
|
|
|
## Basic Concepts
|
|
|
|
|
|
|
|
In SGX land, the hash of the code that will run on the enclave is called
|
|
|
|
`mr_enclave` (for enclave "measurement")
|
|
|
|
|
|
|
|
Verifying that the code with a given `mr_encalve` executed on an SGX device is
|
|
|
|
called `remote attestation` (RA).
|
|
|
|
|
|
|
|
Intel's latest standard for remote attestation is called DCAP (Data Center
|
|
|
|
Attestation Primitives)
|
|
|
|
|
|
|
|
DCAP verification is basically verification of an x509 certificate
|
|
|
|
chain of signatures from Intel and from the given SGX device.
|
|
|
|
|
|
|
|
Secure DCAP verification depends on an up-to-date index of SGX versions (microcode and software)
|
|
|
|
and their security status (i.e. whether they are out-dated or need a security
|
|
|
|
update). This index is called the Trusted Computing Base (TCB). A valid DCAP signature must be generated by
|
|
|
|
an SGX version that is up-to-date according to the TCB info.
|
|
|
|
|
|
|
|
To establish a secure session between a smart contract and a TEE, Quartz
|
|
|
|
performs a handshake where the smart contract
|
|
|
|
verifies remote attestations from the TEE, and the TEE verifies light client proofs from the smart contract.
|
|
|
|
|
|
|
|
## Handshake
|
|
|
|
|
|
|
|
The goal of the handshake is to establish:
|
|
|
|
|
|
|
|
- specific code is running on the TEE (given by an `mr_enclave`)
|
|
|
|
- a specific TEE is running (given by a `nonce`)
|
2024-10-02 03:57:13 +00:00
|
|
|
- the TEE has a specific decryption key (given by a `pubkey`)
|
2024-09-29 04:55:04 +00:00
|
|
|
|
|
|
|
This is done in three corresponding steps:
|
|
|
|
|
|
|
|
- Instantiate
|
|
|
|
- SessionCreate
|
|
|
|
- SessionSetPubKey
|
|
|
|
|
|
|
|
In `Instantiate`, the smart contract is configured with a given `mr_enclave` and with the
|
|
|
|
light client parameters for verification (ie. weak subjectivity initialization).
|
|
|
|
This is a trusted initialization phase that requires off chain social consensus
|
|
|
|
to align on valid code to run and on legitimate light client initialization. The
|
|
|
|
`mr_enclave` should correspond to audited code with reproducible builds.
|
|
|
|
|
|
|
|
In SessionCreate, a nonce is generated on the TEE and remote attests to it. The smart
|
|
|
|
contract verifies the RA and that it was produced from the correct `mr_encalve`,
|
|
|
|
and stores the nonce.
|
|
|
|
|
|
|
|
In SessionPubKey, the TEE verifies a light client proof that the nonce was
|
|
|
|
stored in the contract, generates an encryption key pair, and remote attests to
|
|
|
|
the nonce and pubkey. The smart contract verifies the RA and that the nonce is the same and stores the pubkey.
|
|
|
|
|
2024-10-02 03:57:13 +00:00
|
|
|
The TEE is now ready to process requests encrypted to the pubkey.
|
2024-09-29 04:55:04 +00:00
|
|
|
|
|
|
|
## Execution
|
|
|
|
|
|
|
|
After the handshake, encrypted requests can be submitted to the smart contract,
|
|
|
|
encrypted to the TEE's now registered pubkey. At whatever cadence defined by the
|
|
|
|
contract, the TEE can fetch the encrypted requests, verify a light client proof of the requests and
|
|
|
|
the contracts authorization for the TEE to process them, decrypt the requests, and perform
|
|
|
|
some computation.
|
|
|
|
|
|
|
|
The TEE can then remote attest to the results, and optionally produce a
|
|
|
|
zero-knowledge proof (ZKP) of the whole execution.
|
|
|
|
|
|
|
|
The smart contract can then verify the RA and the ZKP. The ZKP provides
|
|
|
|
additional guarantees of the correctness of the execution performed by the TEE.
|