On a recent flight, I was sat next to a security auditor. He asked “can someone steal keys used to encrypt credit cards from the server memory?” It depends, was my reply. But his question left me wondering. Why hasn’t anyone built a server side white box implementation?

Why does it depend?
Like any implementation, some are more secure than others. If the server side code was using ‘standard cryptographic APIs’ and they were black box implementations then unfortunately, the answer would be yes, the keys could be stolen. Admittedly, it would require a sufficiently skilled hacker or corrupt administrator to view the memory. But it is possible for the keys to be stolen.

Luckily, most organizations use a ‘Hardware Security Module’ (HSM). The HSM is often called the anchor of trust. It generates, stores, and protects cryptographic keys. It offers protection in the form of strong authentication and physical tamper resistance in a locked down piece of hardware. However, HSMs also have a weakness – they have to ‘trust’ the calling application. An attacker can ‘sock puppet’ the HSM library to get it to decrypt content, even though it keeps the actual key safe.

What happens in the cloud?
With promises of greater flexibility and lower costs, the move to cloud services shows no signs of stopping. Although there are cloud enabled HSMs available, this solution isn’t ideally suited for the cloud. HSMs run over the network which adds substantial performance overhead. They’re expensive and rely on physical admin keys. More importantly, ‘trusting’ the calling cloud server is risky on shared cloud hosting as the number of machines is larger and management is complex. Assuming the server is secure is a weakness. If a hacker were to gain control of the cloud server, they can simply ask the HSM to decrypt the protected data and it will. No questions asked.

What’s the case for white box?
With white box, the keys to access the HSM or to decrypt the data would be blended into the application itself. The keys are only unlocked when running inside the application. If integrity verification doesn’t match, the application is unable to unlock the white box and the keys are not usable.

White box techniques would protect against keys being stolen from memory, as per the auditors original question, and would prevent a hacker gaining control using the cloud server to access data. It would also prevent sock puppeting the application to decrypt data.

It would seem to be an enhancement to the security. But, is anyone interested in such a solution? So far most people seem to trust their cloud providers. If that changes maybe you should let us know.