Privacy in Livy TEE

Livy TEE lets a program execute against private runtime state while publishing only the proof material needed for verification.

The privacy model has two parts:

• the TEE isolates runtime memory while the computation runs
• commit_hashed commits private values by hash so verifiers can check them later without requiring public disclosure

Runtime Privacy

A trusted execution environment runs the program inside an isolated runtime. The host can start the workload and observe declared outputs, but it should not be able to read the program's private memory while the runtime is executing.

For Livy TEE, the attestation quote ties verification to the measured runtime:

• the program identity and runtime measurements
• the ordered public values the program chose to expose
• private-value commitments created during execution
• the verifier path used to appraise the quote

This gives the verifier a statement about what ran and what was committed, without turning every input into public data.

commit_hashed

Use commit_hashed when a value must influence execution but should not be published.

The runtime should canonicalize the private value, domain-separate the commitment, hash the bytes, and bind the hash into the attested material. The receipt can expose the commitment while the raw value stays with the data owner, verifier, or private audit process.

private state -> canonical bytes -> domain-separated hash -> attested commitment

This pattern is useful for:

• private evidence blobs
• large source documents
• balances, risk scores, or thresholds that should not be public
• verifier-only audit fields
• source payloads that are disclosed only under policy

The commitment proves that a specific hidden value was bound into the attested execution. It does not reveal the value by itself.

Verifying Private State

A verifier can check private state in two modes.

With a private opening, the verifier receives the hidden value through an approved private channel. It canonicalizes the value the same way the runtime did, recomputes the commit_hashed digest, and compares it to the commitment in the attested receipt.

Without a private opening, the verifier can still check that the attested runtime committed to a stable hidden value. This is useful when the product needs public proof that private state was used, but only a designated auditor or counterparty is allowed to inspect the raw state.

Verification Checklist

To verify a private-state claim, check:

• the TEE quote is valid and appraised by the expected verifier path
• the runtime measurements match the expected program or policy
• the public values match the expected request, output, or receipt
• the commit_hashed commitments are present in the attested material
• any private opening recomputes to the published commitment
• the program's public result follows from the verified private state and public values

If any of those checks fail, the private-state claim should not be accepted.

Boundaries

TEE privacy is a runtime confidentiality boundary, not a general secrecy guarantee for the whole product.

Livy TEE does not hide values that the program outputs, logs, stores in public receipts, sends to external services, or reveals through the application layer. It also does not prove that an external source was truthful unless the source claim is modeled, committed, and verified.

Use commit_hashed for private values that need durable verification. Publish raw values only when the product, policy, or user consent requires disclosure.