DevHub LAN: Architecting a Zero-Trust Security Layer for Local Networks

Building secure local area network (LAN) applications presents a unique set of challenges. Unlike traditional web applications where a centralized server acts as the absolute source of truth, peer-to-peer (P2P) and local-first architectures require robust, decentralized trust mechanisms.

In Phase 3 of the DevHub LAN project, the objective was to implement a production-grade Security & Trust Infrastructure. This article explores the engineering decisions, cryptographic stack, and architectural patterns used to secure device communications, prevent replay attacks, and manage zero-trust device identities within an Electron application.

The Challenge: Trust in a Trustless Local Network

When two devices discover each other on a local network via mDNS or UDP broadcasting, they have no inherent reason to trust one another. In a corporate or public Wi-Fi setting, broadcasting sensitive developer data (environment variables, local build logs, or API keys) without mutual authentication is a critical security vulnerability.

We needed a system that provided:

Verifiable Device Identity: A way to uniquely identify a device without relying on easily spoofable MAC or IP addresses.
Mutual Authentication: Ensuring both the sender and receiver are who they claim to be.
End-to-End Encryption (E2EE): All payload data must be encrypted in transit using industry-standard cryptography.
Replay Attack Prevention: Ensuring intercepted payloads cannot be re-transmitted by a malicious actor.

1. Device Identity System

To solve the identity problem, we implemented a public key infrastructure (PKI) tailored for the local environment.

Upon the first launch of the DevHub LAN Electron application, the system generates an RSA-2048 keypair.

The Private Key is stored securely in the system's native keychain (using keytar in Node.js/Electron).
The Public Key is used to derive a unique DeviceID (a SHA-256 hash of the public key).

This DeviceID acts as the primary identifier across the network. Because it is cryptographically tied to the private key, no other device can successfully impersonate it during the handshake phase.

2. The Secure Handshake Protocol

Before any sensitive data is exchanged, devices must establish a secure session. We designed a 3-way handshake protocol inspired by TLS but optimized for our P2P WebSocket architecture.

Step 1: Client Hello

Device A discovers Device B and initiates a connection, sending:

Its DeviceID
Its Public Key
A randomly generated Nonce_A (Number used once)

Step 2: Server Hello & Challenge

Device B receives the request. It verifies the DeviceID matches the hash of the Public Key. It then responds with:

Its own DeviceID and Public Key.
A new Nonce_B.
A signature: Sign(Nonce_A + Nonce_B, PrivateKey_B).

Step 3: Client Verify & Key Exchange

Device A verifies Device B's signature using Device B's Public Key. This proves Device B holds the correct private key. Device A then sends:

A signature: Sign(Nonce_A + Nonce_B, PrivateKey_A).
An Ephemeral Symmetric Key (AES-256-GCM), encrypted using Device B's Public Key.

Once Device B verifies Device A's signature and decrypts the symmetric key, the secure session is established. All subsequent communication over the WebSocket uses this AES-256-GCM key.

3. End-to-End Encryption (AES-256-GCM)

We chose AES-256-GCM (Galois/Counter Mode) for payload encryption. GCM is an authenticated encryption algorithm, meaning it provides both data confidentiality and data authenticity.

If an attacker attempts to modify the encrypted payload in transit, the GCM authentication tag validation will fail, and the payload will be dropped immediately by the receiver.

import crypto from "crypto";

export function encryptPayload(payload: any, symmetricKey: Buffer) {
  const iv = crypto.randomBytes(12); // 96-bit IV recommended for GCM
  const cipher = crypto.createCipheriv("aes-256-gcm", symmetricKey, iv);

  const jsonPayload = JSON.stringify(payload);
  let encrypted = cipher.update(jsonPayload, "utf8", "base64");
  encrypted += cipher.final("base64");

  const authTag = cipher.getAuthTag();

  return {
    iv: iv.toString("base64"),
    data: encrypted,
    authTag: authTag.toString("base64"),
  };
}

4. Replay Attack Prevention

Even with E2EE, an attacker could record an encrypted packet (e.g., a "trigger build" command) and replay it later. Because the packet is validly encrypted, the receiving device might execute it again.

To mitigate this, we introduced a strict sequence numbering and timestamp validation system:

Timestamps: Every encrypted payload includes a Unix timestamp. If a received packet is older than an acceptable skew window (e.g., 5 seconds), it is rejected.
Sequence Numbers: Each session maintains a monotonically increasing sequence counter. If a packet arrives with a sequence number less than or equal to the highest sequence number seen, it is rejected as a replay.

Integrating with Electron

The security architecture operates entirely within the Node.js main process of the Electron application. The renderer process (the React frontend) never has access to the private keys or raw network sockets.

When the user interacts with the UI, the renderer sends an IPC (Inter-Process Communication) message to the main process. The main process handles the encryption, sequence generation, and network transmission, completely isolating the cryptographic operations from potential XSS vulnerabilities in the frontend.

Conclusion

Building zero-trust architecture on a local network requires a fundamental shift from traditional web development. By implementing a custom PKI, a strict 3-way handshake, AES-256 authenticated encryption, and robust replay protections, DevHub LAN ensures that local developer collaboration remains fast, decentralized, and highly secure.

Security is never a finalized feature—it is a continuous process of threat modeling and mitigation. As we move towards Phase 4, we will be exploring Perfect Forward Secrecy (PFS) and automatic key rotation to further harden the local communication layer.