Packet Level Authentication (PLA)

How Access Control in VeilNet Works

VeilNet is essentially a non-IP network. Therefore, conventional network policies based on IP addresses or subnets are not applicable. This is our unique design to offer maximum compatibility with existing networks and services.

To achieve access control, VeilNet utilizes Packet Level Authentication (PLA) which is the deepest access control achievable in any network. It prevents any unwanted access even if your local network is compromised. This is impossible to be implemented in overlay networks, no matter they are built on IPsec, OpenVPN or WireGuard.

Packet Level Authentication (PLA)

In VeilNet, packets are authenticated based on identities. These identities are not hashes, checksums or public keys. VeilNet identities includes:

• User Identity: Each user has a cryptographic identity, which is stored in the database in VeilNet authentication system. This identity is only accessible by Conflux instances deployed by the user's registration token.
• Conflux Identity: Each Conflux instance has a cryptographic identity, which is generated by the Conflux instance on startup. This identity is only accessible by the Conflux instance itself.
• Realm Identity: Each realm has a cryptographic identity, which is accessible by all authenticated Conflux instances under the realm. This identity is used for control channel message encryption to ensure VeilNet does not contain any plaintext metadata.
• Team Identity: Each team is created by the user, and assessible by all Conflux instances under the team. This identity is used for access control policies.

These identities are never shared or exposed onto VeilNet under any circumstances and only exists in the local memory of the Conflux instance. The exchange of these identities is only done during the initial registration process of a Conflux instance with the Guardian.

If the identities are not shared, how does VeilNet achieve access control?

VeilNet achieves access control by the post-quantum cryptography standard Dilithium DSA. With Dilithium DSA, each conflux instance will locally generate a pair of public and private keys. However, these keys are not used for encryption (such as IPsec, OpenVPN or WireGuard), but for creating quantum-resistant signatures.

In Anchor Protocol, the header of each packet contains:

• Dilithium Public Key: The public key of the Dilithium DSA algorithm.
• Conflux Signature: The signature of the Conflux instance based on the Conflux identity.
• Team Signature: The signature of the teams associated with the Conflux instance, created by the conflux instance itself via Dilithium Public key and its Conflux signature as context.
• Packet Signature: The signature of the packet based on the packet data, via Dilithium Private Key and its Conflux Signature as context.

When a Conflux instance first join the VeilNet, it will broadcast a Echo announce its Conflux Signature andd Dilithium Public Key as a immutable pair. All other Conflux instances will store such information in their local memory.

For a packet to be considered as valid, it must pass the following Tripple Factor Authentication (TFA):

1. The Conflux Signature and Dilithium Public Key must be the same as the one stored in the local memory.
2. The Team Signature must be reproducable by the Dilithium Public key and the Conflux signature inside the packet header.
3. The Packet Signature must be valid when it is verified by the Dilithium Public key inside the packet header.

How does this TFA prevent forged packets?

First, if the Conflux Signature and Dilithium Public Key are not the same as the one stored in the local memory, the packet is considered as invalid. This implements the Trust on First Use (TOFU) principle.

Then, if the attacker copied the Conflux Signature and Dilithium Public key, it can not reproduce the Team Signature because it can not accuqire the Team Identity from Guardian.

If we assume the Guardian is compromised, the attacker fetched the Team Identity and forged the Team Signature. The packet will still be invalid because the Packet Signature could be produced by Dilithium Private key from the conflux instance memory.

Therefore, the TFA can only be bypassed if the attacker can:

• Compromise the Guardian.
• Compromise the NATS Super Cluster with forged certificates.
• Compromise the Conflux instance and obtain a full memory dump.

These three conditions are nearly impossible to achieve at the same time.

Why it is impossible to breach VeilNet?

Even under above scenario, the attacker still cannot obtain the shared secret from secure streams, which is exchanged Peer-to-Peer (P2P) via Kyber KEM, another post-quantum cryptography standard. The shared secret is rotated as fast as 15s.

Considering TFA, two post-quantum cryptography standards, and AES-GCM 256 encryption (independent on header and payload), the security of VeilNet is generations ahead of any secure networks currently exists.