8.3 How encryption works

Veeam® Cloud Connect offers complete encryption for data at rest thanks to Veeam Backup & Replication™ encryption capabilities, but also for data in flight, so that any information exchanged between a tenant and a service provider is protected while traveling over an insecure channel like the internet.

Security savvy people would probably like to know more details about how network encryption is implemented in Veeam Cloud Connect. This appendix is designed to give you all the details you need.

SSL and AES

Veeam Cloud Connect uses two different encryption technologies: SSL (Secure Socket Layer) and AES (Advanced Encryption Standard).

8.10: SSL and AES are the two encryption algorithms used in Veeam Cloud Connect

SSL is a generic term related to a family of communication encryption technologies. In more detail, Veeam Cloud Connect uses the latest TLS (Transport Layer Security) protocol and never fails back to older and insecure versions of SSL.

AES is also used together with SSL. It’s a symmetric encryption algorithm, and the de-facto standard for advanced data encryption.

During the initial connection between a customer and a service provider, the communication channel over a single TCP port (6180 by default) is protected with SSL. By verifying the SSL certificate published by the service provider, and comparing it to the hostname the provider is using for publishing Veeam Cloud Connect itself, the customer is assured that he is effectively connecting to the chosen service provider.

Providers can also create and send customers the fingerprint of their own SSL certificate for additional security.

SSL is an asymmetric encryption algorithm. There is a private key that is safely stored with the service provider, and a public key that is published over the internet and retrieved by users. This technology is well suited for protecting communications over unsecured channels like the internet, especially for the initial handshake. But, at the same time, it’s not suitable to exchange large amount of data. As an asymmetric algorithm, its performance during decryption is far worse than during the encryption. Also, it guarantees the authenticity of the server publishing the key — in this case the Cloud Connect environment — but not the user that is sending data to it.

While all control and configuration commands use the SSL/TLS tunnel, the exchange of data between a customer and a service provider — for example during a backup operation — uses the other Veeam Backup & Replication encryption based on AES-256.

Key exchange

One of the security issues of using a symmetric key over an insecure channel, like the internet, is the fact that anyone who holds a copy of the key can decrypt the cyphered data. So, it’s paramount to implement a secure mechanism to safely exchange the AES keys between the customer and the service provider.

Let’s see how this happens in Veeam Cloud Connect.

There are two Veeam Backup & Replication installations involved in Cloud Connect. One at the service provider, publishing the service, and one at the customer side, consuming the service.

Every activity is initiated by the customer side. When a new operation towards Cloud Connect needs to be started, the customer side sends a control command over the SSL tunnel.

The Cloud Connect installation at the service provider responds to the “Start” command, and it creates the encryption Key A. This key uses AES-256.

8.11: Cloud Connect Service creates AES key A

Using the SSL protected tunnel, Key A is securely and directly passed to the job manager of the customer and the target data mover at the service provider via a local network communication.

8.12: Key A is passed to customer and service provider data movers

The customer job manager then creates their own encryption key, Key B, to be used for encrypting traffic between the customer and the service provider data movers.

8.13: Customer VBR installation creates Key B

A new tunnel is initiated by the customer job manager using Key A. Thanks to this, only the service provider side is able to decrypt data coming from the customer side. Using this tunnel, Key B is delivered in a secure way to the data mover at the service provider side. At the same time, Key B is also delivered locally to a customer data mover using the local network.

8.14: Key B is delivered to customer and service provider datamovers

From here on, data transfers of the backup job payload is encrypted using Key B. In this way data is encrypted in flight by an encryption key that is created by the customer and not by the service provider.

Thanks to the use of Key B, customer data is safely sent to the service provider. Any attempt to intercept and modify the encrypted traffic raises a security warning as the key is only owned by the user and his service provider. This guarantees to customers the avoidance of possible middleman attacks.

When additional data transfers need to be done during a new session between the customer and the service provider, the entire process is repeated from the beginning and new keys, Key A and Key B, are generated again.

Finally, when WAN acceleration is used, the process is exactly the same, and Key B is also passed to both WAN accelerators at source and target locations. In this way, WAN acceleration is able to decrypt on-the-fly data blocks encrypted by the users.

This solution allows the protection of Cloud Connect user communications, as it’s leveraged regardless of whether or not the user is also encrypting their backups. For backup file encryption an additional set of AES keys are created to encrypt backup files. Those keys are not related to the communication keys.