Question

I have a three part question that address SYMMETRIC KEYs in SQL Server 2008 R2.

1. How can I restrict just one account to access the ability to ENCRYPT/DECRYPT using a SYMMETRIC KEY?
2. When data is passed to SQL Server, it is passed “in-the-clear” and can be passed by both stored procs and ad-hoc queries. Can I use a trigger for updating the column that needs encrypting as it’s being inserted using the account above and the SYMMETRIC KEY?
3. In a year’s time, by my company’s policy, the keys will have to rotated and changed. Is there a way to rotate the keys easily, or will this require a (decrypt with old key, encrypt with new key) script?

FYI, We am using SQL Server 2008 R2 Standard and don’t have the benefit of TDE. 🙁

Thanks for your replies! 🙂

Answer 1

Encryption is usually controlled by controlling the encryption hierarchy, not (only) by access control. In other words users can encrypt and decrypt the data by virtue of knowing the decryption/encryption key (the password that protects the key, to be specific). All good encryption schemes use a key hierarchy. A typical simple hierarchy is

• data is encrypted with a symmetric key
• the symmetric key is encrypted with a certificate
• the private key associated with the certificate is encrypted with a password
• authorized users provide the private key decryption password in order to access the data

You can also add explicit grant/deny/revoke permissions on the certificates used, see GRANT Certificates Permissions but that is no substitute to knowing the certificate encryption password password. Now back to your questions:

How can I restrict just one account to access the ability to ENCRYPT/DECRYPT using a SYMMETRIC KEY

The ability should apply to the certificate that encrypts the symmetric key, not to the symmetric key itself. With this level of indirection you can create a certificate for each user that has accesses to the data, and have each user know only its own access password. Revoking access is a s simple as dropping the certificate for that one particular user, w/o affecting any other user’s access. Adding a new user implies adding a new certificate and adding this new certificate’s encryption to the symmetric key encrypting the data, thus in effect granting access to the data. The alternative of users sharing the access password never works in practice due to social reasons.

Can I use a trigger for updating the column that needs encrypting as it’s being inserted using the account above and the SYMMETRIC KEY

Ideally the application layer should call a stored procedure for manipulating data that explicitly encrypts the data before insert. You can roll a poor-man ‘transparent’ solution by using INSTEAD OF triggers. A computed column can expose the decrypted data, it will show NULL to all users (sessions) that did not properly open a decryption certificate first.

the keys will have to rotated and changed

You rotate the certificates that encrypt the symmetric key, not the symmetric key itself. The symmetric key should also be changed periodically but not roatated, simply add a new symmetric key and start using it for new data and updates of the old data, in order to limit the scope of a brute force and to reduce birthday-attack probabilities. The justification is that re-encrypting the data-at rest is often prohibitively expensive. Most encryption schemes rotate a key higher in the encryption hierarchy (ie. the certificates mentioned above) not the actual symmetric key used to encrypt the data.