PKCS #11 -標準方案簡介
PKCS #11 是一種標準,可針對保留加密資訊及執行加密功能的裝置指定應用程式設計介面 (API),稱為 Cryptoki。 Cryptoki API 遵循簡單的物件型方法。 此方法解決技術獨立及資源共用的目標,向應用程式呈現稱為 加密記號之裝置的一般邏輯視圖。
Cryptoki 會將應用程式與加密裝置的詳細資料隔離。 應用程式不需要將介面變更為不同類型的裝置,或在不同環境中執行。 因此,該應用是行動式的。 Cryptoki API 的功能組織成下列種類:
- 一般用途函數 (四個函數)
- 插槽和記號管理功能 (九個功能)
- 階段作業管理功能 (八個功能)
- 物件管理函數 (九個函數)
- 加密功能 (四個功能)
- 解密函數 (四個函數)
- 訊息摘要函數 (五個函數)
- 簽署、驗證及 MAC 功能 (12 個功能)
- 雙重用途加密函數 (四個函數)
- 金鑰管理功能 (五個功能)
- 亂數產生函數 (兩個函數)
- 平行函數管理函數 (兩個函數)
並非所有 PKCS #11 函數都由 IBM Cloud® Hyper Protect Crypto Services實作。 如需實作的 PKCS #11 函數,請參閱 支援的 PKCS #11 函數。
若要檢閱 PKCS #11 標準文件,請參閱:
- Cryptographic Token Interface Usage Guide Version 2.40
- 加密記號介面基本規格版本 2.40 Plus Errata 01
- 加密記號介面現行機制規格版本 2.40 Plus Errata 01
PKCS #11 實作元件
若要連接並使用 PKCS #11 API,您需要瞭解 Hyper Protect Crypto Services 所實作的 PKCS #11 API,以及與 GREP11 API 的關係。 如需相關資訊,請參閱 比較 PKCS #11 API 與 GREP11 API。 在 PKCS #11 API 支援下,您不需要變更使用 PKCS #11 標準的現有應用程式。Hyper Protect Crypto Services 也會提供隔離的金鑰儲存庫,以儲存 PKCS #11 函數所產生的加密金鑰。 這些金鑰受主要金鑰保護,且應用程式永遠不會在本端看到金鑰檔。
在您可以使用 PKCS #11 API 之前,請先安裝 PKCS #11 程式庫。 以此方式,PKCS #11 應用程式可以與 PKCS #11 程式庫互動,然後透過 gRPC呼叫 Hyper Protect Crypto Services 所實作的加密函數。 下圖顯示 Hyper Protect Crypto Services PKCS #11 程式庫所實作的關鍵元件,以及不同元件之間的互動。
下列各節詳細說明每一個 PKCS #11 元件。
應用程式
應用程式在單一位址空間內執行。 控制項的所有執行緒都在應用程式中執行。 透過從其中一個執行緒呼叫 Cryptoki 函數 C_Initialize
,應用程式變成 Cryptoki 應用程式。 發出此呼叫之後,應用程式可以呼叫其他 Cryptoki 函數。 當應用程式完成使用 Cryptoki 時,它會呼叫 Cryptoki 函數 C_Finalize
,並不再是 Cryptoki 應用程式。
如果您在 IBM Z (s390x) 平台上使用 SunPKCS11 提供者執行 Java PKCS #11 應用程式,請確定您使用最新的 IBM Semeru JVM,並在啟動應用程式時指定 -Xjit:noResumableTrapHandler
Java 選項。 您可以在 IBM Semeru 執行時期下載頁面」上,將 架構 過濾器欄位變更為 s390x,以下載 IBM Semeru JVM 的最新 s390x 版本。
使用者
PKCS #11 標準定義兩種登入使用者類型: 安全主管 (SO) 和一般使用者。 如果使用者未使用 C_Login
Cryptoki 函數登入,則該使用者也稱為匿名使用者。 只有一般使用者可以存取記號上的專用物件,且只有在鑑別一般使用者之後,才會授與該存取權。 在 Hyper Protect Crypto Services PKCS #11 實作中,安全管理者和一般使用者由 API 金鑰鑑別。 也支援匿名使用者。 如需設定 PKCS #11 使用者類型的指示,請參閱
設定 PKCS #11 使用者類型的最佳作法。
階段作業
Cryptoki API 需要應用程式使用記號開啟一個以上階段作業,以取得對記號物件及函數的存取權。 階段作業提供應用程式與記號之間的邏輯連線。 階段作業可以是讀寫 (R/W) 階段作業或唯讀 (R/O) 階段作業。
若要取得對記號之專用物件的存取權,一般使用者需要登入並進行鑑別。 如需深入瞭解階段作業的相關資訊,請參閱 PKCS #11 Cryptographic Token Interface Usage Guide。
金鑰物件
金鑰物件儲存在與 PKCS #11 應用程式一起存在的記憶體內金鑰儲存庫中,或儲存在資料庫支援的金鑰儲存庫中。 如果金鑰物件的 CKA_TOKEN 屬性設為 true
,則金鑰物件會儲存在資料庫支援的金鑰儲存庫中。 否則,金鑰物件會儲存在記憶體內金鑰儲存庫中。
在主要金鑰輪替之後,不會自動輪替記憶體內金鑰儲存庫中的金鑰物件。 如果在服務實例中啟用 PKCS #11 金鑰儲存庫,則在主要金鑰輪替完成之後,您需要重新啟動所有作用中的 PKCS #11 應用程式,以清除記憶體內金鑰儲存庫。
如下圖所示,PKCS #11 金鑰物件是 PKCS #11 物件類別的範例:
- 資料: 由應用程式定義資料物件。
- 憑證: 憑證物件儲存憑證。
- 金鑰: 金鑰物件儲存加密金鑰。 金鑰可以是公開金鑰、私密金鑰或秘密金鑰。 這些金鑰的每一種類型都有子類型,可在特定機制中使用。
- 公開金鑰: 金鑰組的公開元件,任何人都可以使用它來加密訊息,以便讓特定收件人能夠存取金鑰組的私密金鑰。 公開金鑰也用來驗證私密金鑰所建立的簽章。
- 私密金鑰: 用來解密訊息之金鑰組的私密元件。 私密金鑰也用來建立簽章。
- 秘密金鑰: 秘密金鑰是產生的位元串流,用來對稱加密及解密訊息。
Cloud Identity and Access Management
IBM Cloud Identity and Access Management (IAM) 提供使用者鑑別及存取控制,以實作 PKCS #11 API。 透過使用 API 金鑰,PKCS #11 程式庫會取得用來執行 Cryptoki API 呼叫的載送記號。
PKCS #11 的這項實作等於 API 金鑰與使用者的 PIN 碼。 如需設定服務 ID 及對應 API 金鑰的相關資訊,請參閱 為 SO 使用者、一般使用者及匿名使用者建立服務 ID。
加密服務
在 PKCS #11 程式庫起始設定處理程序中,會建立從 PKCS #11 程式庫到 IBM Cloud的 gRPC 連線。 gRPC 連線可協助 PKCS #11 程式庫呼叫 Cryptoki 函數,例如 C_Encrypt
、C_Decrypt
、C_Sign
及 C_Verify
,這需要使用「硬體安全模組 (HSM)」。
金鑰儲存庫
有兩種主要類型的金鑰儲存庫可用:
- 記憶體內金鑰儲存庫: 暫時將金鑰物件儲存在記憶體中。 儲存在記憶體內金鑰儲存庫中的金鑰物件也稱為 階段作業物件。 當您呼叫該階段作業的
C_CloseSession
函數時,會毀損特定階段作業中的階段作業物件。 在呼叫C_Finalize
函數之後,會毀損所有階段作業中的階段作業物件。 - 資料庫支援的金鑰儲存庫: 將金鑰物件儲存在資料庫中。 儲存在資料庫支持金鑰儲存庫中的金鑰物件也稱為 記號物件。 如果已啟用
sessionauth
參數,且已配置金鑰儲存庫的密碼,則會加密並鑑別資料庫支援的金鑰儲存庫。 依預設,會停用sessionauth
參數。 對於每一個服務實例,最多支援五個已鑑別的金鑰儲存庫。 您可以啟用sessionauth
參數,將產生的金鑰加密至金鑰儲存庫,或在使用金鑰之前將金鑰解密。 密碼可以是 6-8 個字元。
金鑰儲存庫密碼不會儲存在服務實例中。 作為金鑰儲存庫管理者,您負責維護密碼的本端副本。 如果遺失密碼,您需要聯絡支援團隊來重設金鑰儲存庫,這表示會清除金鑰儲存庫中的所有資料。
記憶體內金鑰儲存庫和資料庫支援的金鑰儲存庫都由下列類型的金鑰儲存庫組成:
- 公用金鑰儲存庫: 儲存較不敏感且要由任何使用者類型存取的金鑰。
- 私密金鑰儲存庫: 儲存加密機密資料及僅供一般使用者存取的金鑰。
視 使用者類型 及金鑰屬性設定而定,產生的金鑰會儲存在不同的金鑰儲存庫中。 下列清單彙總如何儲存金鑰的準則:
-
CKA_TOKEN 屬性值決定產生的金鑰是儲存在記憶體內金鑰儲存庫中,還是儲存在資料庫支援的金鑰儲存庫中。
如果您要將金鑰儲存在資料庫支援的金鑰儲存庫中,請將金鑰或金鑰組產生範本中的 CKA_TOKEN 設為
TRUE
。 PKCS #11 程式庫起始設定處理程序會建立與 IBM Cloud的 gRPC 連線,以協助在資料庫支援的金鑰儲存庫中儲存及擷取金鑰物件。 依預設,CKA_TOKEN 設為FALSE
,這表示金鑰物件儲存在 PKCS #11 應用程式處理程序位址空間內的記憶體內金鑰儲存庫中。 -
CKA_PRIVATE 屬性值決定將一般使用者所產生的金鑰儲存在公開或私密金鑰儲存庫中。
依預設,如果使用者以一般使用者身分登入,則產生的金鑰會儲存在私密金鑰儲存庫中,但 CKA_PRIVATE 設為
FALSE
的情況除外。 如果使用者以 SO 使用者身分登入或未登入 (稱為匿名使用者),則產生的金鑰一律儲存在公開金鑰儲存庫中。 如果 SO 使用者或匿名使用者在金鑰產生範本中指定 CKA_PRIVATE 為TRUE
,則會從伺服器傳回錯誤。對於非對稱金鑰組,您需要針對公開和私密金鑰分別設定 CKA_PRIVATE 屬性,這表示金鑰組可以儲存在不同的金鑰儲存庫中。
請參閱下表,以取得使用者類型、索引鍵屬性和金鑰儲存庫之間的關係,以及如何儲存索引鍵的詳細說明。
使用者類型 | CKA_TOKEN | CKA_PRIVATE | 金鑰的金鑰儲存庫 | 私人還是公共? |
---|---|---|---|---|
SO 使用者 | FALSE |
N/A | 記憶體內金鑰儲存庫 | 公用 |
SO 使用者 | TRUE |
N/A | 資料庫支援的金鑰儲存庫 | 公用 |
匿名使用者 | FALSE |
N/A | 記憶體內金鑰儲存庫 | 公用 |
匿名使用者 | TRUE |
N/A | 資料庫支援的金鑰儲存庫 | 公用 |
一般使用者 | FALSE |
FALSE |
記憶體內金鑰儲存庫 | 公用 |
一般使用者 | FALSE |
TRUE |
記憶體內金鑰儲存庫 | 專用 |
一般使用者 | TRUE |
FALSE |
資料庫支援的金鑰儲存庫 | 公用 |
一般使用者 | TRUE |
TRUE |
資料庫支援的金鑰儲存庫 | 專用 |
量子後加密法支援
使用 PKCS #11 API,您也可以執行 post-quantum cryptographic 作業。 傳統加密法依賴複雜的數學問題,而這些問題是傳統電腦難以解決的。 然而,利用計算能力,量子計算機可以解決這些問題。 量子後加密法被認為可以抵抗量子計算機的密碼分析攻擊。 它通常使用非對稱演算法,並有多種方法。
PKCS #11 API 提供 Dilithium 演算法 用於量子後加密法。 它是一種基於點陣的數字簽名方案,可用於簽名生成和驗證。 目前僅支援 第 2 輪 Dilithium 的高安全版本,且無法用於
C_SignUpdate
和 C_VerifyUpdate
作業。
只有 IBM 4769 加密卡 (也稱為 Crypto Express 7S (CEX7S)) 才支援 Dilithium 演算法。 如果您在使用 CEX7S 加密卡的 Virtual Private Cloud (VPC) 型區域中建立實例,則可以將 Dilithium 演算法用於具有 PKCS #11 API 的量子後加密法。 如需 VPC 型地區的清單,請參閱 地區及位置。
如需 PKCS #11中 Dilithium 演算法支援的相關資訊,請參閱 PKCS #11 API 參考資料。 您也可以在 GitHub 範例儲存庫中找到 Dilithium 演算法程式碼範例。