Storing sensitive data in memory

Question

I have application with needs to have access to some sensitive data(in this case cryptographic keys). At this point I'm storing them in file so they can be read while script is proccessed.

However it's not safe enough according to security standards I have to follow, because if server root account is compromised someone may easily read & copy them.

Typical solution is to mount external memory containg keys, start application, unmount memory and let in run with data cached in ram. Of course since it's PHP it's not possible.

Is there any other solution? At this point my only idea is small side application with will serve keys however I'm not sure how should it work to be safe.

Answer 1

As you know already, no matter what you do, if the key is available to the application, it will certainly be available to malicious code that has gained root access on the server, and most probably to code that has gained access to the UID under which the application runs too. It's just a question of how easy it is.

Buy since your application is not long-running, it sounds like you will have to accept a level of risk beyond that.

Your idea is to use a daemon of some sort which keeps the keys in RAM and can be queried by the application. That works, but you probably already realise that if your application can query it, then malicious code can query it too. If you choose that option anyway, consider using memcached (why reinvent the wheel?).

The only other option I can think of would be to write an Apache module (in C) that loads the secret at system startup time (after which the persistent copy of the secret is unmounted) and a PHP extension (in C) to get the secret from the Apache module that lives in the same process. That assumes you're using PHP as an Apache module, not as an external process. But to me this sounds like overkill, because it is quite complex and it doesn't actually remove the risk.

Have you considered what to do about swap space? You can use mlock or similar (in C) to keep the secret from being written to swap if it's in a confined location, but it would be difficult to protect it in this way once it's been handed over to the PHP interpreter. So you had better run the system without swap.

Consider a design change that will confine the secret to a single location in a long-running daemon (probably not written in PHP) and have the PHP application delegate the cryptographic functions that need access to the secret to this daemon.