How is HSM access gated?

Question

On the backend if I use a HSM (or even have the master key on a physical server), I need to do operations using that key. That means the app server is going to call into the HSM (or keyserver). What is the usual practice of authenticating calls to the HSM? Reading around, its usually done through a key pair that the HSM signs/knows about. But if the app server is compromised then an attacker could just relay the messages and perform the operations using the HSM and get valid data. I believe this is to be expected and par for the course, when the server itself is compromised.

I understand that the main idea behind using HSMs is to protect the key. But is there much thought/effort put into identifying compromised access to HSMs/Keyservers?

Answer 1

This can be accomplished in many ways. The most simple access control to a HSM is a physical button. So if a malware compromises the host computer, somebody still needs to be physically present to push the button for the HSM to do anything.

Then you have a whole range of different access protection, ranging from verifying the software in the host server "externally", to requiring a PIN (that the server will itself erase if it founds itself to be compromised).

A HSM can also limit operations on a key. For example, only allow a key to be used for signing and not decryption for example. Or require specific formats on the input data that is being signed or decrypted.

Another thing a HSM can enforce is rate-limiting, both for authentication attempts but also for operations. A server that usually decrypt lets say 1 message per 15 minutes can set to be rate limited to maximum 1 message per 10 minutes, which would reduce the usefullness of the HSM access from a compromised server.

However, the main objective for a HSM is not to limit access to the HSM itself. The main objective for a HSM is to ensure that the key itself, never leaves the HSM. Here it ranges all the way from simple HSM that will only allow access through a simple interface, but it will not have any features that prevent physical compromise/attack, and the other end of the scale is very advanced HSMs that can resist a attack even if a adversiary has unmonitored physical access to the HSM for a very long time.

To make a analogy:

Imagine itself: If somebody was being able to use your car key once, does it matter? Is your car compromised? No, because your car key was not copied. The adversiary gained a one-time access to your car. As soon as you have reclaimed control of the car key, the car key is fully secure and safe to use.

But if somebody COPY the car key, its effectively compromised and needs to be replaced.

Imagine the same thing with encryption keys. Some encryption keys can be hard or cumbersome to replace, and the process of replacing it can itself be vulnerable to permanent irrevocable compromise if the replace process involves the compromised key. (example: A attacker uses the compromised key to initiate the replace process to his own key. If the key managing system is distributed and not managed, the company or individual has permanently lost access to that record).

Here a HSM can also contain functionality to prevent the corresponding data for initiating the replace process (revocation certificate etc.) from being signed unless a specific PIN is entered, one which the server don't know.