In terms of infrastructure, how do Cloud providers (organizations providing SaaS, PaaS, or IaaS via the cloud) manage keys and cryptography?

From my understanding, "private" datacenters tend to manage and offload cryptography with dedicated hardware appliances (such as HSMs, ADCs, or SSL accelerators). In that case, asymmetric keys are managed directly on this dedicated hardware.

For a cloud provider that may have more than one datacenter and deals with many distinct and dynamic customers I find it difficult to see how it is possible to use dedicated hardware based solutions to manage and generate customers' keys.

My questions: are dedicated security appliances implementable in a cloud datacenter? How are keys typically managed and where are they generally stored?


Some HSM (I am more used to those from nCipher) allow cloud-like operation: several HSM may share the same "security world", which means that they see the same private keys, which they exchange with each other through encrypted tunnels. Storage itself is not, physically, in the HSM; it is external but encrypted with keys which are kept within the HSM (the complete setup involves several types of smartcards and it is a bit more complex than that, but you get the idea).

  • Thanks Thomas. Seems complicated to put into practise but a solution nonetheless. – Louis Mar 14 '11 at 15:48

Azure has a mechanism that securely downloads the private keys into each deployed VM with the private key being non-exportable. Here is a whitepaper that describes the process in section



How you can install certificates into Azure


  • This is a great overview of how Azure does it, but the problem with this is that these certificates can only be added during deployment. You cannot add or remove them in a production system. – Steve May 11 '11 at 15:32
  • It doesn't look like anything is done to prevent VMs from snooping one each other vie e.g. cache miss measurement. The VM isolation chapter doesn't even mention the issue. Pretty frightening... – Bruno Rohée May 11 '11 at 16:53
  • 1
    @Bruno can you elaborate on that? – Steve May 11 '11 at 20:10
  • All the attacks where processes snoop on each other using things such as cache miss to e.g. deduce the private part of a RSA key after another process performed a crypto operation apply to virtual machines on commodity hardware. Short of externalizing all crypto to snooping proof hardware crypto mostly can't be made safe on the cloud. See e.g. the seminal paper daemonology.net/hyperthreading-considered-harmful and daemonology.net/papers/htt.pdf for examples of the issue. Current commodity hardware just can't permit to isolate VMs enough to make such attacks impossible. – Bruno Rohée May 12 '11 at 0:45
  • However such attacks can be made pretty hard, algorithms implementation can be designed that expose little if any information, and you could trade performance for security at the hypervisor level by e.g. aggressively invalidating cache when context switching to one VM to the other, but basically commodity hardware makes it impossible to perfectly isolate VMs from each other, making many side channels attacks practical. A downside to virtualization solutions that vendors aren't too happy discussing... – Bruno Rohée May 12 '11 at 0:52

Amazon now support the use of SafeNet HSMs with CloudHSM.
Microsoft Azure supports the use of Thales HSMs: Thales, Microsoft serve secure crypto in the cloud.

I doubt it's yet possible to describe "typical" usage, key management, or storage, the details will vary with both cloud provider and HSM vendor.

The Azure "Bring Your Own Key" concept does allow you to use keys generated on your own HSM, but you almost certainly still have to trust your cloud provider to manage the HSMs correctly.

(HSMs are designed to be extremely difficult for an unauthorized person to extract keys from, but allowing HSMs to share keys for failover and scalability means sharing secrets between them, and that has to be done in a trusted fashion. In the case of the nCipher (now Thales) HSMs that @thomas-pornin mentions, if an attacker gets uncontrolled access to a quorum of the Administrator smartcards used to add an HSM to a Security World, they can effectively extract keys from that World. In the SafeNet case, similar considerations apply to a Luna PED. Unless the cloud provider allows you direct access to "your" HSM in the datacentre, you have to trust their initial setup. Once secrets are established with the HSMs, then secure authenticated communication with them is possible.)

Edit, some years later: Amazon's CloudHSM now uses their own hardware, the SafeNet (now Gemalto) HSMs are now "CloudHSM Classic", which is going to be phased out because the Luna 5 HSMs are End Of Life AWS CloudHSM Classic FAQs.

Thales and Gemalto are merging, but the former nCipher HSM business is being sold to Entrust Datacard. Thales to sell GP HSM business.

Microsoft Azure now offers dedicated HSMs What is Azure Dedicated HSM?.


This IEEE article from yesterday points out many providers see security as the users' problem http://spectrum.ieee.org/riskfactor/telecom/internet/your-security-not-our-problem-say-cloud-providers?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+IeeeSpectrum+(IEEE+Spectrum) . I would suggest avoiding assumptions about the very opaque cloud and instead get specifics from your provider before contracting for service.

  • Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Scott Pack Oct 31 '12 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.