Tactical Profile

For environments where the network is a variable, not a given.

The Tactical Profile is an operational and security profile of the Tunnel platform. It governs how Tunnel Mobile, Tunnel Command and Tunnel Relay behave when connectivity is intermittent, contested or absent, and when operational identity must not become a permanent relationship record. It is a profile of the platform, not a separate product and not a second mobile application.

  • Disconnected operation
  • Mission-scoped identity
  • Native only
  • Customer-controlled trust

One platform

The same components, operating under different assumptions.

Nothing in the Tactical Profile is a parallel system. The clients, the authority model and the bundle format are the platform's own, placed under a profile that assumes the environment is hostile to the assumptions ordinary software makes.

01

Tunnel Mobile

Native Android and iOS endpoints, operating with content sealed on the device and composed whether or not a link exists.
Explore Tunnel Mobile02

Tunnel Command

Native desktop administration: missions, compartments, enrollment, authority issuance and revocation, under the customer's control.
Explore Tunnel Command03

Tunnel Relay

Customer-operated custody infrastructure carrying sealed bundles across links that appear and disappear.
Explore Tunnel Relay

Secure Mission Bundles

Communication as a package, not a session.

A session assumes both parties are present. A package does not. Under the Tactical Profile every communication is a Secure Mission Bundle that carries its own authorization, policy and expiration, and can be delivered whenever a permitted transport appears.

Anatomy of a Secure Mission BundleA Secure Mission Bundle is the transport-independent encrypted unit Tunnel uses to protect and deliver operational communication. A routing envelope visible to the relay carries only a directional delivery alias, custody policy, priority and expiration. A sealed inner section, readable only by authorized recipients, carries sender authentication, mission and compartment context, transport restrictions and the encrypted content itself.ROUTING ENVELOPE · VISIBLE TO RELAYDirectional delivery aliasmission-scoped, non-enumerableCustody policystore, forward, expirePriorityscheduling classCreation and expirationsigned validity windowReplay and duplicate guardsingle-acceptance markersCryptographic suitealgorithm identificationSEALSEALED SECTION · AUTHORIZED RECIPIENTS ONLYEncrypted message contenttext, files, voice notesSender authenticationsignature over the assertionAuthorized-recipient policywho may open itMission and compartmentoperational contextCommunication authoritydirectional, time-limitedTransport restrictionspermitted carriage
The relay reads the outer envelope in order to carry, schedule and expire the bundle. It does not hold the keys required to open the sealed section.

Store-carry-forward

Offline operation as the normal case.

Bundles are composed offline, held on the device, handed to relay custody when a link appears, and collected on the next contact window. An interrupted transfer resumes; a bundle past its validity window is refused rather than delivered late.

Delivery across an intermittent linkA sender composes and seals a bundle while disconnected. The bundle waits on the device. When any permitted transport becomes available it is handed to the relay, which holds it in encrypted custody. The recipient collects it on the next contact window. If the validity window closes first, the bundle expires rather than being delivered late.1Composed offlinesealed on device2Held on deviceawaiting any transport3Relay custodyencrypted, opaque4Collectednext contact windowDASHED: LINK AVAILABLE ONLY INTERMITTENTLYContent is encrypted before it reaches relay custody and stays sealed for the whole journey.A bundle collected after its validity window has closed is refused rather than opened.
Delivery is resumable and does not require sender and recipient to be connected at the same time. Carriage windows and radio-layer performance depend on the transport and its integration partner.

Mission-scoped identity

Operational identity that does not accumulate.

An operator holds a mission-scoped pseudonym in each operational context. Authority to communicate is directional, capability-scoped and time-limited, and it does not carry into another mission or become a permanent contact.

Mission-scoped communication authorityAn operator holds a separate mission-scoped pseudonymous identity in each mission. Authority to communicate is directional and issued per edge: authority to reach one counterpart in one mission does not create authority to reach a different counterpart, or the same counterpart in a different mission. Each device learns only its own edges, never the mission topology.MISSION AOperatorpseudonym A-1Counterpartpseudonym A-2two directional grantsexpires with the missionMISSION BSame operatorpseudonym B-1Counterpartpseudonym B-4one directional grantno reply authority issuedThe same person in two missions is two unrelated operational identities.Neither mission's authority carries into the other.The mission authority signs who may communicate. It holds no key-agreement material and cannot derive payload keys.
Authorization is scoped to a mission, a direction, a capability and a validity window. It expires on its own, and it can be revoked.
Mission-scoped pseudonyms
The identity an operator presents in a mission is scoped to that mission. Two missions on one device do not present the same operational identity.
Mission compartments
Compartments bound who may communicate within a mission. They are an authorization structure issued by the customer's authority, not a renamed group chat.
Directional communication authority
Authority is issued per edge and per direction. Authority to reach a counterpart does not create authority for that counterpart to reply; a reply requires separately issued authority.
Expiring authorization
Authority carries a signed validity window and ends on its own, so permission is not something the organization must remember to remove.
Contact-graph minimization
Each device learns its own edges rather than the mission topology, so a captured device does not disclose the shape of the mission.

Authorization to communicate with someone in one operational context does not automatically create an independent or permanent relationship with that person.

Provisioning and device trust

Bringing a device into a mission, and taking it out again.

Enrollment happens under the customer's authority. Trust is bound to the device. A device that is lost is a device that can be withdrawn without disturbing anything else.

QR-controlled provisioning

Devices are provisioned through a controlled, in-person exchange rather than an emailed link, so the act of enrolling is itself an authorized event.

Device-bound trust where supported

Credentials are bound to the specific device. A credential copied onto another device does not function there.

Independent device revocation

Each device is revoked on its own. An operator who loses one device keeps standing on the others.

Customer-controlled trust

The root of trust that makes all of this meaningful is held by the customer in a sovereign deployment.
Device loss and revocationEach enrolled device holds its own credentials and its own authorizations. When a device is revoked in Tunnel Command, new signed state withdraws that device's authority. Connected devices apply it on receipt. A disconnected device applies it when it next receives newer signed state, or when its existing authority reaches the end of its validity window, whichever comes first. The operator's other devices are unaffected.Tunnel Commandrevocation issuedOperator device 2unaffected, retains authorityRevoked deviceauthority withdrawnDisconnected deviceapplies on next contactcredentials are per deviceno reuse on another devicebounded by validity windowA credential bound to one device does not function if it is copied to another.
Revocation is bounded rather than instantaneous: a device that is out of contact cannot apply state it has not yet received. The signed validity window bounds that exposure.

Boundaries

Native only. Deliberately.

The Tactical Profile runs on native clients because a browser cannot hold the properties the profile depends on. This is not a gap to be filled later. It is the boundary.

  • Native Android
  • Native iOS
  • Native desktop Tunnel Command
  • No browser Tactical client
  • No browser Tactical administration
  • No browser credential storage
  • No cookie-based Tactical authentication
  • No browser fallback

Transport and partners

Tunnel is the application layer.

The Tactical Profile is designed to carry bundles over approved transports and customer-operated relay infrastructure. The links themselves come from partners.

The partner integration boundaryTunnel supplies the application layer: endpoint cryptography, mission authority, bundle format, custody and delivery logic, and administration. Partners supply the layers Tunnel does not build: hardened devices, radio and SATCOM links, waveform behavior, hardware security modules and sovereign hosting. The boundary between them is an interface, and each side is accountable for its own layer.TUNNEL PROVIDESEndpoint cryptography and key rolesMission and communication authoritySecure Mission Bundle formatCustody, scheduling and expiration logicAdministration and device lifecycleSigned software and policy distributionINTERFACEPARTNER PROVIDESHardened and purpose-built devicesRadio and SATCOM linksWaveform, LPI/LPD and jamming resistanceHardware security modulesSovereign and accredited hostingField integration and sustainmentJoint customer value comes from a defined interface, not from either side overstating the other’s layer.
Radio-layer performance and protection depend on qualified communications hardware and integration partners. Tunnel makes no waveform-layer claim.

Radio-layer performance and protection depend on qualified communications hardware and integration partners. Tunnel makes no waveform-layer claim.

  • Approved transport integration is scoped per deployment and per partner.
  • Relay infrastructure under the Tactical Profile is customer-operated.
  • Hardened-device integration is a partner boundary with a defined interface.
  • Tunnel holds no government authorization and represents no approval for classified information.

Notice

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.

Controlled evaluation

Prove the profile under your own operating conditions.

Organizations assess this profile against their own operational conditions: their links, their compartments, their device handling and their loss scenarios. Tunnel runs controlled evaluations built around those questions.

Request a Controlled EvaluationRequest a Private Briefing