Packet-Level Authentication

Overview

VeilNet is effectively a non-IP network. Conventional policies based on IP addresses or subnets do not apply. Access control is achieved by Packet-Level Authentication (PLA): every packet is authenticated based on identity, not on hashes, checksums, or raw public keys. This is the deepest access control achievable in a network—it prevents unwanted access even if the local network is compromised, and cannot be implemented in the same way in overlay networks built on IPsec, OpenVPN, or WireGuard.

The Anchor Protocol implements PLA using post-quantum cryptography. Two standards are used: Dilithium DSA for signatures (so packets and identities are signed and verified) and Kyber KEM for key exchange (so session keys are agreed peer-to-peer in a post-quantum way). Together with identity binding, this gives triple-factor authentication (TFA) at the packet level: only packets that pass all three checks are accepted.

Identity in VeilNet

VeilNet identities are cryptographic identities tied to users, Conflux instances, realms, and access-control identity (JWT scope or taint). They are never shared or exposed onto the overlay; they exist only in the local memory of each Conflux instance. Exchange of identity material happens only during the initial registration of a Conflux instance with the Guardian.

• User identity — Stored in the VeilNet authentication system; accessible only by Conflux instances deployed under that user’s registration token.
• Conflux identity — Generated by the Conflux instance at startup; accessible only by that instance.
• Realm identity — Shared by all authenticated Conflux instances in the realm; used for control-channel message encryption so the control plane carries no plaintext metadata.
• JWT scope or taint — Used as the access-control identity. When using an IdP, the Conflux instance’s JWT scope (e.g. claims from the identity provider) defines which peers it can talk to. When not using an IdP, taints (simple labels) are used the same way. Only the Conflux instance (and the Guardian, at registration) has this identity; it is used to create a signature in the packet header so peers can verify access policy.

Because these identities are never sent over the wire in the clear, access control is achieved by signatures derived from them—verified using post-quantum algorithms—rather than by exposing the identities themselves.

Post-quantum standards

Anchor uses post-quantum cryptography so that authentication and key exchange remain secure against both classical and quantum adversaries.

• Dilithium DSA — A post-quantum digital signature standard (e.g. FIPS 204). Each Conflux instance generates a Dilithium key pair (public and private). The keys are used for signing and verification, not for encrypting payloads. Conflux signs packets and identity-related material with the private key; peers verify using the public key. So packet authenticity and identity binding are quantum-resistant.
• Kyber KEM — A post-quantum key encapsulation standard (e.g. FIPS 203). Used for peer-to-peer key agreement: two Conflux instances agree a shared secret via Kyber KEM. That secret is then used (with symmetric encryption) for the actual data stream. The shared secret can be rotated frequently (e.g. on the order of seconds), so compromise of one session does not expose long-term traffic.

Payload encryption (e.g. AES-GCM 256) is applied independently to header and payload, so both integrity and confidentiality are protected. The combination of Dilithium (signatures), Kyber (key exchange), and AES-GCM gives post-quantum security across authentication, key establishment, and data protection.

Packet-level authentication and TFA

In Anchor, the header of each packet carries:

• Dilithium public key — The public key used to verify the packet and related signatures.
• Conflux signature — A signature binding the Conflux instance’s identity (and the Dilithium key) so peers can recognize the sender.
• Scope/taint signature — A signature over the JWT scope or taint associated with the Conflux instance, created using the Dilithium private key and Conflux signature as context; used for access-control policy (e.g. which scopes or taints can talk).
• Packet signature — A signature over the packet data, created using the Dilithium private key and Conflux signature as context; binds the packet to the sender and prevents tampering.

When a Conflux instance joins the overlay, it broadcasts an Echo announcing its Conflux signature and Dilithium public key as an immutable pair. Other Conflux instances store this pair in local memory (Trust on First Use, TOFU). From then on, every packet is checked against that pair and the three factors below.

A packet is accepted only if it passes Triple Factor Authentication (TFA):

1. The Conflux signature and Dilithium public key in the packet header match the pair stored in local memory (so the sender is a known, legitimate Conflux instance).
2. The scope/taint signature can be reproduced (verified) using the Dilithium public key and Conflux signature in the header (so the sender’s JWT scope or taint is valid and matches access policy).
3. The Packet signature is valid when verified with the Dilithium public key in the header (so the packet was signed by the claimed sender and was not tampered with).

If any of these checks fails, the packet is discarded. So access control is enforced per packet, based on identity and post-quantum signatures—not on IP or port.

Why TFA prevents forged packets

• Factor 1 — If the Conflux signature and Dilithium public key do not match the stored pair, the packet is invalid. An attacker cannot impersonate a Conflux instance without being present at TOFU (Echo) time or without breaking the binding between Conflux identity and Dilithium key.
• Factor 2 — Even if an attacker copies a Conflux signature and Dilithium public key from the wire, they cannot reproduce the scope/taint signature without the JWT scope or taint (access-control identity), which is only available from the Guardian at registration and only to the Conflux instance that is authorized for that scope or taint. So forged packets cannot satisfy scope- or taint-based access policy.
• Factor 3 — Even if the Guardian were compromised and an attacker obtained scope/taint and forged the scope/taint signature, the Packet signature can only be produced with the Dilithium private key held in the Conflux instance’s memory. Without that key, the packet signature does not verify and the packet is rejected.

So to bypass TFA, an attacker would need to compromise the Guardian, compromise the control plane (e.g. NATS) with forged or stolen credentials, and compromise a Conflux instance and obtain a full memory dump. These three conditions are nearly impossible to achieve at the same time. In addition, even in that scenario, the shared secrets used for the actual data streams are exchanged peer-to-peer via Kyber KEM and rotated frequently—they are not stored at the Guardian. So VeilNet’s packet-level authentication, built on post-quantum standards and identity, protects user traffic from every angle.