Security architecture
Security built around explicit trust boundaries.
A security architecture is only useful to a technical evaluator if its limits are stated as carefully as its properties. What follows describes how Tunnel protects communication, which component holds which authority, and which exposures remain.
- Endpoint cryptography
- Device trust
- Mission authority
- Relay custody
The invariant
Authority to communicate and the ability to read are held by different keys, in different places.
The separation is structural. Authority to communicate is expressed as a signature; content confidentiality comes from a key agreement. These are different key roles, on different curves, with different lifetimes, and holding the first can never produce the second.
01 · Endpoint cryptography
Content is protected where the operator is, not where the server is.
Payload keys are derived on the endpoints. Key establishment combines an X25519 agreement with an ML-KEM-768 encapsulation, so that a recording made today is not opened later by an adversary with a quantum capability against the classical half alone.
- Hybrid post-quantum cryptography is incorporated into the platform architecture: ML-KEM-768 combined with X25519 in key establishment.
- ML-KEM-768 is the mechanism standardized as FIPS 203. Tunnel implements FIPS-standardized algorithms; that is not the same as validation of a cryptographic module, and Tunnel does not describe it as such.
- Signature authentication uses Ed25519. Post-quantum signature migration is a separate matter from post-quantum key establishment, and Tunnel keeps the two claims distinct.
- Message content is encrypted before relay custody, and stays sealed for the whole journey.
Key roles
The most damaging simplification available in this domain is calling all of these “the identity key”. They have different algorithms, different protection classes, different lifetimes and different revocation semantics.
| Role | Algorithm | Purpose and lifetime |
|---|---|---|
| Device-binding key | NIST P-256 ECDSA | Proves this specific device and authenticates it to the deployment. Generated inside the platform's secure element where one is present, and not exportable. Rotated only by re-enrollment. |
| Protocol signing key | Ed25519 | Sender authentication on a Secure Mission Bundle. It signs. It has no key-agreement surface and cannot produce one. |
| Protocol agreement key | X25519 | The classical half of hybrid key establishment. Rotatable independently of the other roles. |
| Post-quantum KEM key | ML-KEM-768 | The post-quantum half of hybrid key establishment. Rotatable independently. |
| Payload key | Derived, per session | Derived on the endpoints from the agreement and encapsulation results. It exists only at the endpoints, and no administrative component contributes an input to its derivation. |
| Mission-authority signing key | Ed25519 | Held by the issuing authority to sign who may communicate. It carries no agreement or decapsulation capability, so holding it does not yield a payload key. |
| Relay custody capability key | Issued capability | Authorizes one specific relay operation, such as upload, retrieval or acknowledgement, as a separate authority. It does not authorize reading. |
02 · Device trust
Key protection is stated per platform, per algorithm, per key.
Tunnel states which protection class applies, on which platform, to which key. The industry shorthand 'hardware-backed' collapses four genuinely different situations into one word: Android Keystore is an interface, a TEE is a mode of the main processor, StrongBox is a discrete element with a narrower algorithm set, and the Apple Secure Enclave is its own design. Each earns its own label here.
- Hardware-generated, non-exportable
- Generated inside the secure element, never existed outside it, with no interface that extracts it. An attacker must break the secure element.
- Hardware-resident
- Generated and used inside the secure element, relying on the platform's own guarantee rather than an additional Tunnel assertion. An attacker must break the secure element.
- Hardware-wrapped
- A software key encrypted at rest under a hardware-resident key, and therefore plaintext in process memory while it is in use. An attacker must execute code in the process while it runs.
- Software-protected
- Protected by the operating system keystore or application encryption, with no hardware root. An attacker must read the filesystem with sufficient privilege.
The distinction that matters most is between the hardware-resident classes and hardware-wrapped. A hardware-wrapped key defeats an attacker who steals storage. An attacker executing code inside the process defeats it, because the key must be plaintext in memory to be used.
04 · Message confidentiality
What is sealed, and what has to be readable to deliver it.
A bundle is split so that the question 'what does the infrastructure learn?' has a short answer that can be checked rather than trusted.
06 · Relay custody
The relay is authorized to carry, and separately authorized for each operation.
Possession of a delivery alias does not authorize a relay operation. Upload, retrieval and acknowledgement are separate authorities, and the operation is named inside the issuer's signature.
- Relay infrastructure is not designed to possess payload decryption keys.
- Custody policy, priority and expiration travel with the bundle.
- Replay markers and duplicate suppression bound single acceptance.
- Bundles past their validity window are refused rather than delivered late.
07 · Metadata minimization
Reduced, bounded and described.
Minimization is a real property, and it is a different property from anonymity. Tunnel reduces what persists and what correlates. What a live network observer can see remains visible, and the section below says exactly what that is.
- Reduced
- Persistent identity and relationship metadata are minimized according to deployment profile. Mission-scoped addressing reduces persistent relationship exposure, turning a durable identified edge list into a scoped one.
- Bounded
- What relay infrastructure persists is limited to what custody and delivery require, and is subject to the retention policy of the deployment, which the customer controls in a sovereign deployment.
- Remaining
- Network-layer metadata such as source address, timing, ciphertext size and session continuity remains observable. So does the fact that an authenticated device connected.
- Not claimed
- Tunnel does not claim network anonymity, zero metadata, an eliminated traffic graph or unlinkable mission activity against a live network observer.
08 · Revocation
Withdrawal is real, and it is bounded.
Each device holds its own credentials and its own authorizations, so a device can be withdrawn on its own. A device that is out of contact cannot apply state it has not received; the signed validity window is what bounds that exposure.
Revocation takes effect when the device receives newer signed state, or at authorization expiration, whichever comes first. Tunnel does not claim immediate revocation of a disconnected device.
09 · Sovereign control
The strongest available reduction in third-party dependency.
In a sovereign deployment the infrastructure, the enrollment authority, the enrollment authority, the audit domain and the update process are all customer-held. There is no universal Tunnel master key and no permanent vendor access capable of decrypting customer content.
- Cryptographic roots generated and held by the customer, optionally in customer-managed HSMs.
- Air-gapped installation with an offline signed update process.
- Role separation so that no single administrative role holds the whole of the authority.
- Customer-controlled logging, retention and audit review.
11 · Technical evidence index
What can be reviewed, and under what terms.
A controlled register rather than a list of assurances. Each entry names its scope, and where an entry has a limit the limit is part of the scope.
E-01
Trust boundary model
Which party holds which key, and what each one cannot do with it.
AVAILABLE IN ARCHITECTURE REVIEW
E-02
Threat model
Adversaries considered, and the exposures accepted rather than solved.
AVAILABLE IN SECURITY BRIEFING
E-03
Hybrid key establishment
ML-KEM-768 combined with X25519 across the client platforms.
TECHNICAL EVIDENCE AVAILABLE
E-04
Cross-language test vectors
Known-answer vectors reproduced independently across the client implementations.
TECHNICAL EVIDENCE AVAILABLE
E-05
Key protection classes
Stated per platform, per algorithm and per security level. No blanket hardware-backed claim.
AVAILABLE IN ARCHITECTURE REVIEW
E-06
Mission authority and directionality
One authorization permits one direction. Reverse authority is a separate issuance.
TECHNICAL EVIDENCE AVAILABLE
E-07
Enrollment and revocation
Device-bound credentials, independent withdrawal, and the bound on when withdrawal takes effect.
TECHNICAL EVIDENCE AVAILABLE
E-08
Restart continuity
Queue survival across device restart. Delivery completing with the application never opened is not claimed.
TECHNICAL EVIDENCE AVAILABLE
E-09
Delivery state taxonomy
Eight states, with the two a reader expects deliberately absent.
TECHNICAL EVIDENCE AVAILABLE
E-10
Deployment artifact separation
Managed and sovereign builds are separated at build time, not by runtime configuration.
AVAILABLE IN ARCHITECTURE REVIEW
E-11
Controlled evaluation protocol
Scope, environment and acceptance criteria, agreed in writing before an evaluation begins.
AVAILABLE UNDER CONTROLLED EVALUATION
- TECHNICAL EVIDENCE AVAILABLETECHNICAL EVIDENCE AVAILABLE
- Evidence exists for review within the defined scope.
- AVAILABLE IN SECURITY BRIEFINGAVAILABLE IN SECURITY BRIEFING
- Reviewed with an engineer present.
- AVAILABLE IN ARCHITECTURE REVIEWAVAILABLE IN ARCHITECTURE REVIEW
- Architecture, trust boundaries and evidence scope are reviewed directly.
- AVAILABLE UNDER CONTROLLED EVALUATIONAVAILABLE UNDER CONTROLLED EVALUATION
- Released and assessed under an agreed evaluation scope.
This register names no certification, no third-party evaluation and no deployment, because none exists. Each label describes how an item is reviewed, not how mature it is. Nothing here is released publicly; it is reviewed under a briefing, an architecture review or an agreed evaluation scope.
10 · Deployment dependencies and stated limits
What the architecture depends on, and where it stops.
Every property above rests on something. These are the dependencies and the exposures that remain, published here so an evaluator finds them in the documentation rather than in testing.
- Endpoint integrity
- Device compromise is contained through device-specific credentials, authorization and revocation policies. It is not eliminated. An adversary in control of an unlocked device with content displayed defeats cryptography, and Tunnel does not claim otherwise.
- Platform secure elements
- Protection class depends on what the device platform provides. Assurance is stated per platform, per algorithm and per security level rather than as a single claim.
- Network observation
- Source address, timing, size and session continuity remain observable at the network layer regardless of deployment model.
- Transport partners
- Radio-layer performance and protection depend on qualified communications hardware and integration partners. Tunnel makes no claim about low probability of intercept or detection, frequency hopping, jamming resistance or waveform protection.
- Displayed content
- Content that has already been displayed or copied is beyond the platform's reach. Tunnel does not claim recall, unsending or secure deletion of previously viewed information.
- Media remanence
- Keys are destroyed on command and compartment material is removed. Physical media remanence is addressed by the customer's media handling policy, not by a platform claim.
- Authorization outside the platform
- Tunnel governs relationships inside the platform. It cannot prevent contact conducted outside it.
- External authorization
- Tunnel holds no government authorization. It is not NSA approved, not CSfC listed, not NIAP or Common Criteria certified, not FedRAMP authorized, and does not use a CMVP-validated cryptographic module. No approval for classified information is represented.
Reporting a vulnerability
Security researchers and customer security teams can reach the Tunnel security function directly at security@tunnelmessenger.com. Please do not include operational secrets, credentials or classified material in an initial report.
Product configurations, integrations and operational capabilities are delivered according to customer requirements, deployment environment, validation scope and applicable authorization. No approval for classified information is represented.
Next step
Bring your own threat model.
A security architecture review is one of the most common reasons organizations request a briefing. Come with the questions your evaluator will ask.