The Emperor’s New Cryptosystem:

How Transparent Data Encryption Doesn’t Really Do Anything

Jacob Ansari, CISSP, MSIA, QSA, PA-QSA

403 Labs, LLC

403 Labs, LLC

• Full-service information security and compliance consulting firm headquartered in Milwaukee with additional offices in Chicago and San Francisco

• Experts in the Payment Card Industry (PCI)– PCI Forensics Investigator (PFI)– Qualified Security Assessor (QSA)– Payment Application Qualified Security Assessor (PA-QSA)– Approved Scanning Vendor (ASV)

• Penetration testing, including web applications• Experienced in handling computer forensic

investigations

What we’re trying to do here

• Define our terms clearly• Figure out the root of the problem• Discuss some solutions

Defining our terms: TDE

• The application doesn’t do the crypto, some other underlying piece does:– Database– Disk or database instance– Hardware crypto device

What do we want crypto to do?

• Protect data from unauthorized access• Control continues to work even when other

security controls fail– Otherwise what’s the point of encrypting?

Why is TDE a good idea?

• Implementing a good cryptosystem is hard– Computationally intensive

• Hardware devices will do this work for you

– Labor intensive• Even using a good API takes time and effort

Why is TDE a good idea?

• Implementing a good cryptosystem is hard– Software implementation has a variety of

challenges• Not just AES vs. 3DES • Select the right mode (e.g., CBC vs. ECB)• Figure out things like IVs, salts, etc.

Why is TDE a good idea?

• Implementing a good cryptosystem is hard– Key management is tricky

• Generating keys• Data-encrypting keys vs. key-encrypting keys• Key storage• Key rotation

– This is 98% of the compliance headache

Why is TDE a good idea?

• Use an existing or specialized tool– Why write a crypto scheme if the database

will do it for you natively?– Sometimes using something like this is the

only way to fit it on to a legacy application• Old hardware or software• Doesn’t support a good cryptographic routine• Need to get it done before the polar ice caps melt

How does this usually work?

• Native database encryption:– Enable TDE at the database column level– Establish key values and properties– INSERT and SELECT statements, for

example, then encrypt and decrypt automatically

– Current versions of MS SQL Server and Oracle do this

How does this usually work?

How does this usually work?

• Disk/database instance encryption– Encryption occurs at the file system or

database instance level– Mounting the disk or opening the database

requires a decrypt action– Decrypted while in operation

• Either in part or entirely

– Oracle Wallet, EFS, TrueCrypt do this

How does this usually work?

• Hardware device– Sits in front of the database and intercepts

database queries– Encrypts and decrypts and passes back and

forth between the database and the initiator of the query

– SafeNet (formerly Ingrian) and Vormetric make these devices

How does this usually work?

So what’s the problem?

• Disk or database instance encryption– Decrypted while the file system or database is

in use– Can technically meet compliance

requirements– Nice for laptops that go missing; less useful

for servers• Once decrypted, the system doesn’t distinguish

between legitimate and illegitimate use

So what’s the problem?

• Hardware or native column-level encryption– Encrypts or decrypts at the behest of the

database user making the query– If the database user has the right to decrypt,

then the application that makes the query using that credential has the right to decrypt.

So what’s the problem?

• Many applications make use of a single database user account

• Thus the ability to decrypt is controlled by the application’s access controls– If that control fails, the crypto fails with it

How would an attack work?

• Web application– An attack using SQL injection would query as

the user who can decrypt• Making database queries defeats the cryptosystem• What good is the expensive crypto toy?

How would an attack work?

• The application likely has some users who have decrypt privilege– Attack their credentials– Attack their sessions

• Some crappy web app password is the key to the database

Attacks Part Deux

• Client software– Probably a connection string embedded in the

client somewhere• Sometimes it’s in the web content

– Just found credentials in ASP pages two weeks ago

• Sometimes it’s compiled or encoded– Get the client and dig it out with OllyDbg or the like– For .NET applications, ILDASM makes this really easy

Attacks Part Deux

• This actually happened!• Database used views to distinguish

between clear and ciphertext• Just select from the decrypted view:

SELECT * from CARD_DATA_ENC ->

SELECT * from CARD_DATA

Common Thread

• Anyone (from the database’s view) can call the decrypt routines

• Users, by consequence, have too many privileges

• Encryption doesn’t hold up when other controls fail

The Root of the Problem

• Access control– Often endemic to application architecture

• Maps many application accounts onto one database account with no difference in database-level permissions

– Not really fixed by dropping in some crypto module or device

• Kind of like using SSL on a web server running Apache 1.3.33

So how do we fix this?

• Do crypto at the application layer– Pros: Database just sees ciphertext– Cons: Do crypto at the application layer

• Key management• Implement the cryptosystem yourself

– Verdict: Not really a terrible idea outright. Just not the right solution for everyone

So how do we fix this?

• Map each application user to an individual database user account– Pro: Can manage database-level access at a

very granular level– Cons: Everything else

• Nightmare to manage• May cause non-compliance with PCI DSS

– Verdict: Not a chance

So how do we fix this?

So how do we fix this?

• Map application users to a small set of role accounts– Pros: Gives some useful granularity to the

database, not impossible to manage– Cons: Maybe requires some major application

re-architecture– Verdict: Let’s explore this some more

Database Role Accounts

• What roles make the most sense?– Write/Encrypt– Read/Decrypt– Read/No Decrypt

Database Role Accounts

• Write/Encrypt– Insert records into the database that get

encrypted along the way– Call the encrypt routine– Quite possibly granted to low-level users or a

large percentage of the user population– Potential weakness: expose symmetric keys

during the encrypt routine

Database Role Accounts

• Read/No Decrypt– Can SELECT or read records from the

database– Does not call the decryption routine– Granted to most application users– Potential weaknesses: Probably not much

Database Role Accounts

• Read/Decrypt– Can SELECT or read records from the

database– Does call decrypt routine– Granted to privileged users, admins– Potential weaknesses: ATTACK

APPLICATION HERE• Smaller attack surface than before

What this entails

• The application has to support these kinds of roles

• Application needs to map application users onto these database roles

• Granting the same application user too many database roles breaks this

What this entails

• Need to think clearly about what users need to do within the application– Easy to grant too many permissions– Easy to get lazy about who should have

access to what

• Who needs to decrypt and why?– Who needs to encrypt?

Variations on the theme

• Separate schema instead of roles:– Important data – Other data

• Each schema has its own user• Grant application users access to the

important data schema based on their role– Reduced attack surface

What this entails

• Possibly requires a major database re-architecture– Cranky DBAs

• Application use cases need to make sense– If everyone can encrypt and everyone gets

access to the important data schema this fails

Some other considerations

• Don’t embed credentials in something hard-coded– For MS SQL databases, you probably want to

use Windows authentication instead of mixed mode

– Oracle databases support a client-side credential store with Oracle Wallet

Some other considerations

• Be careful of who can query the database directly– Don’t expose the database port to the Internet

• For that matter, don’t expose it to anything other than the proper front-end system

• Maybe rethink databases exposed internally to your user population

Some other considerations

• Good key management practices– Still need to rotate keys on hardware devices

• Key rotation with a big data set is a chore; plan for this

• Stupid passwords and unencrypted management interfaces still matter– Default users are still a problem– Default services like HTTP are still a problem

Some other considerations

• Hardware devices come with default role accounts– Stupid user accounts like:

• Admin• Key manager

• Just because it’s a security device doesn’t mean it’s secure

Wrapping things up

• TDE isn’t hopelessly broken– Has value; can’t stand alone

• Security in layers and all that advice from 2001

• Not a silver bullet– Just like everything else

• Legacy apps pose serious challenges– TDE might not be able to fix them

In conclusion

• Many thanks!• Questions?

Jacob Ansari

jansari[at]403labs[dot]com

877-403-LABS