Change encryption key S3 repository

[dotdk]

Hello forum.

We as a service provider, are about to onboard a customer that already has a Veeam M365 backup service at another service provider, and has a repository with 5 years of retention that is encrypted.
The customer want to move the data to us, but as their current service provider has encrypted their data with a encryption key they have used for multiple customers, they are not willing to share the encryption key with the customer or us.

So we are exploring ways methods to see if we can help the customer get their historical data to us.

One of the methods was to clone their S3 bucket and then change the encryption key to a new encryption key on the bucket. I have been looking at the documentation:
https://helpcenter.veeam.com/docs/vbo36 ... ord-change
But as far as I see, the older data from before the encryption key change will require the previously used encryption key, in order to access it.

The scenario is that we want to clone their current S3 bucket at their current provider to our S3 system, we have done this before but with unique encryption keys so there haven't been a need to change it previously.

Can we do this or will need the original encryption key from the current service provider.

I have asked the same question to support and it should be theoretically possible, but does anyone have real life experience with changing encryption keys and reading historical data without the old(er) encryption keys available?

[Mildur]

Hi Thomas

The previously used encryption key is required, or encryption would make no sense at all.
Imagine attackers having access to the protected data in the bucket without knowing the encryption key. Wouldn't be a great solution.

What you need todo is adding the S3 repository to the new backup server and provide the original encryption key to get access to the backups.
After that you can change the encryption key to a different one.

Best,
Fabian

[mjr.epicfail]

Hi Thomas,

As far as I know you will always need the original key to decrypt the already backed-up data. No way around that.
If the old ServiceProvider is unwilling to share this key, for obvious reasons in this case.

I'm not sure if the clone of data will help you in this case, if the older key needs to be present to decrypt older backups. The documentation is a bit ambiguous about this as there is some writing about replacing older keys but also that you need to create a chain of keys (which is unnecessary if you replace the old key/encryption.

In structured backups, the old backup files are not re-encrypted and when forever forward is in use you will need *all* encryption keys ever used in that chain until a new active full is run.

[dotdk]

Sorry I might now have explained what we wanted to do clearly enough,

So we want to clone the S3 bucket, lets call it bucket1 - to another S3 bucket lets call that one bucket2.

Then add bucket2 to the existing (other service providers) Veeam M365 backup environment where we can use the original encryption key, and then add a new encryption key to the environment and replace the original key on bucket2 with the newly added key.

Then remove the bucket2 repository from the other service provider add it to our environment, after cloning it again along with the newly created key, would we then be able to read the historical data?

[Mildur]

Only the last used <encryption password> is required. You don't need the entire history of encryption passwords.

So we want to clone the S3 bucket, lets call it bucket1 - to another S3 bucket lets call that one bucket2.

Keep in mind, that this is not a supported procedure. Our support team won't be able to help if something breaks.

Best,
Fabian

[dotdk]

Ok, great Mildur, that it what I was looking for it wasnt clear to me from the documentation.

[dotdk]

Only the last used <encryption password> is required. You don't need the entire history of encryption passwords.


Keep in mind, that this is not a supported procedure. Our support team won't be able to help if something breaks.

Best,
Fabian

We know, but in this case this is our only chance to get the data.

[mjr.epicfail]

I would suggest the following:

- Create a new isolated bucket
- Give old SP access to that bucket
- Let old SP clone repo to that bucket
- Generate a temporary encryption Key and give that to old SP
- Let old SP re encrypt with tempory key
- Obtain access to the isolated bucket
- rekey API to that bucket
- Add bucket to own VB365 and reencrypt with a new key