8

This post on Securing Java Application Data for Cloud Computing offers a good introduction to using a Java KeyStore for securing encrypted data in the cloud. It neglects, however, to answer the fundamental question, as noted in one of the comments: how would you protect the keystore password on the cloud?

We are designing a SAAS web application in the AWS public cloud, which will have many end users (scaling to millions). All user data will be encrypted on a per-user basis with standard encryption. The password-protected encryption keys will be stored on a remote secure keyserver, which requires an API secret key to access. This has essentially the same problem noted in the question above, with the keyserver API secret key being directly comparable to the keystore password: how would you protect the keyserver API secret key on the cloud?

Note that our web application needs access to this secret key so that it can obtain per-user keys for encrypting and decrypting the user data. We are using AES-256 symmetric encryption, but the fundamental problem remains even for a PKI solution, as you still need to secure the private key. Note also that we could use a keystore instead of a remote keyserver, but this just reduces to the previous question and again the fundamental problem remains.

Some further constraints:

  • Storing the secret on the remote secure keyserver is impossible, obviously, since it is used to access that keyserver.
  • Storing the secret on the cloud filesystem is insecure, since the main point is to keep the secret from being accessible to anyone who breaches the cloud filesystem. (If the cloud filesystem were perfectly secure, we would not need to encrypt the data there.) Also, given that cloud resources are expected go down and need restarting, relying on the cloud to hold the secret is unreliable.
  • Storing the secret in the code is unacceptable, for many reasons including: version control, plain-text storage, reverse engineering, key rotation, etc. See also Should a closed source website keep a secret key in its source?.
  • Storing the secret in an HSM is impractical, since we cannot attach one to a virtual cloud server. See also Storage of 'secrets', keystores, HSMs and the rest.
  • Storing the secret outside the cloud for remote loading by the application is also problematic: we are looking for a purely cloud-based approach to avoid having any internal servers to maintain; network reliability is not guaranteed; authenticating the cloud server's request for secret on the internal server has its own issues; etc.
  • Any manual interaction should be minimized, since we want servers to start and restart as automatically as possible to reduce any downtime or human errors. My guess is that manual interaction may be necessary.

So, what is the best practice for storing a secret on the cloud? How should a web app load such a secret? I would be particularly interested in a Java solution, but this is a general problem in any language.

Improve this question
2
  • Here is one approach we are considering: creating a limited user interface for manually entering the secret when the application starts. This would be a one-time initialization, possibly holding the secret in memory as a private field of a Singleton. I have not tried this approach in the past. Is this a viable approach? Are there any concerns with such an approach? Does anyone have examples of how to do this in a web app (as opposed to a command-line interface)?
    – Richard
    Commented Mar 13, 2013 at 19:57
  • AWS recently announced a CloudHSM service that mostly negates my 4th bullet above, which may address some of our key storage issues. I am currently exploring this as a part of the solution. For reference, here are links to some information: techcrunch.com/2013/03/26/… aws.amazon.com/about-aws/whats-new/2013/03/26/… aws.amazon.com/documentation/cloudhsm docs.aws.amazon.com/cloudhsm/latest/gsg/…
    – Richard
    Commented Apr 11, 2013 at 20:42

1 Answer 1

Reset to default
5

"In the Cloud" means "on a virtual machine which runs on the infrastructure of some big company with which we have a contractual relation". By definition, when you store things "in the cloud", you are trusting the cloud provider. That provider has all the technical power to look at the fine details of the entrails of your code and data and everything you store on these machines.

It's like trying to maintain the integrity of your body, when you are already on the operation table, under general anesthesia, and the surgeon has his scalpel in hand. It's a bit late to mistrust the surgeon...

If the secret is valuable, then don't store it in the cloud. Said otherwise: if you cannot afford the extra cost of a dedicated hardware server, then the secret data cannot be worth that much -- or possibly you are way too much avaricious for your own good.

Improve this answer
5
  • Thomas, I understand some amount of trust is given over to the cloud provider. But due to regulatory and business concerns for our application (HIPAA and business agreements with other parties), keeping keys in storage on the cloud filesystem is not permitted. Different localities and industries have different restrictions, so simply trusting the cloud provider with keys is not always sufficient, which is why we are using a remote key server. This reduces the number of keys we need to manage from the cloud, and hence reduces the threat target area, but cannot eliminate the fundamental problem.
    – Richard
    Commented Mar 13, 2013 at 20:06
  • 1
    Yes, indeed, it does not eliminate the fundamental problem. And that problem is that, by definition and in unavoidable way, cloud-based computing trusts the cloud provider with the data. All you can do with elaborate games with keys and encryption is dance around the issue.
    – Thomas Pornin
    Commented Mar 13, 2013 at 20:09
  • @user2141042 If the concerns are regulatory in nature, you can find cloud providers that can provide environments that are HIPPA/PCI/Whatever-you-need certified.
    – Xander
    Commented Mar 13, 2013 at 20:26
  • @Xander, yes, and I am in fact using one of the cloud providers that supports HIPAA compliance, but that still comes down to my responsibility to protect the API key. The only advice from that provider I have received is, "you should treat it like any secret maintained by the app, e.g. database passwords." Except for the constraints mentioned above!
    – Richard
    Commented Mar 14, 2013 at 20:57
  • This fundamental problem is a major barrier to adopting cloud technologies in regulated industries, especially with reluctant business partners. I understand that there might not be a good or clear solution. I was mainly hoping to check that I had not missed anything obvious that could be counted as a best practice. Currently, I am still leaning toward the approach of creating a limited user interface for manually entering the secret when the application starts. Although awkward from an automation standpoint, it at least minimizes the exposure of the secret. I wish I could do better. Thanks.
    – Richard
    Commented Mar 14, 2013 at 21:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .