Hardware Security Modules (HSMs) are physical devices attached or embedded in another computer to handle various cryptographic functions. HSMs are supposed to provide both physical and logical protection of the cryptographic material stored on the HSM while handling cryptographic functions for the computer to which they are attached.
As websites move to the cloud, are HSMs the right way to achieve our goals?
Before we talk about goals, it is useful to consider a basic model for talking about them. Our Safety team often uses the following model to consider whether a system is safe:
- What are the goals we are trying to achieve? (Or, in Leveson’s STPA hazard-oriented view, what are the accidents/losses which you wish to prevent?)
- What are the adversaries we wish to defeat?
- What are the powers available to those adversaries? What *moves* are available to them?
- And finally, what controls inhibit adversaries’ use of their powers, thus protecting our goals?
Our hazards (or unacceptable losses) are:
- An adversary can operate a webserver that pretends to be ours;
- An adversary can decrypt SSL traffic; and
- An adversary can conduct a man-in-the-middle attack on our SSL website.
In the protection of SSL certificates in the cloud, it would seem that our goals are two-fold:
- Keep the private key *secret* from third parties; and
- Prevent unauthorized and undetected use of the key in cryptographic functions. While SSL certificate revocation is a weak control (many browsers do not check for revocation), it is that which generally constrains this goal to both unauthorized *and* undetected; a detected adversary can be dealt with through revocation.
I could argue that the first is a special case of the second, except that I want to distinguish between “cryptographic functions over the valid lifetime of the certificate” and “cryptographic functions after the certificate is supposed to be gone.”
As an aside, I could also argue that these goals are insufficient; after all, except for doing man in the middle attacks, *any* SSL certificate signed by any of the many certificate authorities in the browser store would enable an adversary to cause the first of the losses. HSMs don’t really help with that problem.
Given that caveat, what are the interesting adversaries? I propose four “interesting” adversaries, mostly defined by their powers:
- The adversary who has remotely compromised a server;
- The adversary who has taken physical control of a server which is still online;
- The adversary who has taken physical control of a server at end of life; and
- The adversary who has been given administrative access to a system.
The moves available to these adversaries are clear:
- Copy key material (anyone with administrative access);
- Change which key material or SSL configuration we’ll use (thus downgrading the integrity of legitimate connections)
- Escalate privileges to administrative access (anyone with physical or remote access); and
- Make API calls to execute cryptographic functions (anyone with administrative access).
What controls will affect these adversaries?
- Use of an HSM will inhibit the copying of keying material;
- Use of revocation will reduce the exposure of copied keying material;
- System-integrated physical security (systems that evaluate their own cameras and cabinets, for instance) inhibit escalation from physical access to administrative access;
- Auditing systems inhibits adversary privilege escalation;
- Encrypting keying material, and only providing decrypted versions to audited, online systems inhibits adversaries with physical control of systems.
What I find interesting is that for systems outside the physical purview of a company, HSMs may have a subtle flaw: since HSMs must provide an API to be of use, *that API remains exposed to an adversary who has taken possession of an HSM*. This may be a minor issue if an HSM is in a server in a “secure” facility, it becomes significant in distributed data centers. On the contrary, the control system which includes tightly coupled local physical security, auditing, and software encryption may strike a different balance: slightly less stringent security against an adversary who can gain administrative access (after all, they can likely copy the keys), in exchange for greater security against adversaries who have physical access.
This isn’t to say that this is the only way to assemble a control system to protect SSL keys; merely that a reflexive jump to an HSM-based solution may not actually meet the security goals that many companies might have.
(Full disclosure: I’m the primary inventor of Akamai’s SSL content delivery network, which has incorporated software-based key management for over a decade.)