Security overview

How Utly Remote decides who is who, who may do what, and what the operator of the service can and cannot do. The threat model is the same material with every mechanism named; this page is the version you can read in ten minutes.

The rule the design follows

The introduction service — the broker — is treated as part of the threat. It introduces two machines and relays their handshake, and the design assumes it might lie, delay, swap messages, or hand its database to someone. Everything that matters is checked between the two machines themselves, so trusting the operator is barely required.

Identity: a key, not a login

Each installation generates an Ed25519 key pair on first run and keeps the private half sealed to the Windows account (DPAPI). The public key is what the broker binds to the nine-digit ID, permanently. Registering with the broker means signing a fresh challenge with that key, so nobody can take an ID over by claiming it, and a captured registration cannot be replayed.

Sessions: keys the server never has

A session is a WebRTC connection between the two machines: DTLS-SRTP for the media, a DTLS data channel for input, clipboard, files and control. The keys come from a handshake between the two endpoints. The broker relays only the session descriptions.

Each side signs its DTLS certificate fingerprint with its identity key and sends the signature alongside its offer or answer. The other side verifies it against the public key the broker delivered with the request and against its own record of that ID. A broker that swapped a description would present a fingerprint carrying no valid signature, and the handshake would not complete.

First contact: pinning and four words

The first time you accept an ID, your machine records its public key. A different key under the same ID is refused on the viewer side and flagged in caution on the host’s accept card; forgetting a pin is a deliberate, per-peer action in Settings.

The first contact is the one moment pinning cannot help, so both screens show four words computed from both connection fingerprints. A device in the middle that terminated the encryption on each side would show different words. Read them aloud on the phone before you accept; if they differ, hang up.

Consent and permissions

A session exists only after the host clicks Accept, or after a viewer proves the unattended password. Keyboard and mouse, clipboard, audio and files are separate grants chosen on the accept card and changeable during the session. The host enforces them itself: with input off, its own injector drops input; with files off, it answers no file request. Nothing relies on the viewer behaving.

Unattended access: a password proved, never sent

The unattended password is registered with OPAQUE, a protocol in which the host keeps a record from which the password cannot be recovered and the viewer proves knowledge of the password without transmitting it. The broker relays three messages that reveal nothing about it. The exchange is bound to both sides’ connection fingerprints, so a relayed login cannot be reused for another connection. A wrong password fails on the viewer’s side first; five failures from one ID lock that ID out for thirty minutes, and twenty failures from any mix of IDs stop the host offering the password for thirty minutes.

Before the first password can be set, the app shows a warning about phone scams. Someone who says they were told to install it gets ten minutes of friction instead of a password field — see safety.

The host service

With the service installed, the host side runs as a Windows service and starts an agent in the console session, which is what lets it show the logon screen, answer UAC and send Ctrl+Alt+Del. The app you see is a front for that agent, connected over a named pipe whose permissions admit only the system, administrators and interactively signed-in users; the app checks that the pipe is served by the system or by itself before trusting it. The identity, the pins and the unattended record live with the agent under ProgramData, sealed with machine-scope DPAPI and readable by the system and administrators only.

The session log

Every session start and end, permission change, declined request, failed login, lockout, key change and file transfer is appended to a log on the host, each line carrying a hash of the line before it. The log page verifies the chain on every read and marks the first broken line. It catches edits and deletions by anyone who is not prepared to rewrite everything after them, which an administrator could — the same administrator who could replace the program.

Accounts

Accounts are optional and change nothing for a machine that never signs in. The password goes through the same OPAQUE protocol with the broker as the server, so the broker never sees it, and a sign-in for an unknown email is answered with a dummy record so the exchange cannot tell whether the email exists. Sign-up enrols an authenticator before anything is stored and hands out eight single-use recovery codes. A new device signs in with the password and then waits for one second factor: approval from a device already signed in, an authenticator code (each accepted once), or a recovery code. Devices hold random tokens, stored hashed on the broker and sealed on the device; any signed-in device can revoke any other, and a revoked device is cut off at once.

The address book

With an account, the names you give machines sync between your devices. The key comes from the OPAQUE export key, which the client derives from the password and the broker never learns. Each entry is sealed with XChaCha20-Poly1305 under a key on the broker that is an HMAC of the ID, so the broker cannot read an entry or tell which ID it names. Only names sync.

Updates

The app downloads updates over TLS and verifies a minisign signature against a key built into the program before anything runs. The signing key is held by the developer, not by the web host; a compromised web host can at most withhold updates. A build that does not start is rolled back.

Abuse

Anyone can report an ID from inside the app; reports carry a registered ID and an address and are read by a person. A blocked ID cannot register and cannot open sessions in either direction. The full policy is on the terms page.

What remains

Someone with your unlocked machine can impersonate you from it; DPAPI ties secrets to the Windows account, not to a person. A social engineer who talks a host into clicking Accept is not stopped by cryptography, which is why the accept card names the requester and the four words exist. The broker operator learns who connects to whom and when, and can deny service. Everything else is written down, with what each actor gets, in the threat model.