How Nexus Secures Your PC: Encryption and Pairing

Published 2026-07-22

Nexus controls real hardware on your PC, and its phone and tablet panels can reach that PC from across the room or across the world. That makes security a first-class design constraint, not a feature bolted on afterward. This article walks through the actual mechanisms: how the local surface is locked down, how a phone earns trust through pairing, how remote sessions are encrypted end to end, and how Nexus establishes a direct peer-to-peer link through home routers without ever handing your data to a middleman.

Everything below describes what the shipping code does. Where a detail matters for your threat model, we state it plainly rather than rounding up.

The shape of the system: three trust zones

Nexus draws a hard line between three environments, and a different mechanism guards each boundary.

The dashboard UI and its token live entirely on loopback. The LAN sees only the pairing and panel surfaces, over pinned HTTPS. The internet only ever sees ciphertext.

Zone 1: the local machine

The Nexus service listens on two local ports: plain HTTP on 9400 and HTTPS on 9443. Both are bound on all network interfaces on purpose, because a phone on the same Wi-Fi has to be able to reach the pairing and panel surfaces without any cloud round-trip.

Binding on all interfaces raises an obvious question: if the ports are reachable from the LAN, what stops another machine on your network from opening your dashboard? The answer is that reachability and authorization are two different things, and the desktop control surface is pinned to loopback at both layers:

The dashboard UI is served only to 127.0.0.1. A request for the dashboard shell from any non-loopback address is refused before it reaches the static file handler, in every path spelling. Only the phone-panel and pairing routes are served to the LAN.
The desktop token is honored only from loopback. The dashboard authenticates with a 256-bit token generated from a cryptographically secure RNG, minted the first time the service runs and readable only over the loopback /pair endpoint. Even if that token leaked, it is rejected when presented from any address other than 127.0.0.1, so it cannot drive your PC from another machine.

Service-control endpoints (stop the service, change startup mode) go further still: they return 404 to any non-loopback caller, so their very existence is never disclosed to a network scanner. Token comparisons throughout use a constant-time equality check, so timing cannot leak a token byte by byte.

Zone 2: your local network

A phone or tablet on your Wi-Fi talks to the PC over HTTPS on 9443. Because the service runs on your own hardware, there is no public certificate authority to issue it a certificate. Instead, Nexus generates a self-signed certificate locally (RSA-2048, SHA-256 signature) and the mobile apps pin it.

The pin is not the whole certificate; it is the SHA-256 hash of the certificate's SubjectPublicKeyInfo (the SPKI: the public key plus its algorithm identifier), encoded as URL-safe base64. The iOS and Android apps compute that hash from the certificate presented during the TLS handshake and compare it to the fingerprint they received when pairing. If it does not match, the connection is dropped. There is no fallback to CA validation: the pin is the sole trust anchor, which is exactly what you want for a device you provisioned yourself. Both apps ship identical, cross-checked test vectors so the two platforms compute the same pin byte for byte.

Pairing: how a phone earns trust

Pairing is the moment a new device is granted access, so it is where Nexus spends its cryptographic care. The default flow uses a QR code plus a short-authentication-string (SAS) comparison and an explicit approval on the PC.

The SAS is derived from the exact public key the phone's TLS handshake saw. An attacker who terminates TLS with a different certificate computes a different SAS, so the two-screen digit comparison catches an active machine-in-the-middle.

The security property worth understanding is why the SAS defeats a machine-in-the-middle. The six displayed digits are derived with HKDF-SHA256 from a random nonce, with the derivation bound to the certificate's SPKI fingerprint. If an attacker sits between the phone and the PC and terminates TLS with a substitute certificate, the phone's handshake sees a different public key, so the phone computes a different SAS. The digits on the two screens no longer match, and the human comparison fails the pairing. The pair token itself is 192 bits from a secure RNG, single-use, and expires after 60 seconds.

Two variants share the same SAS core for cases where scanning a QR is inconvenient: a 6-digit code the PC displays and you type on the phone, and a Wi-Fi discovery flow that finds the PC over Bonjour and then runs the same SAS comparison. All three require a physical Allow click on the host and are rate limited to five attempts before a five-minute lockout.

Sessions and the remote killswitch

A successful pairing yields a 256-bit session token. The PC never keeps the token itself: it stores only the token's SHA-256 hash, and the plaintext is handed to the device exactly once. Every later request is authenticated by hashing the presented token and comparing, in constant time, against the stored hashes.

Session lifetime is deliberately tiered by how the session was established. A session claimed over pinned HTTPS or over the encrypted relay gets a 30-day idle window; a session claimed over plain HTTP (the browser fallback) gets only 24 hours and is additionally bound to the client's address and user-agent, because a sniffed plain-HTTP cookie is a real risk and should expire fast. One global "Pair Remote" switch revokes every remote session at once, and it is enforced on every path, including over the relay: off means off.

Zone 3: remote access without trusting a middleman

When your phone leaves the house, it can no longer reach the PC directly. Nexus bridges the two through a relay, but the relay is built so that it can forward your traffic without being able to read it.

The relay is a zero-knowledge byte forwarder. It pairs two sockets by a random rendezvous id and copies encrypted frames between them; it holds no keys and can decrypt nothing.

The relay is a byte forwarder, not a trusted party

Nexus runs a small set of relays: a legacy default and region-pinned instances (currently a US and an Asia-Pacific region). When the service starts it asks the control plane which relay is nearest (computed from coarse edge geolocation using great-circle distance) and connects to that one over a secure WebSocket. It refuses any endpoint that is not wss://, so a compromised directory cannot downgrade the connection to plaintext. The phone learns which relay to use from a tag embedded in the pairing QR, so both ends meet on the same instance.

On that instance, the relay does exactly one thing: it pairs a host socket and a client socket that present the same rendezvous id, and copies binary frames between them. It never parses, never decrypts, and never stores your data. What it can observe is limited to a truncated hash of the rendezvous id, the connecting IP addresses, and byte counts for capacity accounting.

End-to-end encryption details

The confidentiality and integrity live entirely on the two endpoints, and the C# service and the browser implementation interoperate byte for byte:

All key material is derived with HKDF-SHA256. From the session token, each endpoint derives a 32-byte relay root. From that root it derives the rendezvous id and, for each connection, a fresh 32-byte AEAD key using a random per-connection salt.
The rendezvous id is a 128-bit value produced by a one-way derivation. Because HKDF is not reversible, the relay, which only ever sees that id, cannot work backward to any key.
Every frame is sealed with AES-256-GCM (128-bit authentication tag). The nonce encodes a direction byte and a per-connection counter that increases by one for every frame; the receiver enforces strict monotonicity, so replayed or reordered frames are rejected, and any tag mismatch tears the channel down. A fresh key per connection is what makes restarting the counter safe.
The session token itself never travels the network. The rendezvous id proves which session is connecting; a successful AES-256-GCM decryption proves the peer actually holds the derived key. Possession is demonstrated, never transmitted.

The same sealed handshake also runs directly between the phone and the PC over the LAN, with no relay in the middle at all, so the local path is protected by the identical cryptography.

Your phone's ordinary requests (device lists, layouts, control actions) and the live telemetry socket are both carried inside this encrypted tunnel. A conservative allowlist governs what may be tunneled at all: high-risk and irreversible operations, such as flashing device firmware or powering the machine off, are never carried over the relay, only over the local network.

NAT punch-through: getting off the relay

Relaying every byte through a data center works, but it adds latency and hops. So once a relay session is live, Nexus tries, in the background, to establish a direct peer-to-peer connection between the phone and the PC and then step off the relay entirely.

The relay bootstraps a direct link, then gets out of the way. Signaling rides the already-encrypted tunnel, address discovery uses STUN only, and if the direct path fails the session drops back to the relay automatically.

This is standard WebRTC, used carefully. The PC side uses the SIPSorcery library; the phone side uses the browser's built-in WebRTC. Both are configured with STUN servers only and no TURN. That distinction matters: STUN is used purely to discover each side's public address so the two peers can punch through their home routers, but the actual data channel is peer to peer. There is no TURN relay that could carry (and therefore see the metadata of) your traffic if the punch-through succeeds.

The sequence:

A relay session is already live and encrypted.
Each side queries STUN to learn its own public address and port.
The two sides exchange their connection descriptions (SDP and ICE candidates) through the existing encrypted relay tunnel. The signaling is never sent in the clear.
WebRTC opens a direct data channel. That channel carries the very same AES-256-GCM framing as the relay path, with independent per-channel keys, so going direct does not weaken the encryption.
Once the direct channel is confirmed, Nexus closes the relay connection. If the direct path later drops for any reason, the session reconnects through the relay automatically, with backoff so a flapping link never hammers the signaling endpoint.

The result is that most remote sessions end up as a direct, encrypted, peer-to-peer link, with the relay acting only as an encrypted introducer that then bows out.

What the system can and cannot see

Being specific about the boundary is the point of an article like this:

The relay cannot read your traffic. It forwards opaque AES-256-GCM frames keyed by material it never possesses. It sees connection metadata (a hashed rendezvous id, IP addresses, byte counts), which is what any forwarding node must see to do its job.
STUN servers see an IP and port, because discovering your public address is their entire function. They see no application data, and if punch-through succeeds the data path does not go through them at all.
On the PC, session tokens are stored hashed, so a copy of the settings file does not hand an attacker a working session. The desktop token is a loopback-only credential protected by operating-system file permissions; even copied, it is useless from another machine because it is rejected off loopback.
The mobile apps trust exactly one key: the certificate you pinned at pairing. No public certificate authority can mint a certificate that your app will accept for your PC.

The through-line

Nexus is layered on purpose. The dangerous surface (full desktop control) is confined to the machine itself. The convenient surface (phone and tablet panels) is granted only through a pairing step with an anti-machine-in-the-middle check and a physical approval. And the remote surface is end-to-end encrypted whether it runs over the relay or, better, over a direct peer-to-peer link that the relay only helps to establish.

None of this depends on trusting Nexus's servers with your data, because those servers are never given the keys to read it. The service is open source, so the mechanisms described here can be read in full rather than taken on faith.