HSM公司通常会提供PKCS＃11 API来与HSM合作，还是只提供自己的加密API？
在每种情况下如何集成到Linux应用程序（使用OpenSSL，可能就像人们如何称呼第三方库的openssl引擎？）和Windows应用程序？
什么是首选？ PKCS＃11 API还是通用API？
两者的优点和缺点是什么？
HSM供应商告诉我们，他们可以提供PKCS＃11 API和用C语言编写的加密API。我试图理解这些术语，因此也就是这个问题！
我将进一步研究一个简单的概述：）
非常感谢！
答案 0 :(得分：1)
PKCS＃11 （来自wiki的定义）
PKCS＃11标准为加密令牌定义了一个独立于平台的API，例如硬件安全模块（HSM）和智能卡，并命名API本身＆＃34; Cryptoki＆＃34; （来自＆＃34;加密令牌接口＆＃34;发音为＆＃34;加密密钥＆＃34; - 但＆＃34; PKCS＃11＆＃34;通常用于指代API以及标准它定义了它。）
因此，这通常是所有HSM制造商使用的标准API。
如果他们实施此API，则完全取决于HSM供应商。如果他们确实实现了它，您应该能够使用来自任何平台的标准PKCS＃11 API（只要它们支持它）或任何可以充当软件和硬件之间的中间件的第三方库与其硬件进行通信。如果他们没有实现它，他们通常会编写自己专有的API，这些API可能特定于平台并仅与其设备通信。这会强制您使用其API与其硬件进行通信（在本例中为HSM）。
因此，从您的角度来看，如果您使用标准的PKCS＃11 API，并且将来如果您与其他HSM供应商合作，您也可以使用相同的代码与新的HSM进行通信（因为PKCS＃11是一个标准）。但是，如果您使用自己的API，并与新的HSM供应商进行通信，则无法重复使用您的代码，因为他们的API可能只适用于他们的设备。
答案 1 :(得分：1)
通常提供PKCS＃11库，只是为了与提供此类库的其他产品竞争。 PKCS＃11是可以从软件中使用的通用接口。有许多软件包允许使用下面的PKCS＃11令牌标准，例如 OpenSSL PKCS＃11引擎和Java语言中的PKCS＃11安全提供程序。
尽管可以扩展PKCS＃11，但这并不意味着必须支持HSM的所有功能。 PKCS＃11是一个相对较低级别的接口。有时使用更适合特定用例的专有API更有意义。可以在安全设备上执行加密协议的更多部分，效果更好。
至于哪一个更好，这完全取决于您的用例和威胁模型以及可以提供的加密API。