Question

In this article is explained how to decrypt a symmetric key. For example:

SELECT SK.name, SK.symmetric_key_id, SK.key_length, SK.algorithm_desc,
       KE.crypt_type_desc,
       COALESCE(C.name,AK.name,PSK.name) AS protector_name,
       KE.crypt_property AS encrypted_key,
       COALESCE(DECRYPTBYCERT(C.certificate_id,KE.crypt_property),
                DECRYPTBYASYMKEY(AK.asymmetric_key_id,KE.crypt_property)) AS decrypted_key
  FROM sys.key_encryptions AS KE
  JOIN sys.symmetric_keys AS SK
    ON KE.key_id = SK.symmetric_key_id
  LEFT JOIN sys.certificates AS C
    ON KE.thumbprint = C.thumbprint
  LEFT JOIN sys.asymmetric_keys AS AK
    ON KE.thumbprint = AK.thumbprint
  LEFT JOIN sys.symmetric_keys AS PSK
    ON KE.thumbprint = CAST(PSK.key_guid AS VARBINARY(50));

It can be tested using the following query:

-- 
CREATE MASTER KEY ENCRYPTION
BY PASSWORD = 'smGK_MasterKeyPassword@';

-- 
CREATE CERTIFICATE [CERT_V001]
WITH SUBJECT = 'User for protecting SM symetric keys.'


--
CREATE SYMMETRIC KEY [SK_SecurityUsers_V001]
WITH ALGORITHM = AES_256 ENCRYPTION
BY CERTIFICATE [CERT_V001]
GO


DECLARE @Email NVARCHAR(128) = 'sometest@google.com';
DECLARE @EmailEncrypted VARBINARY(256);

OPEN SYMMETRIC KEY [SK_SecurityUsers_V001] DECRYPTION
BY CERTIFICATE [CERT_V001];

SELECT @EmailEncrypted = ENCRYPTBYKEY(KEY_GUID('SK_SecurityUsers_V001'),@Email);
SELECT @EmailEncrypted;

CLOSE SYMMETRIC KEY [SK_SecurityUsers_V001];


OPEN SYMMETRIC KEY [SK_SecurityUsers_V001] DECRYPTION
BY CERTIFICATE [CERT_V001];

SELECT CONVERT(NVARCHAR(128), DECRYPTBYKEY(@EmailEncrypted));

CLOSE SYMMETRIC KEY [SK_SecurityUsers_V001];


--DROP SYMMETRIC KEY [SK_SecurityUsers_V001];
--DROP CERTIFICATE [CERT_V001];
--DROP MASTER KEY;

I am wondering, does this mean the data is not protected at all?

In the article is said, that:

However, for password-protected and symmetric-key-protected keys this sadly does not work.

I guess this means I need to use one of these types of encryption in order to be sure the data is protected?

Was it helpful?

Solution

I am wondering, does this mean the data is not protected at all?

No, it's protected but as shown in the article you need to have access to all of the keys in order to decrypt the values. The article takes a bunch of liberties and glosses over quite a few things when it comes to the protection of the keys. Try doing this without being a sysadmin, knowing the DMK password, or using transparent decryption hierarchy. Could you still do it - most likely not.

The secrets in SQL Server are generally protected by levels of encryption - where one key encrypts the other which encrypts the other. If you can unwind all of those levels (which again the article doesn't even really talk about and just kind of glosses over) then absolutely you can decrypt the data. SQL Server doesn't use any homemade encryption, it's all industry standard algorithms which are publically documented. There is nothing stopping anyone from implementing something to reverse it if they had all the keys. This is why over provisioning permissions is a bad thing.

the data must be encrypted in rest and I want to check if the above behavior can give a person who has access to the database, but do not know the database master key password, the ability to encrypt the data.

In this case, no they generally wouldn't be able to get to the decrypted data. There are, however, edge cases that won't stop someone with administrative access and a decent working knowledge of encryption from possibly getting the data.

It's all about "reasonable protection" wherein you've given a reasonable enough protection to the data. If you wanted it to be extremely secure then you'd need to use an HSM, which another team owns and audits on an extremely frequent basis. No one would have administrative access to the server, and no one would have sysadmin access to SQL Server. That's probably not going to fly - so "reasonable" protection should be sufficed.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top