1

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?

bnsmith
  • 67
  • 8

2 Answers2

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.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 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 '21 at 02:05
  • @bnsmith I updated the answer. – ThoriumBR Aug 13 '21 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 '21 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 '21 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 '21 at 18:14
  • I think that I'm starting to understand better. If the auth server was compromised, then the hacker could send bogus requests to the auth server to get authorized as any/all of the customers. This authorization could then be sent to the (non-hacked) API server, which would accept the authorization as valid (because the auth server told it to). The theoretical HSM would decrypt everything, again because the auth server said that it was OK. So compromising the auth server totally wrecks any security that this architecture may have had. – bnsmith Aug 13 '21 at 23:19
  • If the hacker compromises the API server but not the auth server, then the hacker could decrypt the data of any customer that logs in legitimately. If we assume that all customers log in at least once per week, then the hacker could decrypt and steal all of the data in about a week's time, which I guess slows the attacker down a bit, and gives the good guys more time to detect and stop the intrusion, but it's a lot of effort to implement such a big new feature in the HSM for such a marginal gain. Therefore, an architecture like this will probably never be attempted. – bnsmith Aug 13 '21 at 23:24
0

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

Bharat Vasant
  • 284
  • 1
  • 8
  • 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 '21 at 23:23