Our project is to apply digital signature to PDF, so each user should have their own key pairs and a certificate. To keep key securely, we plan to purchase HSM, but from what I understand HSM have a limited number of keys that it can store.

So to my question, how should we handle this situation that we have hundreds or thousands of users that need to store their own keys and certificates.

One idea that I have:

  • Generate a master key in HSM
  • Generate user keys outside of HSM
  • Encrypt user key with master key
  • Store encrypted user key

But I’m not sure if this is the best practice.

Thank you.

  • Your proposal essentially means that everyone of these hundreds or thousands of users needs to have access to the HSM in order to decrypt its own key. And that each of these users can not only decrypt its own key but als the encrypted key of every other user - since everything is protected by a single secret. There are several ways to tackle the problem, like giving each user some smart card or similar (essentially a personal HSM), using qualified remote signatures ... Different solutions provide different security and have different costs, so you need to know what security you actually need Dec 9, 2021 at 17:48
  • Yes everyone will need access to decrypt their key but not directly, let’s say through our web api service. And providing each user with their own HSM would be too much of the cost.
    – Norak
    Dec 9, 2021 at 19:08
  • You have conflicting goals: security vs. costs. The way to find the right balance is to make the requirements more clear. Your current requirement of "keep key securely" is not specific enough - keep it securely from what kind of threats? For some reason you came to the conclusion that you want hardware protection if the keys. But if your requirement is solid hardware protection of all keys, then your solution is obviously not sufficient. So the best practice you ask for is to first determine the threats and risks, then decide on a solution which sufficiently mitigates these. Dec 9, 2021 at 19:29
  • Sorry for not specific enough. To "keep key securely", I meant to keep it from able to export or steal. In case key is stolen, they can create signature using customer identity. And yes you are right, we want to keep the key secure and also keep the cost down, that why I was thinking that we should have only one master key in HSM and encrypt all other keys. And I just would like to know if that way is secure enough to store those key or it's actually a bad practice. And sorry if my question is confusing, but thank you so much for spending time comment.
    – Norak
    Dec 10, 2021 at 4:39
  • "I meant to keep it from able to export or steal" - By whom? Insider, external attacker who managed to infiltrate your network, ... ? And how does your approach protect the keys against stealing? All it protects is the master key - the individual keys will be accessible at least for some time because in order to use these you need to decrypt these and then use the decrypted secrets outside the HSM. Dec 10, 2021 at 5:16

2 Answers 2


You will achieve better protection if you:

  • generate a master key in HSM
  • generate a user key in HSM
  • wrap user key with master key and store the wrapped key outside the HSM
  • delete the user key in HSM if it was not a session key (speaking in PKCS#11 terms)

To work with the key you need to:

  • unwrap the user key key using the master key
  • perform cryptographic operation
  • delete the user key in HSM if it was not a session key (speaking in PKCS#11 terms)

There are also HSM vendors that provide an (encrypted) external keystore with practically unlimited size. Therefore, you will just create new user keys and use them inside the HSM without requiring a master key (this one is implicitly used by the HSM to protect the keys in the external keystore).

But as discussed before, this only protects you from the keys being stolen, not from misusing them. The latter is completely up to your application checking the permissions of the app user.


What you're describing is the function of a Cryptographic Key Management System. A key manager will contain several components: a Hardware Security Module (HSM, generally with a PKCS#11 interface) to securely store the master key and to encrypt/decrypt client keys; a database of encrypted client keys; some kind of server with an interface to grant authenticated users access to their keys; and a management function that allows an administrator to bind to the HSM, manage the database, manage users, permissions, access rules, backup and recover keys, log access to the keys, etc.

Some KMS will only serve as a bare-bones key manager, while others will offer cryptography as a service, and can encrypt/decrypt user data or sign documents without the user's key ever leaving the secured perimeter of the KMS.

Key manager services deliver keys and cryptographic functions via interfaces, which are offered in a variety of protocols. Probably the most notable standard in the space that you might consider is the Key Management Interoperability Protocol (KMIP), a binary protocol defined by OASIS and supported by many vendors in the space. KMS vendors that have been in the business a long time usually come with ancient legacy proprietary interfaces (that you might want to ignore); more modern key managers include RESTful API access to cryptographic keys and functions.

Key managers will often incorporate a certificate management system, too; allowing the KMS to not only generate keys, but issue certificates for those keys or users.

Key managers also offer a variety of authentication options. All offer some simple form of username/password access. Those with certificate functions may offer mutual TLS authentication. Many integrate with other authentication, including OIDC/JWT, LDAP integration, AWS, GCP, Kerberos, etc.

There are both open source and commercial offerings in this space. The commercial systems used by major banks and financial institutions are generally very expensive, but they deliver pre-built servers that comes with a full suite of tamper protection and even physical armor. Some big cloud vendors (GCP, AWS, Azure, etc.) offer key management as an integrated service; they can replicate your keys for you so they're highly available wherever your servers are. There are also companies offering dedicated standalone key management services you can contract with.

I would caution against building your own system without more information. The well-known risks of "rolling your own cryptography" strongly apply to key management. A key management server is usually protecting keys that encrypt business critical data. Getting the service secured is therefore a critical security function; any vulnerabilities will be magnified in importance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .