
Decrypt/Extract NitroKey HSM RSA Private Keys - mrb
https://raymii.org/s/articles/Decrypt_NitroKey_HSM_or_SmartCard-HSM_private_keys.html
======
mdewinter
Author here, do note that device access and access to all previously setup
passwords and PINs is required for this to work. It still beats the purpose of
the HSM though. The article explains this a bit more in the #Rationale
section. Happy to answer questions or comments.

~~~
zimmerfrei
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.

~~~
mdewinter
> 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.

I'm aware of the FIPS standard, therefore I worded the piece as my opinion. I
think it's better to be able to rotate the keys then to restore to the
same/other device. Since extraction might lead to decryption. I do also know
that software-wise that is an inconvinience and in some cases not possible.
Bur still, a device that protects private keys should not give them up. As you
say, my opinion.

> 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.

Stealing should be protected by the tamper-protection, thus causing a wipe of
the device. In that case you might have a bigger problem, someone has access
to your datacenter and racks. In that case a backup is very welcome. (I do
find it a hard problem where the two sides, no backup, a backup, both are
equally important.

> 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.

We've had a situation were two different revisions of the same device were not
able to load a wrapped key. Support flew in and told us they could fix in in a
new firmware in three months, no guarantees. We installed screen recorders and
a keylogger, since they were on our production env (audit logging). They did,
with undocumented commands, export the key from the device in an unencrypted
format and loaded it into the other model so that we could continue our
operation. Reviewing the recording and the logs showed that the commands did
also work on other HSM's we had. I'm still under NDA so I cannot talk about
which brand or model specific.

~~~
jacquesm
> They did, with undocumented commands, export the key from the device in an
> unencrypted format and loaded it into the other model so that we could
> continue our operation.

NDA or not, that company should be put out of business. Essentially they've
backdoored that HSM.

Assuming it is true this is _far_ bigger news than the article you wrote.

------
JoachimSchipper
Note that this is not a vulnerability, per se - it requires the attacker to
already have the keys to the castle (DKEK).

~~~
lorenzhs
The author addresses your comment in the abstract. Being able to ever recover
the keys defeats the purpose of a Hardware Security Module.

