Imagine a system architecture where an API server is able to send a request to an HSM, and the HSM is able to decrypt some data for a particular user/customer, in order to serve some hypothetical purpose. In this case, if the API server is compromised, a hacker would be able to make many requests to the HSM to decrypt all of the data for all of the customers.

Typically, people suggest configuring the HSM with something like a rate limit to reduce the damage that would come from a server compromise, but I'm curious if it is possible to take this idea a step further and implement a method for controlling the HSM that involves requests from multiple servers.

For example, if we imagine that the API servers are behind a load balancer, then would it be possible to have the load balancer send a message to the HSM to notify it that an API server will shortly be sending a request for a particular customer? In that case, the HSM would first receive a notification from the load balancer, followed soon after by a request from the API server. If the HSM could be programmed to require both of those things before decrypting anything, then a hacker that compromised only the API server (and not the load balancer as well) would not be able to steal any data at all unless a legitimate request from a particular customer came in. This kind of "pseudo-quorum" architecture seems like it would be very secure to me, but I'm not an expert so there could easily be something obvious that I'm missing. Would this actually be a secure architecture for an API? And are there any HSMs that can be programmed to do something like this?


Load Balancer would be facing the internet and Application Servers would be behind load balancer with the ports open to only IPs of Load Balancer. Thus there are more chances of reverse scenario of what you had mentioned. Also, Load Balancer does not send the requests to application servers in synchronous way, thus there is no guarantee to support first intimation HSM before sending the actual decryption request. It can be in any order!

What I feel is security of cluster is as strong as the weakest link..!!

We had a project in middle east, where requirement was to hide HSM User PIN from Application Servers also. We had a HSM provider in Europe, who was ready to build such functionality where HSM User PIN encrypted with a public key (at browser) and provide encrypted User PIN to HSM, which will first decrypt the User PIN with the corresponding private key in the HSM and then will access the HSM operation (Mechanism). Thus, Application Server will never see the HSM User PIN.

After all, in my opinion, security architecting is mitigation and reduction of attack surface (and is infinite..!!)

  • I think that I understand your point about the Application Servers and Load Balancers. The Load Balancers would definitely be more exposed to the Internet and so would be more likely to get hacked. The ordering problem is also a big one... so my original idea definitely wouldn't work.
    – bnsmith
    Aug 11 at 23:15
  • I was hoping that you might be able to share a little more detail on the solution from your project. It seems like the User PIN would be stored away from both the Application Servers and the Load Balancers, on the end-user's computer (or in their memory?). It would then be sent (in encrypted form) straight to the HSM, which would be the only thing that could decrypt it. This means that there wouldn't be any secrets stored on either the Application Servers or the Load Balancer. What if there was a need to actually store some sort of secret locally rather than leaving it to the user?
    – bnsmith
    Aug 11 at 23:19
  • You understood it right. It was not api signing or encryption/decryption but interactive signing. Thus onus of protecting User PIN has been transferred to User. The HSM had Server built-in which can provide accounts for multiple users and can store thousand of keys of users in internal HDD protected by key stored in HSM hardware. This allowed key storage for few thousand or even a million users..!! Regarding storing secret locally, one option is to use KeyProtection provided by local CertStore or KeyChain. In .NET Core there are good API for Key Protection. Other frameworks will also have it. Aug 12 at 5:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.