Security architecture
& threat model
A public technical report on the ENCLAVE platform. This document is the canonical reference for our security posture and is updated alongside each platform release. All claims are recoverable from the receipts linked below.
§ 01 THREAT MODEL
What this platform protects against, and what it cannot. We name our adversaries.
A device that claims to protect everyone against everything protects no one.
The boundary below is explicit and load-bearing for every other decision in this document.
We defend, and we defend well
-
Remote network adversary
Active interception, lawful or unlawful, on any network the device touches. Mitigated by E2EE, certificate pinning, and isolated VPN.
-
Application-level exploit
Memory corruption, logic bugs, malicious payloads. Reduced by sandboxing, hardened malloc, scoped permissions, no ad SDKs.
-
Supply-chain compromise at validated stages
Tampered firmware, build artifacts, or update payloads. Mitigated by reproducible builds, dual-key signing, and attestation.
-
Lost or stolen locked device
Opportunistic theft, customs inspection, hotel staff. Mitigated by full-disk encryption tied to secure element and rate-limited PIN.
We do not protect against
-
Sustained physical access by nation-state
Unlimited time, custom hardware, decap, FIPS. ENCLAVE is not a substitute for physical custody and operational tradecraft.
-
Compelled disclosure by the device holder
Duress, coercion, lawful order against the user. No technical control survives a willing principal at the keyboard.
-
User installation of unverified code
Sideloaded binaries from unrusted origins. The platform warns; it does not guarantee. User policy carries this risk.
-
Counterparty compromise (recipient devices)
A perfect message sent to a backdoored phone is a leaked message. Out of scope by definition of endpoint security.
§ 02 BOOT CHAIN
Verified from silicon to first user code.
A chain of measurements rooted in hardware.
Each stage verifies and measures the next; any deviation halts boot and surfaces in attestation. The chain is reproducible from public artifacts.
- 01Hardware root of trust
- 02Bootloader
- 03Kernel
- 04System image
- 05Userspace
Each stage measures and verifies the next. Any deviation halts boot and is reported through attestation.
§ 03 ATTESTATION FLOW
How a verifier proves the device is what it claims.
How a device proves its state to a remote verifier.
Five messages between three parties. The verifier ends with a yes/no decision tied to a published expected state. The device cannot lie convincingly without breaking the hardware root of trust.
DEVICE
client
ATTESTATION SVC
vendor-operated
VERIFIER
enterprise / counterparty
- 01
nonce_request()
Random challenge issued to bind the quote to this round.
- 02
TEE.quote(nonce, PCRs)
Trusted Execution Environment seals the measurement set with the attestation key.
- 03
signed_quote + cert_chain
Service forwards the assertion — it never sees the device key, only the signature.
- 04
attestation_token
Verifier compares the quote against the expected platform state and decides admission.
Five messages between three parties. The verifier ends with a yes/no decision tied to a published expected state. The device cannot lie convincingly without breaking the hardware root of trust.
§ 04 DATA RESIDENCY
What lives on-device, what crosses the network.
Data residency
Every data class below is documented. If a class is not listed, it is not collected. Schema and field-level details ship in the open-source repo.
| Data class | Stored where | Leaves device? | Readable by |
|---|---|---|---|
| Contacts | on-device | no | user only |
| Messages | on-device, E2EE in transit | encrypted blobs only | sender + recipient |
| Location | not collected | no | — |
| Crash diagnostics | opt-in only | hashed + aggregated | engineering, 30d retention |
| Telemetry | disabled | no | — |
All fields above are observable in the source tree at github.com/enclave/specs, including JSON Schema and OpenAPI for any service that touches device data.
§ 05 FIRST-PARTY APP STACK
The default applications shipped with all releases.
First-party application stack
The six applications below cover the entire default workflow. None embed third-party SDKs, advertising, or analytics. All releases match a published build artifact.
- 01 Vault
Credentials, OTP seeds, recovery codes. Backed by the secure element.
repo · github.com/enclave/vault
- 02 Messenger
Signal-compatible client with sealed sender, disappearing media, and verified safety numbers by default.
repo · github.com/enclave/messenger
- 03 Browser
Hardened webview. JIT off by default, fingerprinting surfaces minimised, isolated per origin.
repo · github.com/enclave/browser
- 04 Mail
E2EE-first IMAP client. OpenPGP, S/MIME, autocrypt. Remote images blocked by default.
repo · github.com/enclave/mail
- 05 Files
On-device file manager with per-folder encryption and explicit share intents. No background indexing.
repo · github.com/enclave/files
- 06 Updater
Dual-key signed OTA delivery against an A/B partition. Reproducible build proofs published per release.
repo · github.com/enclave/updater
§ 06 UPDATE MODEL
Cadence, signing, delivery, rollback.
Update model
Software you cannot patch is software you cannot defend. ENCLAVE ships predictable monthly updates plus emergency releases. Every package is dual-signed and delivered against an A/B partition, so a failed boot never bricks the device.
- cadence
- monthly + emergency
- signing
- dual-key (vendor + build infra), 2-of-2 required
- delivery
- verified A/B partition, atomic swap on success
- rollback
- signed pin, prior good slot held 30 days
§ 07 AUDIT HISTORY
External engagements. Pending engagements are listed before they complete.
Audit history
Independent review is the only meaningful form of validation for a platform that asks for trust. Reports are published in full, including findings that have not yet been remediated.
| Date | Auditor | Scope | Findings | Report |
|---|---|---|---|---|
| 2026-Q3 | Trail of Bits | Boot chain & attestation service | 1 medium, 0 high | PDF → |
| 2026-Q4 | NCC Group | Sandboxing model & IPC surface | 1 high, 4 medium | PDF → |
| 2026-Q2 | Cure53 | Browser & webview hardening | 2 medium, 4 low | PDF → |
| — | pending | OS userspace, default applications | — | — |
§ 08 DISCLOSURE POLICY
How to report a vulnerability in this platform.
Disclosure policy
We treat researchers as partners. Reports are acknowledged within 72 hours, triaged within five working days, and resolved on a timeline appropriate to severity. We will not pursue legal action against good-faith research that respects user data and provides reasonable disclosure time.