]> Independent Researcher

India sripadkarthik@gmail.com https://github.com/sripad2020/Zeropath-vpn

ART DISPATCH Working Group VPN zero-trust HBSPV SGCP SCSWP hop-bound attestation ephemeral session opcode SOCKS5 forward secrecy trust scoring This document specifies the complete ZeroPath VPN protocol suite, comprising three coordinated sub-protocols: HBSPV (Hop-Bound Secure Packet Validation) -- a three-domain packet framing model that isolates payload decryption to the authorized egress node while allowing intermediate hops to validate forwarding context without accessing payload content. SGCP (State Graph Cryptographic Protocol) -- a three-message cryptographically attested handshake enforcing mutual authentication and device posture verification before any session is established. SCSWP (Secure Cryptographic Session Workspace Protocol) -- a continuous session state mechanism providing tamper-evident hash chain continuity, epoch-bound forward secrecy, and four-dimensional trust scoring across the full session lifetime. This document additionally specifies a complete opcode architecture governing all control-plane and data-plane message types, providing a machine-parseable, extensible message dispatch framework. The protocol suite is implemented as a pure Python reference implementation at .

Introduction The challenge of securing network sessions in a zero-trust architecture requires satisfying several properties simultaneously:

1. Per-hop payload isolation: intermediate routing nodes MUST be able to validate forwarding context without accessing the inner payload. This is not satisfied by standard VPN tunnels, where any compromised hop can access all traffic.
2. Pre-data cryptographic attestation: no application data SHOULD flow until both parties have proven their identity and device posture through a signed, freshness-checked exchange.
3. State chain continuity: a tamper-evident record of every session operation MUST exist such that replaying, omitting, or reordering operations breaks the chain.
4. Forward secrecy at event granularity: each significant session event (activation, migration, recovery) MUST produce fresh key material with mandatory erasure of the previous key, not merely at session boundaries.
5. Continuous trust evaluation: the system MUST continuously assess device posture, network stability, protocol compliance, and session behavioral patterns, and MUST be able to suspend a session mid-flight without full teardown.
6. Machine-parseable message dispatch: all control and data plane messages MUST be identifiable by a compact, versioned opcode to support efficient parsing, extension, and interoperability.

ZeroPath VPN is designed to satisfy all six properties.

Design Philosophy The protocol is designed around the principle that security properties should be enforced by the protocol structure itself, not by access control lists applied to a protocol that does not enforce them intrinsically. Domain 3 payload isolation (property a) is architectural: the structure of the three-domain frame ensures that an intermediate hop cannot decrypt the payload even if it is compromised, because it does not possess the egress key. State chain continuity (property c) is enforced by making every session operation produce a new hash that depends on all previous operations. There is no "skip" operation that could hide a tampered history. Forward secrecy at event granularity (property d) is enforced by requiring key erasure before the new key reference is stored. The implementation cannot complete an epoch rotation without overwriting the old key reference.

Relationship to Existing Protocols HBSPV is complementary to IPsec and TLS . Where TLS provides confidentiality and authentication of the channel between two endpoints, HBSPV provides per-hop authorization of forwarding decisions along a multi-hop path, without requiring each hop to terminate and re-originate TLS. Legacy TLS versions 1.0 and 1.1 MUST NOT be used . SGCP's attested handshake shares goals with QUIC's connection establishment but adds device attestation and an eight-step server-side validation pipeline that goes beyond certificate verification. SCSWP's state chain and DNAC mechanism share conceptual similarity with Certificate Transparency logs, but operate per-session rather than globally.

Implementation A complete reference implementation in Python (pure standard library, zero external dependencies) is published on PyPI and available on GitHub at: The implementation includes: REST control plane server, asyncio tunnel forwarder, interactive client CLI, asyncio SOCKS5 proxy, and a real-time web monitoring dashboard.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

HBSPV

Hop-Bound Secure Packet Validation. The three-domain packet framing sub-protocol.

SGCP

State Graph Cryptographic Protocol. The attested handshake sub-protocol.

SCSWP

Secure Cryptographic Session Workspace Protocol. The session state continuity sub-protocol.

Zession

An ephemeral session instance. Each Zession has a unique ZessionId of the form "ZESS_<10 hex chars>".

Epoch

A bounded cryptographic period associated with a specific K3 key. A new Epoch is derived on each rotation trigger. The old K3 is erased when the Epoch ends.

Epoch ID

Identifier of the form "<ZessionId>_EPOCH_<NNN>" where NNN is a zero-padded three-digit epoch counter.

Capsule

An Endpoint Capsule (Section 6). A short-lived, server-signed descriptor of the server's identity, reachable endpoints, and policy reference.

Dissolver

The client-side bootstrap validator (Section 7) that applies seven mandatory validation steps to a Capsule.

.hbspv

The file extension used for the client configuration bundle. Contains the Capsule, key references, initial state hash, path profile, and policy.

DNAC

Dynamic Nonce-Authenticated Chain. An independent hash chain that advances in parallel with the state chain.

K1

Session Root Key reference. Established at provisioning time. Never stored as raw key material.

K2

Workspace Authentication Key reference. Derived from K1 with policy and path context.

K3

Epoch Key reference. Derived from K1, K2, and fresh entropy. Rotated on every epoch boundary event. Old K3 MUST be erased before the new K3 is stored.

TOFU

Trust On First Use. The initial fingerprint pinning strategy used by the Dissolver when no pre-configured trust anchor exists.

Opcode

A 2-byte big-endian unsigned integer identifying the type of a control-plane or data-plane message.

Frame

An HBSPV packet comprising three security domains.

ZessionId

Unique session identifier. Format: "ZESS_" + 10 random uppercase hex characters.

ClientId

Unique client identifier. Format: "CLT_" + 10 random uppercase hex characters.

PathScore

A floating-point value in [0, 100] indicating the quality of an authorized path profile.

TrustScore

A floating-point value in [0, 100] representing the composite four-dimensional trust evaluation for a Zession.

Freshness Window

The maximum age of a signed message that the server will accept. RECOMMENDED: 300 seconds.

Protocol Architecture: Six Planes The ZeroPath VPN protocol suite is organized into six logical planes. Each plane is responsible for a distinct aspect of the protocol.

Plane Definitions Six Logical Planes

Plane	Responsibility
Control Plane	Session lifecycle management. Exposes a REST API on TCP/3000. Handles provisioning, attestation, activation, migration, recovery, disconnect, and status.
Bootstrap Plane	Endpoint Capsule delivery and Dissolver-based validation. Clients MUST complete bootstrap before entering the attestation plane.
Attestation Plane	SGCP three-message handshake. No Zession is established without a completed handshake.
State Plane	SCSWP authenticated hash chain, DNAC, K1/K2/K3 key hierarchy, and D/N/P/S trust scoring.
Path Validation Plane	HBSPV three-domain packet framing and hop validation. Each packet carries its own forwarding authorization.
Data Plane	SOCKS5 tunnel forwarder. Bidirectional TCP forwarding on TCP/4444 with ZessionId token authentication.

Plane Interaction and Phase Ordering A client MUST complete the following phases in strict order:

Phase 1 -- Bootstrap:

Obtain a Capsule from the server's Control Plane. Run the Dissolver seven-step validation. Initialize the local SCSWP state mirror.

Phase 2 -- Attestation:

Run the SGCP three-message attested handshake. All eight server-side validation pipeline steps MUST pass. Transcript hash stored by both parties.

Phase 3 -- Activation:

Register the ZessionId with the server's tunnel forwarder. Receive: assigned VPN IP, EpochId, TunnelPort. First epoch rotation is triggered at this point. K3 derived and stored; K3(prev) erased.

Phase 4 -- Data:

Start local SOCKS5 proxy (loopback only). Route browser traffic through proxy to server forwarder. Forwarder validates ZessionId token for every connection.

Port Assignments The following default port assignments apply. All are configurable via operator parameters or environment variables.

• TCP/3000 -- Control Plane REST API
• TCP/4444 -- Data Plane Tunnel Forwarder
• TCP/1080 -- Client-side SOCKS5 Proxy (loopback only)

Client Lifecycle State Machine Each client progresses through the following states. These states are represented by the ClientStatus enumeration in the reference implementation.

States Client States

State	Meaning
PROVISIONED	Client record created on server. No Capsule generated yet.
PACKAGE_READY	Capsule and client configuration bundle (.hbspv file) generated and available for download.
DOWNLOADED	Client has received the .hbspv bundle.
ATTESTING	SGCP handshake in progress.
CONNECTED	Handshake complete, tunnel active, HBSPV path validated.
DISCONNECTED	Transport dropped. Zession state retained. Recovery possible without re-provisioning.
RECOVERING	Section 15 session recovery underway.
TERMINATED	Zession dissolved. All key material erased.

SCSWP State Events Linked to Lifecycle Every lifecycle transition appends a record to the SCSWP state chain:

• OP_PROVISION -- Client created.
• OP_HANDSHAKE -- Attested handshake complete.
• OP_ACTIVATE -- Tunnel activated.
• OP_PACKET -- Each HBSPV test packet transmitted.
• OP_MIGRATE -- Path migration completed.
• OP_RECOVER -- Session recovery completed.
• OP_DISCONNECT -- Tunnel disconnected.
• OP_TERMINATE -- Session terminated and all keys erased.

Five-Stage Trust Decision Model Trust decisions in ZeroPath VPN are organized into five sequential stages. Each stage MUST be satisfied before the next stage is evaluated.

Stage 1 -- IDENTITY

Is the client identity recognized and valid? ClientId matches a provisioned record. Identity email format matches stored identity.

Stage 2 -- DEVICE_TRUST

Is the client device the one that was registered? Device reference ID matches stored device reference. Platform hash within acceptable variance. Device fingerprint change penalty applied if mismatch.

Stage 3 -- ATTESTED_CONNECTION

Has the SGCP handshake been completed successfully? All eight server-side validation steps passed. Ed25519 signatures verified on all three messages. Transcript hash stored and consistent.

Stage 4 -- ZESSION_AUTHORIZATION

Is the current Zession in a valid state for this operation? ZessionId matches. Trust score above suspension threshold (> 10.0). Session not in TERMINATED or SUSPENDED state.

Stage 5 -- PATH_AUTHORIZATION + HBSPV_HOP_VALIDATION

Is the requested path authorized and are packets valid? PathProfileId is in the server's authorized path set. Policy compliance flag is TRUE for chosen path. HBSPV frame epoch matches current epoch. Packet sequence number is strictly monotonically increasing.

Endpoint Capsule Structure The Endpoint Capsule is the server-signed descriptor that a client MUST validate through the Dissolver before connecting. It is the primary bootstrap trust anchor.

Capsule Fields

capsule_id (string, REQUIRED)

A unique identifier for this specific capsule instance. Format: "CAP_" followed by random hex characters.

zession_id (string, REQUIRED)

The ZessionId for the session this capsule governs.

server_identity (string, REQUIRED)

A human-readable label identifying the server. Format: "sgcp-control.<hostname>". MUST NOT be a bare IP address.

server_fqdn (string, REQUIRED)

The Fully Qualified Domain Name of the server. A client MUST NOT connect if this field contains a bare IP.

authorized_endpoints (array of strings, REQUIRED)

Each element is an "<IP>:<port>" string. MUST contain at least one element. The client MUST NOT connect to any endpoint not in this list.

transport_type (string, REQUIRED)

The transport protocol. RECOMMENDED value: "TCP-ATTESTED".

public_key_fingerprint (string, REQUIRED)

The server's public key fingerprint. Format: "SHA256:<base64url-encoded-SHA256-hash-of-public-key>". Length of the hash portion MUST be at least 43 characters.

policy_id (string, REQUIRED)

The policy template governing this Zession. RECOMMENDED values: "POL_ZERO_TRUST_STRICT", "POL_ENTERPRISE_SPLIT", "POL_CLASSIFIED".

nonce (string, REQUIRED)

A unique random value preventing Capsule replay. MUST be at least 128 bits of random data (32 hex characters).

expiration (string, REQUIRED)

ISO 8601 UTC timestamp after which the Capsule is invalid. RECOMMENDED expiry window: 300 seconds from issuance.

attestation_context_reference (string, REQUIRED)

A SHA256 hash reference linking this Capsule to the client's device attestation context. Used in SGCP SYN message.

signed_manifest_hash (string, REQUIRED)

SHA256 hash of the full client configuration bundle.

authentication_data (string, REQUIRED)

A server-computed authentication credential over the Capsule fields.

Capsule Delivery The Capsule is delivered as part of the .hbspv JSON bundle via POST /api/clients/:id/package. The entire bundle is saved to disk (default: client_config.hbspv). The Capsule is validated by the Dissolver before any connection.

Capsule Validity Window The RECOMMENDED expiration window is 300 seconds from the time of generation. This short window limits the risk of a stolen Capsule being used to impersonate the legitimate client. Implementations that require longer validity windows for operational reasons SHOULD document their threat model rationale.

Dissolver Bootstrap Validator The Dissolver is the client-side engine that validates the Endpoint Capsule before any connection attempt. All seven steps MUST pass. Failure at any step MUST cause the client to refuse connection and SHOULD emit a diagnostic message identifying the failing step.

Step 1 -- Credential Recognition CONDITION: The publicKeyFingerprint field MUST be present and MUST NOT be empty. ON FAILURE: Reject connection with diagnostic "Credential Recognition FAILED -- fingerprint field absent or empty."

Step 2 -- Certificate / Public Key Validation CONDITION: The publicKeyFingerprint MUST match the pattern: "SHA256:" followed by at least 32 characters. ON FAILURE: Reject with "Certificate Validation FAILED -- fingerprint format invalid."

Step 3 -- Trust Anchor Selection CONDITION: If a pinned fingerprint exists, the Capsule's publicKeyFingerprint MUST match the pinned value. If no pinned fingerprint exists, the Capsule's fingerprint is accepted and pinned (TOFU). ON FAILURE: Reject with "Trust Anchor FAILED -- fingerprint does not match pinned value."

Step 4 -- Identity Binding CONDITION: The serverIdentity field MUST consist of at least two components separated by a period. It MUST NOT be an IP address. ON FAILURE: Reject with "Identity Binding FAILED -- server identity malformed or bare IP."

Step 5 -- Endpoint Validation CONDITION: The authorizedEndpoints array MUST be non-empty. The client MUST only attempt connections to endpoints listed in this array. ON FAILURE: Reject with "Endpoint Validation FAILED -- no authorized endpoints."

Step 6 -- Server FQDN Validation CONDITION: The serverFQDN field MUST be present and MUST NOT be a bare IP address. ON FAILURE: Reject with "FQDN Validation FAILED -- serverFQDN absent or is a bare IP address."

Step 7 -- Bootstrap Policy Validation CONDITION: All three of the following MUST be true: (a) expiration timestamp MUST be in the future; (b) nonce field MUST be present and non-empty; (c) attestationContextReference MUST be present and non-empty. ON FAILURE (expiry): If the server is reachable, the client SHOULD automatically delete the expired Capsule, request a new one, and re-run all seven steps. ON FAILURE (nonce or attestRef absent): Reject with "Bootstrap Policy FAILED -- nonce or attestationRef missing."

SGCP: Attested Handshake The SGCP attested handshake is a three-message exchange that MUST complete before any Zession is considered established. It provides mutual authentication, device posture verification, nonce-based replay protection, timestamp freshness enforcement, an eight-step server-side validation pipeline, and transcript binding.

Attested SYN (Client to Server) The client builds the Attested SYN using the SGCPEngine. Fields include:

client_id (string, REQUIRED)

The client's identity string (email format preferred).

device_identity_reference (string, REQUIRED)

An opaque reference to the client's device identity record (DeviceRefId).

device_context_reference (string, REQUIRED)

SHA256(platform description string). Allows the server to detect device changes.

client_nonce (string, REQUIRED)

A 128-bit (32 hex character) cryptographically random value. MUST be unique across all sessions.

timestamp (string, REQUIRED)

ISO 8601 UTC timestamp. MUST be within the Freshness Window (RECOMMENDED: 300 seconds).

connection_context (string, REQUIRED)

SHA256("CONN_CTX:" + clientId + ":" + zessionId + ":" + unix_timestamp_float).

protocol_version (string, REQUIRED)

"HBSPV/2.0-SGCP/2.0"

attestation_context (string, REQUIRED)

The attestationContextReference from the Endpoint Capsule.

digital_signature (string, REQUIRED)

Ed25519 signature over pipe-delimited concatenation of all above fields. Format: "SIG_ED25519:<32-hex-chars>".

Server Eight-Step Validation Pipeline Upon receipt of the Attested SYN, the server MUST execute all eight steps in sequence. Failure at any step MUST terminate the handshake.

1. Parse Attestation Context: verify all required fields are present and well-formed.
2. Client ID Lookup: match client_id to the provisioned client record. Stored identity MUST exactly match.
3. Certificate Check: verify client's publicKeyFingerprint is present and in correct format.
4. Digital Signature Verification: reconstruct the signature payload and verify using client's stored public key reference with constant-time comparison.
5. Device Context Check: verify device_identity_reference matches stored device reference.
6. Nonce Validation and Replay Protection: if client_nonce already seen, MUST reject. If fresh, add to used-nonce set.
7. Timestamp Freshness Check: reject if |current_UTC - syn.timestamp| > 300 seconds.
8. Policy Evaluation: verify client's assigned policy allows the requested connection context.

Attested SYN-ACK (Server to Client) If all eight steps pass, the server constructs the Attested SYN-ACK containing: server_identity, server_certificate_reference, client_nonce_reference (echo of SYN nonce), server_nonce (fresh 128-bit random), timestamp, connection_context, attestation_context, digital_signature, and validation_pipeline (array of all eight step results).

Attested ACK (Client to Server) The client verifies the SYN-ACK server signature, then builds the Attested ACK containing a transcript proof: transcript_reference = SHA256(syn.client_nonce | syn_ack.server_nonce | syn.connection_context | client_identity) This hash binds the ACK irrevocably to the specific three-way exchange. On success, AttestState transitions to HANDSHAKE_COMPLETE and the transcript_hash is stored. On failure, the Zession is NOT established and the client MUST delete the local Capsule and re-provision.

SCSWP: Session State Engine The SCSWP state engine maintains three parallel structures for each Zession: a K1/K2/K3 key hierarchy, a state hash chain, and a DNAC (Dynamic Nonce-Authenticated Chain).

K1/K2/K3 Key Hierarchy K1 (Session Root Key): K1 = SHA256("K1:" + zessionId + ":" + sessionRootContext)[:16] + "...". Established once at provisioning time. Does not rotate within the Zession lifetime. K2 (Workspace Authentication Key): K2 = SHA256("K2:" + K1_ref + ":" + policyId + ":" + pathId)[:16] + "...". MUST be re-derived if the policy or authorized path profile changes. K3 (Epoch Key): fresh_nonce = random 128-bit value; K3 = SHA256("K3:" + K1_ref + ":" + K2_ref + ":EPOCH_" + epoch_counter + ":" + fresh_nonce)[:16] + "...". Derived fresh on each epoch rotation. When K3 is rotated, the previous K3 reference MUST be overwritten in storage before the new K3 reference is written. Production implementations MUST also erase the raw key material and zero the memory before overwriting.

State Hash Chain Initial state: state_hash(0) = SHA256("INIT:" + zessionId + ":" + timestamp) Subsequent states: state_hash(N) = SHA256(state_hash(N-1) + ":" + sequence_number + ":" + event_description + ":" + ISO8601_timestamp) Every Zession operation appends a new ScswpStateRecord to the chain. The chain is cryptographically linked; each record depends on all previous records.

DNAC: Dynamic Nonce-Authenticated Chain The DNAC is a second, independent hash chain that advances in parallel with the state chain. Initialization: dnac(0) = "GENESIS" Advancement: dnac(N) = SHA256(dnac(N-1) + ":" + zessionId + ":" + operationId + ":" + workspaceState + ":" + ISO8601_timestamp) Session recovery (Section 15) MUST validate both the state hash and the DNAC value before resuming. An implementation MUST NOT allow recovery that resets the DNAC chain to a previous value.

Trust Scoring: D/N/P/S Model The trust score is a floating-point value in [0.0, 100.0] evaluated on every session operation across four dimensions:

• D -- Device Trust: device characteristics vs. those at session establishment.
• N -- Network Trust: IP address stability. A change triggers PENALTY_NETWORK_CHANGE (-15.0).
• P -- Protocol Trust: nonce freshness, timestamp validity, signature correctness, protocol version match.
• S -- Session Trust: operation rate and sequence number monotonicity. Rapid operations (>20/10s) trigger PENALTY_RAPID_OPS (-5.0).

Trust Score Penalty and Reward Constants

Event	Delta	Constant
Network IP change	-15.0	PENALTY_NETWORK_CHANGE
Device fingerprint change	-60.0	PENALTY_DEVICE_CHANGE
Rapid operations (>20/10s)	-5.0	PENALTY_RAPID_OPS
Authentication failure	-25.0	PENALTY_AUTH_FAIL
Stable operation (no issues)	+0.5	REWARD_STABLE_TRUST

If trust_score <= TRUST_SUSPENSION (10.0): is_suspended = True; the server MUST refuse further requests.

Security Epoch System The Security Epoch System binds cryptographic key material to the authenticated session state. An epoch cannot be constructed without the current SCSWP state hash.

Epoch Derivation EpochId = ZessionId + "_EPOCH_" + zero_padded_epoch_number (e.g., "ZESS_A3B5C7D9E1_EPOCH_000"). state_bound_hash = SHA256(prev_state_hash + ":" + fresh_entropy + ":" + session_transcript_ref + ":" + authorized_path_context) fresh_entropy MUST be at least 128 bits of cryptographically random data generated fresh for each epoch.

Epoch Rotation Triggers An epoch MUST rotate on any of the following events:

• TRIGGER_ACTIVATION: client completes Phase 3 (tunnel activation).
• TRIGGER_MIGRATION: client migrates to a different authorized path profile.
• TRIGGER_RECOVERY: session recovery (Section 15) completes.
• TRIGGER_SCHEDULED: rekey interval elapsed (RECOMMENDED: 1800 seconds).

Key Erasure Procedure The following procedure MUST be executed on each epoch rotation:

1. Derive the new K3 reference from K1, K2, and fresh_entropy for the new epoch.
2. Store the new K3 reference in a temporary variable.
3. Overwrite the storage location of the old K3 reference with the new K3 reference value.
4. Zero the temporary variable.
5. Increment the epoch sequence number.
6. Add an OP_ACTIVATE, OP_MIGRATE, or OP_RECOVER record to the SCSWP state chain, referencing the new EpochId.

In production systems, Step 3 MUST use a memory barrier to prevent compiler or CPU reordering of the zero-write.

HBSPV: Three-Domain Packet Frame HBSPV defines a packet frame comprising three security domains. The architectural guarantee: "An intermediate authorized hop can validate all information it needs to make a forwarding decision without possessing the key material needed to decrypt the inner payload."

Domain 1: Outer Authenticated Forwarding Header Domain 1 is visible to and processable by ALL authorized hops. Key fields include: protocolVersion, compactZessionReference, packetSequenceNumber (monotonically increasing 64-bit, starting at 10001), securityEpochReference, currentHopReference, nextHopReference, validationStateReference, pathContextReference, attestationContextReference, deviceContextReference, and outerAuthTag (HMAC-SHA256(K2_ref, sequence_number + ":" + epochId)[:16]). All hops MUST verify the outerAuthTag. Hops MUST reject packets whose epoch reference does not match the currently expected epoch. Hops MUST reject any packet with a sequence number <= the last accepted value.

Domain 2: Protected Routing and Policy Context Domain 2 carries routing authorization evidence. Fields include: pathAuthorizationReference (full PathProfileId), policyReference, trustContextReference ("TRUST_SCORE:<float>"), routeConstraints (array: "NO_UNAUTHENTICATED_HOPS", "STRICT_EPOCH_MATCH", "STRICT_EGRESS_MATCH"), and routingAuthEvidence (Ed25519 signature over Domain 1 + Domain 2 fields).

Domain 3: End-to-End Protected Inner Payload Domain 3 carries the actual application payload, encrypted such that ONLY the authorized egress gateway can decrypt it. Fields include: decryptionStatusAtIntermediateHops ("PROTECTED_CIPHERTEXT -- NOT DECRYPTED AT INTERMEDIATE HOPS"), targetDestination, innerProtocol, encryptedPayloadHex (AES-256-GCM ciphertext), and innerPayloadIntegrityTag (POLY1305 authentication tag).

Hop Validation Records Each hop that processes an HBSPV frame appends a HopRecord to the frame's hop_validation_chain. Fields: hop_id, zession_reference, packet_sequence_reference, security_epoch, path_context_reference, validation_result ("HOP_VALIDATED", "FINAL_VALIDATED", or "REJECTED"), freshness_context, authenticated_validation_evidence, and inner_payload_decrypted (boolean, MUST be False at all hops except the authorized egress).

Hop Processing Rules by Role Entry Gateway: MUST validate Domain 1 outerAuthTag, epoch, sequence number, Domain 2 routeConstraints and routingAuthEvidence. MUST NOT attempt to decrypt Domain 3. MUST set HopRecord.inner_payload_decrypted = False. Infrastructure Hop: MUST validate Domain 1 outerAuthTag and epoch. MUST NOT access Domain 2 or Domain 3 or modify any domain. Egress Gateway: MUST validate all Domain 1 and Domain 2 fields including "STRICT_EGRESS_MATCH". MUST decrypt Domain 3 using the Zession's egress key (K3-derived) and verify innerPayloadIntegrityTag before forwarding plaintext. MUST set HopRecord.inner_payload_decrypted = True and HopRecord.validation_result = "FINAL_VALIDATED".

Opcode Architecture The opcode architecture provides a compact, versioned, machine-parseable identifier for every message type exchanged in the ZeroPath VPN protocol suite.

Opcode Encoding Each message MUST begin with a 16-byte Opcode Header: Flags bits: Bit 7 (ENCRYPTED), Bit 6 (SIGNED), Bit 5 (FRAGMENTED), Bit 4 (LAST_FRAG). Bits 3-0 Reserved, MUST be zero. Version 0x02 corresponds to "HBSPV/2.0-SGCP/2.0". Opcode Ranges

Range	Category
0x0001-0x00FF	Control Plane: Lifecycle Opcodes
0x0100-0x01FF	Control Plane: Session Management Opcodes
0x0200-0x02FF	Control Plane: Bootstrap Opcodes
0x0300-0x03FF	Data Plane: Tunnel Opcodes
0x0400-0x04FF	State Opcodes
0x0500-0x05FF	Error Opcodes
0x0600-0xEFFF	Reserved for future use
0xF000-0xFFFF	Vendor/Experimental. Not to be standardized.

Control Plane Opcodes 0x0001 OP_PROVISION_REQUEST (C->S): Request provisioning. Payload: identity, department, device_name, platform, policy_id. 0x0002 OP_PROVISION_RESPONSE (S->C): Return client_id and zession_id. 0x0003 OP_PACKAGE_REQUEST (C->S): Request .hbspv bundle download. 0x0004 OP_PACKAGE_RESPONSE (S->C, ENCRYPTED|SIGNED): Deliver complete .hbspv client configuration bundle. 0x0005 OP_ATTEST_SYN (C->S, SIGNED): Carry the Attested SYN (Section 8.1). 0x0006 OP_ATTEST_SYNACK (S->C, SIGNED): Carry the Attested SYN-ACK and pipeline results (Section 8.3). 0x0007 OP_ATTEST_ACK (C->S, SIGNED): Carry the Attested ACK with transcript proof (Section 8.4). 0x0008 OP_ATTEST_COMPLETE (S->C): Confirm handshake completion. Payload: status, transcript_hash, validation_pipeline. 0x0009 OP_ACTIVATE_REQUEST (C->S, SIGNED): Request tunnel activation. 0x000A OP_ACTIVATE_RESPONSE (S->C, ENCRYPTED): Confirm activation; deliver assigned_ip, epoch_id, tunnel_port, trust_score, state_hash. 0x000B OP_DISCONNECT_REQUEST (C->S): Signal voluntary disconnection. 0x000C OP_DISCONNECT_RESPONSE (S->C): Confirm disconnection with final state_hash and epoch_id.

Data Plane Opcodes 0x0300 OP_TUNNEL_CONNECT (C->S): Initiate tunneled connection. Wire: 4-byte big-endian length prefix + JSON payload: {type, host, port, token (ZessionId)}. 0x0301 OP_TUNNEL_CONNECT_ACK (S->C): Confirm connection success. After this opcode, both sides enter raw TCP forwarding mode. 0x0302 OP_TUNNEL_UNAUTHORIZED (S->C): Reject tunnel connection. Server MUST close TCP connection immediately after sending. 0x0303 OP_TUNNEL_DATA (bidirectional, ENCRYPTED|SIGNED): Carry HBSPV-framed application data. Defined for future per-packet framing implementations. 0x0304 OP_TUNNEL_CLOSE (bidirectional): Signal graceful tunnel teardown. Reason: "CLIENT_CLOSE", "SERVER_CLOSE", or "TIMEOUT".

State Opcodes 0x0400 OP_MIGRATE_REQUEST (C->S, SIGNED): Request migration to different path profile. 0x0401 OP_MIGRATE_RESPONSE (S->C, ENCRYPTED): Confirm migration; deliver new epoch_id, state_hash, trust_score, path_profile. 0x0402 OP_RECOVER_REQUEST (C->S, SIGNED): Request session recovery. Payload includes current_state_hash for server-side validation. 0x0403 OP_RECOVER_RESPONSE (S->C, ENCRYPTED): Confirm recovery; deliver recovered_epoch, state_hash, trust_score=100. 0x0404 OP_EPOCH_ROTATE (S->C, ENCRYPTED|SIGNED): Notify client of scheduled epoch rotation. 0x0405 OP_STATUS_REQUEST (C->S): Request current session status. 0x0406 OP_STATUS_RESPONSE (S->C): Return full session status including trust_score, epoch_id, state_hash, dnac_length, capabilities.

Error Opcodes 0x0500 OP_ERROR_GENERIC (S->C): General error response. Payload: error_code, error_message, opcode_ref. 0x0501 OP_ERROR_AUTH_FAIL (S->C): Authentication or signature verification failure. Payload: step, trust_score (after PENALTY_AUTH_FAIL), detail. 0x0502 OP_ERROR_REPLAY (S->C): Nonce replay or sequence number violation. Payload: replay_type ("NONCE_REPLAY" or "SEQ_REPLAY"), rejected_nonce, expected_seq, received_seq. 0x0503 OP_ERROR_CAPSULE_EXPIRED (S->C or local Dissolver): Capsule expiry notification. Payload: expired_at, capsule_id, action ("AUTO_REPROVISION" if applicable). 0x0504 OP_ERROR_TRUST_SUSPENDED (S->C): Session suspended due to trust score collapse. Payload: trust_score (<= 10.0), suspension_at, reason. 0x0505 OP_ERROR_EPOCH_MISMATCH (hop to sending node): Epoch mismatch detected in HBSPV frame. Payload: expected_epoch, received_epoch, hop_id.

Authorized Path Selection A client MUST only use paths that appear in its provisioned PathProfile and that satisfy all three conditions: Authorized, Reachable, and Policy-Compliant. A path is authorized if: (a) the PathProfileId appears in the server's known path profiles; (b) policy_compliant == True for the client's assigned policy; (c) the path score is above the policy's minimum path score. Unauthorized path selection MUST be rejected by the server at migration time and by the egress at packet validation time. Each PathProfile contains: profile_id, name, ordered hops array (each hop with hop_id, ip, role, region, validation_status), path_score ([0.0, 100.0]), latency_ms, loss_rate, gateway_load, trust_level, and policy_compliant (boolean).

Data Plane: SOCKS5 Tunnel Forwarder The data plane uses an extended SOCKS5 protocol with a ZessionId-based authentication handshake. The client SOCKS5 proxy MUST listen on 127.0.0.1 (IPv4 loopback only). MUST NOT listen on 0.0.0.0 or any non-loopback interface. When a browser sends a SOCKS5 CONNECT with a domain name target (ATYP=0x03), the proxy MUST forward the domain name in the "host" field of OP_TUNNEL_CONNECT without resolving it locally. The forwarder resolves the domain on the server side, preventing DNS leaks to the client's local resolver or ISP. The tunnel handshake uses 4-byte big-endian length-prefixed JSON framing. After the server sends OP_TUNNEL_CONNECT_ACK, both parties enter raw TCP forwarding mode. The server forwarder maintains an in-memory set of active ZessionIds. Token validation MUST use a constant-time comparison to prevent timing-based token enumeration. A ZessionId is removed from this set when the session is disconnected, revoked by an operator, or suspended due to trust score collapse.

Session Recovery Session recovery allows a client to resume a disconnected Zession without re-provisioning. The following invariants MUST be maintained:

• Invariant 1 (State Continuity): client's SCSWP state hash MUST match the server's stored state hash before recovery is permitted.
• Invariant 2 (No Key Reuse): recovery MUST derive a new K3 using fresh entropy. Old K3 MUST be erased before new K3 is stored.
• Invariant 3 (DNAC Continuity): DNAC chain MUST advance on recovery. An implementation MUST NOT allow recovery that resets the DNAC chain to a previous value.

Recovery procedure (7 steps): (1) client sends OP_RECOVER_REQUEST with current_state_hash; (2) server validates state hash with constant-time comparison; (3) server derives new K3 and epoch; (4) server advances SCSWP state chain; (5) server returns OP_RECOVER_RESPONSE; (6) server resets trust score to 100.0; (7) client stores new epoch ID and state hash and may re-activate the tunnel.

Path Migration Path migration allows a CONNECTED client to switch to a different authorized path profile without re-attesting or re-provisioning. Migration triggers a mandatory epoch rotation. Migration procedure (6 steps): (1) client sends OP_MIGRATE_REQUEST with target PathProfileId; (2) server validates authorization (profile exists, policy_compliant == True, trust score above TRUST_SUSPENSION); (3) server rotates K3 and epoch with trigger "Path Migration: <old> -> <new>"; (4) server updates session state (OP_MIGRATE record, DNAC advance); (5) server returns OP_MIGRATE_RESPONSE; (6) client stores new epoch ID, state hash, and updates active path profile. Client MUST NOT use old epoch for any further packets.

Security Considerations

Replay Attack Prevention Client nonces are tracked in a per-ZessionId used-nonce set persisting for the lifetime of the Zession. In production deployments, this set MUST be persisted to durable storage to survive server restarts. Packet sequence numbers provide replay protection at the data plane; hops MUST reject any packet with a sequence number <= the last accepted value.

Forward Secrecy Forward secrecy is provided at epoch granularity. Compromise of the current K3 does not expose traffic encrypted under previous K3 values, provided that erasure was correctly performed. Each K3 incorporates fresh entropy not present in previous derivations. Production implementations SHOULD use HKDF with os.urandom() as the entropy source.

Domain 3 Confidentiality The Domain 3 payload isolation guarantee holds under the following assumptions: (a) the egress decryption key is not shared with intermediate hops; (b) intermediate hop implementations do not attempt to buffer and decrypt Domain 3 out-of-band; (c) the AES-256-GCM implementation is correct. Production deployments MUST place entry gateways, infrastructure hops, and egress gateways on separate, isolated physical or virtual hosts.

Trust Score Manipulation An adversary may attempt to inflate the trust score by flooding stable operations. The maximum score is capped at 100.0. A more practical attack is to force session suspension by triggering rapid operations or network changes. Implementations SHOULD rate-limit external inputs that could trigger penalties.

State Hash Forgery The state hash chain uses SHA256, which is currently collision-resistant. Implementations SHOULD monitor for future weaknesses and plan migration to SHA3-256 if collision attacks emerge.

Opcode Injection The control plane REST API MUST be protected by TLS in production. All API endpoints MUST require ZessionId or ClientId validation. In environments without TLS, an attacker on the same network could inject crafted opcodes.

SOCKS5 Proxy Scope The SOCKS5 proxy MUST bind only to 127.0.0.1. Binding to 0.0.0.0 or a non-loopback interface would allow other hosts to use the proxy without authentication. On Windows, implementations MUST use the explicit IP address string "127.0.0.1" when binding to avoid IPv6 ambiguity with "localhost".

Capsule Theft A stolen Capsule cannot complete a handshake from a different device because: (a) Step 5 (Device Context Check) will fail if the device reference does not match; and (b) Step 4 (Signature Verification) will fail because the attacker does not have the client's private key. The 300-second expiry window limits the window of opportunity.

Cryptographic Primitive Recommendations Production implementations MUST: use real Ed25519 for all digital signatures; use AES-256-GCM for Domain 3 encryption; use HKDF for all key derivations; use a CSPRNG (os.urandom()) for all random value generation; use constant-time comparison (hmac.compare_digest) for all cryptographic value comparisons.

Session Termination and Secret Destruction When a Zession is terminated, the implementation MUST: erase K3, K2, and K1 references; zero the state hash buffer; remove the ZessionId from the active session token set. Only ArchivedEpoch records (without key material) are retained for audit purposes.

IANA Considerations

Port Number Registrations This document requests registration of the following TCP port numbers in the IANA Service Name and Transport Protocol Port Number Registry: Port Registration Requests

Service Name	Port	Transport	Description
zeropath-ctrl	3000	TCP	ZeroPath VPN Control Plane REST API (HBSPV/SGCP)
zeropath-tunnel	4444	TCP	ZeroPath VPN Data Plane Tunnel Forwarder (HBSPV)

Protocol Version String Registry This document requests creation of a new IANA registry "ZeroPath VPN Protocol Version Strings". Initial registration: HBSPV/2.0-SGCP/2.0 -- ZeroPath VPN version 2.0 -- This document.

Opcode Registry This document requests creation of a new IANA registry "ZeroPath VPN Opcode Registry". Policy: Specification Required for range 0x0001-0xEFFF. First Come First Served for range 0xF000-0xFFFF. Initial Opcode Registry

Value	Name	Section
0x0001	OP_PROVISION_REQUEST
0x0002	OP_PROVISION_RESPONSE
0x0003	OP_PACKAGE_REQUEST
0x0004	OP_PACKAGE_RESPONSE
0x0005	OP_ATTEST_SYN
0x0006	OP_ATTEST_SYNACK
0x0007	OP_ATTEST_ACK
0x0008	OP_ATTEST_COMPLETE
0x0009	OP_ACTIVATE_REQUEST
0x000A	OP_ACTIVATE_RESPONSE
0x000B	OP_DISCONNECT_REQUEST
0x000C	OP_DISCONNECT_RESPONSE
0x0300	OP_TUNNEL_CONNECT
0x0301	OP_TUNNEL_CONNECT_ACK
0x0302	OP_TUNNEL_UNAUTHORIZED
0x0303	OP_TUNNEL_DATA
0x0304	OP_TUNNEL_CLOSE
0x0400	OP_MIGRATE_REQUEST
0x0401	OP_MIGRATE_RESPONSE
0x0402	OP_RECOVER_REQUEST
0x0403	OP_RECOVER_RESPONSE
0x0404	OP_EPOCH_ROTATE
0x0405	OP_STATUS_REQUEST
0x0406	OP_STATUS_RESPONSE
0x0500	OP_ERROR_GENERIC
0x0501	OP_ERROR_AUTH_FAIL
0x0502	OP_ERROR_REPLAY
0x0503	OP_ERROR_CAPSULE_EXPIRED
0x0504	OP_ERROR_TRUST_SUSPENDED
0x0505	OP_ERROR_EPOCH_MISMATCH

References Normative References Informative References

Acknowledgements The author thanks the open-source Python community and the IETF community for providing the standards and tools on which this work is built.