Question

I am looking into encrypting some sensitive data in SQL Server, such as bank account numbers and social security numbers in order to comply with new state laws. I am using SQL Server 2008 as my database with .NET code. I have used .NET to encrypt passwords, but for this I’m thinking of using Microsoft’s built in encryption by just encrypting the few columns of data I need to with a simple Symmetric Key Encryption. If I go SQL Server encryption I can decrypt the data from outside reporting tools and not just within my .NET application. Here’s the example I’m using:
http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/

It uses a certificate created by SQL Server and then the DecryptByKey function to decrypt the data, but I’m trying to determine how secure this really is? How do I control what users can decrypt data or can anybody do it so long as they open the symmetric key and use the decrypt function?

Answer 1

You have two alternatives:

1. Cryptographic control. With this only the users that know the password can decrypt the data. The downside is that the user must enter the decryption password each time they access the data. A Report woul have to contain a Password parameter that the user running the report fills with the data access password. Application must request the password from the user. Web sites must request password from visitor. And so on and so forth

2. Access control. The data is encrypted with a key that SQL Server itself has access to (ultimately the ecnryption chain goes all the way up to the Service Master Key and this is encrypted using DPAPI). This gives you no greater protection other that granting and denying SELECT would give you: is access control, not cryptographic control. Such a scheme protects solely against accidental loss of media (somebody finds a disk with your database, or you loose a laptop with the database on it). You can achieve the very same using Transparent Data Encryption or file level encryption (BitLocker).

The common data encryption scenario is to encrypt the data with a symmetric key, and then encryt the symmetric key with an asymmetric key (usually the private key of a certificate). The asymmetric key is then in turn encrypted with a password, and this password must be presented when trying to access data. The primary reason for this two level indirection is password change: when a password or a private key is compromissed the symmetric key is re-encrypted with a different asymmetric key or the asymmetric key is re-encrypted with a different password. This way the access password has changed without requiring a re-encryption of all the data. If the access would be granted directly to the symmetric key then a password compromise would possibly require to re-encrypt all the data, possible terabytes of data.

Where the two scenarios I presented differ is whether the asymmetric key is also ecnrypted with the database master key or not. Case 1) it isn’t, case 2) it is. This is all explained in Encryption Hierarchy.