HSM2 security measures

Does your HSM2 track/log security sensitive operations like exporting keys for backup, login to admin interface, etc.

Is login to admin interface protected just by a PIN/password code?

Cannot you do an admin login to NK HSM2 only after authentication by NK PRO2 or at least FIDO2 token? Would not it be more secure? Without such security measures I think NK HSM2 suits only for keeping my workstation private keys (provided I carry HSM2 token together with me all the time when I leave a computer place to prevent key export or reflash) but for keeping a server side keys (like /etc/ssh/ssh_host_ecdsa_key) I would prefer a NK PRO2 over HSM2 though it may look like a paradox at first glance.

I would prefer HSM2 would keep a nonvolatile log for at least the latest 10 operations done with some timestamps with milliseconds, at least tick time counters since last token power on and a shift equal to the latest earlier previous timestamp added after which the operation has been done. Also a random number can be added to each row to make that row unique and protected from a repeatable fake operation by someone else.

It would be nice if at least time stamps and types of actions done would be stored inside the anti tamper smart card somehow which would borrow a space from a few key slots. Textual descriptions for action type ids can be already stored in the USB firmware.

It would allow me to save a snapshot of the earlier HSM2 log to other places and later compare and verify that nobody except me logged into admin interface and tricked something without my knowledge.
It would be difficult to repeat all my actions synchronously to my earlier saved log with a precision by each millisecond.

Actually I think NK PRO2 may be more secure if it does not allow a silent export of the keys.

Nitrokey HSM doesn’t contain a log and won’t do so anytime soon.

None of the Nitrokeys allows silent export of private keys. Only Nitrokey HSM allows encrypted export of private keys. This feature requires the Nitrokey HSM being initialized in a setup allowing exports. If you don’t want exports, don’t enable it during initialization and your are fine.

I did not read the manuals for NK HSM2 yet and not sure of how does authentication to NK HSM2 work.

Does it have any protection from a party having or getting a knowledge of the admin PIN?

Lets imagine that a teleportation and telepathy exists (in addition to side channels like emission from keyboards and other buses). A small portion of so called “targeted individuals” most likely can even confirm that it does actually exist for sure. Most likely some secret agencies even employ telepathists, they can read thoughts and predict events to avoid being noticed during their secret operations, and it is not related to side channel leaks like electromagnetic emission from different information buses in computers. They can reflash BIOS of computers to inject virtualization trojans and backdoors if those injected during manufacturing time are already too old or partially neutralized by open firmwares like Libreboot.

Taking into account above issues (believe in them or not), NK PRO2 is protected much better than NK HSM2 for mentioned use cases: no reflashing allowed even verified by signature (like Yubikey, btw., who knows, may be your master keys already leaked), absolutely non extractable keys inside NK PRO2 at least as it is known to public, though I do not exclude there are backdoors present for extraction if needed for someones like agencies.

To provide the same level of protection NK HSM2 shall require an admin to present his NK PRO2 for authentication and keep at least a few of last operations in its non volatile log marking each event inside a secure smart card difficult for a forgery - combination of:
random number
runtime tick stamp since power on even without a persistent non volatile internal clock, may be displaying it (as a switchable option) as always increasing numbers by adding previous known value as a shift to new one just for a convenience of looking at them by humans.

It is extremely insecure in 2020 to allow access only by PIN code to such a sensitive device like HSM2 especially with a lack of logs even if the PIN is typed on a small 5" virtual touch pad screen attached together with HSM2 only to a standalone very low powered SoC powered only from a battery (which is hard to scan via electromagnetic channel).

Also modern HSMs often offer support for RSA 8192 which would be welcome too.
The keys could be generated outside of the token in a box protected from emission leakage and then imported into HSM, then immediately destroyed outside.

May be better solutions exist, it is my IMHO, I am NOT a security specialist.

Just a few of ideas for your next HSM3 may be :wink:

Please make yourself familiar with Nitrokey HSM first. For instance, we have some screen casts in our video channel.

If you feel that PIN verification is too weak, then you could use the public key authentication mechanism instead and even configure a n-of-m threshold authentication scheme.

However those advanced mechanism need some integration on the software side, as the standard PKCS#11 interface does not allow such sophisticated mechanisms. One option would be to use the Smart Card Shell, OpenSCDP, OCF or the JCEProvider instead. All of them support PKA.

And by the way, information emanation is one of major topic evaluated as part of the Common Criteria certification. See FTP_EMSEC.1 in the Security Target.

I am afraid all of them are just software wrappers outside of HSM2 and still require a PIN for authentication to HSM2 by themselves, may be entered automatically by the software, would not it be even worse if the PIN is stored in a file system even encrypted somehow unless decryption key is derived somehow from a key stored in device like NK PRO2 again? And then the PIN still would be passed via USB channel of the token anyway available for remote scanners, already not encrypted at least by asymmetric master keys (public part)?

Sorry (though happily) if I am wrong, I have to read the docs at first.

Nope. Public key authentication is a native function of the SmartCard-HSM. No tricks with cached PIN or so.

And if you are afraid of PIN disclosure on the way between input device and the HSM, you could establish a secure channel that protects integrity and confidentiality of data exchanged.

1 Like