Your data is unreadable to your provider, and to us
Encryption happens on the workstation, with a key that never travels over the network. This is not a configuration option: it is how it works by default.
"And you — can you read our data?"
It is the question that comes up in meetings, sooner or later. The answer has to be verifiable, not reassuring.
Many solutions encrypt at rest, on the server side: the data is encrypted on the backup server's disk. That protects against physical theft of the disk. It does not protect if somebody gains access to the server, since it is the server that holds the key.
BeBackup encrypts at source. Data is encrypted on the machine being backed up, before it leaves, with a key that never leaves that machine. The server stores only unintelligible blocks and the hash of the key — enough to check that an agent presents the right key, never enough to decrypt.
The chain, step by step
-
1
On the workstation
Every block is compressed (LZO) then encrypted with AES-256 by the agent, before anything is sent. Source passwords are themselves encrypted and tied to the workstation's hardware identifier.
-
2
On the network
TLS 1.3 transport between agent and server, on OpenSSL 3.5, with AES encryption of the packets. Neither the TLS nor the packet encryption can be disabled by configuration.
-
3
On the server
The blocks arrive already encrypted and are stored as they are. The server holds only the hash of the data key, not the key.
-
4
On verification
Every block carries its hashes, before and after compression. The server therefore checks data integrity without ever being able to decrypt it.
The trade-off, stated plainly
Encryption whose key stays with the client has a consequence that must be said clearly: the key is specific to each workstation and it cannot be replaced. Nobody can regenerate it — neither you nor us.
That is exactly what makes the confidentiality guarantee credible — and it is also what makes the keeping the recovery key safe an operational task in its own right, to be organised before the first deployment. For a provider running an estate, that is a procedure to write, not a box to tick.
A service provider may also choose toimpose a key from the server side for the workstations it administers, if it prefers to centralise that responsibility rather than leave it to each machine. What a service provider takes on
A single port to open
The server listens on a single port for the agents, the web interface and the certificates. Routing is decided by reading the ClientHello (SNI and ALPN): the server identifies the nature of the connection before routing it.
For the network administrator, that means one firewall rule instead of three, and a correspondingly smaller exposed surface. The maintenance mode also locks access to the local network alone.
Certificates: issued, imported, renewed
- Internal certificate authority: creating the CA and the certificates, generating CSRs, importing external certificates and regenerating the server certificate — all from the interface.
-
Automatic Let's Encrypt: issued from the interface through ACME v2 (
tls-alpn-01andhttp-01), then automatic renewal 30 days before expiry. Let's Encrypt, Buypass and ZeroSSL are offered, and a custom authority can be given by URL. - TLS 1.2 floor for browsers, TLS 1.3 for agents.
The certificate that expires on a Sunday morning is an operations classic. Here, renewal depends neither on a scheduled task to write nor on a reminder in a diary.
Controlling access to the console
-
TOTP two-factor authentication
Compatible with Google Authenticator and equivalents, with a QR code generated by the server.
-
Device enrolment
A connection from an unknown device triggers a validation code and a "new device registered" email giving the IP address and the browser. Each user then manages their devices: rename, delete, sign out everywhere.
-
Client certificate can be required
A certificate can be required per web user and for linked servers. The session is validated both on the IP address and on the certificate.
-
Email address validation
By a code sent out, with failed logins counted and the password salted per session key.
Have the model audited
We are happy to go through the encryption chain with your security officer or your auditor, evidence in hand.
The other pages in this section Features
- What's new in v7 Microsoft 365, BeBackup Drive, agents for macOS, Linux, Synology, Android and iPhone…
- Microsoft 365 Mailboxes, contacts, calendars, OneDrive and SharePoint backed up through Microsoft Graph…
- System and virtualisation SmartImage, disk image, VSS for SQL Server and Hyper-V, VMware VMs backed up agentlessly with…
- Restore and recovery A file, a folder, a partition, a whole disk, a physical machine to an ESXi VM, booting under…
- For service providers Multi-client console, white label, per-technician rights, quotas and a real-time dashboard…
- You are here Security and encryption
Contact the BeBackup team
Would you like to know more about our BeBackup backup solution?