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
The authority that permits communication does not possess the keys required to decrypt communication.
This separation is structural rather than promised. The authority to communicate is expressed as a signature. Content confidentiality comes from a key agreement. Signing authority and key agreement are different key roles, on different curves, with different lifetimes. Holding the first cannot 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.
'Hardware-backed' is ambiguous and Tunnel does not use it as a claim. Android Keystore is an interface, not a location. A TEE is not a discrete secure element. StrongBox supports a narrower algorithm set than the TEE around it, not a wider one. The Apple Secure Enclave is none of those things. Tunnel states which protection class applies, where.
- 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 resists an attacker who steals storage. It does not resist an attacker executing code in the process, 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, not eliminated.
Minimization is a real property and it is not anonymity. Tunnel reduces what persists and what correlates; it does not claim to remove what a network observer can see.
- 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.
10 · Deployment dependencies and stated limits
What the architecture depends on, and what it does not cover.
Every property above rests on something. These are the dependencies and the exposures that remain, stated so that an evaluator does not have to discover them.
- 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.