Definition
en·clave noun
- A distinct, protected area entirely surrounded by a larger environment, often with its own rules, boundaries, or governing structure.
- A territory or group that is isolated for safety, identity, or autonomy.
Examples:
- A small nation completely surrounded by another country.
- A culturally distinct neighborhood within a larger city.
- A protected zone that operates independently from the area around it.
What Does “Enclave” Mean in Computing?
In computer architecture, an enclave is a protected, isolated region of memory where code and data can run securely — even if the rest of the system is compromised.
Think of it as a vault inside your computer:
- Sealed off from the outside
- Tamper-resistant
- Unreadable from the outside
- Protected by the processor hardware itself
Modern processors like Intel SGX, AMD SEV-SNP, and ARM CCA support enclaves at the hardware level. These technologies allow software to carve out small secure zones where sensitive computations can occur safely.
The Core Idea: A Safe Room Inside a House
Imagine your computer process as a house. A normal program is one big open space — no walls, no doors. Everything inside can interact with everything else. There’s no mechanism for keeping secrets. One bad library, one malicious plug-in, or one exploit gives an attacker access to all your rooms.
An enclave is like adding a reinforced safe room inside that house:
- It has its own locked door
- Only specific people (or code) can enter
- What happens in that room stays in that room
- Even if someone breaks into the house, they still can’t get in
The enclave is protected even from the operating system — including the kernel, hypervisor, and cloud provider.
Why Enclaves Matter
In today’s world:
- Companies run untrusted third-party libraries
- Cloud workloads run alongside unknown neighbors.
- Supply-chain attacks break into trusted software.
- Malware often targets the operating system itself.
In a traditional architecture, once an attacker compromises the OS, all secrets are exposed. That includes passwords, encryption keys, customer data, AI models, and proprietary code.
Enclaves change the rules.
Enclaves protect sensitive data even if the operating system has been breached.
That’s why they’re used in:
- Cryptocurrency wallets
- Password managers
- Secure voting systems
- Confidential AI computation
- Military and intelligence systems
- Privacy-preserving cloud computing
They provide hardware-enforced protection, not just software checks.
What Happens Inside an Enclave?
Inside an enclave, three things occur:
- Code executes securely
The processor measures and verifies the code running inside. Tampered code won’t run.
- Data remains confidential
Even with full system access, attackers can’t see enclave memory.
- Communication is controlled
Anything entering or leaving the enclave must pass through secure pathways that preserve confidentiality and integrity.
This means:
- Encryption keys can live safely inside
- Sensitive calculations can run privately
- Libraries can protect their own internal state
- Callers only get back allowed results — not a peek into memory
Enclaves can share encryption keys with each other. Two enclaves can securely setup a common, shared encryption key known only to the two enclaves and the CPU. This can be used to:
- Provide shared encryption keys between the two enclaves to encrypt messages between them
- Verify the enclave it’s interacting with is authentic and not an “enclave-in-the-middle”
A Simple Analogy: Bank Transaction Envelopes
Think of an enclave as a sealed envelope inside a company:
- A customer submits a request
- The enclave opens the envelope inside its secure room
- It performs the operation
- It returns only the result — not the internal details
This is very similar to what Applied Enclaves calls notes: secure, structured packets used for communication between enclaves.
How Applied Enclaves Extends This Concept
Today, enclaves are used mostly as isolated mini-programs. Applied Enclaves takes the idea much further:
Instead of one enclave per application, we create one enclave per executable and per library.
Everything inside a process gets its own secure box.
It is the first practical model of sub-process isolation.
This unlocks:
- Trust boundaries within a process
- Verified, signed, provenance-checked dependencies
- Encrypted function calls between libraries
- “Share-by-choice” rather than “share-by-default”
- Private data structures that other code cannot read
- Resilience even if the operating system is infected
This is the foundation of the Enclave Binary Interface (eABI) and the Applied Enclaves architecture.
Why This Matters to You
Whether you’re an investor, designer, engineer, or policymaker:
Enclaves represent the future of trusted computing.
They let software:
- Keep secrets
- Enforce boundaries
- Reject untrusted components
- Remain secure even during a breach
Applied Enclaves takes this powerful hardware capability and makes it available at the level where developers actually work — inside compilers, loaders, and runtime libraries.
We believe enclaves will become as fundamental to secure computing as address spaces, TLS, and virtual memory.
What is Intel SGX?
A Clear, Semi-Technical Explanation for Non-Engineers
Intel SGX — Software Guard Extensions — is a hardware feature built into many Intel processors that allows software to create enclaves: small, highly protected regions of memory where sensitive code and data can run safely.
Put simply: SGX is a technology inside certain Intel CPUs that makes enclaves possible.
It creates secure “rooms” inside a running program where important work can be done privately and protected from the rest of the system.
Why was SGX Created?
Modern computing environments are noisy, shared, and untrusted:
- Cloud providers run code from thousands of different customers
- Operating systems, drivers, hypervisors, and firmware can all be attacked
- Third-party libraries are everywhere — and usually unvetted
- Supply chain attacks compromise software before it reaches you
Intel SGX was designed to answer one powerful question: “How can a program keep its secrets even if the operating system has been hacked?”
SGX moves part of the trust model into hardware, where attackers have a much harder time reaching it.
The Core Idea: Build a Vault Inside the CPU
A normal program stores its data in regular RAM. Any privileged attacker (root, kernel malware, hypervisor, cloud admin) can read it.
SGX changes this: SGX creates enclaves — secure memory regions protected by the CPU itself.
Inside an SGX enclave:
- Data is encrypted in memory
- The CPU blocks all outside access
- Even privileged software can’t peek inside
- Only the enclave’s own code can touch its secrets
- Attempts to probe or tamper with it fail by design
- Enclaves can authenticate (or “attest” the authenticity) for each other
- Enclaves can share symmetric keys between each other
Think of it as a vault with walls made of silicon, not software.
Even if the operating system, hypervisor, or cloud environment is compromised, SGX memory remains protected.
What Can SGX Protect?
SGX enclaves are commonly used to protect:
- Cryptographic keys
- Passwords and authentication flows
- Secure database queries
- Proprietary algorithms
- Digital rights or licensing code
- AI models
- Multi-party computation and privacy-preserving analytics
- Financial or health data processing
But their most important quality is this: SGX protects data in use, not just data at rest or in transit.
Encryption protects files and network traffic.
SGX protects the computation itself.
How Does SGX Work (Without Getting Too Technical)?
When a program starts, it can create one or more enclaves.
Each enclave has three main properties:
- Sealed Memory
Only enclave code can access enclave memory.
Everything else — OS, drivers, firmware — is blocked.
- Measured Code
The CPU cryptographically measures the enclave’s code when it loads.
This prevents tampering.
- Attestation
An enclave can prove to another computer that:
- It’s running on genuine Intel hardware
- It’s running the correct code
- It hasn’t been modified
This is crucial for cloud deployments and distributed systems.
Together, these features form a trusted island inside an untrusted ocean.
⸻
An Easy Analogy: SGX as a Secure Workspace
Imagine a large office building (your computer):
- Many people walk in and out.
- Security guards try their best, but breaches happen.
- Anyone with a master key (OS, admin, attacker) can access most rooms.
SGX allows a company to build a sealed, access-controlled micro-office inside the building:
- Fingerprint-only entry
- Soundproof walls
- Independent wiring
- Its own shredder
- No cameras allowed
- Guards can’t enter
- Landlord can’t enter
- Even the building owner can’t enter
Only employees on the enclave’s short list are allowed inside.
Where SGX Shines — and Where It Doesn’t
Strengths
- Protects data from privileged attackers
- Prevents inspection of proprietary algorithms
- Stops memory-scraping, credential harvesting attacks
- Enables secure multi-party computation
- Useful for confidential cloud workloads
- Hardware-level enforcement (much harder to bypass)
Limitations
- Enclaves are traditionally small
- You can’t simply “enclave” a whole program
- SGX by itself does not redesign the process architecture
- Developers must structure their software around enclave boundaries
This last point is exactly what Applied Enclaves solves: Making enclave-style protections usable throughout an entire program without requiring developers to become SGX experts.
How Applied Enclaves Builds on SGX
Traditional SGX usage:
- 1 enclave per application
- Developers must manually decide what goes inside
- Limited, specialized, cumbersome tooling
Applied Enclaves introduces a new architecture:
One enclave per executable and per library — automatically.
Instead of hand-crafted enclave boundaries, your compiler, loader, and runtime:
- Partition your program into enclaves
- Enforce trust boundaries internally
- Verify signatures and provenance
- Coordinate secure communication
- Protect data even inside a process
- Build secure call pathways
- Control how functions cross boundaries
Applied Enclaves turns SGX from a niche feature into a first-class execution model.
The Bottom Line
Intel SGX = the hardware foundation
A secure vault built into the CPU.
Enclaves = the safe rooms inside software
Protected zones for sensitive work.
Applied Enclaves = the architectural revolution
A whole process where every executable and library gets its own secure space.
SGX started the movement toward confidential computing.
Applied Enclaves brings it to the mainstream — and into everyday software development.
Comparison of Enclave Technologies
| Feature / Property | Intel SGX | ARM TrustZone | AMD SEV-SNP | Apple Secure Enclave |
|---|---|---|---|---|
| Purpose | Fine-grained, per-application secure enclaves | Split the whole system into ‘Secure World’ and ‘Normal world’ | Protect entire virtual machines in cloud environments | Dedicated secure coprocessor for keys, biometrics, encryption |
| Granularity | Very fine-grained-enclave per app or per library | Coarse – Entire trusted OS + apps run in ‘Secure World’ | Coarse – Protects whole VM memory, not app-level | Fixed-purpose secure subsystem |
| Who Creates the Enclave? | Each application creates its own enclaves programmatically | Each device manufacturer or the OS vendor configures ‘Secure World’ | The hypervisor/cloud platform generates each secure VM | Apple firmware manages the Secure Enclave |
| Protects Against | Malicious OS, hypervisor, drivers | Untrusted apps from ‘Normal world’ | Malicious hypervisors or cloud operators | Malware in main OS accessing key material |
| Memory Protection | Enclave pages encrypted and isolated in RAM | Secure world memory isolated; shared RAM must be explicitly managed | All VM memory encrypted w/ integrity protection | Separate memory, encrypted, not addressable by the main CPU |
| Attestation | Local & remote attestation built into hardware | Usually software-based; varies by vendor | Strong remote attestation | Limited attestation; mostly internal to Apple’s ecosystem |
| Developer Experience | Harder – Must adapt code to enclaves | Easier – Entire secure OS runs in TrustZone | No code changes – VMs run unchanged | Developers don’t write code “in” Apple Secure Enclave |
| Threat Model | “Hostile OS” model – OS cannot read enclave memory | “Hostile apps” model – ‘Secure World’ is trusted, ‘Normal world’ isn’t | Cloud VMs requiring strong tenant isolation | Protect device secrets from OS-level malware |
| Use Cases | Confidential computing, key handling, DRM, privacy, search on encrypted data, supply chain protection | Mobile payments, DRM, root-of-trust, isolated security services | Cloud VMs requiring strong tenant isolation | Face ID/Touch ID, secure keys, wallet, passkeys |
| Strengths | Strong isolation, fine granularity, rich attestation, key sharing between enclaves | Simple mental model, widely deployed on mobile | Perfect for cloud multi-tenancy; minimal developer burden | Strong hardware isolation, integrated security |
| Weaknesses | Unable to share enclaves, paging overhead, complex API | Coarse model – not suitable for per-library trust boundaries | No intra-process protection, only VM-level | Not general-purpose; controlled by Apple |
| Who Controls Keys? | Intel root keys; UEFI-managed keys; developer key-signing required | Secure world OS vendor | AMD hardware root of trust | Apple -controlled secure element keys |
| Adoption Context | Confidential computing, cloud, cryptographic applications | Mobile (Android, IoT, Automotive) | Public cloud (Azure, Google, Oracle, etc.) | iOS/macOS ecosystem |
| In Summary | Enclaves at code-level granularity | Two-world system isolation | Encrypted VMs with attestation | Private co-processor for sensitive operations |
Narrative Summary
Intel SGX Provides very fine-grained enclaves inside applications. Protects secrets even from the OS and hypervisor. Best for confidential computing, supply-chain defense, and per-library trust boundaries.
ARM TrustZone Splits the whole device into “secure” and “normal” worlds. Great for DRM, payments, hardware-backed authentication, and mobile security — but too coarse for software compartmentalization inside one process.
AMD SEV-SNP Encrypts and protects entire virtual machines in the cloud from malicious hypervisors. Perfect for cloud multi-tenancy, but provides no intra-process protection.
Apple Secure Enclave A dedicated secure processor for biometric authentication and key management. Not designed for running general software, but excellent for protecting secrets on consumer devices.
How This Fits Applied Enclaves
Consider existing enclave technologies:
- SGX = enclaves exist
- TrustZone = enclaves exist
- SEV-SNP = enclaves exist
- Apple SE = enclaves exist
However, none of these technologies can:
- Partition libraries into enclaves
- Protect private stacks, heaps, and globals inside a process (without manually programming it)
- Enforce trust-by-choice loading
- Encrypt inter-library calling
- Create one enclave per executable
- Create enforceable eABI boundaries
- Build a new process architecture on top of enclaves
Applied Enclaves transforms enclave technology from a hardware feature into a full execution model.
Want to Learn More?
We’d be happy to walk you through how Applied Enclaves leverages enclave technology to rebuild the trust model of modern computing.
→ Request a Technical Briefing
→ Explore the Applied Enclaves Architecture
→ Contact Us: [email protected]