HSM公司通常提供PKCS＃11 API來與HSM一起工作，還是隻提供他們自己的加密API？PKCS11或Cryptographic API？
在每種情況下，如何集成到Linux應用程序（使用OpenSSL，可能就像人們將如何爲第三方庫調用openssl引擎？）和Windows應用程序？
什麼是一般首選？ PKCS＃11 API或通用API？
兩者的優缺點是什麼？
HSM供應商告訴我們，他們可以提供PKCS＃11 API和用C語言編寫的加密API。我正試圖理解這些術語，因此也是這個問題！
一個簡單的概述，我會進一步研究:)
非常感謝！
PKCS＃11（來自維基定義）
＃11標準定義了一種獨立於平臺的API來加密的令牌的PKCS，諸如硬件安全模塊（HSM）和智能卡，和名稱的API本身就是「Cryptoki」（來自「密碼令牌接口」，發音爲「crypto-key」 - 但「PKCS＃11」通常用於指代API以及定義它的標準）。
所以這通常是所有HSM製造商使用的標準API。
如果他們實現這個API，它完全依賴於HSM供應商。如果他們確實實現了它，則應該能夠使用來自任何平臺（只要他們支持它）的標準PKCS＃11 API或任何可充當軟件與其硬件之間的中間件的第三方庫進行通信。如果他們沒有實現它，他們通常會編寫他們自己的專用API，這些API可能是特定於平臺的，並且只與他們的設備通信。這迫使您使用他們的API與他們的硬件進行通信（在這種情況下，HSM）。因此，從你的角度來看，如果你使用標準的PKCS＃11 API，並且將來如果你與另一個HSM供應商合作，你可以使用相同的代碼與新的HSM進行通信（因爲PKCS＃11是一個標準）。但是，如果您使用自己的API並與新的HSM供應商進行通信，則無法重用您的代碼，因爲他們的API可能僅適用於其設備。
通常提供一個PKCS＃11庫，如果只是爲了與其他也提供這種庫的產品競爭。 PKCS＃11是一個可以從軟件使用的通用接口。有許多軟件包允許使用下面的PKCS＃11令牌標準，如OpenSSL PKCS＃11引擎和Java語言中的PKCS＃11安全提供程序。
儘管可以擴展PKCS＃11，但這並不意味着HSM的所有功能都必須得到支持。 PKCS＃11是一個相對較低級別的界面。有時候使用專用API更適合特定用例會更有意義。密碼協議的更多部分可以在安全設備上執行，越好越好。
至於哪一個更好，那完全取決於您的用例和威脅模型以及可以提供的加密API。
它也取決於HSM的類型，大多數通用HSM支持PKCS＃11，但特殊用途的HSM（如支付）更可能不支持。 – zaph