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.
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.
