Guidance Needed: Using AWS CloudHSM for Document Signing Solution

Hey,

Hope you're keeping well.

For a high-volume document signing solution, CloudHSM is well-suited for securely storing and using private keys, but you’ll want to design around its network-based API model. Typically, your signing operations run from an EC2 instance or container in the same VPC, using the CloudHSM client to communicate with the cluster. Authentication can be fully automated using application code with pre-configured credentials, so there’s no manual password prompt in production.

Thanks and regards,
Taz

Hey,

Hope you're keeping well.

CloudHSM is a good fit for securely managing signing keys, but you’ll need to architect for its network-based access model. Your application typically connects via the CloudHSM client from an EC2 instance or container in the same VPC to perform signing operations. You can automate authentication using pre-provisioned crypto users so no interactive password entry is required in production. For high throughput, deploy multiple HSMs in the cluster and use client-side load balancing to spread requests. AWS docs on “Using CloudHSM for digital signatures” and “Best practices for CloudHSM clusters” are worth reviewing for performance tuning and integration patterns.

Thanks and regards,
Taz

Hi, some answers inline, hope it helps

Best practices for hosting and using signing certificates on AWS CloudHSM

• Only keys are stored in CloudHSM
• Certs are stored in the certstore of your systems.
• For example in MS windows, older CloudHSM SDKs versions (3.x) would create "key reference files" in your systems to represent the keys stored in the HSM to allow the provider (KSP) to interact with the keys. Your systems will be blind to the fact that the keys are not local btw
• Newer SDK versions (5.x) dont need "key reference files" and the provider can interact directly with the keys stored in the HSM
• https://docs.aws.amazon.com/cloudhsm/latest/userguide/client-sdk5.html

Typical performance benchmarks (signing speed, latency, throughput)

• there are workflows out there executing over 10k signing operations/day from multiple systems (100's)
• you can up to 900 concurrent connections.
• https://docs.aws.amazon.com/cloudhsm/latest/userguide/limits.html

Architecture recommendations for high-volume document-signing operations

• try not to share crypto users among signing systems (example: one system can lock the user due to bad password attempts and halt operations )
• you can have a max of 1024 crypto users created. These are hard quotas.
• https://docs.aws.amazon.com/cloudhsm/latest/userguide/limits.html

Any limitations or challenges faced during implementation

• Avoid the use of "$" signs in your crypto users passwords. MS systems might interpret everything to the right of it as a variable

Is an EC2 instance required to use CloudHSM for signing operations?

• your signing systems can be anywhere, even on-prem, same VPC as the Cluster would be simpler, robust, more secure, less moving parts
• https://docs.aws.amazon.com/cloudhsm/latest/userguide/cluster-architecture.html

Will CloudHSM prompt for a password, or require manual password input during certificate usage, or can this process be fully automated programmatically?

• It can be 100% baked in your application or code signing flow, here are code samples: https://docs.aws.amazon.com/cloudhsm/latest/userguide/java-samples.html#java-samples-code_5

This blog might be useful: https://aws.amazon.com/blogs/apn/signing-data-using-keys-stored-in-aws-cloudhsm-with-python/