Time is Right for Database Encryption

Remember that any indices generated from encrypted fields won't be valid, either. And because these fields don't relate to the actual data, it'll be harder for the database administrator and developer to debug problems. As a matter of fact, unless you have a mechanism to decrypt your database data on the fly, any query that uses encrypted fields to search or order data will cause trouble.

Database software, such as Sybase's, lets you create encrypted databases. Access requires a key, which also lets you decrypt on the fly. This all-or-nothing encryption, with the entire database encrypted or not, can cost you in overhead. However, Sybase offers helpful tips for getting around the problem. And though the all-or-nothing approach is beyond the scope of this article, it may prove a viable option in high-security situations, given recent improvements in hard-drive speed and capacity.

Trading Spaces

Disk space is an issue with database encryption because encrypted fields are larger than unencrypted fields. They're a little larger for textual data and a lot larger for numeric and binary data--data in a numeric field, for example, gets encrypted one byte at a time and grows to two bytes when it's encrypted. RAID arrays, SANs and network-attached storage devices give you plenty of space, unless you have a massive database of millions of rows, each row with hundreds of bytes.

Most database-encryption mechanisms present encrypted data as characters, one character per hexadecimal digit. That's a big increase: When encrypted, a 4-byte integer becomes an 8-byte character string. Most encryption algorithms use 64-bit DES, so your 4-byte (32-bit) integer becomes a string of 16 encrypted characters. Bottom line: When building your disk capacity for database encryption, anticipate that your data will triple or quadruple in size. In addition, make sure you have sufficient logical-memory space.Keep in mind, too, that encryption increases your data fields. To allow for this, increase the size of the field so the column is larger, and change the field type to accommodate the encrypted data. Numeric fields, then, would be changed to character fields large enough to store encrypted data.

And don't encrypt anything that doesn't need it. Encrypt a credit-card number, but don't bother encrypting your customer's first name.

If you run a high-volume database system, encryption and decryption may not bring it to its knees, but it might hurt performance. Ask your database vendor which encryption-acceleration tools work with its product. Many database-encryption vendors have relationships with acceleration-tool suppliers. Oracle's database, for instance, has a working relationship with nCipher.Once you know which data to encrypt in your database, decide what to do with the encryption-decryption keys. Don't send your data over the network unencrypted if it's stored in your database in encrypted form. Anyone with access (legal or illicit) to your network can sniff the packets running over it and view your unencrypted data, defeating the purpose of encrypting your database.

This is why client applications should decrypt the data after they receive it from the database. That's the most secure place to handle encryption and decryption. But changing all your client applications usually isn't realistic. If you find that modifying your apps is not an option, look for a solution that allows for decryption on the database and protection of your data while on the network. Using SSL to communicate with your database will protect your data while it traverses the LAN. It's simple to implement, especially since you probably already use it for transmitting sensitive information over the Internet.

Each client with your homegrown apps should have a key to decrypt the data received from a database-query response. For externally developed applications, your best bet is to use stored procedures and views that decrypt and return the data. But even that might not be possible for all applications, because they're keyed to specific table/column combinations and can't be redirected to use queries and views. Whether you decrypt on the server or the client, the keys still must be stored somewhere.Oracle has one of the best solutions for in-database encryption-decryption keys. It stores the keys, encrypted, in a table. For users with access rights, it decrypts the keys, which in turn decrypt the desired data. The downside, of course, is that you have unencrypted data on the network, but the benefit is making access to encrypted data secure. Not even the database administrator can see the unencrypted data--even the keys to get at the data are encrypted. This solution can be implemented in any of the major databases, and Oracle provides a secure key generator as well as other tools to get you started.

Another option is to add a third-party package, from a security company like nCipher or RSA Security, that encrypts the data on the way into the database and decrypts it on the way out. If you're building an e-business infrastructure, for instance, or if implementing encryption on your own isn't realistic, it makes sense to go with such an encryption-decryption product, which typically includes acceleration features. But bear in mind that vendor offerings vary in how they create and protect encryption-decryption keys.

Alternatively, you can store the keys on disk and give only the database admin the right to access the key file. This works so long as you can secure the file in question. Remember that for your data to be secure, the communication protocol must be secure as well, as in the case of SSL.

Make sure you have two "live" copies of the table you're working on--or at least send the data out to disk somewhere so you can reimport it later. Because you're encrypting live data, you need to be sure you can get it back to its original form quickly. Backups may work, but they're slower and not likely up-to-date.

Create a new column in your table for each field you intend to encrypt. Check with your encryption vendor to ensure that the fields are large enough to hold the encrypted data. Remove the old columns from the database, and give the encrypted columns their original column names.The Price You Pay

If this sounds like a lot of work, it is. You can't encrypt your database in a vacuum. Don't forget that applications access this data, so you have to consider how encrypting it will affect them. An app for accessing credit-card information still must be able to get that information in a readable format.

And though encrypting data is a logical next step in better securing your enterprise, it carries a high price: application performance can suffer, database recovery takes longer because you have to decrypt encrypted fields, and troubleshooting bad queries becomes trickier because the data in the fields is in its encrypted form. Still, the payoff is big: You can sleep at night knowing that even if an intruder does find a way into your network, he or she couldn't steal sensitive employee or customer information.

Don MacVittie is an application engineer at WPS Resources. Write to him at [email protected].

Post a comment or question on this story.

How to Encrypt Database Data1. Determine what to encrypt. Keep the list short, encrypting only those fields with sensitive data. Once fields are encrypted, indices generated from them will be invalid.

2. Decide where to handle encryption and decryption for your database. The most secure place is on the client--but the client needs this capability built in. If that doesn't work, the database will have to do, possibly with a third-party encryption tool.

3. Protect your keys. Oracle recommends storing them in a table in encrypted form, then accessing them with a stored procedure that decrypts them, gets the data requested, decrypts it with the unencrypted key and returns the resulting data set. Or store them on a disk, and give only the database rights needed to access the key file; this works if you can secure the file.

4. Implement, or get access to, a secure key-generation system. Oracle bundles a secure key generator with 9i. Other vendors have their own tools.

5. Know how much disk space you need for larger fields. This varies from solution to solution.6. Keep two live copies of the table for each field you encrypt. Or stream it out to disk so you can reimport it later. Check with your encryption vendor to ensure that the fields are large enough to hold the encrypted data. Don't

forget to delete the extra table when all is OK.

7. Use your encryption vendor's tool to copy the unencrypted data and then encrypt it. Place the encrypted data into the new field you created.

Here's a vendor sampling of database-encryption tools that will help protect your data.

• Application Security, DbEncrypt, www.appsecinc.com• Ingrian Networks, DataSecure Platforms, www.ingrian.com

• Ncipher, CipherTools, www.ncipher.com

• Relational Database Consultants, Encryption Wizard for Oracle, www.relationalwizards.com

• RSA Security, BSafe, www.rsasecurity.com

• Vormetric, CoreGuard Core Security System, www.vormetric.com