The Public Cloud, Pigeons and Risk Management — Part 4

The Public Cloud and Key Management

Ian Farquhar, Advisory Technology Consultant for RSA, the Security Division of EMC

I have recently been asked if the research paper about key leakage across VMs running on a hypervisor invalidates the position I advanced in this series of blogs?

No, it doesn’t, although key management is something which deserves far more attention than it gets from the general INFOSEC community, outside of the government COMSEC agencies.  Oh, and by the way, this is a very cool piece of research.

Some general comments I would make, beyond the three remediation methods recommended in the paper itself.

1. This is a side-channel attack, joining many other side-channel attacks.  That statement doesn’t discount the value of this research paper, but highlights the need to properly design key hierarchies (both for asymmetrical and symmetrical keys) properly.  Minimize the use of the highest-value keys, and try to derive session and transient keys.  Ari Juels, one of the paper’s authors, references other side-channel attacks here.
2. Cryptoperiods matter.  The shorter a specific key runs, the harder it is to compromise, and you need to gather a lot of data to mount this attack.  Interesting, Western high grade cryptographic hardware since at least the 80’s has never used the actual key, but derived Traffic Encryption Key from the actual key using a one way function[1], and would update it at a much higher frequency that the cryptoperiod.  This technique would seem to be valuable against these sorts of attacks, although is difficult to deploy in pre-existing protocols.
3. Realize that software techniques around the way the key is processed and stored by the running application can make this attack very difficult to mount (analogous to the countermeasures which appeared after power analysis was developed).  The paper suggests several approaches here, and I would suspect we’ll see some of them appear in hypervisors soon.
4. For some risk profiles, hardware crypto – including HSMs and appliance-based key management appliances – may be the best option.
5. Co-residency matters, as the paper says.  But you need an instrumented VM to mount this attack.  Ensuring that you’re only co-resident with trusted workloads, or workloads which are in a known configuration which aren’t instrumented for this attack, significantly reduces the risk.  Based on the current paper, I see little opportunity you could mount this attack from code running outside of a kernel.
6. Risk evaluation may decide that key management functions are completely unacceptable for public cloud deployment, which is exactly the process this article describes.

Keys are a boundary case: extremely high value, and extremely short.  The nice thing about crypto is that we compress our information risk into the key.  The bad thing is that it makes the key incredibly valuable.  Key management is a fascinating area of study.

Ian Farquhar is an Advisory Technology Consultant for RSA, the Security Division of EMC.  In this role, he advises organizations throughout Australia and New Zealand in areas including information security, cryptography, compliance, privacy and data protection.  Ian also contributes to R&D at RSA in the area of hardware security.  Ian has over 20 years of experience working in the IT security industry.