Why Privasys

The Trust Problem

Cloud computing requires handing over your data and code to a third party. Even with encryption at rest and in transit, there is a fundamental gap: data must be decrypted to be processed, and during that window the cloud provider, the host OS, the hypervisor, and any privileged attacker can observe it.

Confidential Computing closes this gap by running workloads inside hardware-enforced Trusted Execution Environments (TEEs). Technologies like Intel SGX and Intel TDX ensure that memory is encrypted, CPU state is isolated, and even a compromised hypervisor cannot peek inside.

But hardware isolation alone is insufficient. A critical UX problem remains:

How does a remote client know it's actually talking to a genuine TEE running the expected code?

The traditional answer — remote attestation — requires custom client-side code, specialised SDKs, and an out-of-band attestation flow that is alien to the browser-based web.

Our Approach

Privasys takes a different path. Instead of asking every client to speak a custom attestation protocol, we embed the attestation evidence directly into standard TLS certificates. This technique is called RA-TLS (Remote Attestation TLS), and it means:

• Zero client-side changes. Any TLS client — a browser, curl, a mobile app — can connect without modification. HTTPS just works.
• Composable with existing PKI. The RA-TLS certificate is signed by a private CA, chaining into your organisation's existing trust hierarchy.
• Cryptographic binding. The hardware quote's ReportData contains a hash of the TLS public key, making the attestation inseparable from the TLS session.
• Verifiable by anyone. A relying party extracts the quote from a standard X.509 extension and verifies it against the chip vendor's attestation infrastructure.

What Privasys Provides

Privasys is not a hosted platform. It is open-source infrastructure that you deploy on your own hardware or cloud instances:

Enclave OS (Mini)

A minimal OS layer for Intel SGX enclaves, written entirely in Rust. It provides RA-TLS ingress, an encrypted key-value store, MRENCLAVE-sealed configuration, and a WASM runtime for running arbitrary business logic inside the enclave — all communicating with the untrusted host through lock-free circular buffers instead of traditional OCALLs.

→ Enclave OS documentation

Caddy RA-TLS Module

A tls.issuance module for the Caddy web server that produces RA-TLS certificates for Confidential VMs (Intel TDX, AMD SEV-SNP planned). Caddy handles TLS termination, certificate caching, and renewal; our module generates keys inside the TEE, obtains hardware quotes, and signs certificates. Supports both deterministic and challenge-response attestation.

→ Caddy RA-TLS documentation

RA-TLS Clients

Multi-language client libraries (Python, Go, Rust, TypeScript, C#/.NET) for connecting to RA-TLS servers. Each client demonstrates how to verify attested TLS connections using custom CA trust roots.

→ RA-TLS Clients documentation

Design Principles

Honest by Design

Traditional cloud requires you to trust the provider. Privasys replaces trust with verification:

• The enclave's identity (MRENCLAVE) proves exactly which code is running.
• The RA-TLS certificate proves the TLS key was generated inside that enclave.
• The Config Merkle root proves exactly which CA, modules, and WASM applications are loaded.
• All of this is embedded in a standard X.509 certificate that any client can inspect.

Don't trust. Verify.