Whoa. Never would I have thought that a HSM allowed key exports.
I somehow assumed that real, non-toy HSMs involved dedicated generators as companion devices with
heavily reduced attack surface, which generate and store private key material, are able to transfer it to the HSM proper (and to a paper backup), and are strictly kept offline after that.
From #Rationale (concerning the backup option that most commercial HSMs allow):
>> I do am of the opinion that HSM's should not offer this option (getting access to the private key).
It boils down to your opinion then. Within the industry "HSM" is pretty much synonimous of compliance to FIPS 140, which allows key extraction even at its highest level (Level 4), provided that the risk is mitigated appropriately (E.g. by means of a split secret policy and more in general by means of all the security measures that go beyond the technologic ones provided by the HSM itself).
You are free to keep your opinion but the statement that such possibility "still beats the purpose of the HSM though" is not shared by many people.
Also (again concerning the backups):
>> Since it requires so many steps and so much access, I don't think this is a huge risk, but a rather nice convinience.
No, it is not a convenience. It is a manner to mitigate the risk of denial of service one may cause by purposedly destroying or stealing your HSM.
>> I've seen multiple big-name HSM's where their support was able to decrypt the key and transfer it to another HSM model, but since I've signed an NDA I cannot tell which ones that were.
I challenge this statement: I deal with most big-name HSMs (and there are not that many) and none of them can do this.
I do know because that is a risk we explicitly check for when evaluating one.
In certain cases you may manipulate their API to extract some keys if they were generated internally in a certain way, but that is a known, public problem in the industry.
What surprises me is that you can extract the private key at all - I would expect it to be firmly inside a HSM, that only accepts signing requests and the key never leaves the module & the HSM wipes the key if it detects tampering (there is usually a battery inside to power the tampering detection even if the device is not plugged in).
So just exporting the private key so easily without some pretty involved hight-tech HSM key extraction sounds insane.
You can get the keys off of a HSM with a scanning tunneling electron microscope, a lot of time, and some electronics engineers depending on the type of hardware. It is possible, but unbelievably more difficult.
If the get the server with the hsm in it via a NSL, game over. That being said, it is impossible for a hack to get the private keys, so this is still a massive win.
> the keypair corresponding to the private key is likely to be revoked/discarded.
That's precisely it! Publishing a private key -- anyone's -- invalidates the security of the private-public key pair, making it worthless as security.
There's going to be some consequence to this, such as the third party "changing the locks" and locking out you, or your users.
Similarly, it might allow hackers to intercept the comms, break into your code, or whatever.
The essential, fundamental point I'm trying to get across here is that it never ever makes sense to publish a private key, and then rely on it for any purpose.
Yeah, that simply won’t happen with keys in HSMs, where private keys reside more and more frequently nowadays, as they should for security reasons. They are specifically designed to make it impossible for the key to leak. In Europe for example, this is a prerequisite for signatures with legal value.
The PKCS#11 standard, which is implemented by most HSMs defines two attributes that control this:
- Marking a key as “sensitive” means that the raw key material cannot be exported, except in encrypted (“wrapped”) form. Such an encrypted key can then be unwrapped to install it on another HSM. This key-wrapping facility is largely to allow backup or replication (but see below).
- Marking a key as “non-extractable” also means that it cannot be exported even in encrypted/wrapped form.
You generally configure a policy on the HSM to say that all private keys must be sensitive etc. It is pretty common (in my experience, dealing with banks primarily) to enable a policy that enforces all private keys to be sensitive and non-extractable. Proprietary mechanisms are then used to replication and backup of those keys (that effectively ignore those attributes/work at a lower level).
That is a TERRIBLE idea, if foo can be compromised. Even if you secure the private key with a passphrase, it still needs to be loaded into foo's memory, by a binary resident on foo, which can be used to exfiltrate that private key.
If you're confident foo cannot be compromised, then the whole point is moot anyway.
> You can't actually "prevent the private key from being disclosed even if the user wants to export it" out of box on Windows [if you have an HSM this may be an option although it may also make the keys unsuitable for some purposes].
All modern laptops ship with TPM that basically allows provisioning private keys in an non exportable way. Additionally server can remotely attest that the key is stored in the TPM. (your HSM remark probably covers this though)
There is some security concerns with exporting the ephemeral private key material over a network connection. Technically there is nothing that makes this impossible, but from a policy perspective it may be a nonstarter.
Looks like the private key can be leaked regardless of the use of a passphrase, but you'd get the encrypted form that would need to be cracked offline.
As I understand it, it should be impossible to export a private key from an HSM.
I'm not very familiar with HSMs though, so I might be wrong about this.
reply