Trusted execution

Some of Umbra's attesters run inside AWS Nitro enclaves: isolated machines whose code is fixed and measured when they start. An enclave can prove what it is running with an attestation document signed by AWS hardware, and Umbra's Solana programs check that document before the enclave's key is allowed to sign for the pool.

EnclavesCopy Anchor Link

A Nitro enclave is a virtual machine carved out of an AWS EC2 host. It has no persistent storage, no interactive access and no network connection of its own; it talks to its host over a local channel. Once it has started, not even the host's operator can read its memory or change its code. Keys generated inside the enclave stay inside it unless the enclave's own code sends them out.

That makes an enclave a reasonable place for a key that no single person should hold, provided you can tell from outside which code the enclave is running.

MeasurementsCopy Anchor Link

When an enclave boots, the Nitro hypervisor records hashes of what it loaded in platform configuration registers (PCRs). AWS defines the first three: PCR0 is the hash of the enclave image, PCR1 of its kernel and boot code, PCR2 of the application. Two enclaves with the same PCR0, PCR1 and PCR2 booted the same image.

On chain, Umbra reduces these to one value, the measurement: the Keccak-256 hash of PCR0, PCR1 and PCR2 together. Each guardian cluster keeps a set of approved measurements, at most four, which changes only through a timelocked proposal, and the fee enclave program keeps its own approved set under its governance. An enclave running any other measurement is refused.

An enclave launched in debug mode, which lets its operator attach a console, reports PCR0, PCR1 and PCR2 as all zeros whatever code it runs, and AWS still signs its documents. The Nitro verifier refuses any document whose PCR0, PCR1 or PCR2 is all zeros. Neither a guardian cluster nor the fee enclave program can approve the measurement of three zero registers.

AttestationCopy Anchor Link

An enclave can ask the Nitro hardware for an attestation document at any time. The document contains the PCRs, a timestamp and optional fields the enclave fills in, user data among them, and it is signed with ECDSA P-384 by a key whose certificate chains back to AWS's Nitro root certificate. Umbra's enclaves put a hash of their public keys into that data, which binds those keys to the measurement: a key named in a valid document was generated by an enclave running the measured image.

Checks on chainCopy Anchor Link

Three Solana programs take part in admitting an enclave key, each checking one layer, as the chart below shows. The numbered list after it says what each one checks.

flowchart LR
doc["Attestation document and certificates"] --> p384["P-384 signature verifier"]
p384 -- "one result per signature" --> nitro["Nitro attestation verifier"]
nitro -- "attestation marker" --> registry["Guardian node registry or fee enclave program"]
registry --> key["Enclave key may sign for the pool"]

1. Signatures. Every signature in the certificate chain, and the document's own, is verified by the P-384 signature verifier program, which spreads the work over several transactions and publishes a result for each. See signatures.
2. The document. The Nitro attestation verifier checks that the certificate chain starts from the root key governance has anchored, that every certificate is P-384 with SHA-384 and was valid at the document's timestamp, that every issuer is a certificate authority, and that the document is within five minutes of the chain's clock. It then creates an attestation marker whose address commits to the document's user data, measurement and timestamp, and which records the epoch of the root anchor it was verified under.
3. Admission. The guardian node registry, or the fee enclave program, accepts the enclave's keys only if the marker exists for exactly those keys, the marker's anchor epoch is the verifier's current one, the measurement is in its approved set, the document is recent enough and the BLS key comes with a proof of possession. When governance replaces the root anchor, the epoch moves on and every marker verified under the old anchor stops counting. The guardian node registry also ties the document to the node's own account and to its current boot.

What attestation proves, and what it does notCopy Anchor Link

An accepted attestation shows that the named keys were produced inside an AWS Nitro enclave that booted an image with the approved measurement, at around the stated time, as far as AWS's signing keys can be trusted.

It does not show:

• that the measured code is correct, or free of bugs that leak its keys;
• that the measured image was built from any particular published source code, unless the build can be reproduced and compared;
• anything about AWS itself, whose root certificate is the anchor every check depends on;
• that the enclave keeps running: whoever operates the host can stop it at any time;
• resistance to attacks on the hardware, such as side channels, which is outside the model.

What runs in enclavesCopy Anchor Link

Four kinds of component run in Nitro enclaves, and only two of them sign for the pool.

The three guardian nodes. They co-sign every registration and value transaction, and they hold the viewing-key shares. Each node's BLS key is admitted through the guardian node registry by the checks above, so the combined attester signature can only include a guardian node's signature if that key came from an approved image.

The fee enclave. It opens each transaction's fee commitments, checks them and co-signs. Its key is admitted through the fee enclave program, which keeps its own set of approved measurements.

The key-generation enclaves. root-gen holds the root from which the guardian nodes and the fee enclave derive their signing keys. It seals the root only to an enclave whose attestation shows code that a threshold of signers granted, and each consuming enclave checks root-gen's attestation in turn before it accepts the root. Both checks are made off chain, against the QuorumOS release's PCR0 to PCR2 and the manifest that PCR17 and PCR18 commit to. quorum-gen generates a QuorumOS quorum key and splits it among its share holders. Neither signs for the pool, and no program checks them; the chain relies on them only through the attestations of the enclaves they provision.

The prover enclave. A library for a proving service that would run in an enclave. It is built but not deployed, and all proving happens on users' devices today.

The screener, the data endorser, the relayer and the indexer are ordinary services, not enclaves. The screener and the data endorser register BLS keys with a proof of possession, but nothing on chain attests to the code any of these four runs, so what each of them sees and does rests on its operator.

RelatedCopy Anchor Link