Customers Environment:
1. Encryption key is generated on the Windows platform through custom software, but if we can move away from that to an automated approach all the better. The key is moved to Oracle manually and we want to replace this with automation.
2. Credit card information is interfaced to our system then automatically encrypted using the key and stored in a SQL 2008 Enterprise Edition server table (only the one column is encrypted).
3. The SQL Server data is then sent to our Oracle database as encrypted data where it is stored in one column of a table. It is then decrypted and sent to a payment services company who send us back a billing code, which replaces the encrypted credit card number. So most of the encrypted credit cards are only stored for a short period of time, but some with problems are stored much longer.
Questions Addressed:
Our Alliance Key Manager (AKM) Hardware Security Module (HSM) provides full life-cycle management of encryption keys for PCI DSS and PII compliance. It works with applications and databases on a variety of platforms including Windows, Linux, UNIX, and IBM mainframes. We support the Microsoft EKM architecture for automatic encryption of SQL Server using TDE or Cell Level Encryption. Our customers also use AKM to manage keys for Oracle database applications, and support for Oracle TDE (requires Oracle Enterprise Edition and Advanced Security) is in our product roadmap.
SQL Server:
Because you are running SQL Server Enterprise edition, you have two options. The first is to deploy Extensible Key Management (EKM), which is supported by our Alliance Key Manager. EKM gives you the ability to automate encryption through Transparent Data Encryption (TDE) or Cell Level Encryption. TDE is usually the choice people make as it is the easiest to deploy and does not require any programming. Cell Level Encryption requires a bit of programming, but still fully automates the storage of keys on the key server.
The second approach is to use our Windows .NET key retrieval assembly to retrieve an encryption key from our key server and perform encryption in your application. Since you are already doing an encryption with a local key, this would probably be a pretty simple task. It appears that you might need this type of granular approach to support your current integration between SQL Server and Oracle. We have C# and VBNET sample code that shows how to retrieve a key from the key server.
Additionally, we support Windows 2003 for either approach and both of these approaches will meet PCI DSS standards for key management.
Oracle:
Our customers are currently using our key manager to encrypt data in Oracle databases. We provide sample code in Java, Perl, PHP, and other languages to support this. We also provide a shared library that does secure key retrieval from a variety of platforms, and also sample code that shows how use the shared library in PL/SQL.
Encryption keys are generated on the encryption key manager using a secure administrator's console installed on a Windows PC. The interface to the key manager is a wire protocol and you can drive it from any application platform that supports SSL/TLS. All of your OS's do so. Our business users attempting to meet PCI DSS requirements for Dual Control and Separation of Duties typically stick to using our secure key management console.
Encryption on HSM:
Our Alliance Key Manager also supports encryption on the server. Rather than retrieving the key to your business application, you can send the data to the key manager with the name of the key you want to use, and it will return the encrypted or decrypted data back to your application on the secure connection. No key leaves the key server with this approach - just an alternative that is worth mentioning.
We hope that this case study can help you with your encryption project. Listen to our podcast “Encryption Key Management with Microsoft SQL Server 2008 to learn how easy it is for your organization to start encrypting data on your SQL Server.