In various discussions of Security Architecture, I have read that HSMs can be configured with rate limiting on the number of encryptions/decryptions that can be performed in a given amount of time. If I understand correctly, the purpose of a rate limit would be to limit the damage that would come from a hacker that manages to compromise a server that is authorized to make use of the HSM. For example, if an API server had 1000 encrypted files that each stored the data for one customer, then a hacker that compromised the API server would have to ask the HSM to decrypt each of those 1000 files to steal all of the data. A rate limit of, say, 10 files per hour would make it very time consuming for the hacker to get all of the data for all of the customers. Ideally, the hacker would be detected and booted out before they got too much data.

This led to me thinking about the possibility of implementing a method for stopping decryptions from taking place that involved having the HSM send requests to other external services, rather than relying solely on an internal system clock. Going back to the previous example, if the HSM received a request from the API server, could the HSM then send a request to the API's authentication server to ask if that particular customer had actually authenticated recently? If the user hadn't successfully logged in within the last 10 minutes, then the HSM could refuse to perform the decryption operation, and the data would be safe.

This would essentially mean that the hacker would need to compromise both the API server and the authentication server to decrypt and steal all of the data for all of the users (assuming the API server and the authentication server are two completely independent servers). The hacker could still steal the data of customers that happen to log-in while the API server is breached, but getting ALL of the data would require waiting for all of the customers to login at least once.

Are any HSMs capable of sending requests and taking an action based on the response? Or are they all limited to simpler things like rate limiting?

2 Answers 2


A rate limit of, say, 10 files per hour

... would be a terrible file server.

rather than relying solely on an internal system clock.

HSM clock is running inside a securely designed dedicated hardware with security in mind, and security above everything (above usability, performance, power consumption, and price). An external clock source cannot be more secure than the HSM clock.

If an attacker managed to breach the internal network and compromised any server, nothing really stops him from breaching all other servers. On a corporate environment, usually most servers are under the same domain, and a domain admin can have privileged access on them. An attacker with domain admin credentials can control the API server and the authentication server, the clock server, the email server...

if the HSM received a request from the API server, could the HSM then send a request to the API's authentication server to ask if that particular customer had actually authenticated recently?

The API server should be able to answer that. HSM role is encrypting, decrypting, signing, and storing private keys. Not to ask around if the request is legit or not. Another dedicated server have to do that.

Or are they all limited to simpler things like rate limiting?

The more complex the controls, the larger the attack surface. You usually don't let people access the HSM directly, it is only accessed inside a secure network, behind a well designed firewall, and accessible only by white-listed addresses. I don't think someone would buy and setup an HSM and let it be accessible by any hacker attacking a desktop.

Remember that if your secure encryption server is so slow that takes an hour to decrypt a file (because at 10 files per hour, the queue for decrypting files will be quite large), your users will stop encrypting files. If you have the HSM talk to another server to decrypt something, you will need to protect this new server, and that adds complexity.

Even if the API server and authentication servers are on different domains, providers and continents, it won't change a thing. A compromised API server may get the decryption request, change it, and ask the HSM to decrypt a different file, saving the decrypted version somewhere and returning an error to the original client. A compromised authentication server may always return "client authenticated, go ahead" to every request from the attacker.

  • It seems pretty clear from the answers here that there is no existing HSM that does this sort of request/response stuff. I'm still not completely convinced that it's a bad idea, though you do raise a good point about domain admin credentials. To have a hacker compromise one server, but not the other, it would be necessary for each of the two servers to be in different domains. Perhaps if the auth server was in a different domain than the API server and controlled by different admins, then there would be some extra safety from both hackers and internal bad actors?
    – bnsmith
    Aug 13, 2021 at 2:05
  • @bnsmith I updated the answer.
    – ThoriumBR
    Aug 13, 2021 at 10:48
  • Regarding your most recent update to the answer, if the compromised API server asked the HSM to decrypt a different file, and the HSM then sent a request to the authentication server to ask if a specific customer had logged in recently, the authentication server would say "no". Then the HSM would refuse to decrypt. For the hacker to get around this, the hacker would have to compromise both the API server and the authentication server, wouldn't they? Hacking two servers seems harder than only hacking just one, or am I still missing something?
    – bnsmith
    Aug 13, 2021 at 18:06
  • If the API server stores the encrypted files, and the authentication server exerts some control over when the HSM is allowed to decrypt any files, then hacking only one of those two servers wouldn't allow any data decryption to take place. The two servers would be a little like a "mini-quorum" needed to do something useful with the HSM. Of course, this is all purely theoretical since no HSMs can actually send requests out like this, but it's still fun to think about. Thanks for all your insight, @ThoriumBR!
    – bnsmith
    Aug 13, 2021 at 18:09
  • HSM only knows the encrypted file, and if it can decrypt it or not. API server knows every file and can ask the HSM to decrypt files. The auth server knows nothing about the files any client have. Those assumptions are true or you have role overlap on the servers. If a hacker compromises the API server, it can ask the HSM to decrypt any file belonging to a recent client. If he compromises the auth server, he can let a program decrypting files day and night and the auth server will always reply "it is online, go ahead".
    – ThoriumBR
    Aug 13, 2021 at 18:14

As I know, HSM rate limiting is mostly commercial (some HSM even don't offer rate limiting) but as you think, you can use rate limiting to restrict damage done in small amount of time. These rates are per second. If rate is limited to 10 operations per seconds (TPS - throughput per second), It would require less than 2 minutes to complete 1000 operations.

Most of the HSM have limited functionality to crypto operations. Some HSM has value added Server (software) inbuilt. But I don't think any HSM vendor will be easily ready to modify his software unless large quantities of HSM are required and they may take months to deliver the customized update..!!

In one project, where we are providing signing using API, we have used SMS OTP as second factor authentication from user. Application server can limit number of operations allowed before requiring next OTP. If it is set to 1, user will have to call OTP submission API before every operation. HSMs are only good at protecting the keys..!!

  • Downselected this answer - "As you know" is a horrible way to start an answer. All HSMs have rate limitation built in, because it gives the vendor an economy of scope -- call sell a rate limited 'fast' HSM at a better price point. Rather than look at the numbers (10 TPS/1000 documents) it is better to focus on the idea presented. No HSM has a server in it. There are appliances that have HSMs in them; the appliance is what provides the server. There is an HSM vendor with an SDK, you could write your own rate limiter in a couple days.
    – rip...
    Oct 11, 2021 at 23:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .