Zero Trust Consortium

India sripadkarthik@gmail.com https://github.com/sripad2020/ztop-research/

Security SECDISPATCH zero trust file transfer cryptographic protocol application layer Ed25519 Merkle tree This document defines the Zero Trust Transfer Orchestration Protocol (ZTOP), a novel Application Layer (OSI Layer 7) protocol for orchestrating cryptographically authenticated, continuously attested peer-to-peer file transfer in Zero Trust Architectures (ZTA). ZTOP operates within a TLS 1.3 transport tunnel and introduces: a hardware-derived cryptographic Peer Identity using HKDF-SHA512 and Ed25519; a 5-layer X.509 certificate chain with custom OID-encoded Zero Trust metadata; a continuous 16-field Heartbeat attestation protocol; a 100-point Adaptive Tamper Resistance Score across six security dimensions; a dual-signed 19-field Metadata Exchange Protocol preceding any payload transfer; a 380-byte Cryptographic Execution Manifest (CEM) permanently bound to every transferred file; SHA-256 binary Merkle-tree chunk integrity with immediate per-chunk proof validation; protocol-native static pre-execution behavioral analysis; and a 7-Level non-repudiation Signature Chain. A transfer is considered complete only when all seven cryptographic signatures are present and verified. A Python reference implementation is available at: https://github.com/sripad2020/ztop-research/

File transfer protocols have not evolved with Zero Trust security principles . Protocols such as SFTP and FTP authenticate a user once via a static credential and subsequently establish an open, trusted channel. They have no awareness of device security posture, real-time behavioral analysis of the transferred content, or cryptographic non-repudiation of the transaction itself. Enterprises today solve this limitation by deploying five or more separate security products alongside a legacy file transfer protocol, resulting in fragmented, expensive, and operationally complex architectures. ZTOP defines a single, self-contained Application Layer protocol that natively integrates all of the following: Cryptographic Peer Identity derived from hardware attestation Continuous device posture evaluation and dynamic trust scoring Declarative organizational policy enforcement Pre-payload metadata negotiation with dual attestation signatures File-level Cryptographic Execution Manifests (CEM) Per-chunk Merkle tree integrity without requiring full-file arrival Protocol-native static behavioral analysis of received files A 7-Level non-repudiation signature chain Trust-preserving session resumption after transport disconnection ZTOP does NOT replace TCP, IP, TLS, or QUIC. It operates within a TLS 1.3 tunnel and defines how endpoints behave before, during, and after a file transfer.

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. The following terms are used in this document: A cryptographically derived, hardware-bound identifier for a ZTOP endpoint. Represented as Base58(SHA3-256(Ed25519PublicKey)). A ZTOP server that enforces policy and trust evaluation on behalf of an organization. A value from 0 to 100 representing a device's computed security posture at a point in time. Cryptographic Execution Manifest. A 380-byte signed header permanently bound to every ZTOP-transferred file. A short-lived (12-hour) X.509 certificate issued by the Gateway, binding a device's identity and trust score to an active session. The root hash of a binary SHA-256 Merkle tree constructed over all file chunks. A sequence of seven Ed25519 signatures constituting cryptographic non-repudiation of a complete transfer. A 16-field signed packet sent every 10 seconds by the Client to continuously attest its identity and network context. Tamper Resistance Score. A 100-point composite score evaluated across six security dimensions.

ZTOP is an Application Layer (OSI Layer 7) protocol. It MUST operate within an encrypted transport tunnel. Implementations MUST support TLS 1.3 as the transport. Implementations MAY additionally support QUIC .

ZTOP consists of fifteen logical engines. Each engine MUST be instantiated per active session on the Gateway. Table 1 lists all components. EngineResponsibility PeerIDEngineDerive and validate cryptographic Peer IDs CertStoreMaintain root CA, org CAs, and device cert chains CertEngineIssue Session and Transfer Receipt X.509 certs TrustEngineScore device posture (0-100 points) TamperScoreEngineCompute 100-pt Adaptive Tamper Resistance Score PolicyEngineEvaluate six organizational transfer rules HeartbeatEngineValidate 16-field signed attestation packets MerkleEngineBuild Merkle trees and verify per-chunk proofs CEMEngineDeserialize and verify Cryptographic Execution Manifests MetadataEngineExecute 9-step pre-transfer metadata validation ExecutionAnalyzerPerform static behavioral analysis of files SignatureChainEngineBuild and verify 7-level non-repudiation chain ReconnectManagerCache session state for trust-preserving reconnect IntegrityEngineCompute and verify SHA-256/SHA3-512 file hashes AuditEngineProduce sealed ECDSA-signed audit records

All ZTOP messages SHALL be encoded as frames in Network Byte Order (Big-Endian). Every frame consists of three fixed headers, a variable TLV payload, raw payload data, and two mandatory footers.

The 2-byte Flags field encodes eight independent Zero Trust control signals as a bitmask: ValueNameZero Trust Role 0x0001PAYLOAD_ENCRYPTEDData frames without this MUST be rejected 0x0002PAYLOAD_COMPRESSEDPayload uses codec from Routing Header 0x0004REQUIRES_ACKReceiver MUST acknowledge this frame 0x0008PRIORITY_BOOSTGateway processes before standard frames 0x0010SIGNED96-byte ECDSA-P384 footer is appended 0x0020LAST_CHUNKFinal chunk of an active transfer 0x0040RECOVERY_MODEFrame is part of a reconnect handshake 0x0080HEARTBEAT_EXPECTEDSender mandates Heartbeat from receiver A receiver that observes a TRANSFER_CHUNK packet without PAYLOAD_ENCRYPTED set MUST reject the packet with error code ENCRYPTION_REQUIRED and MAY terminate the session.

All metadata fields are carried as Type-Length-Value (TLV) records. Each TLV consists of a 2-byte unsigned integer type, a 2-byte unsigned integer length, and a value field of that many bytes. All fields are Big-Endian encoded. An implementation receiving an unknown mandatory TLV type (codes 0x0000-0x7FFF) MUST return an ERROR packet and close the session. An implementation receiving an unknown optional TLV type (codes 0x8000-0xFFFF) MUST silently ignore it.

OpCodeMessage NameDirection 0x01HELLOClient to Server 0x02DISCOVERServer to Client 0x03REGISTERClient to Server 0x04IDENTITY_REQUESTServer to Client 0x05IDENTITY_RESPONSEClient to Server 0x06TRUST_REQUESTClient to Server 0x07TRUST_RESPONSEServer to Client 0x08POLICY_REQUESTClient to Server 0x09POLICY_RESPONSEServer to Client 0x0ACAPABILITY_NEGOTIATEBoth 0x0BSESSION_CREATEClient to Server 0x0CSESSION_ACCEPTServer to Client 0x0ESESSION_RECOVERClient to Server 0x0FSESSION_CLOSEEither 0x10HEARTBEATClient to Server 0x20TRANSFER_REQUESTClient to Server 0x21TRANSFER_STARTServer to Client 0x22TRANSFER_CHUNKClient to Server 0x23TRANSFER_ACKServer to Client 0x27TRANSFER_COMPLETEClient to Server 0x28TRANSFER_REJECT_CHUNKServer to Client 0x33AUDIT_COMMITServer to Client 0xFFERROREither

A ZTOP session MUST traverse the following states in order. Backward transitions are NOT permitted except as noted for the RECOVERING state. A Gateway MUST reject any message whose implied state transition is not permitted, and MUST respond with an ERROR packet containing code SESSION_STATE_INVALID.

= threshold v [DEVICE_TRUSTED] | <- PolicyEngine returns permitted=True (all 6 checks) v [POLICY_APPROVED] | <- Session Certificate issued, capabilities negotiated v [SESSION_ACTIVE] <------------------------------------+ | <- Transport disconnection detected | v | [RECOVERING] -- Peer ID re-validated via HB ----------+ | (7 retries exhausted) v [FAILED] (terminal) | [TERMINATED] (terminal) ]]>

Every ZTOP endpoint MUST derive a Peer ID using the following algorithm. Implementations MUST NOT use Fibonacci sequences or other deterministic mathematical sequences for Peer ID derivation or any cryptographic key generation.

The salt MUST be stored in hardware-backed secure storage (TPM 2.0 or TEE) and MUST NOT be transmitted over the network.

ZTOP implements a five-layer X.509 certificate hierarchy. All certificates use ECDSA-P384 or Ed25519. The five layers are: Root CA (10 years), Org CA (1 year), Device Certificate (30 days), Session Certificate (12 hours), and Transfer Receipt Certificate (1 year). Session Certificates MUST embed the following custom OID extensions: OIDNamePresent In 1.3.6.1.4.1.99999.1ZTOP-DeviceIDDevice Certificate 1.3.6.1.4.1.99999.2ZTOP-SessionIDSession Certificate 1.3.6.1.4.1.99999.3ZTOP-TrustScoreSession Certificate 1.3.6.1.4.1.99999.4ZTOP-PolicyVersionSession Certificate 1.3.6.1.4.1.99999.6ZTOP-NetworkInfoSession Certificate 1.3.6.1.4.1.99999.7ZTOP-PostureHashDevice Certificate 1.3.6.1.4.1.99999.8ZTOP-TransferIDReceipt Certificate 1.3.6.1.4.1.99999.9ZTOP-FileHashReceipt Certificate

The Client MUST submit a PostureData record. The TrustEngine assigns weighted scores summing to a maximum of 100. The default threshold is 70; implementations MAY configure a higher value. A Gateway MUST terminate any session where the score falls below the configured threshold. SignalWeightCondition EDR Active+30Endpoint Detection and Response running TPM Attested+20Hardware TPM 2.0 attestation present Firewall Active+15Host-based firewall enabled OS Version Current+15OS major version at or above 10 Patch Level Fresh+10Last patch applied within 30 days VPN Connected+5Network posture includes VPN Antivirus OK+5AV status is OK or ACTIVE

The TamperScoreEngine computes a 100-point composite score across six security dimensions. A Gateway MUST re-evaluate this score at every Heartbeat interval and after every chunk transfer event. DimensionMax PointsSignals Device Posture20OS patch, EDR, Firewall, TPM, Disk Encryption Certificate20Chain validity, Expiry, OCSP, Pinning Heartbeat15Consecutive successes, Latency quality Policy Compliance15Version current, org rules, DLP checked File Integrity20Merkle root match, chunk success, CEM sig Network Signature10VPN, Geo-fence, IP reputation Trust bands and required Gateway actions: Score RangeBandRequired Action 95-100TRUSTEDPermit full transfer 80-94LIMITEDPermit with enhanced audit logging 60-79RESTRICTEDPermit only via proxied analysis 0-59DISCONNECTMUST terminate session immediately

A Client MUST send a signed Heartbeat packet every 10 seconds while a session is in SESSION_ACTIVE or RECOVERING state. The Heartbeat packet MUST contain 16 fields including: peer_id, counter (monotonic), timestamp (microseconds), device_uuid, cert_fingerprint (SHA-256 of active session cert DER), current_ip, mac_hash (SHA-256 of MAC address), port, network_signature (Ed25519 over IP:Port), policy_version, session_token (SHA-256 of session_id), cpu_arch_hash, os_version_hash, nonce (16 random bytes), and a digital_signature (Ed25519 over all preceding 14 fields). A Gateway MUST validate each Heartbeat through eight sequential checks: nonce uniqueness, timestamp freshness (30 second tolerance), policy version match, IP consistency, digital signature verification, certificate fingerprint match, counter monotonicity, and session token match. Consecutive failures drive the session through the following states: 0-2 failures = HEALTHY; 3-4 failures = WARNING; 5+ failures = SLEEP with backoff delays of [2, 5, 10, 30, 60, 120, 300] seconds. After 7 failed retry attempts, the session MUST enter FAILED state.

Every file transferred via ZTOP MUST be prepended with a 380-byte Cryptographic Execution Manifest (CEM). The CEM gives the file a permanent cryptographic identity independent of the transport channel.

Execution Policy Flags: 0x0001=ALLOW_EXEC, 0x0002=SANDBOX_ONLY, 0x0004=NO_NETWORK, 0x0008=NO_SUBPROCESS, 0x0010=IMMUTABLE, 0x0020=AUDIT_ON_EXEC.

Files are split into chunks of the negotiated chunk_size. A binary SHA-256 Merkle tree is constructed bottom-up. When the number of chunks is odd, the last leaf MUST be duplicated to form its parent. Each TRANSFER_CHUNK packet MUST include: chunk_id, sequence number, byte offset, length, SHA-256 chunk_hash, session_id, per-chunk nonce, Merkle proof (sibling hashes bottom-up), and raw chunk data. A Gateway MUST immediately verify each chunk upon receipt. Verification MUST include: SHA-256(received_data) equals chunk_hash; the Merkle proof ascent from chunk_hash reaches the pre-agreed Merkle Root; the sequence number is greater than the last accepted; and the nonce is not in the seen_nonces cache.

After complete file reassembly and before issuing AUDIT_COMMIT, the Gateway MUST perform static behavioral analysis. The Gateway MUST NOT deliver the file to destination storage until this analysis completes. The analysis pipeline MUST include: Shannon entropy computation over the first 64 KB (entropy above 7.5 indicates packing or encryption, adding 20 risk points); for PE files, scanning for dangerous API imports including CreateProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread (each adding 8 risk points, maximum 50); for ELF files, scanning for dangerous syscall strings including execve, ptrace, and mprotect (each adding 6 risk points, maximum 40); for Python files, regex matching against dangerous import and call patterns (each adding 5 to 10 risk points, maximum 40). The final risk_score is min(sum, 100). A score of 60 or higher MUST result in MALICIOUS verdict: the file buffer MUST be wiped and the transfer MUST be aborted. A score of 25 or higher results in SUSPICIOUS verdict and MUST be logged. A score below 25 results in CLEAN verdict and the transfer proceeds to the Signature Chain.

A transfer is marked SYNC_COMPLETE only when seven independent Ed25519 signatures are present and verified. The seven levels are: L1 (File Hash, Sender key), L2 (Merkle Root, Sender key), L3 (Metadata hash, Sender key), L4 (Sender Completion Assertion, Sender key), L5 (Receiver Acceptance Assertion, Receiver key), L6 (Session Digest over L1-L5, Session key), L7 (Gateway Completion Seal, Gateway key). An AUDIT_COMMIT MUST NOT be issued until all seven signatures pass verification. Failure of any level MUST result in transfer rejection.

If a transport disconnection occurs during an active transfer, the Gateway MUST save the session state to a persistent ReconnectCache keyed by Session ID. Cache entries MUST expire after 3600 seconds. Upon reconnection with RECOVERY_MODE flag set, the Client presents its cached session_key_id. The Gateway performs a fresh Heartbeat challenge. If the challenge passes and a valid cache entry exists, the transfer resumes from the last verified chunk without repeating the full handshake. The retry backoff schedule MUST be [2, 5, 10, 30, 60, 120, 300] seconds. After 7 failed attempts, a full new handshake is REQUIRED.

ZTOP assumes the adversary has full network access including the ability to observe, inject, delay, and replay packets, but does NOT have access to TLS session keys or endpoints' Ed25519 private keys. All ZTOP packets include a 12-byte Nonce field. Receivers MUST maintain a nonce cache with a TTL of 300 seconds. Any packet whose nonce is found in the cache MUST be rejected. All packets include a Timestamp field. Receivers MUST reject packets with a timestamp deviation greater than 300 seconds from local time. The 12-hour Session Certificate TTL limits the impact of key compromise. In the event of Org CA key compromise, the Gateway MUST immediately revoke all issued certificates and MUST NOT accept new session connections until new CA material is provisioned. Implementations SHOULD implement OCSP stapling for real-time revocation checking. ZTOP MUST operate within a TLS 1.3 tunnel . Implementations MUST NOT support TLS versions earlier than 1.3. The current specification uses Ed25519 and ECDSA-P384 for digital signatures. These algorithms are not resistant to quantum computing attacks. Future versions of this specification SHOULD incorporate NIST-standardized post-quantum algorithms as they become widely deployed.

IANA is requested to assign the following port number: ztop 7890 TCP Zero Trust Transfer Orchestration Protocol This document IANA is requested to create a new registry "ZTOP OpCodes" with the initial assignments from Section 4.4. New entries require Standards Action . IANA is requested to create a new registry "ZTOP TLV Types" with range 0x0000-0x7FFF (Standards Action) and 0x8000-0xFFFF (First Come First Served). IANA is requested to register the custom X.509 OIDs listed in Section 7. Interim assignments under 1.3.6.1.4.1.99999 SHALL be replaced upon formal assignment.

NIST NIST

The authors acknowledge the foundational work of the IETF TLS Working Group, the COSE Working Group, and the broader Zero Trust research community whose contributions made this work possible.