Security Hubs

Security hubs are specialized peers that participate in DSKE key generation using Shamir secret sharing. They store key shares and provide PSRD (Pre-Shared Random Data) to clients, but they never hold or reconstruct complete keys.

What Security Hubs Do

Each security hub:

• Stores key shares — fragments of secrets that are useless individually
• Provides PSRD — one-time entropy that clients need for key operations
• Authenticates clients — each client has a unique ID and credentials per hub
• Operates independently — hubs don't communicate with each other

A minimum of 2 hubs is required for key reconstruction. This means even if one hub is compromised, the attacker cannot reconstruct any secret without shares from another hub.

How Threshold Cryptography Works

When a secret is generated, DSKE uses Shamir secret sharing to split it into shares:

32-byte secret
    │
    ├─► Share 1 → Security Hub A
    │
    └─► Share 2 → Security Hub B

To recover the secret, a peer needs shares from at least shares_required (default: 2) different hubs. Each share alone reveals nothing about the original secret.

With more than 2 hubs, you get redundancy — any 2 of N hubs can reconstruct the secret, so the system tolerates hub failures.

Setting Up a Security Hub

Step 1: Mark the Peer as a Security Hub

In the management dashboard or via the REST API, set dske_security_hub: true on the peer that will serve as a security hub.

When the first security hub registers, the management server automatically creates:

• A "DSKE Security Hubs" group containing all hub peers
• A bidirectional access policy (All ↔ DSKE Security Hubs) ensuring hub reachability

This guarantees that all peers can reach the hubs regardless of other policy changes.

Step 2: Security Hub Provisioner

Once marked as a security hub, the peer automatically runs a provisioner that:

• Maintains a pool of 5 pre-generated PSRD files in /var/lib/qufabric/dske/psrd-out/
• Replenishes the pool every 10 seconds when files are consumed
• Each file contains 256 KiB of entropy (128 KiB per direction)
• Files are written atomically to prevent partial reads

Step 3: Distribute PSRD to Clients

PSRD files must be transferred from the security hub to each client peer. This is an out-of-band process — use any secure transfer method (SSH, encrypted file transfer, etc.):

# On the security hub, PSRD files are in:
/var/lib/qufabric/dske/psrd-out/

# Transfer to the client peer
scp /var/lib/qufabric/dske/psrd-out/client-name.json user@client:/tmp/

# On the client peer, ingest the PSRD
qufabric dske ingest-psrd /tmp/client-name.json

Security Hub Properties

Placement Recommendations

For maximum security and availability:

• Deploy at least 2 security hubs — this is the minimum for threshold reconstruction
• Separate infrastructure — place hubs on different networks, cloud providers, or physical locations
• Independent administration — ideally, different administrators manage different hubs
• Monitor PSRD levels — ensure hubs have sufficient PSRD to provision clients

Network Planning

Security hubs communicate with clients over the standard WireGuard tunnel (wg0). Ensure:

1. Hub peers are reachable from all client peers via the WireGuard network
2. The auto-created "DSKE Security Hubs" policy is not modified or deleted
3. Hub peers have stable connectivity — DSKE operations depend on hub availability

Adding Clients to a Security Hub

On the security hub, use the local distributor CLI to manage clients:

# Add a new DSKE client
sudo -u qbtld qbt-local-distributor dske-client add my-client-name --json

# List all registered clients
sudo -u qbtld qbt-local-distributor dske-client list --json

# Generate PSRD for a client
sudo -u qbtld qbt-local-distributor dske-client assign-psrd \
  --first \
  --user-bytes 524288 \
  --server-bytes 524288 \
  --user-id <dske-client-id> \
  -o /tmp/psrd-output

The generated PSRD file is a wrapped JSON containing the hub endpoint, hub ID, client ID, and base64-encoded PSRD data — everything the client needs to register with the hub.