4

Roughly speaking HSM is supposed to ingest or generate some secret material (key) and then never export them through the command interface. The keys can only be used according to their configured policy. In order to make sure the keys are really non-exportable, HSM hardware is designed to be tamper-resistant and resist physical key extraction attempts.

Clearly, tamper-resistance is required to protect the raw key material from a physical attacker. However, I am considering what actual security advantage is gained by doing so. Assume that physical tamper-resistance measures are perfect. Then there are roughly two classes of attackers:

  1. Remote attackers who can only talk to the HSM through the command interface. Here, physical security is unimportant, and the key is protected as long as the firmware refuses to export the key.

  2. Local attackers who have physical access. Then assuming the physical anti-tamper measures are perfect, sure the attacker can no longer export the raw keys. However, the attacker can unplug the application server, plug in their attacking device, and talk to the HSM directly through the command interface and use the keys however they want.

Now, we can certainly configure key-usage policies such as "sign but not decrypt", but since our own application need to use that key too, it follows that any (application-level) useful usage of the said key must be allowed by the policy. Thus, while the attacker is technically prevented from e.g., using the RSA2048 signing key as a P-256 scalar then encrypting data with it, the attacker won't be interested in doing this anyway, no?

It seems like what we really need is delay of access (so transient physical access where the attacker is forced to leave in a short amount of time does not lead to key compromise) and tamper-evidence, and that can be cheaply accomplished by e.g., reinforcing the enclosure and does not require expensive tamper-resistant hardware.

Of course, HSMs are used for a reason. What am I missing?

Improve this question
New contributor
user1641237 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
0

4 Answers 4

Reset to default
5

Even with physical access to the HSM, an attacker cannot just use the keys however they want. This is really the point.

HSMs have different roles (e.g., Security Officer and standard user) and partitions. Each user must authenticate towards the HSM and is then restricted to a partition and subject to a policy. For example, they can only use specific keys for specific purposes at a set rate. So even a physical attacker needs the credentials of a legitimate user (which are hopefully well-protected) to gain access, they can only use the keys while they're present (which greatly increases the risk of detection), and the HSM still limits what they can do.

Compare that with simply storing the keys in standard memory: An attacker can create a perfect copy of the keys and use them offline whenever and however they want.

Improve this answer
11
  • HSM certainly can be configured to require authentication per use, but these keys are "administrative keys" in a sense. Indeed these admin keys (as well as HSM root keys) are very secure, but I don't care about HSM's keys. I care about my application keys like TLS certificates, which is of course operating unattended. Commented 2 days ago
  • @user1641237: I am talking about your keys. Even if an attacker is standing right in front of the HSM, they cannot simply use your TLS keys (unless you somehow assume that you've badly screwed up the configuration). They need to (1) steal the credentials from the target application to impersonate that application towards the HSM, (2) stay physically present to use the key, (3) not try to trigger any intrusion detection, and (4) accept any limitations enforced by the HSM (like rate limits). Do you not see how much more difficult this is compared to copying the key from some server storage? Commented 2 days ago
  • @user1641237: This seems a bit like the question why we need to protect password hashes in the application backend when attackers can just try out passwords in the frontend. Because an online attack is slow, “loud” and can be stopped at any time once detected. In comparison, if the attacker walks away with the hashes, they have all the time in the world to quietly break them offline. One way to protect the hashes is in fact an HSM. Commented 2 days ago
  • I get that they need to authenticate to the HSM, but won't a separate, cheap $500 box programmed to enforce the limit (over a local network link) do the same? We are talking about Very Expensive (TM) hardware anti-tamper measures here... These features do not matter for any "remote attacker" talking through the command interface. Commented yesterday
  • 1
    @user1641237: Maybe the issue here is the term “tamper-proof”. HSMs aren't just difficult to break into – this could be implemented in all kinds of ways and doesn't require sophisticated hardware. They actively destroy the keys when tampering is detected. Commented yesterday
4

Using a HSM has to be relatively easy, otherwise nobody would bother. Once authenticated to the HSM the client must be able to use the keys to sign, sometimes thousands, if not millions, of transactions per day.

For example, a general purpose Thales Luna Network HSM will allow keys to be used on the back of mTLS and a password. The certificates/private-key for this and the password must be stored on the client, so a compromise of the client would compromise the keys in the HSM.

In this scenario, the misuse of the keys would only be noticed by monitoring the HSM logs.

In essence, HSMs simply ensure your keys can't be extracted, but provide no guarantee that they can't be used - either by legitimate users or otherwise.

So your "attacking device", if it got hold of the credentials from the client, would indeed be able to abuse the HSM. But, your logs would show it. Or, if they completely removed the HSM, the lack of logs would be a giveaway. You're not using HSMs without some form of monitoring are you?

The anti-tamper on the other hand is to ensure that the keys are disabled/deleted if someone does attempt to open the device to somehow extract the keys - however unlikely that may be. It provides confidence that nobody would succeed if they attempted, and also confidence that when powered off (e.g. in transit) that any tampering would be noticed.

These are two different scenarios, which you shouldn't confuse.

Improve this answer
2
  • Okay, but if all we need is tamper-evidence then a cheap $500 server box locked in a metal enclosure over an Ethernet link provides the same functionality... If the attacker can wield angle grinders in the server room to cut the enclosure, then they can surely remove an HSM from the room altogether and use it elsewhere at their leisure, no? If they can't, then all they do is still talk over the command interface. Commented 2 days ago
  • I think my key question is "when physical anti-tampering starts to matter, then the attacker is already in a position to use the HSM as an oracle, so whether the attacker can extract raw keys in addition to using them over an oracle interface doesn't sound like much a difference". Commented 2 days ago
1

HSMs are used for a reason. What am I missing?

Non-repudiation. An assurance that only you can (or did) authenticate with the secret. These are typically useful in legal scenarios and proceedings where a lot of zeros are involved.

https://en.wikipedia.org/wiki/Non-repudiation

Improve this answer
0

Aside from all the other good answers, a properly secure HSM does become unusable if tampered with, which would prevent the usage of any extracted keys (and presumably raise all kinds of alerts).

An HSM doesn't just store the secret keys in the clear on its internal storage. If it did, then extracting that storage would provide access to the keys, and just like you propose in the question, even if it sets off tamper alerts, there'd still be a period of time when they'd be usable. (Even putting aside the question of using them to decrypt already-captured data.) Rather, the HSM has what's called a LMK (Local Master Key) that is usually randomly generated when it's first turned on, and every key that the HSM is protecting is encrypted with that LMK before being stored. When the key needs to be used, the HSM decrypts it in memory, applies it as necessary, and then clears that memory.

If tampering of any kind is detected, the HSM wipes the LMK from its storage. That immediately renders all the other keys useless, since there's no longer any way to decrypt them (or at a minimum, doing so is at least as hard as decrypting the data without the key at all). So even if you were to copy them out, that wouldn't get you anything.

That said, for redundancy, it is possible with all HSMs I've worked with to set them up to use an existing LMK so that they can read existing keys, so if you're able to extract the keys from one HSM and then use them on a different one that has the same LMK, there is an attack avenue there, but it's the same remote access one that you would have had in the first place - you can't just walk off with the extracted keys and be able to use them at your convenience later.

As for the possibility of using physical access to the HSM as an oracle without directly tampering with it, you're not going to be able to do any better with that access then you would in your first scenario of remote command access. Any physical console requires physical key cards in place to do anything sensitive, so you couldn't (for example) load your own export key onto the HSM to export all the keys it has. All you can do, as you point out in the question, is whatever the application normally using the HSM can do. So if it's supposed to be able to decrypt data, then you can "trick" the HSM into decrypting that same data - but that's not a compromise of the keys and doesn't give you any kind of persistent access.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.