Good call. OnlyKey talks a little about it: https://docs.onlykey.io/security.html

Yeah, there is one flaw that I recently noted: how does the HSM authenticate legitimate users?

Like "I am an app, dear HSM, please perform following crypto operation for me."

If an attacker can pretend to be a legitimate HSM user, then she does not need key access, she just asks the HSM to perform a crypto operation on her behalf.

On the other hand, if the HSM needs secrets in order to authenticate legitimate users, then those secrets are prone to those attacks, against an HSM shall protect.

Or dont i get it?

It's a whole "chain of trust" kind of problem just like X.509.

Not really, since that would just be kicking the can down the road. Yes, you can have authentication between application servers and HSMs, but ultimately, whatever credential is used for that can be stolen from the application server, and then whoever has it can talk to the HSM.

The real benefit of HSMs is that they can make low-level keys accessible via a high-level interface that restricts the type of operations that can be performed at all. For example, an HSM will never just hand raw keys to application servers, but rather only let them perform various operations (based on their permissions). The higher level and specific these permissions are, the better.

Disclaimer: I have worked in the past for one of the major HSM vendors, but things can be changed in the last years.

To authenticate an application, you should generate a client certificate and share to the application, in order to create a mutual authentication trust. When you request some operations to HSM you need to authenticate yourself with the certificate. Of course the certificate must be kept as a secret and not shared with anybody. There is also a sort of RBAC scheme related to client certificate.

You're absolutely right: If a HSM is just used as a signing/decryption oracle, it doesn't add much value.

They're most useful if they can perform high-level operations, such as "please validate whether the entered card PIN <encrypted PIN block> here matches <PIN verification value on file>, given <credit card number>". The output of that example operation would only be a single bit of information (yes or no), rather than e.g. leaking the entire correct PIN, or even just the decrypted PIN that was entered at the POS.

But even just a signing/decryption oracle can be a step up from just storing long-lived private and secret keys on your application servers, where you'll never know for sure whether they were exfiltrated at some point.

I don't think I get the 1-Click reference here – could you please elaborate?