ZeroPath VPN: Hop-Bound Secure Packet Validation with State-Bound Ephemeral Sessions, Cryptographic Attestation, and Opcode-Driven Control Architecture

1.1. 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.¶

1.2. Relationship to Existing Protocols

HBSPV is complementary to IPsec [RFC4301] and TLS [RFC8446]. 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 [RFC8996].¶

SGCP's attested handshake shares goals with QUIC's connection establishment [RFC9000] 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 [RFC9162] logs, but operate per-session rather than globally.¶

1.3. Implementation

A complete reference implementation [IMPL] in Python (pure standard library, zero external dependencies) is published on PyPI [PYPI] and available on GitHub at: https://github.com/sripad2020/Zeropath-vpn¶

The implementation includes: REST control plane server, asyncio tunnel forwarder, interactive client CLI, asyncio SOCKS5 proxy, and a real-time web monitoring dashboard.¶

3.1. Plane Definitions

3.2. 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.¶

3.3. 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)¶

4.1. States

4.2. 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.¶

6.1. 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.¶

6.2. 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.¶

6.3. 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.¶

7.1. 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."¶

7.2. 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."¶

7.3. 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."¶

7.4. 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."¶

7.5. 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."¶

7.6. 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."¶

7.7. 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."¶

8.1. 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>".¶

8.2. 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.¶

8.3. 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).¶

8.4. 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.¶

9.1. 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.¶

9.2. 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.¶

9.3. 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.¶

9.4. 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).¶

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

10.1. 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.¶

10.2. 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).¶

10.3. 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.¶

11.1. 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.¶

11.2. 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).¶

11.3. 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).¶

11.4. 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).¶

11.5. 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".¶

12.1. Opcode Encoding

Each message MUST begin with a 16-byte Opcode Header:¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Opcode (16 bits)     |   Version (8 bits)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Flags (8 bits)       |    Payload Length (32 bits)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Payload Length continued (MSB to LSB)               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Session ID (64 bits)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Payload (variable, JSON encoded)             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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".¶

12.2. 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.¶

12.3. 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".¶

12.4. 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.¶

12.5. 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.¶

17.1. 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.¶

17.2. 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 [RFC5869] with os.urandom() as the entropy source.¶

17.3. 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.¶

17.4. 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.¶

17.5. 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.¶

17.6. 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.¶

17.7. 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".¶

17.8. 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.¶

17.9. Cryptographic Primitive Recommendations

Production implementations MUST: use real Ed25519 [RFC8032] for all digital signatures; use AES-256-GCM for Domain 3 encryption; use HKDF [RFC5869] 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.¶

17.10. 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.¶

18.1. Port Number Registrations

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

18.2. 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.¶

18.3. 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.¶