I am working on a cloud-based digital signature with a Hardware Security Module (HSM). I know that PKCS#11 AND Microsoft CryptoAPI implementation is required. I want to simulate the total process. For this, is Thales Simulator best for HSM? How can I connect this with PKCS#11 or Microsoft CryptoAPI? Or can anyone offer a better solution to simulate cloud based digital signature with Hardware Security Module?

Note: It will be better for me to simulate in Windows.

  • The server must do the 'wrapping'/composition of the signature. The cryptographic signature itself MUST be done inside the HSM, not by the server. As the private key cannot be extracted from the HSM (in a plain form). For sure, speaking in terms of secure environment. The authentication issue can use OTP, Bio, etc. Did you manage to deploy the scenario? What did you finally use? I’m interested in doing a basic scenario too.
    – Sergio GM
    Commented Jan 9, 2017 at 16:32

1 Answer 1


Your question seems peculiarly obscure to me, so I'll write here some explanation about the meaning of the terms you employ, under the hope that it will reduce confusion and lead to either an answer or at least a clearer question.

PKCS#11 is an Application Programming Interface: it is a set of functions, that applications use, and that are provided by a given device or system. From the point of view of an application, a "PKCS#11 driver" is a DLL that the application can load, and that DLL offers some functions for creating and using cryptographic keys. The application does not know how the keys are created and managed and used, and that is the whole point of using a standardized API. A physical device for managing keys (says, a HSM) will come along with a DLL provided by the HSM vendor, the DLL implementing the PKCS#11 interface. That way, any application that knows how to load a PKCS#11 DLL and call functions in it will be "instantly" compatible with all HSM that provide such a DLL.

There is no need for the key management system to be "physical". The application calls the DLL, and the DLL does what it wishes; it may use files and simple software to perform the cryptographic operations; it may call upon some remote server to do the job; or anything else. The application, by definition, does not know and cannot know what the DLL does.

Presumably, if you want to simulate things, then you could imagine using a PKCS#11 DLL that does things in pure software, so that you may develop and test your application before actually buying a HSM. That's the theory; it does not work well in practice because PKCS#11 is a huge API, and while PKCS#11 specifies functions and arguments, it does not pin down all possible behaviours, so implementing PKCS#11 is only one step towards interoperability. Speaking of which, not all HSM are equivalent to each other, so making tests with one HSM does not mean that your application will run with all HSM on the market.

To make things simple, if you need to simulate a HSM from vendor XXX, then the best, most faithful simulation is probably the simulator provided by XXX itself, because that's the point of such a simulator. Mind that "best" does not automatically mean "good".

CryptoAPI is a Microsoft-only API that is somewhat analogous to PKCS#11. Applications call CryptoAPI's functions to perform various operations related to cryptography (including signing documents or validating X.509 certificates). Some of these operations are about key creation, management and usage; CryptoAPI delegates these to what Microsoft calls Cryptographic Service Providers. The CSP really are DLL that CryptoAPI loads; the CSP implements some standardized functions and handle access to the system (physical or software device) that does the job. A CSP is similar in concept to a PKCS#11 DLL; the difference is mostly that CSP exist only in Windows, while PKCS#11 also works on other operating systems.

So applications on Windows have the choice between using CryptoAPI or PKCS#11. The Firefox Web browser, for instance, uses PKCS#11 exclusively, when it needs to talk to cryptographic hardware devices (especially smart cards); for the same purposes, Internet Explorer will rely on CryptoAPI.

Some HSM vendors (e.g. Thales) provide both a PKCS#11 DLL and a CSP for CryptoAPI with their HSM.

"Cloud-based" and HSM are a weird combination. When you do things "in the Cloud", you send your data to be stored and processed somewhere remote, so that the whole thing may be virtualized and moved around without changing anything on your side. You normally want to use HSM precisely so that such things do not happen.

Possibly, you might want to mean that you will have a "shared HSM": the HSM will be located in a network-reachable location, and various client systems will delegate cryptographic operations to this HSM through an HSM-specific protocol (presumably a protocol with enough cryptography to make that secure). Still with Thales HSM, they have a product called "nShield Connect" that does exactly that.

Calling this HSM-sharing "cloud-based" is a rather confusing statement, though.

  • fyi - I believe YubiKey offers an unlisted cloud based offering of their HSM... Commented Aug 3, 2015 at 21:14
  • The information is very helpful for me. Now the summary of my system scenario: 1) Private keys are stored on HSM(e.g. nShield Connect) rather than smart card 2) HSM is connected with a central application server where Cryptographic operation or digital signing process is performed 4) Users upload documents and send signing request to application server through third party applications (e.g. internet explorer) 5) Application server extract private keys from HSM 6) Then server sign the document and return it to the user. Note: Biometric authentication may be applied to access private key
    – Taif
    Commented Aug 5, 2015 at 23:41
  • How I can simulate my system ? can I create a virtual server? I heard about Omnet++.
    – Taif
    Commented Aug 6, 2015 at 11:41
  • "Application server extract private keys from HSM" is not correct. The application server uses the HSM to sign the document using the private keys securely stored in the HSM. The private keys are never extractable from the HSM.
    – Ron McLeod
    Commented Dec 6, 2021 at 23:40

You must log in to answer this question.

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