Database encryption?
August 20th, 2007 by admin Posted in Encryption
Troy emailed to ask:
We have been looking at database encryption as it applies to PCI Compliance in the United States. We have been told that we must encrypt the credit card numbers as they are stored in our SQL Server 2005 database. We developed a method where we used the key in SQL to create a certificate to encrypt and decrypt the data, as outlined in a whitepaper from Microsoft on how to use SQL Server 2005 encryption.
We have now been told that the weakness in this method is key management. Since the key is stored in the database with the credit card data, it is not compliant. Is there a resource that describes the recommended way to use SQL Server 2005 to encrypt credit card data that resolves the key and certificate issues?
I know that Damon has posted a good link to Oracle security relating to PCI, but I have not seen something like this for MS SQL.
Although storing the decryption key in the database itself is a bad idea, I would caution you against trying to map all your processes directly to the controls. Instead, try to view the intent behind requirement 3.4-3.6 and determine if your security controls achieve that goal.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
14 Responses to “Database encryption?”
By E.K. on Aug 21, 2007
As it wasn’t mentioned in the article I will suggest that you look into a Host Security Module (HSM). These are the devices used by banks to secure ATM transactions. Many of them have the added benefit of letting you offload the processing power needed to actually perform the encryption/ decryption.
By Damon on Aug 21, 2007
I second E.K.’s suggestion of investigating HSM’s.
As these devices are dedicated to the task of encryption, they are well prepared to address the variety of issues to maintain PCI compliance including key management. As Troy discovered, a solution that only utilizes SQL Server will likely not be robust enough to comply with PCI.
Furthermore, I know of at least one HSM that allows you to limit read/write access based on the keys being used to access the encryption module. While not necessarily required by PCI, this could put you ahead of the game by limiting front-end servers to write CC data while only allowing the backend processing systems to read CC data.
By Michael Dahn on Aug 21, 2007
@Damon, I agree that in many circumstances using an HSM is the best way to approach database encryption. When individual applications hit different databases, one might evaluate that or other solutions.
By DLee on Sep 4, 2007
Damon -
Can you recommend some HSM options? Particularly the one you mention in the second paragraph of your above message? Thanks!
By Damon on Sep 14, 2007
@DLee - While I generally try to remain product-agnostic, the particular one I am referring to is by nCipher and can be found on their site here: http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/10/nethsm
I’m not sure if any good comparisons/bakeoffs exist in the world of HSM’s, but definitely something to look into during the evaluation process.
By DLee on Sep 20, 2007
Thanks much for help!
By Djalil on Sep 23, 2008
@ Michael Dahn
What if only one application hits the Database?
Will it be business reasonable to say that SQL encryption key management is enough?
thanks
By Michael Dahn on Sep 24, 2008
@Djalil, the situation becomes more complex as you describe singular environments. Call me if you wish to discuss.
By John Markh on Feb 3, 2009
The MSSQL solution is very similar to the Oracle Advanced Security Transparent Data Encryption and it all comes down to how you design (hey, you need to be creative and knowledgeable) and manage the implementation.
By Maik on Mar 4, 2009
I’ve a similar situation with our own environment:
We use a key management software but without a HSM. It uses Java keystores which I greatly dislike. Keys created by the software are stored encrypted in its database.
The applications (processing / backent) have memory tables, that cache the received keys encrypted with a master key. The master key is different on each appliction and able to access the applications certificate private keys for key management and to en/decrypt the encryption / decryption keys inside the memory table cache. The master key is XORed split knowledge and never stored on the system in merged form or partially, only the application holds it in memory when started. For the merge process the key is only on a volatile ramdisk that will be wiped after the application boot process started.
The question is if this setup is OK for compliance or is it better to store all private keys / certs inside a HSM that will be accessed by the key management software. This will create quite some overhead in my opinion.
Regards,
Maik
By SQL Tutorials on Apr 30, 2009
You know, the thing about SQL is, that there is virtually nothing that can replace it.
Does anyone know if a substitute exists for sql? I mean besides MS SQL and Oracle and all that jazz. Thanks.
By Brian on Jul 15, 2009
Thank you this helped me as well. I am also looking at NuBridges, and was wondering on anyones opinion about this company
By John Markh on Jul 17, 2009
I have working with NuBridges people and assessed number of implementations. The product is flexable enough and from security/compliance standpoint can(!) provide what is needed to:
1. Secure your data
2. Comply with PCI DSS
By Howard T Rogers on Aug 6, 2009
I have worked with Protegrity and a number of implementations during 10 years. The product can provide what is needed:
1. Secure your data
2. Comply with PCI DSS
3. HSM support
4. Data Type Preserving Encryption
5. Data Tokenization