Timeline for answer to What advantage do hardware tamper-resistance provide in HSM? by Ja1024
Current License: CC BY-SA 4.0
Post Revisions
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| 21 hours ago | comment | added | Ja1024 | @user1641237: I'm not sure why you keep skipping over the major differences to then claim there are none. Again, with an HSM, the attacker (1) has to physically steal the entire HSM instead of just copying data, (2) also has to obtain credentials for the keys, and (3) is still limited by the HSM's policies. Those are three huge differences compared to your standard-storage-in-a-reinforced-cabin approach. So your claim that there isn't much of a difference is obviously false. | |
| 22 hours ago | comment | added | grawity | @user1641237: I believe the idea is that the attacker doesn't get a persistent oracle capability to use the key, as the firmware running within the tamper-proof hardware requires some form of authentication before it allows the attacker to do so, whether a PIN or password or a smartcard key that the attacker doesn't own (and the tamper-proof property prevents the attacker from bypassing that requirement). | |
| 22 hours ago | comment | added | user1641237 | 3) advanced local attack, where: a. if the hardware is not tamper-proof, then the attacker gets the key; but b. if the hardware is tamper-proof, the attacker hurls the tamper-proof hardware offsite, and gets a persistent oracle capability to use the key... which isn't much a difference. | |
| 22 hours ago | comment | added | user1641237 | "Once a physical attacker has broken into your cabin..." - yeah, I guess my point is by this point, the physical attacker is already capable of hurling the HSM off-site then use it over the command interface. So the raw key is protected, but the attacker get to use it. So it is either 1) pure remote attack, where tamper-proofness doesn't matter and "behind a command interface" is the important part; 2) transient low-grade local attack, where the reinforced cabin is the important part; or ... (continued) | |
| yesterday | comment | added | Ja1024 | @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. | |
| yesterday | comment | added | Ja1024 | @user1641237: Once a physical attacker has broken into your cabin, they can copy the keys and use them offline in any way they want. It doesn't matter what fancy interface or restrictions you've set up, because those can all be bypassed at this point. When an attacker tries to break into an HSM, the keys get zapped. There is no way to bypass the restrictions. | |
| yesterday | comment | added | user1641237 | (So I am very aware of the advantage to keep key away from the application server and only allow usage through a command interface, but I am not getting the point of using Expensive (TM) tamper-proof hardware vs. just a separate $500 server box (implementing the same command interface, but on commodity hardware) locked in a cabin.) | |
| yesterday | comment | added | user1641237 | 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. | |
| 2 days ago | comment | added | Ja1024 | @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. | |
| 2 days ago | comment | added | Ja1024 | @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? | |
| 2 days ago | comment | added | user1641237 | 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. | |
| 2 days ago | history | answered | Ja1024 | CC BY-SA 4.0 |