2

I've been building a product using AWS CloudHSM and things are working well in the POC.

Now I want move to production, I've realised that there will be a need to authenticate with the HSM in order to have it sign messages with private keys it holds.

The problem this manifests is there seems to always be a need to keep a private key in software.

For e.g. my signing manager I have to keep the private key in a software based keystore!

Does this not erode the value of using a HSM in the first place? What is best practice?

Woodstock
  • 679
  • 6
  • 20
  • 2
    Best practice is to distribute short-lived and narrow-scoped credentials for aws identities. It should be obvious that this is better than handing out long-lived encryption and/or signing keys. You can also generate separate credentials for encryption and decryption, for instance, which isn't possible with directly usable keys. You're not getting around having some kind of credentials somewhere, but you can control how powerful (and thus risky) the credentials are. – Peter May 13 '19 at 16:14

1 Answers1

0

Is the system that you are working on entirely contained within AWS? If you are attempting to gate access to certain high-risk HSM operations, like adding a completely new private key, perhaps you could try to require authentication from something like a YubiKey. This would be a hardware-based solution, but would come with its own set of problems, like deciding how many YubiKeys to authorize with the HSM (for redundancy in case of a hardware failure) and where to keep the YubiKeys when not in use.

Similarly, if there were an on-prem component to your overall system (ie. a server outside of AWS that would be communicating with the CloudHSM), then you could similarly add a hardware component to authenticate that particular server. If that server were compromised, then the hacker could use that server's hardware to make requests to the CloudHSM, but only for as long as they were able to maintain their active connection to that server. They wouldn't be able to steal the keys and allow themselves to access the CloudHSM system from anywhere in the world at any time.

If the system that you're working on is entirely within AWS and you can't add any bits of hardware, then there are still some strategies that you might be able to use to add some level of control, though these are highly dependent on the specifics of your application. For example, Square developed a system for storing cryptocurrency in "cold wallets", where the HSMs that control the cold wallet private keys have custom programming that restrict the HSMs from signing any cryptocurrency transaction, except for ones that transfer cryptocurrency to... the "hot wallets" belonging to Square. If a hacker was able to compromise a server and force the HSM to sign a transaction, it wouldn't allow them to directly steal anything from the cold wallets.

I'm not sure if AWS CloudHSM allows you to run custom code within the HSM's secure enclave, but that's the only option that I can think of.

bnsmith
  • 67
  • 8