Security architecture

This page describes RemCam's access-control and key-management design for security teams evaluating a deployment. It reflects the shipping implementation, not aspiration; where a design choice diverges from common practice (for example, certificate pinning instead of a CA hierarchy) the rationale is stated.

Deployment and exposure model

• RemCam is a single Go binary installed as a system service on the managed server, running as a dedicated non-root service account. There is no cloud relay, agent mesh, or third-party remote-access vendor in the path: all viewing and control traffic stays between the VMS/operator and the server.
• Out of the box, the web console binds to 127.0.0.1 only. The RTSP desktop stream and the ONVIF interface are loopback-only permanently - they are consumed by the co-located VMS server and are never network-exposed. The only way to expose the console on a network is the explicit per-interface binding toggle, which is always HTTPS.
• Outbound connections are limited to the licensing service (activation, deactivation, signed-update check) over HTTPS.

Two-factor access

Each listener (loopback and each bound interface) is independently configurable for two-factor enforcement. With 2FA enabled on a listener:

• Factor 1 - possession, at the TLS layer. The listener runs mutual TLS. The client must present an enrolled client certificate during the handshake; without one the handshake is rejected before any HTTP exchange - no login page, no error page, no application surface at all. An unauthenticated attacker on that network sees a failed TLS session, nothing more.
• Factor 2 - knowledge, at the application layer. A certificate-verified connection still requires the account password to establish a session. The certificate identifies the account; sign-in completes only after password verification.

With 2FA disabled, either factor alone signs in (certificate or password) - appropriate for the loopback listener and trusted management networks. The console prevents enabling 2FA before the administrator holds a working client certificate, so the enforcement change cannot lock out the operator enabling it.

Client-certificate pinning

RemCam deliberately does not operate a CA hierarchy. Client certificates are individually pinned, not chain-validated:

• Each certificate is generated on the server (Go standard library cryptography only - no external CA, no certificate service, no network call), self-signed, and enrolled by its SHA-256 fingerprint, bound to one administrator account and labelled per device.
• At the TLS layer the verifier checks the presented leaf certificate's fingerprint against the enrolled set. There is no CA trust anchor to steal, no chain to mis-validate, and enrolling one certificate grants exactly one identity - compromise of a certificate never mints authority over others.
• Certificates have an explicit lifecycle: issued → active, with suspend, re-enable, and revoke operations per certificate. Deleting an account revokes all its certificates. Presentation of a revoked certificate is treated as a security signal: it is rejected at the handshake and raises an alarm event to the VMS.
• The downloadable .p12 bundle contains only the client private key and its end-entity certificate, protected by a password set at generation. It never includes a CA certificate - importing it cannot add a trust anchor to the operator's browser.
• Certificate use is tracked (last presented / last used), and a replacement certificate's first use auto-revokes the certificate it supersedes.

Server TLS

• The server certificate is generated locally at first start (Go standard library; no external CA or ACME dependency - the console must work on air-gapped networks). The installer places it in the OS and browser trust stores on the server; operators verify it on their own devices via the published SHA-256 fingerprint (trust-on-first-use endpoint).
• Minimum TLS 1.2, chosen for NX Witness embedded-browser compatibility.

Credential and key storage

• Account passwords are stored as bcrypt hashes, work factor 12. Verification is timing-equalised: unknown accounts compare against a decoy hash so response timing does not disclose account existence. Plaintext passwords are never written to disk or logs.
• Secrets at rest (Linux): credentials (account store, RTSP credentials and similar) live in an encrypted file store under /etc/vmsmc/credentials (directory mode 0700, owned by the service account). Each entry is AES-256-GCM encrypted; the key is derived via HKDF-SHA256 from the machine identity and a per-install random salt, so credential files are not portable to another machine and a copied disk image alone does not yield credentials without the accompanying machine identity.
• Secrets at rest (Windows): the platform credential store is used via the operating system's native facility.
• Private keys: the server TLS key and enrolled client certificate material are held under /etc/vmsmc (mode 0700, service account only). Client private keys exist server-side only transiently at generation and inside the password-protected .p12 delivered to the administrator.
• Sessions are held in memory only - a service restart invalidates every session token.

Session and lockout policy

• Sessions carry an absolute lifetime of 24 hours and an idle ceiling of 8 hours; expired tokens are evicted on first rejection.
• Brute-force lockout is global, not per-source or per-account: failed sign-ins from any source share one escalating counter, so rotating source addresses or usernames does not reset the threshold. After the final threshold the console locks permanently until the service is restarted on the server itself - a deliberate "physical-presence to recover" property.

Audit trail

• Every security-relevant action - sign-in and failure, lockout, session start, console control acquire/release/force, account and configuration changes, certificate lifecycle transitions, service start/stop - is written to the local event log and published as ONVIF events under the tns1:RemCam topic tree (full list in the usage guide). The VMS can alarm on, bookmark, and retain them under its own retention policy, on infrastructure the security team already controls.
• The management session itself is evidence: the server's desktop is a recorded camera feed, so every keystroke's effect is in the VMS archive alongside the events.

Software supply chain

• Updates are Ed25519-signed. The signature is verified against a key pinned in the binary, and re-verified inside the privileged apply step - a file swapped after the initial verification (download-to-install TOCTOU) is rejected. Update downloads refuse cleartext HTTP to non-loopback hosts.
• The product is one statically-built Go binary: no bundled interpreters, no FFmpeg or transcoder subprocesses, no plugin loading. Privileged operations (OS trust-store updates and similar) are delegated to a single audited helper with validated arguments rather than running the service as root; the systemd unit applies kernel-surface sandboxing (protected kernel tunables/modules/logs, locked personality, restricted realtime and SUID/SGID creation).

Reporting a vulnerability

Email support@remcam.software with details. We acknowledge reports promptly, and security-critical fixes are flagged to deployed consoles through the signed update channel with a time-boxed application window.