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

密碼引擎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 Crypto API

微軟的CryptoAPI是Win32平臺下為應用程式開發者提供的資料加密和安全的編碼介面。CryptoAPI函式集包含了基本的ASN.1的編碼、解碼，雜湊，資料加密和解密，數字證書管理等重要的密碼學應用功能。資料的加密、解密支援對稱和非對稱兩類演算法。CryptoAPI是所有微軟的Win32的應用程式以及第三方廠商應有程式使用的資料加密介面，諸如Internet Explorer、OutLook、Adobe等應用都是基於CryptoAPI開發的。

1.1 Crypto API在程式設計中的使用方式

CryptoAPI本身不實現密碼運算相關操作，而是作業系統通過呼叫CryptoSPI函式介面相應的加密服務提供者函式（CSP）來實現。CryptoAPI函式使用“加密服務提供者”（CSP）完成資料加密、解密以及金鑰的儲存管理、所有的CSP都是相互獨立的模組。理論上，CSP應該獨立於特定的應用程式，也就是說所有的應用程式可以使用任何一個CSP。但是，實際上有些應用程式只能與特定的CSP協作。CSP與應用程式之間的關係類似於Windows GDI模型。CSP就類似於圖形硬體驅動程式。

1.2Crypto API包含的函式

CryptoAPI體系主要由以下幾部分組成：

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

1.2.1基本加密函式

服務提供者函式

** 金鑰的產生和交換函式**

編碼/解碼函式

資料加密/解密函式

雜湊和數字簽名函式

1.2.2 證書和證書庫函式

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

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


維護函式

1.2.3 證書驗證函式

證書驗證是通過CTL 和證書列表進行的.
使用CTL的函式

證書鏈驗證函式

總結這些API在程式設計中的使用方式

（1）Crypto API
使用CryptoAPI編寫一個檔案保護程式，具有如下功能：

（1）給定明文檔案，生成加密檔案，同時產生檔案的數字簽名檔案；

（2）給定密文檔案，解密出明文檔案，並驗證簽名的正確性。

在不安全的網路上進行安全的資料傳輸涉及三個方面的要求：資訊隱藏，身份鑑別和完整性檢驗。CryptoAPI除了提供上述三個功能外還提供標準的ASN.1編碼、解碼，資訊解密，數字證書和證書儲存區的管理，證書信任列表、吊銷列表和證書有效性檢查等功能。

資訊隱藏
資訊隱藏的意義是保障資訊內容只能被特定的人獲取。資訊隱藏通常是使用某種形式的密碼學方式。資料加密演算法能保障資訊的安區隱藏和傳輸。資料加密演算法是將明文資料經過一定的變換使其看上去是一組毫無意義的資料。在沒有加密金鑰的情況下，對於好的加密演算法想從密文獲取明文資訊是不可能的。被加密的資料可以是任意的ASCII編碼文字檔案，資料庫檔案，和任意需要進行安全傳輸的資料。這裡，“資訊”是指任意的一段資料，“明文”是指任意一段沒有被加密的資料，“密文”是指任意一段加密的資料。被加密的資料可以在不安全的通道上進行傳輸而不傷害其安全性。之後，密文可以被還原成明文.

資料加密和解密的概念是：對資料加密的時候需要一個加密金鑰，相當於門上的一把鑰匙。解密的時候，需要使用一個解密金鑰來解開資料。加密金鑰、解密金鑰可以相同也可以不相同。
加密金鑰必須小心儲存，給其它使用者的時候也必須通過安全的通道傳遞。對解密金鑰的訪問許可權必須小心控制，因為擁有解密金鑰意味著可以解開所有相應加密金鑰加密的資訊。

身份鑑別
安全通訊的前提是通訊的雙方知道對方的身份。身份鑑別的任務就是鑑別一個使用者或者實體的真實身份。標識使用者身份的文件通常被稱為信任狀或者憑證。

身份鑑別有時候也用來判定接受的資料就是被髮送的資料。如果A向B傳送了一段資料，B需要鑑別這段資料就是A發出去的，而不是其它冒充A發出去的。為了滿足這類驗證的需求，CryptoAPI提供數字簽名和校驗函式，用來對資訊進行鑑別。

因為在計算機網網路上傳輸的資料與使用者之間並沒有物理連線，因此對資料進行鑑別的憑證也必須能夠在網路上進行傳輸。這種憑證必須由受信任的憑證發行機構發行。

數字證書就是平常說的證書就是這種憑證，是計算機在網路上進行身份驗證的有效憑證。

數字證書是由一個被稱為證書機構的信任組織或實體頒發的憑證。它包含與證書對應的使用者公鑰以及其它一些記錄證書主題和使用者資訊的資料。證書機構只有在驗證了證書主題和證書對應的使用者公鑰的有效性之後才會簽發證書。

證書申請者和證書機構之間交換籤發證書資訊可以使用物理介質，比如軟盤，進行傳輸。通常，這種資訊都是在計算機網路上進行完成的。證書機構使用被信任的服務程式處理使用者的請求和證書的簽發工作。

完整性檢測
任何通過不安全介質傳輸的資訊都可以被意外或蓄意的修改。在現實世界中，蓋章、簽名就是用來提供和證明資訊完整性的工具。

資訊的接收者不但需要確定資訊是由誰傳送的，還要確定自己收到的資訊是傳送者傳送的資訊，而沒有任何的變化。要建立資料的完整性檢測機制，不僅要傳送資訊本身，還要傳送用來校驗資料的資訊，這一資訊通常被稱作雜湊值。資料和驗證資訊都可以與數字簽名一起傳送來證明其完整性。

PKCS#11

架構

會話狀態

物件

機制

根據機制標記，可以分為幾類：
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：金鑰派生

操作

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

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

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

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

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

令牌的邏輯檢視

Cryptoki的令牌邏輯檢視是一個能儲存物件和能執行密碼函式的裝置。Cryptoki定義如下三個物件：資料、證書和金鑰。資料物件由應用程式定義。一個證書物件儲存一個證書。一個金鑰物件儲存一個密碼金鑰。金鑰可以是一個公共金鑰、一個私鑰或是一個保密金鑰，每個種類的金鑰在專用機制中使用其的輔助型。令牌的這種邏輯檢視如下圖所示：

GM/T 0016-2012

3.1 簡介

這個標準規定了基於PKI密碼體制的智慧密碼鑰匙密碼應用介面，描述了密碼應用介面的函式、資料型別、引數的定義和裝置的安全要求。

3.2 結構模型

層次關係：智慧密碼鑰匙密碼應用介面位於智慧密碼鑰匙應用程式與裝置之間

裝置的應用結構：一個裝置中存在裝置認證金鑰和多個應用，應用之間相互獨立。裝置的邏輯結構如下圖：

裝置管理系列函式

訪問控制系列函式

應用管理函式

容器管理系列函式

密碼服務系列函式

四、GMT 0018-2012

本標準的目標是為公鑰密碼基礎設施應用體系框架下的服務類密碼裝置制定統一的應用介面標準，通過該介面呼叫密碼裝置，向上層提供基礎密碼服務。為該類密碼裝置的開發、使用及檢測提供標準依據和指導，有利於提高該類密碼裝置的產品化、標準化和系列化水平。
範圍：本標準規定了公鑰密碼基礎設施應用技術體系下服務類密碼裝置的應用介面標準，適用於服務類密碼裝置的研製、使用，以及基於該類密碼裝置的應用開發，也可用於指導該類密碼裝置的檢測。
密碼裝置應用介面在公鑰密碼基礎設施應用技術體系框架中的位置：在公鑰密碼基礎設施應用技術體系框架中，密碼裝置服務層由密碼機、密碼卡、智慧密碼終瑞等裝置組成，通過本標準規定的密碼裝置應用介面向通用密碼服務層提供基礎密碼服務。如下圖：

基礎密碼服務包括金鑰生成、單一的密碼運算、檔案管理等服務。
本標準採用C語言描述介面函式，無特別說明時，函式中引數的長度單位均為位元組數。

裝置管理類函式：

開啟裝置：SDF_OpenDevice
關閉裝置：SDF_CloseDevice
建立會話：SDF_OpenSession
關閉會話：SDF_CloseSession
獲取裝置資訊：SDF_GetDeviceInfo
產生隨機數：SDF_GenerateRandom
獲取私鑰使用許可權：SDF_GetPrivateKeyAccessRight
釋放私鑰使用許可權：SDF_ReleasePrivateKeyAccessRight

金鑰管理類函式：

匯出 RSA 簽名公鑰:SDF_ExportSignPublicKey_RSA
匯出 RSA 加密公鑰:SDF_ExportEncPublicKey_RSA
產生RSA非對稱金鑰對並輸出:SDF_GenerateKeyPair_RSA
生成會話金鑰並用內部RSA公鑰加密輸出:SDF_GenerateKeyWithIPK_RSA
生成會話金鑰並用外部RSA公鑰加密輸出:SDF_GenerateKeyWithEPK_RSA - 導人會話金鑰並用內部RSA私鑰解密:SDF_ImportKeyWithISK_RSA
基於 RSA 演算法的數宇倍封轉換:SDF_ExchangeDigitEnvelopeBaseOnRSA
匯出 ECC 簽名公鑰：SDF_ExportSignPublicKey_ECC
匯出 ECC 加密公鑰:SDF_ExportEncPublicKey_ECC
產生ECC非對稱金鑰對並輸出：SDF_GenerateKeyPair_ECC
生成會話金鑰並用內部ECC公鑰加密輸岀:SDF_GenerateKeyWithIPK_ECC - 生成會話金鑰並用外部ECC公鑰加密輸出:SDF_GenerateKeyWithEPK_ECC
匯入會話金鑰並用內部ECC私鑰解密:SDFJmportKeyWithlSKJECC
生成金鑰協商引數並輸出:SDF_GenerateAgreementDataWithECC
計算會話金鑰:SDF_GenerateKey WithECC
產生協商資料並計算會話金鑰:SDF—GenerateAgreementDataAndKeyWithECC
基於 ECC演算法的數字信封轉換:SDF_ExchangeDigitEnvelopeBaseOnECC
生成會話金鑰並用金鑰加密金鑰加密輸出: SDF_GenerateKeyWithKEK
匯入會話金鑰並用金鑰加密金鑰解密:SDF_ImportKeyWithKEK
銷燬會話金鑰:SDF_DestroyKey

非對稱演算法運算類函式

部公鑰 RSA 運算:SDF_ExternalPublicKeyOperation_RSA
內部公鑰 RSA 運算:SDF_InternalPublicKeyOperation_RSA
內部私鑰 RSA 運算:SDF_InternalPrivateKeyOperation_RSA
外部金鑰 ECC 驗證:SDF_ExternalVerify_ECC
內部金鑰 ECC 簽名:SDF_InternalSign_ECC
內部金鑰 ECC 驗證:SDF_InternalVerify_ECC
外部金鑰 ECC 加密:SDF_ExternalEncrypt_ECC

對稱演算法運算類函式

對稱加密：SDF_Encrypt
對稱解密：SDF_Decrypt
計算MAC:SDF_CalculateMAC

雜湊運算類函式

雜湊運算初始化：SDF_HashInit
多包雜湊運算：SDF_HashUpdate
雜湊運算結束：SDF_HashFinal

安全要求

（1）基於本標準設計、開發的密碼裝置在金鑰管理方面，應滿足以下要求：
裝置金鑰的使用不對應用系統開放；
金鑰必須用安全的方法產生並存儲；
在任何時間、任何情況下，除公鑰外的金鑰均不能以明文形式出現在密碼裝置外；
密碼裝置內部儲存的金鑰應具備有效的金鑰保護機制，防止解剖、探測和非法讀取；
密碼裝置內部儲存的金鑰應具備許可權控制機制，防止非法使用和匯出。
（2）密碼服務要求：
使用的密碼演算法應得到國家密碼主管部門的批准；
使用國家密碼主管部門認可的密碼演算法晶片；
本標準所列的所有介面函式均應能被應用系統任意呼叫。
（3）裝置狀態要求：
密碼裝置應具有初始和就緒兩個狀態；
未安裝裝置金鑰的密碼裝置應處於初始狀態，已安裝裝置金鑰的密碼裝置應處於就緒狀態；
在初始狀態下，除可讀取裝置資訊、裝置金鑰的生成或恢復操作外，不能執行任何操作，生成或恢復裝置金鑰後，密碼裝置處於就緒狀態;
在就緒狀態下，除裝置金鑰的生成或恢復操作外，應能執行任何操作；
在就緒狀態下進行的金鑰操作，裝置操作員應經過密碼裝置的認證。
（4）其他要求：
密碼裝置應有安全機制和措施，保證金鑰在生成、安裝、匯入、儲存、備份.恢復及銷燬整個生存期間的安全,此安全機制可由裝置廠商自行設計實現。

五、以龍脈GM3000Key為例，寫出呼叫不同介面的程式碼（Crypto API,PKCS#11，SKF介面），把執行截圖加入部落格，並提供程式碼連結