Security model

SmartFleet connects installations on customer networks to a server on the internet. This page explains who trusts whom, what is encrypted and what an attacker would need.

No open ports at the customer

The gateway establishes every connection itself: to your server via HTTPS and, for a LoxBerry only during remote maintenance, an encrypted connection for the remote maintenance address. The SmartFleet Gateway handles remote maintenance through its connection to your server as well. No port has to be opened and no port forwarding set up on the customer network. The server has no way into the customer network; it can only leave jobs for the gateway, which picks them up at its next contact and verifies them.

Every message is signed

• During setup your server receives a certificate that traces back to a common SmartFleet root. The server’s private key is generated on the server and never leaves it.
• During pairing the gateway generates a key pair of its own. Your server issues it a certificate. This private key also stays on the gateway.
• Every message from the gateway is signed with its key, every response and every job from the server with the server’s. Both sides check the signature and discard everything else. Repeated messages are detected and rejected.

Ed25519 signatures and the platforms’ maintained cryptography libraries are used (libsodium on the server and on the SmartFleet Gateway, OpenSSL on the LoxBerry).

The deployment code

A code for a new site is valid for 24 hours and can only be used once. It contains your server’s address and certificate. Before pairing, the gateway checks that it really is your server answering at that address, and otherwise aborts without sending anything. An intercepted code that has already been redeemed is worthless.

Remote maintenance: three locks

For remote maintenance an attacker needs three things at once:

1. access to your partner UI – without it no job is created
2. the customer’s remote maintenance password – the server doesn’t know it; the gateway checks a response computed from it
3. your server’s signing key – without it the gateway discards the job

Someone who only captures the server’s database does not have the signing key; it is in config.php. In addition, the customer can block remote maintenance on the gateway at any time (on the SmartFleet Gateway with Remote maintenance allowed, in the plugin with the block), and every remote maintenance session ends by itself after 6 hours.

Password vault: end-to-end encrypted

The vault is encrypted and decrypted in the browser. The master password never leaves the browser; the server only stores ciphertext and public keys. When the gateway transfers passwords, it encrypts them itself with the vault’s public key. On opening, the browser checks that the stored keys match, and refuses to open the vault if someone has swapped them on the server.

Project files

Project files contain access data. The server only stores them at a site with a password vault and encrypts them as they arrive, chunk by chunk, with a separate key per file (XChaCha20-Poly1305). It encrypts that key with the vault’s public key; only the browser can open it, with the master password. For a download the browser releases only the key of that one file, never the master password. After receiving a file the server keeps its key open briefly to evaluate it (system values, documentation preview), for at most 24 hours. Without a vault the file is deleted after the evaluation.

Someone who copies the server’s database and storage cannot read stored project files afterwards. This does not protect against an attacker who controls the running server: they see a file while it is being evaluated or downloaded.

Backups

The gateway encrypts every backup with its own key before it leaves the customer network and seals that key for the site’s password vault. The server cannot read a backup; without a vault, no backup is created. On download, the browser opens the vault with the master password and releases only the key of that one backup. Older backups are still encrypted with the password of the respective Miniserver (AES, 7z). All of them are stored on the server in a directory blocked from the network, under random names. Only a logged-in user with at least the role Viewer Plus can download them.

Login

• Passwords are stored only as hashes.
• Second factor via authenticator app or email, optionally required for everyone.
• Login slows down after failed attempts, separately per origin.
• The emergency access can only be triggered with file access and does not replace the login.
• Every action in the partner UI is logged before it is carried out.

Updates

Server updates are signed with a release key of their own. The server checks the signature and the checksum of every file before it replaces anything, and backs up the previous state first.

What you should do yourself

• Run the server only over HTTPS.
• Keep config.php safe and delete setup.php after setup.
• Require a second factor for all users.
• Only issue open share links with a time limit.
• Leave automatic updates switched on.