實驗一-密碼引擎-3-加密API研究

20211415杨礼松發表於2024-04-14
密碼加密API
目錄
  • 1 CryptoAPI
    • 1.1 五個主要功能區域
    • 1.2 函式
      • 1.2.1 基本加密函式
      • 1.2.2 證書和證書庫函式
      • 1.2.3 證書驗證函式
      • 1.2.4 建立金鑰容器
  • 2 PKCS#11
    • 2.1 函式
    • 2.2 操作
  • 3 GM/T 0018-2012
    • 3.1 簡介
    • 3.2 範圍
    • 3.3 結構模型
    • 3.4 函式
    • 3.5 安全要求
      • 3.5.1 金鑰管理要求
      • 3.5.2 密碼服務要求
      • 3.5.3 裝置狀態要求
      • 3.5.4 其他要求
  • 4 呼叫不同介面的程式碼
    • PKCS#11
    • SKF

密碼引擎API的主要標準和規範包括：
1 微軟的Crypto API
2 RAS公司的PKCS#11標準
3 中國商用密碼標準：GMT 0016-2012 智慧密碼鑰匙密碼應用介面規範，GMT 0018-2012密碼裝置應用介面規範等

研究以上API介面，總結他們的異同，並以龍脈GM3000Key為例，寫出呼叫不同介面的程式碼，提交部落格連結和程式碼連結。
內容：
0 查詢各種標準的原始文件，研究學習（至少包含Crypto API,PKCS#11,GMT 0016-2012,GMT 0018-2012）（5分）
1 總結這些API在程式設計中的使用方式（5分）
2 列出這些API包含的函式，進行分類，並總結它們的異同（10分）
3 以龍脈GM3000Key為例，寫出呼叫不同介面的程式碼（Crypto API,PKCS#11，SKF介面），把執行截圖加入部落格，並提供程式碼連結（10分）

1 CryptoAPI

1.1 五個主要功能區域

基本密碼功能
證書編碼/解碼功能
證書儲存功能
簡化的訊息功能
低階訊息功能

1.2 函式

基本加密函式、證書編碼與解碼函式、證書儲存函式、簡化資訊處理函式、底層資訊處理函式。

1.2.1 基本加密函式

服務提供者函式
img
** 金鑰的產生和交換函式**
img
編碼/解碼函式
img
資料加密/解密函式
img
雜湊和數字簽名函式
img

1.2.2 證書和證書庫函式

這組函式是管理、使用和取得證書、證書撤銷列表和證書信任列表。

  • 證書庫函式：一個使用者站點可以收集許多證書。這些證書是為這個站點的使用者所使用的，證書描述了這個使用者的具體身份。對於每個人，可能有一個以上的證書。證書庫和其相關的函式提供了對庫獲得、列舉、驗證和使用證書庫裡的資訊。
    img
    img
  • 維護函式
    img
  • 證書函式
    img
    img
  • 證書撤銷列表函式
    img

1.2.3 證書驗證函式

證書驗證是透過CTL 和證書列表進行的.

  • 使用CTL的函式
    img
  • 證書鏈驗證函式
    img

1.2.4 建立金鑰容器

建立金鑰容器得到CSP控制代碼:每一個CSP都有一個名字和一個型別，並且名字保證唯一。所以可以透過名字和型別得到一個CSP。然而，要想加密肯定需要金鑰，金鑰放在金鑰容器。金鑰容器並不是一開始就存在的，需要使用者去建立。下面是建立容器的程式碼：

if(CryptAcquireContext(
&hCryptProv, // 返回CSP控制代碼
UserName, // 密碼容器名
NULL, // NULL時使用預設CSP名（微軟RSA Base Provider）
PROV_RSA_FULL, // CSP型別
0)) // Flag values
{
//以UserName為名的金鑰容器存在，那麼我們已經得到了CSP的控制代碼
printf("A crypto context with the %s key container \n", UserName);
printf("has been acquired.\n\n");
}
else //如果金鑰容器不存在，我們需要建立這個金鑰容器
{
if(CryptAcquireContext(
&hCryptProv,
UserName,
NULL,
PROV_RSA_FULL,
CRYPT_NEWKEYSET)) //建立以UserName為名的金鑰容器
{
//建立金鑰容器成功，並得到CSP控制代碼
printf("A new key container has been created.\n");
}
else
{
HandleError("Could not create a new key container.\n");
}
} // End of else

2 PKCS#11

2.1 函式

根據機制標記，可以分為幾類：
CKF_ENCRYPT：加密類
CKF_DECRYPT：解密類
CKF_DIGEST：摘要類
CKF_SIGN：簽名類
CKF_SIGN_RECOVER：可恢復簽名類
CKF_VERIFY：驗證類
CKF_VERIFY_RECOVER：可恢復驗證類
CKF_GENERATE：金鑰產生
CKF_GENERATE_KEY_PAIR：金鑰對產生
CKF_WRAP：金鑰封裝
CKF_UNWRAP：金鑰解封
CKF_DERIVE：金鑰派生
img

2.2 操作

img
Cryptoki 為一個或多個密碼裝置提供一個介面，這些裝置透過大量的槽在系統中執行。每個對應於一個物理閱讀器或另一個裝置介面的槽可包含一個令牌。當一臺密碼裝置存在於閱讀器中，一個令牌就存在於該槽中。當然，由於Cryptoki提供槽和令牌的邏輯檢視，所以可能有其它的物理譯碼。多個槽可能共享一個閱讀器。問題在於一個系統有相當多的槽，應用程式能連線到這些槽的其中任何一個或全部槽的令牌上。

密碼裝置可以按照某一命令集執行某些密碼操作，這些命令通常要經過標準裝置驅動程式，例如PCMCIA卡服務程式或槽服務程式。Cryptoki 使每個密碼裝置看起來邏輯上很象其它裝置，而不管什麼技術實現的。因此，應用程式不必直接與裝置驅動器介面（或甚至不必知道包括那些裝置）；Cryptoki 隱藏了這些細節。的確，基礎裝置完全能用軟體來實現，（例如，在一個伺服器上執行的處理程式），不須專用硬體。

Cryptoki 或許可以作為支援介面功能的庫來實現，而應用程式則與該庫連線。應用程式可以直接與Cryptoki 連線，或者，Cryptoki 是一個所謂的“共享”庫（或動態連線庫），在這種情況下，應用程式動態地連線庫。用Microsoft Windows和OS/2作業系統可以比較容易地生成資料庫，並且在UNIX和DOS中也可相對容易地生成“共享”庫。

由於新庫可以使用，所以動態方法有許多優點；但從安全的角度來說，也有一些缺點。要特別指出的是，如果庫能較容易地被替換，攻擊者有可能用惡意製造的假庫取而代之，以擷取使用者的PIN。即使編碼簽名技術能防止許多動態連線的安全危險，從安全形度來說，一般採用直接連線。總之，應用程式和Cryptoki 庫之間的程式設計介面是相同的。

裝置的種類和所支援的能力的種類將取決於專用Cryptoki 庫。本標準只定義庫的介面，不定義庫的特徵。要特別指出的是，並不是所有的庫支援這個介面（因為不是所有的令牌支援所有的機制）中定義的機制（演算法）。並且庫也許只支援可使用的所有密碼裝置的一個子集。（當然，可以預料更多更好的裝置種類將被開發，以支援多種令牌，而不是單個供應商提供的令牌。）只要開發出應用程式，就會形成Cryptoki 的介面、標準資料庫和令牌“輪廓”。

3 GM/T 0018-2012

3.1 簡介

這個標準規定了基於PKI密碼體制的智慧密碼鑰匙密碼應用介面，描述了密碼應用介面的函式、資料型別、引數的定義和裝置的安全要求。本標準的目標是為公鑰密碼基礎設施應用體系框架下的服務類密碼裝置制定統一的應用介面標準，透過該介面呼叫密碼裝置，向上層提供基礎密碼服務。為該類密碼裝置的開發、使用及檢測提供標準依據和指導，有利於提高該類密碼裝置的產品化、標準化和系列化水平。

3.2 範圍

本標準規定了公鑰密碼基礎設施應用技術體系下服務類密碼裝置的應用介面標準，適用於服務類密碼裝置的研製、使用，以及基於該類密碼裝置的應用開發，也可用於指導該類密碼裝置的檢測。

3.3 結構模型

層次關係：智慧密碼鑰匙密碼應用介面位於智慧密碼鑰匙應用程式與裝置之間
img
裝置的應用結構：一個裝置中存在裝置認證金鑰和多個應用，應用之間相互獨立。裝置的邏輯結構如下圖：
img

3.4 函式

img
訪問控制系列函式
img
應用管理函式
img
容器管理系列函式
img
密碼服務系列函式
img
img

3.5 安全要求

3.5.1 金鑰管理要求

裝置金鑰的使用不對應用系統開放；
金鑰必須用安全的方法產生並儲存；
在任何時間、任何情況下，除公鑰外的金鑰均不能以明文形式出現在密碼裝置外；
密碼裝置內部儲存的金鑰應具備有效的金鑰保護機制，防止解剖、探測和非法讀取；
密碼裝置內部儲存的金鑰應具備許可權控制機制，防止非法使用和匯出。

3.5.2 密碼服務要求

使用的密碼演算法應得到國家密碼主管部門的批准；
使用國家密碼主管部門認可的密碼演算法晶片；
本標準所列的所有介面函式均應能被應用系統任意呼叫。

3.5.3 裝置狀態要求

密碼裝置應具有初始和就緒兩個狀態；
未安裝裝置金鑰的密碼裝置應處於初始狀態，已安裝裝置金鑰的密碼裝置應處於就緒狀態；
在初始狀態下，除可讀取裝置資訊、裝置金鑰的生成或恢復操作外，不能執行任何操作，生成或恢復裝置金鑰後，密碼裝置處於就緒狀態;
在就緒狀態下，除裝置金鑰的生成或恢復操作外，應能執行任何操作；
在就緒狀態下進行的金鑰操作，裝置操作員應經過密碼裝置的認證。

3.5.4 其他要求

密碼裝置應有安全機制和措施，保證金鑰在生成、安裝、匯入、儲存、備份.恢復及銷燬整個生存期間的安全,此安全機制可由裝置廠商自行設計實現

4 呼叫不同介面的程式碼

PKCS#11

相關文章