Symmetric Authenticated Tunneling Protocol (SATP)
Certificate-free symmetric tunneling for provisioned systems that cannot absorb asymmetric cost or trust sprawl
SATP is a fully symmetric authenticated channel protocol designed for deployments in which endpoints are provisioned in advance with secret material and the runtime system must remain small, deterministic, and free of public-key infrastructure. It combines a hierarchical derivation model, a two-packet server-authentication handshake, a memory-hard client authentication phase, and an AEAD-protected duplex data channel built from QRCS symmetric primitives.
Within the QRCS stack, SATP occupies the role of a symmetric authenticated tunneling layer for controlled infrastructures. It is not a generic public internet secure transport. Its strongest fit is where operators already control device enrollment, want to avoid certificate lifecycle management and asymmetric key exchange overhead, and need a post-quantum oriented tunnel whose behavior can be explained as deterministic derivation and strict state validation rather than negotiation.
This positioning reflects a deliberate architectural trade: SATP replaces flexible, negotiation-heavy handshake models with a pre-provisioned trust fabric and hierarchical key derivation system. Keys are issued, consumed, and erased in a controlled lifecycle, enabling forward secrecy and predictive resistance without reliance on asymmetric primitives. The result is a tunnel that behaves as a stateful, strictly validated channel, where every session is derived from known inputs, every packet is authenticated with explicit context, and failure conditions lead to immediate termination rather than degraded security states.
A master derivation key creates server keys, server keys create device key trees, and servers reconstruct the active device leaf on demand rather than storing every client tree at runtime.
Client sends device identity and nonce; server returns the authenticated validation hash under the newly derived channel. The repository positions the tunnel setup path at under one millisecond in the example implementation.
Each packet carries a 1-byte flag, 8-byte sequence value, 8-byte UTC timestamp, and 4-byte payload length, with the serialized header bound as associated data for authenticated encryption.
The public repository describes a footprint under 30 kB flash and 4 kB RAM, aimed at embedded controllers, PLCs, aerospace devices, and other systems where asymmetric stacks are too costly or operationally undesirable.
GitHub Repository
The current repository README positions SATP as a certificate-free post-quantum tunnel with a two-packet handshake, one-time leaf consumption, and a compact embedded deployment profile.
Open RepositoryFormal Analysis
Game-based treatment of channel authenticity, confidentiality, ciphertext integrity, replay resistance, and the bounded forward-secrecy properties of a provisioned symmetric hierarchy.
Open Formal AnalysisTechnical Specification
Engineering description of the root, branch, and device key hierarchy, the 16-byte identity structure, the packet header, the handshake stages, and the operational state machine.
Open Technical SpecificationSATP is a replacement-class symmetric trust protocol, not a stripped-down variant of TLS
The design is aimed at systems where the primary constraint is not internet interoperability but controlled deployment, predictable cost, and long-lifecycle trust management. SATP therefore rejects both certificate-heavy secure-channel models and static shared-secret schemes that collapse under compromise.
Why the model is materially different
SATP uses deterministic symmetric derivation to remove online key distribution, certificate validation, and asymmetric exchange from the runtime tunnel path. That makes it structurally different from both KEM-based channel protocols and centralized ticket systems.
| Dimension | TLS / KEM | Kerberos / PSK | SATP |
|---|---|---|---|
| Crypto model | Asymmetric + symmetric | Symmetric + tickets | Fully symmetric |
| Key distribution | Negotiated online | Central KDC service | Pre-provisioned hierarchy |
| Session derivation | Interactive handshake | Ticket-mediated | Single SHAKE expansion |
| Server state | Moderate | Persistent / ticketing | Minimal / reconstructive |
| PQ posture | Depends on KEM profile | Limited | Native symmetric posture |
High-level technical rationale
The protocol resolves the central weakness of classical symmetric deployments by separating long-term provisioning material from per-session channel state. A device never carries a single static transport key. Instead, it carries a deterministic tree of one-time leaves derived from branch material it cannot reconstruct backward. The server carries only the branch derivation key and reconstructs the active leaf from the device identity at session time.
- Server authentication is performed through a validation hash bound to the device leaf, the server secret STc, and a fresh client nonce.
- Client authentication is completed under the newly established channel using a memory-hard verifier derived through SCB.
- The protocol deliberately eliminates suite negotiation, certificate parsing, and runtime dependence on online trust services.
- Session keys are derived deterministically from pre-issued key material and contextual inputs, ensuring consistent behavior and eliminating ambiguity in key agreement.
- Replay protection and state validation are enforced through strict nonce handling and bounded session state, preventing reuse or reordering of authenticated messages.
Three-tier derivation, one-time device leaves, and a strictly ordered session lifecycle
The formal paper and specification describe SATP as a three-tier symmetric trust infrastructure composed of a master provisioning tier, a branch-server tier, and provisioned client devices. The operational benefit is scale without per-device server storage.
Master tier
The provisioning authority holds the master derivation key M = (mdk, mid, exp). This is the root from which branch-specific server derivation keys are generated, but it is not itself derived from higher-level material.
| Role | Domain root of the symmetric hierarchy |
|---|---|
| Output | Per-branch server derivation keys and inherited expiration |
Branch tier
Each server stores S = (sdk, sid, STc, exp), where the server derivation key is computed as sdk ← Shake256(mdk ∥ cfg ∥ sid). The server also stores the long-term validation secret STc shared with devices under that branch.
| Role | Runtime derivation and device-leaf reconstruction |
|---|---|
| State | Branch derivation key, server identifier, validation secret |
Device tier
Each device is provisioned with a deterministic key tree KTreei, a 16-byte identity string, the shared server secret STc, expiration metadata, and a memory-hard authentication verifier. Each leaf is consumed once and then erased.
| Role | One-time session leaf source and client authentication state |
|---|---|
| Identity | Master, branch, epoch, service, device, and key index fields |
Session establishment
The tunnel derives all session state from a client-generated 32-byte nonce Nh, the active device leaf Kc,i, and the fixed configuration string. The validation hash is
Hc = Shake256(STc ∥ Kc,i ∥ Nh)
and the directional channel tuple is obtained through a single expansion, split into receive and transmit key/nonce pairs:
X = Shake256(Kc,i ∥ cfg ∥ Nh)
(Rk, Rn, Tk, Tn) = X[0:32], X[32:64], X[64:96], X[96:128]
Identity and key-tree structure
The specification defines a 16-byte device identity whose final four bytes encode the active key index. This allows the server to reconstruct the correct leaf on demand while the client advances monotonically through the tree.
| Field | Width | Purpose |
|---|---|---|
| Master ID | 2 bytes | Identifies the root provisioning domain |
| Branch ID | 2 bytes | Selects the branch server scope |
| Epoch Class | 2 bytes | Supports bulk revocation and migration |
| Service ID | 2 bytes | Encodes the access profile or service class |
| Device ID | 4 bytes | Uniquely identifies the client device |
| Key ID | 4 bytes | Monotone index into the device key tree |
Authenticated headers, monotone sequence handling, and deterministic server reconstruction
SATP keeps runtime behavior deliberately narrow. The only plaintext handshake packet is the Connect Request. The Connect Response, the authentication request and response, and all established traffic are processed under AEAD with the serialized packet header bound as associated data.
Packet discipline
| Field | Size | Effect |
|---|---|---|
| Flag | 1 byte | Declares the handshake or data-stage packet type |
| Sequence | 8 bytes | Enforces strict ordering and rollback rejection |
| Timestamp | 8 bytes | Provides freshness-window validation and replay filtering |
| Length | 4 bytes | Binds the exact payload size into authenticated metadata |
Because the header is authenticated as AEAD associated data, metadata tampering is not a secondary parsing problem. It becomes an authentication failure. The formal paper models replay resistance directly through the integrity of the AEAD layer together with authenticated sequence and time validation.
Post-handshake authentication and state progression
After the client verifies the server by comparing the returned Hc value to its locally computed value, it sends an encrypted authentication request carrying a device identifier and a memory-hard verifier Hpass,i = SCB(passphrasei). The server validates this pair against the provisioned record and then returns the encrypted server identifier.
Only after those checks complete do both sides transition to the established state. Invalid tags, unexpected sequence behavior, timestamp expiry, or application-level authentication failure all terminate the session and trigger destruction of active session state.
Formal treatment covers authentication, confidentiality, integrity, and replay resistance under a symmetric hierarchy
The formal analysis models an active adversary with network control, oracle access, and selected device-key compromise powers. The protocol claims are expressed as explicit games rather than generic secure-channel language.
Security properties proved or reduced in the formal model
- Channel authenticity reduces to the pseudo-random behavior of SHAKE-based derivation and correct validation of the server hash Hc.
- Confidentiality of application data is reduced to the IND-CCA style security of the underlying AEAD channel.
- Ciphertext integrity follows from AEAD verification with the packet header bound as associated data.
- Replay resistance is enforced by authenticated sequence numbers and timestamp freshness checks.
- Localized compromise is achieved because exposure of a device key affects that device, while branch compromise affects only its branch and the root remains the global trust anchor.
The main deliberate trade-off
SATP does not claim full forward secrecy in the same sense as an ephemeral asymmetric key-exchange protocol. The formal paper is explicit: because the client nonce Nh is sent in clear and the session tuple is deterministically derived from Kc,i, later compromise of the active device leaf allows reconstruction of that session from recorded traffic.
The protocol instead chooses a more controlled security model: single-use device leaves, session-key erasure at termination, memory-hard client authentication, and bounded compromise domains. That is the correct framing for SATP. Its strength is disciplined deterministic symmetric operation, not emulation of every property of KEM-based tunnels.
Provisioned infrastructure is the primary deployment assumption
SATP is aligned with environments where devices are initialized under administrative control and expected to operate for long periods with limited software footprint, narrow trust assumptions, and tightly bounded runtime complexity. That includes embedded and industrial networks, aerospace and satellite systems, telecom or utility infrastructure, secure field equipment, and controlled service environments where certificate distribution and asymmetric negotiation are unattractive operational burdens.
Its practical value comes from the fact that the runtime tunnel path is entirely symmetric. Session establishment requires no signatures, encapsulations, or certificate parsing at the endpoint; only deterministic derivation, validation of a returned hash, and memory-hard client proof under the established channel. That makes SATP particularly useful where operators need a post-quantum oriented secure tunnel without inheriting the full complexity of PKI-driven transports. The reduction in protocol surface area directly limits implementation risk and simplifies both validation and audit. It also enables predictable performance characteristics, since all cryptographic operations in the data plane are symmetric and bounded in cost.
Deployment profile
SATP is not the broadest tunnel in the QRCS family, but it is one of the most operationally distinct. It occupies the symmetric end of the QRCS secure-channel spectrum and therefore complements rather than duplicates DKTP and QSTP.
| Role in stack | Symmetric authenticated tunneling layer for provisioned systems |
|---|---|
| Replacement case | Static shared-secret tunnels, certificate-heavy embedded transports, selected PSK/KDC models |
| Primary buyers | Defense contractors, aerospace systems, industrial control networks, embedded and IoT platform vendors, telecom infrastructure providers |