Encryption and key recovery
MSP Backups encrypts every backup on the device before it is uploaded. The key is derived from a backup passphrase that is never sent to your server. Your server stores encrypted data and the records that point to it, but not the means to read it.
How the key is made
- Each device has a random salt. The salt is not secret: the device reports it to the server, which keeps it with each restore point so the key can be derived again later.
- The agent runs the passphrase and the salt through Argon2id (3 passes, 64 MiB of memory, 4 lanes) to make a 256-bit master key.
- HKDF splits the master key into three subkeys: one encrypts chunks, one encrypts manifests and one names chunks.
- Each chunk and each manifest is encrypted with AES-256-GCM. GCM authenticates the data, so a chunk that was changed in storage fails to decrypt instead of restoring corrupt bytes.
- Chunk names are an HMAC of the chunk's content under the naming subkey. Two tenants with the same file produce different chunk names, so nobody can tell from storage whether you hold a given file.
What the server sees
| The server stores | The server never receives |
|---|---|
| Tenant, device and user records | The backup passphrase |
| Each restore point's date, size, chunk count and salt | The master key or any subkey |
| The storage object key of each encrypted manifest | File names and file contents inside your backups |
| Storage target credentials, encrypted at rest | Unencrypted chunk data |
Some text about devices does reach the server: folder paths set in policies, the names and errors of backup jobs and sources, and the text of agent alerts (a canary alert names the folder it was found in).
Where the passphrase lives
- On the device. So the background service can run backups without anyone present, the agent keeps the passphrase in its configuration file. On Windows the installer restricts that folder to SYSTEM, Administrators and the signed-in console user. On Linux and macOS the file is under
/etc/cvn-agentor/Library/Application Support/cvn-agent, readable only by root. - In the browser, briefly. When someone restores files in the file explorer, they type the passphrase into the page. The page derives the key and decrypts there. The passphrase is not sent to the server.
Key recovery
There is no key recovery through the server, by design. If the passphrase is lost and the device that held it is gone, that device's backups cannot be decrypted by you, by your server or by us.
While the device still runs, its agent holds the passphrase, so it keeps backing up and can still restore files in place. Restores in the browser, on another machine or from a recovery USB need the passphrase typed in.
Plan for this before you deploy:
- Record every passphrase in your password manager when you set it, under the tenant and device name.
- For disaster recovery, also keep a copy of each important device's
agent.jsonoff the device. It holds the device token and server address the recovery tools need. See Bare-metal and VM recovery. - Test a restore with the recorded passphrase, not with one typed from memory. See Your first backup.
Rotating keys
In the global admin portal, Settings > Maintenance > Rotate keys asks every agent to rotate. On its next backup, each agent generates a new salt, so new restore points use a new key. Old restore points keep their own salt, and the same passphrase still opens them.
Chunk names depend on the key, so the first backup after a rotation uploads each device's data in full. Plan rotations for a time when that upload is acceptable.
Rotation changes the key, not the passphrase. If you think a passphrase has leaked, set a new one on the device (see Agent command line) and keep the old one for the old restore points.