Restoring database with encrypted columns where destination SMK is different

Question

A similar question has been asked before , but I believe the circumstances are slightly different, and I'd also like to understand any alternative solutions. I'm at the stage of information overload right now:\

Certain columns on a database on SERVER A have been encrypted using this approach:

-- Key creation
USE [master];
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ComplexPasswordHere';
CREATE CERTIFICATE MyDbCertificate01 WITH SUBJECT = 'MyDatabase Certificate 01';
CREATE SYMMETRIC KEY SSN_Key_01 WITH ALGORITHM = TRIPLE_DES ENCRYPTION BY CERTIFICATE MyDbCertificate01;

-- Decryption example
USE [MyDB];
GO
OPEN SYMMETRIC KEY SSN_Key_01 DECRYPTION BY CERTIFICATE MyDbCertificate01;
SELECT
  CONVERT(nvarchar(50), DECRYPTBYKEY(PasswordEnc)) AS [Password]
FROM
  [tbl_Users]
CLOSE SYMMETRIC KEY SSN_Key_01;

This database needs to be restored onto SERVER B, which already has a Service Master Key that governs encryption on other databases on that server.

From research, other authors state we can backup/restore the SMK using FORCE , but I think that would obliterate existing encryption on the destination server:

And here lies the problem: The current machine DMK cannot be used on data encrypted with another SMK. It will fail to decrypt, because the SMK has changed. Source

Assuming the above is still accurate, can the database be backed up, along with perhaps the certificate, to enable the destination server to decrypt the data successfully?

Is there any other way to achieving this without damaging the destination server's existing data?

Answer 1

So with the pressure mounting, I decided to get my wallet out and set up a new Azure VM testing server, guaranteeing a completely fresh setup.

The solution turned out as follows (links provided where possible).

1. Restore/Clone Database on Different Server

Use the instructions here (SSMS Restore dialog, overwriting the necessary fields) to restore the database. At this point, the encrypted database fields cannot yet be decrypted

2. Restore Database Master Key

Once restored, it turns out that this answer on dba.stackexchange is all that's required (modified to fit my question).

USE [MyRestoredDatabase]
GO
OPEN MASTER KEY DECRYPTION BY PASSWORD = 'ComplexPasswordHere'; -- This is the password used for --> CREATE MASTER KEY ENCRYPTION BY PASSWORD '....';
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;
GO

From that point onwards, the DECRYPTBYKEY() and other encryption worked fine.

If my assumptions below are incorrect, please post an answer that clarifies where I'm wrong, and I will accept your answer instead...

From my research on the new VM, it appears that when the database is backed up, the certificate and symmetric key are backed up automatically as part of the database (which makes perfect sense). Therefore, the final step is to configure the existing database master key that gets restored, to be under the control of the service master key on the destination machine. SSMS does the re-wiring automatically.

Answer 2

Forgot the details of how to do this again and had to go looking so just a bit of extra information for anyone who might need it.

There are at least two ways to get this done and the second is useful if you can't lay hands on the password for the database key but you are the SQL Server admin.

In that case you can just export the Server master key and overwrite the one in the destination server before you restore the backed up database. Of course this only works on a new server, or one that doesn't already have certificates in use or, in extremis, if you know the key passwords for all the certificates in the destination and can reset them as the EvilDr describes.

USE MASTER
GO
--On original SQL Server set password
BACKUP SERVICE MASTER KEY TO FILE = 'C:\temp\smk' ENCRYPTION BY PASSWORD = 'password';
GO
--On new SQL Server - BEFORE restoring backed up database (or else conflict)
RESTORE SERVICE MASTER KEY FROM FILE = 'C:\temp\smk' DECRYPTION BY PASSWORD = 'password';
GO
--Then restore database from backup with certificate and key included