Protecting database encryption key

srunkel

My question sounds simple but I haven't been able to find a good answer in various articles on security. I need to store Social Security numbers (and other sensitive data) in mySQL using PHP. I plan to encrypt them using some form of symmetric encryption, such as AES.

The question is: how/where do I store the encryption key? If someone can get ahold of my database or otherwise compromise security, it seems like they would easily be able to get the key just by accessing it in the same way my PHP files access it.

Am I missing something? Is there some location on the server combined with some PHP techniques whereby the key can be kept out of the hands of someone who is sophisticated enough and determined enough to grab the database records themselves? It seems completely pointless to encrypt data if the encryption key can be found.

Using Linux.

MarkR

It sounds to me like you're doing everything at the wrong level. Storing data encrypted in the database is pointless and complicated. You'll break many things in the DB by doing so.

If you want to defend against physical attackers, use an encrypted fs and put the database on there - but be prepared to enter the key manually at bootup (ideally on the console) if you want decent defence.

If you want to defend against external would-be attackers, simply don't allow your machine to be compromised and write your application securely.

If you want to defend against people intercepting communications, use HTTPS.

Mark

srunkel

Thanks very much for the reply.

MarkR wrote:
It sounds to me like you're doing everything at the wrong level. Storing data encrypted in the database is pointless and complicated. You'll break many things in the DB by doing so.

You lost me already. It seems generally agreed that really sensitive data should be encrypted in the DB. Nor does it seem that hard. What would it break? Perhaps I'm just too naive to see what you're saying without more info. I can't imagine a large organization like a bank, amazon, etc., not encrypting SSNs or credit card numbers. We're not that size but the data is still valuable for identity theft.

If you want to defend against physical attackers, use an encrypted fs and put the database on there - but be prepared to enter the key manually at bootup (ideally on the console) if you want decent defence.

Do you mean literally a person bodily entering the office and sitting down at the machine? The server is hosted somewhere else, not by me. It's on a virtual private server, possibly moving to a managed private server, at a large hosting company. Perhap this itself is a mistake?

If you want to defend against external would-be attackers, simply don't allow your machine to be compromised and write your application securely.

If you want to defend against people intercepting communications, use HTTPS.

Everything is behind HTTPS. It sounds like what you're getting at is: if the server is secure enough in various ways, then there's no need to encrypt any data since nobody will get at it. But it feels like clients would want to hear, "we encrypt SSNs and other sensitive data." Also since the machine itself is hosted elsewhere, I can't do much to protect against people getting in via means that are outside of my control.

I've seen various forum discussions of encrypting sensitive data, it seems wise regardless of all other measures.

-Scott

MarkR

srunkel wrote:
Thanks very much for the reply.
You lost me already. It seems generally agreed that really sensitive data should be encrypted in the DB.

I can't see why. You're proposing encrypting it in a fashion which will not improve security; someone who compromises the machine can get the data anyway, encryption or no encryption.

Encrypting data in the database will break indexing (and possibly some other things on character data, such as case-sensitivity). Your collation / sort order data will make no sense on a column which is encrypted at the application level.

It might seem reasonable that the database had some built-in encryption - this would definitely be an improvement. But I am not aware that they typically do.

Storing the entire database on an encrypted fs would seem like the way to go; it will encrypt the entire database and be entirely transparent to the app, allowing the database to be used as it if wasn't encrypted.

I can't imagine a large organization like a bank, amazon, etc., not encrypting SSNs or credit card numbers. We're not that size but the data is still valuable for identity theft.

At some level, you must trust that the system won't be compromised. If a system which collects these data is compromised, an attacker can modify the code to store plaintext copies of the data in any case. If the key is stored locally, they can simply decrypt all the existing data.

Do you mean literally a person bodily entering the office and sitting down at the machine?

Yes. Because this is one way you can avoid having the encryption key stored (permanently) on the server. But it's inconvenient.

The server is hosted somewhere else, not by me. It's on a virtual private server, possibly moving to a managed private server, at a large hosting company. Perhap this itself is a mistake?

I should think so. A dedicated server would seem like a much safer option. What virtual server technology is it using? Some are not as good as people seem to think.

OS virtualisation is mostly safe (although there can still be bugs which allow administrators of other VMs to see your data). Other types of virtual server - like these kludgy nasty Linux "virtual" server hacks that various control panels provide - are NOT at all safe against obtaining data from other VS.

It sounds like what you're getting at is: if the server is secure enough in various ways, then there's no need to encrypt any data since nobody will get at it.

Yes.

But it feels like clients would want to hear, "we encrypt SSNs and other sensitive data." Also since the machine itself is hosted elsewhere, I can't do much to protect against people getting in via means that are outside of my control.

You can host it on a dedicated server which is kept at a datacentre who you trust not to allow unauthorised people physical access.

Mark