1148 - How Group Certificates work

Each Redstor account has its own encryption key, which is used to encrypt that account’s data during the backup process. If this encryption key is lost (e.g. if the machine hosting that account's Agent dies and the user cannot remember the encryption key), there is no way to access the backed-up data (not even for Redstor employees). In managed environments, a Group administrator may wish to avoid this scenario by protecting the encryption keys so that they can be recovered if necessary. This is where Group Certificates come in.

Benefits of Group Certificates:

• Contingency - Since there is no way for Redstor to access or reset encryption keys, Group Certificates provide a means of doing this.
• Security – Group Certificates are password-protected and only available to authorised users of the Console where the certificates are loaded.
• Eliminates human error – Group Certificates are much less risky than, for example, manually saving encryption keys to a text file.
• Simplifies key management - Encryption keys are captured automatically when new accounts are created.

A Redstor Group Certificate contains a pair of keys: one that can be shared publicly, and one that remains private. Any information (such as encryption keys) that is encrypted with the public key can only be decrypted with the private key.

The Group Certificate key pair is generated from the Group admin's Console. The private key is then stored within that admin's Console, protected by a passphrase selected by the admin themselves. The public key, in turn, is sent to Redstor as part of a Group Certificate request. You can also request a Group Certificate for a Collection. This certificate will then be valid for all Collections and Groups within the parent Collection.

Since access to encryption keys also allows access to the backed-up data, we first verify that the requesting admin has been appropriately authorised by their organisation before signing the certificate. Encryption keys are only captured if a valid, signed certificate is present. The admin then uploads the signed certificate to the Storage Platform.

From now on, whenever an encryption key is provided by an Agent in order to perform a backup, that key is encrypted using the public key from the Group Certificate, and stored in the relevant AccountServer database. The encryption key's encrypted value can only be decrypted by the private key of that Group Certificate, which is stored securely in the Group admin's Console.

In short: the only way to get to an Agent's encryption key (and therefore its backed-up data) is to have access to the private key stored in the Group admin's Console and to the passphrase created by the Group admin. No-one but the Group admin who requested the Group Certificate can therefore access the encryption keys of a Group's accounts.

Read more about best practices for managing encryption keys here.

Q&A

If I rename or move my Group, do I need to create a new Group Certificate?
No. We link the Group Certificate to the Group GUID and not to its name, which means that you can move a Group/Collection or change its name (and consequently its path) without invalidating its certificate.

If I move an account to a different Group, does the encryption key move as well?
No, the key does not move. As long as the destination Group has an active Group Certificate, the account just has to backup once in its new location for us to capture the encryption key in the appropriate Group Certificate.

Can I get the encryption key for a server that is not backing up anymore?
The backup must run at least once after the Group Certificate is uploaded for the encryption key to be stored. If the server is unavailable after uploading the Group Certificate, the encryption key cannot be retrieved. However, if the Group Certificate was uploaded before the server's last backup process, then the encryption key will be available on the Console where the Group Certificate has been loaded.