0

Hardware security modules are tamper-resistant and PKCS11 PIN is required to use keys. if a software application wants to perform some cryptographic functions, it should know the PIN. but the application is running in a non-secure environment and storing PINs in this environments is risky. Isn't there a contradiction between storing keys in a tamper-resistant hardware and storing PIN in a non-secure software environment? How this problem can be solved?

sfallahdoost
  • 47
  • 6
  • 2
    Even if the PIN is compromised the attackers would need to maintain their access to the compromised system to be able to use the HSM and its keys, so while not ideal the HSM still provides an advantage over keeping the keys on the machine itself where attackers could just get away with the keys and use them at will without needing continuous access to the compromised system. –  Jan 19 '15 at 12:47

1 Answers1

1

In many cases, this problem is solved by having the HSM ask for PIN only at Power-up. Thus a human operator must type the PIN to unlock the HSM. If the server is rebooted, or the HSM module is physically stolen, it will require the PIN again to unlock. The server can also be configured to automatically reboot when a compromise is detected, for example by the signal from a IDS, firewall or such.

But the main advantage of HSM is what Andre Daniel says: That the key is "locked in" the HSM, so the whole HSM needs to be stolen, and you would of course notice if there's a missing HSM. But you won't notice if a key is copied.

It's important to design the HSM in such a way that the attacker cannot gain continuous access to the protected resource. Example: If you have a FDE consisting of a disk key, which encrypts sectors, and then the disk key is encrypted by a master key, which is stored in a HSM. This is a INSECURE solution, since a attacker who wants to steal the key can simply ask the HSM to decrypt the disk key, and then copy the disk key. To gain security in such a case, you need to store the disk key on the HSM as well and feed individual sectors for encryption or decryption.

nolandda
  • 103
  • 4
sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33