PKCS11还是密码API？

Question

HSM公司通常提供一个PKCS#11 API来使用HSM，还是仅仅提供自己的加密API？

在每种情况下，如何集成到Linux应用程序(使用OpenSSL，可能就像如何为第三方库调用openssl引擎一样)？Windows应用程序呢？

什么是一般的首选？PKCS#11 API还是泛型API？

两者的优点和缺点是什么？

一位HSM供应商告诉我们，他们可以同时提供一个PKCS#11 API和一个用C语言编写的密码API。我正在努力理解这些术语，因此也就是这个问题！

一个简单的概述将让我进一步研究:)

非常感谢！

Answer 1

通常，如果只是为了与提供这样一个库的其他产品竞争，则提供一个PKCS#11库。PKCS#11是一个通用的接口，可以从软件中使用。有许多软件包允许在下面使用PKCS#11令牌标准，例如OpenSSL PKCS#11 engine和PKCS#11安全提供程序。

尽管PKCS#11可以扩展，但这并不意味着可以支持HSM的所有功能。PKCS#11是一个相对较低的接口。有时，使用更适合特定用例的专有API更有意义。加密协议中可以在安全设备上执行的部分越多，越好。

至于哪个更好，这完全取决于您的用例和威胁模型以及可以提供的密码API。

Answer 2

PKCS#11 (wiki的定义)

PKCS #11标准为加密令牌(如硬件安全模块(HSM)和智能卡)定义了与平台无关的API，并将API本身命名为"Cryptoki“(来自”密码令牌接口“，发音为”密码密钥“-但"PKCS #11”经常用于引用API以及定义它的标准)。

因此，这通常是标准API的所有HSM制造商的使用。

它完全取决于HSM供应商是否实现了这个API。如果他们确实实现了它，您应该能够使用标准的PKCS#11 API从任何平台(只要他们支持它)或任何第三方库来与他们的硬件进行通信，这些库可以在您的软件和硬件之间充当中间件。如果没有实现它，他们通常会编写自己的专有API，这些API可能是特定于平台的，并且只与他们的设备通信。这迫使您使用他们的API与他们的硬件进行通信(在本例中是HSM)。

因此，从您的角度来看，如果您使用了标准的PKCS#11 API，并且将来如果您与另一个HSM供应商协作，您也可以使用相同的代码与新的HSM进行通信(因为PKCS#11是一个标准)。但是，如果您使用了他们自己的API，并且为了与新的HSM供应商通信，您就不能重用您的代码，因为他们的API可能只适用于他们的设备。