How to protect encryption key from server admin?

Question

Scenario

• Data is encrypted inside DB using key that is never stored in the app server or DB server
• Key is entered upon login and is stored via $_COOKIE['key'] variable for persistence (so user doesn't have to enter it every page load)
• Data is decrypted via $_COOKIE['key']
• $_COOKIE['key'] is destroyed upon browser exit

Threat

Rouge server admin snoops on PHP files, finds out key is stored at $_COOKIE['key'] . He injects malicious code like email_me($_COOKIE['key']); . He erase malicious code after gaining the key.

Question

Is there a way to protect yourself from this kind of scenario?

Answer 1

You can make it harder for a server admin to get the key, but they always can.

Let's think about moving the encryption and decryption to the client side. Now, the server won't get the key, so the server admin should not be able to decrypt the data. That's not quite true, because the server admin can manipulate the page JavaScript so that either the key is sent to the server or nothing is encrypted at all.

The only way a client can be certain that a server admin cannot steal their data, is by using a client software that is open source and cannot be changed on-the-fly by an admin. So, web pages and automatically updating apps are out of the question.

Answer 2

If the key itself is a concern, you can use cryptography oracles like Keyvault in Azure that never release the keys contained within but perform cryptography themselves on data sent to them.

Of course an admin would be able to access the data as long as they have access to the cryptography oracle, but not afterwards, and they would never have the key. This helps in some scenarios, that's the whole point of services like Azure Keyvault. Also you don't need to give actual access to the encryption service to all admins.

Another mitigation (a detective control, as opposed to a preventive one) is audit logging both on the IT and application level. When done right, not even admins can hide the fact that they accessed the data, which again can help mitigate some risks and at least may provide non-repudiation.

Yet another thing you could do is proper change management, controlling who has access (especially write access) to your source code. This can get difficult with script languages like PHP, where you can't really sign code, but you can still have good processes for reviewing and releasing code to production.

So in the end, it's probably less of a technical question, there's a great deal you can do in terms of processes.