CODEWITHSUNDEEP
cryptographypkcs#11jce
user907810
user907810

Reputation: 3368

PKCS11 or Cryptographic API?

Do HSM companies usually provide a PKCS#11 API to work with the HSM or do they just provide their own Cryptographic API?

In each case how to integrate to a Linux Application(using OpenSSL, possibly like how one would call an openssl engine for a 3rd party library?) and to a Windows Application?

What is generally preferred? PKCS#11 API or a generic API?

What are the advantages and disadvantages of the two?

A HSM vendor has told us that they can provide both a PKCS#11 API and a crypto API written in C language. I am trying to understand the terms and therefore this question!

A simple overview would me to research further :)

Many thanks!

Upvotes: 1

Views: 1840

Answers (2)

Maarten Bodewes
Maarten Bodewes

Reputation: 94038

Generally a PKCS#11 library is supplied, if just to compete with the other products that also supply such a library. PKCS#11 is a common interface that can be used from software. There are many software packages that allow the use of the PKCS#11 token standard underneath, such as the OpenSSL PKCS#11 engine and a PKCS#11 security provider in the Java language.

Although PKCS#11 can be extended this doesn't mean that all the functionality of a HSM can necessarily be supported. PKCS#11 is a relatively low level interface. Sometimes it makes more sense to use proprietary API's that better fit a specific use case. The more parts of a cryptographic protocol can be performed on a secured device, the better.

As for which one is better, that depends entirely on your use case and threat model as well as the crypto API that can be provided.

Upvotes: 2

always_a_rookie
always_a_rookie

Reputation: 4840

PKCS#11 (definition from wiki)

The PKCS #11 standard defines a platform-independent API to cryptographic tokens, such as hardware security modules (HSM) and smart cards, and names the API itself "Cryptoki" (from "cryptographic token interface" and pronounced as "crypto-key" - but "PKCS #11" is often used to refer to the API as well as the standard that defines it).

So this is generally the standard API all the HSM manufacturer's use.

It completely depends on the HSM vendor if they implement this API. If they did implement it, you should be able to communicate with their hardware using the standard PKCS#11 API from any platform (provided they support it) or any third-party libraries that can act as a middleware between your software and their hardware. If they didn't implement it, they usually write their own proprietary API that may be specific to a platform and communicate with their devices only. This forces you to use their API to communicate with their hardware (HSM in this case).

So, from your perspective, if you used the standard PKCS#11 API and in future if you collaborated with another HSM vendor, you can use your same code to communicate with the new HSM as well (because PKCS#11 is a standard). But if you used their own API, and to communicate with a new HSM vendor you cannot reuse your code, because their API might only work with their devices.

Upvotes: 1

Related Questions