Can some HSMs send requests to other servers before performing an encryption/decryption operation?

Question

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?

Answer 1

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.

Answer 2

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..!!