CSfC Alignment
NetBird's double VPN architecture is designed with the NSA's Commercial Solutions for Classified (CSfC) Multi-Site Connectivity capability package in mind. This page provides both a conceptual overview and a detailed requirement-by-requirement mapping.
NetBird is designed with CSfC principles in mind. This does not constitute formal CSfC certification or endorsement by the NSA. Organizations seeking formal CSfC compliance should consult their security team and follow the NSA's CSfC process.
Conceptual Alignment
The CSfC program allows classified data to traverse untrusted networks (such as the public internet) by requiring two independent layers of commercial encryption. The core principle is defense in depth — if one layer fails, the other continues to protect the data.
NetBird implements this principle directly:
Classified Data
│
▼
┌───────────────────────────────────────────┐
│ Inner Layer: AES-256-GCM WireGuard │ ← Layer 1
│ Independent key management via DSKE │
└───────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────┐
│ Outer Layer: ChaCha20-Poly1305 WireGuard │ ← Layer 2
│ Standard WireGuard DH key exchange │
└───────────────────────────────────────────┘
│
▼
Untrusted Network (Internet)
The two layers use:
- Different encryption algorithms (AES-256-GCM vs ChaCha20-Poly1305)
- Different key exchange mechanisms (DSKE threshold cryptography vs WireGuard Diffie-Hellman)
- Different protocol implementations (AES WireGuard fork vs standard WireGuard)
This independence means a vulnerability in one layer does not affect the other.
Multi-Site Connectivity Requirements
The CSfC Multi-Site Connectivity capability package defines requirements for protecting data between geographically separated sites over untrusted networks. The following table maps these requirements to NetBird's implementation.
Encryption Requirements
| CSfC Requirement | NetBird Implementation | Notes |
|---|---|---|
| Two independent layers of encryption | WireGuard (ChaCha20-Poly1305) + AES WireGuard (AES-256-GCM) | Each layer is a complete WireGuard implementation with its own handshake, session keys, and transport encryption |
| Layers must use different vendors or implementations | Standard wireguard-go (outer) + wireguard-aes-go fork (inner) | Fork changes only the cipher suite — Noise handshake and protocol logic are identical but the AEAD cipher differs |
| CNSA-compliant algorithms | AES-256-GCM (inner layer) meets CNSA Suite requirements | ChaCha20-Poly1305 (outer layer) provides defense in depth but is not itself CNSA-listed |
Key Management Requirements
| CSfC Requirement | NetBird Implementation | Notes |
|---|---|---|
| Independent key management per layer | WireGuard DH (outer) + DSKE threshold key exchange (inner) | Completely independent key lifecycles |
| No single point of key compromise | DSKE splits keys across 2+ security hubs using Shamir secret sharing | Even with one compromised hub, secrets cannot be reconstructed |
| Key rotation | Outer: WireGuard rekeys every 120 seconds. Inner: DSKE rotates PSK every 120 seconds | Both layers rotate keys independently |
| Secure key distribution | DSKE uses out-of-band PSRD provisioning + hub-mediated share distribution | Complete keys never traverse the network |
Architecture Requirements
| CSfC Requirement | NetBird Implementation | Notes |
|---|---|---|
| Support for multiple sites | Peer-to-peer mesh topology with centralized management | Each site has one or more peers; all peers can communicate via the double VPN |
| Scalable key distribution | DSKE automates PSK generation for all peer pairs | No manual key distribution per peer pair |
| Resilience to component failure | Multiple security hubs provide redundancy; WireGuard handles session recovery automatically | If one hub fails, others can still reconstruct secrets (with N > shares_required hubs) |
| Centralized policy management | Management server distributes access policies, group memberships, and network configuration | Policies are enforced locally on each peer |
Data Protection Requirements
| CSfC Requirement | NetBird Implementation | Notes |
|---|---|---|
| Confidentiality | Double encryption — both layers provide confidentiality | Even if one layer is compromised, data remains protected |
| Integrity | Both WireGuard layers include AEAD authentication | Each layer independently authenticates and verifies packet integrity |
| Anti-replay | WireGuard includes built-in anti-replay protection per session | Both layers maintain independent replay counters |
Algorithm Details
Inner Layer (AES WireGuard)
| Parameter | Value |
|---|---|
| Noise protocol | Noise_IKpsk2_25519_AESGCM_BLAKE2s |
| Handshake AEAD | AES-256-GCM |
| Transport AEAD | AES-256-GCM |
| Key exchange | Curve25519 Diffie-Hellman + DSKE PSK |
| Hash | BLAKE2s |
| PSK | 32-byte DSKE-generated secret, rotated every 120s |
Outer Layer (Standard WireGuard)
| Parameter | Value |
|---|---|
| Noise protocol | Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s |
| Handshake AEAD | ChaCha20-Poly1305 |
| Transport AEAD | ChaCha20-Poly1305 |
| Key exchange | Curve25519 Diffie-Hellman |
| Hash | BLAKE2s |
DSKE Key Generation
| Parameter | Value |
|---|---|
| Secret length | 32 bytes |
| Secret sharing | Shamir secret sharing |
| Minimum shares | 2 (configurable) |
| Master key derivation | HKDF-SHA256 from WireGuard private key |
| Hub communication | REST API over WireGuard tunnel |
Operational Considerations
What NetBird Provides
- Two independent encryption layers with independent key management
- Automated key rotation with no traffic interruption
- Distributed trust via threshold cryptography (no single point of key compromise)
- Centralized policy management with local enforcement
- Peer-to-peer mesh topology for multi-site connectivity
What Organizations Must Provide
- Formal evaluation: CSfC compliance requires a formal evaluation process with the NSA
- Physical security: Endpoint devices must be physically secured per organization policy
- Hub security: Security hubs should be deployed on secured, monitored infrastructure
- PSRD distribution: Secure out-of-band transfer of PSRD files
- Monitoring and audit: Organizations must maintain operational monitoring
- Incident response: Procedures for responding to suspected key compromise