Blog

Database Encryption Misconceptions

By Adrian Lane

I have not been blogging much this week, as I have been up to my eyeballs in a couple different research projects. But as with any research effort, I always learn a lot and it alters my perceptions and recommendations on the security subjects I cover. Sometimes the revelations are not revelatory at all, but because I misunderstood the vendor solution (d’oh!), or I was unable to keep pace with the continuous advancements across the 125+ vendors I attempt to track. Regardless, I wanted to share a couple observations concerning database encryption I think are worth mentioning.

Misconception #1: Microsoft’s Approach to Database Encryption

I believed Microsoft wanted SQL Server to leverage BitLocker and the associated Encrypted File System (EFS). It seemed to me that their strategy was going to be similar to what IBM does with Vormetic: leveraging a generic file system encryption system to secure both database and generic files on disk. They have lots invested in the OS, so why not? Looking at SQL Server 2008, that really does not seem to be the focus – instead Transparent Database Encryption, performed at the block level, is the preferred method for database encryption. Block level encryption is pretty fast, and as it is applied to all the data files, you cannot accidently miss one and leave data exposed. This option seems more appropriate for compliance, as you are moving key management and encryption policy decisions out of IT and into the database. In practice this may be academic, but it’s easier and offers less room for mistakes. All told, that can be the difference in making an auditor happy.

If you look at the SQL Server portfolio of encryption options, they offer the API level ‘cell encryption’, block level TDE, and BitLocker OS level encryption. Coupled with the DPAPI key manager, this means Microsoft’s approach is closer to Oracle’s, with their corresponding dbms_crypto API, block level Tablespace Transparent Encryption (TTE or TDE depending on your reference), wallet key manager, and column level TDE that provides intra-block protection. It’s not surprising that IBM focuses more on storage, Microsoft more on the OS, and Oracle on the application layer, but Oracle and Microsoft now have more similarities than differences.

Misconception #2: Oracle Key Management

I have been known to lock myself in a server lab for a week or more, testing a product every which way, until I am confident I know how a product works. Blue fingered and frozen, I emerge with knowledge of how a product stands up to its competition and how it solves customer problems. I did this with Oracle 10G encryption a few years ago, and came away with the impression that is was very easy to use, with more than acceptable performance, but storing the keys in the database remains an issue. I seem to remember the keys being stored raw in the systems tables. What shocked me is that I learned that the external key server (what Oracle calls a ‘wallet’), is mandatory, not optional. This means that all the keys stored in the database are encrypted by the master key stored in the wallet. I have absolutely no recollection of that being the case, and while I vividly remember setting up keys, I have no memory of installing, configuring or using a wallet. Maybe I had a beta version – who knows? But I was so shocked by this I asked Rich if he knew about it and he said ‘no’. So if both of us can totally misunderstand this requirement, it’s a fair bet others have as well.

The wallet as a required external key management service is important, as it encrypt the keys used to encrypt / decrypt data within the database. Encryption by a master key external to the database makes it virtually impossible for the DBA to get the keys, as they are not sitting around in cleartext on disk. Accessing the master key is a process between the database and the wallet, where the database must securely authenticate itself before it can be provided the master key it needs to decrypt data encryption keys. The master key is in turn secured in the wallet through RSA’s PKCS #5 v2.0 secure password methodology, so the master key never resides in the clear on disk either. You need to make sure the wallet is properly secured and backed up, but these minor management tasks pale in comparison to the extra key security provided. I am happy to be wrong as this is a really solid security choice on their part.

Misconception #3: Application Level Security

I have been saying for years, rather emphatically, that application level encryption is more secure that database encryption. You have the flexibility of what data to encrypt, external key management, the ability to decouple keys from access controls, certificate verification, and the option to double encrypt for certain types of workflow and policy enforcement. While this came at great expense in development time, you at least had the option to be as secure as you needed to be. With the database vendors offering external key managers or even hardware security modules, key hierarchies, and more flexible application of encryption, the gap has closed. While I still believe that the application level can offer a small degree of added security depending upon how well the implementation is done, it’s now splitting hairs. Compromising key security, undermining the cryptography, gaining access to keys in memory, or any attack is going to be pretty much the same regardless of the solution. The database is no longer really easier to hack, as many of the common ways to subvert the system have since been closed.

Do I still think that application level encryption is a bit better than database level encryption? Yes, but only because of what’s possible, and not because of inherent design issuess with the approaches database vendors took.

No Related Posts
Comments

@JA - I have not worked with the product, nor has the vendor ever approached us for a briefing.  I will reach out to Critotech as I need to brush up on the options available for MySQL and see how they perform and how they impact operations.

@Chris - you raise a really good point with this.  Thanks for the correction as the wallet security can be fine, but if your operational security requires unattended mode for continuity of service, you may have a problem. If the key manager cannot handle unattended mode and requires you to place plain text keys in files, you essentially obliterate the security to meet operational requirements, then you are pretty much shooting yourself in the foot. Attended mode and unattended mode for database encryption, especially TDE, is something we did not cover in the Database Encryption series. There are lots of ways to open up key access for the database;everything from having a trusted user enter the password, USB sticks or dongles, automated negotiation between the database and key server to name a few.

By Adrian Lane


Adrian,

Have you worked with www.critotech.com and their product ezNcrypt - Transparent Data Encryption and Key Storage System for MySQL?  We need to encrypt our candidates data while at rest and are looking for feedback.

Thanks

By J A


Adrian,

No the wallet has always been encrypted in my experience (Oracle 9/10). The scenario I was dealing with was storing the public keys for SSL certificates in the wallet, which meant the Oracle Apache httpd server needed unattended access to the wallet contents. Oracle handled this by putting the wallet’s encryption key in the configuration files. Yes, the contents were PKCS encrypted, but anyone who could read the web server configuration could manipulate the wallet to their heart’s content.

Additionally, Oracle broke several standard OpenSSL encryption operations for the wallet, and I have no idea why. We wanted to perform various standard OpenSSL operations for key import/extraction and format conversion, but the wallet tools simply ignored such operations.

By Chris Pepper


@reppep - you may be right in that I am giving them too much credit.  I am fairly certain what I saw in 10G TDE was unencrypted keys in the database, and I have heard from more than one person that earlier version of the wallet were nothing more than a flat file with an unencrypted key as well.  In this case you would be better off having the keys in the database as at least they would be harder to find and protected by database infrastructure.  The current specification for the wallet is RSA’s PKCS #5: I am giving them the benefit of the doubt on this one as PKCS is not a particularly difficult standard to implement. It is possible given their track record with password encryption foibles and revisions of the wallet that they could have botched the implementation.

@HM - when you say ‘full disk’, do you means disk drive, or implemented at the OS/File system level?

By Adrian Lane


Do you guys have thoughts on using Full Disk Encryption and bypassing application encryption altogether?

By HM


> Encryption by a master key external to the database makes it virtually impossible for the DBA to get the keys, as they are not sitting around in cleartext on disk.

Adrian,

I think you’re giving Oracle too much credit here. Last time I saw an Oracle Application Server configuration, the wallet password was in plaintext in `httpd.conf` or equivalent.

I remember Oracle coming to campus to explain how we should spend tens of thousands of dollars (on top of our existing site license) for their bulletproof column/table encryption. I asked how they secured the wallet, or if it was still fully accessible using a plaintext password in a text configuration file, and was assured it *couldn’t* be that weak. The rep making the crypto presentation promised to get back to me with an explanation, but still hadn’t a couple years later when I left that job.

By reppep


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.