應用程式開發者透過裝置業者所提供的軟硬體介面，操作加解密裝置並使用其內的金鑰來進行加解密動作。然而琳瑯滿目的裝置與各種軟硬體介面，一則提高了開發應用程式的困難度，二來被裝置規格綁死，阻礙了相關應用的發展。因此需要一個依據功能性需求所定義的共同介面，讓加解密裝置業者能夠依據介面開發中介軟體，而應用系統業者能夠使用標準介面的中介軟體開發系統。

共通的介面Cryptoki

Cryptoki代表了Cryptographic Token Interface的縮寫，即是定義一組標準化的Crypto Token高階操作介面，描述了Crypto Token可能提供的密碼學演算法、受保護的各類物件與標準化的操作流程。將Crypto Token與應用程式間徹底切割，撰寫應用程式不需要瞭解底層的Crypto Token如何實做、如何與作業系統溝通等，也不會被加解密裝置業者綁死；而裝置業者則專注在如何實作Crypto Token，並撰寫「標準」的API供應用程式開發者使用。

《圖一　應用程式、Cryptoki與Crypto Token 的關係　　》

目前市面上所出現的Cryptoki標準大致上為兩種：CSP與PKCS#11。CSP全名是Cryptographic Service Provider，是微軟所提出的標準，CSP設計必須與Windows作業系統緊密結合，加解密裝置業者在實做CSP後，須將程式送交微軟審核簽署後發行，以確保CSP的安全性；應用系統業者通常不直接使用操作CSP API，而透過使用微軟CAPI（Cryptographic API）間接地操作CSP。PKCS#11則是由RSA Laboratories所提出的，它是以ANSI C的方式實做，並以動態模組（.dll或.so檔案）方式發行，因此可以很容易的移植到不同的作業系統如Microsoft Windows、Linux等Unix like OS。

PKCS#11

PKCS#11詳細定義了操作加解密裝置所需的運作模式、使用者模式、函式介面、錯誤碼、物件類別與物件所支援的各種加解密演算法機制（Mechanism），應用系統開發者僅需使用少數操作模式與各類常數，就能夠使用或操作加解密裝置內各類物件與金鑰，或用其金鑰進行加密。以下即簡介其內容與如何撰寫一個PKCS#11程式。

Slot V.S. Token

Token代表一個可儲存金鑰的裝置實體，可以是一張智慧卡、一台安控伺服器等。而PKCS#11則定義虛擬的插槽（Slot）用來對應實體的Token，其對應方式沒有一定的規則，一對一、一對多或多對一的關係，皆是可能的對應關係；一個Slot可以對應一個實體的USB Token或一張IC卡亦或是HSM中的一部分；又或者是一個Slot對應多台安控伺服器。對應的規則完全看加解密裝置業者依據需求賦予不同的意義。應用系統開發者僅需要把每個Slot當成一個獨立的Token。

PKCS#11的物件類別架構

而在Slot的下面管理多種類型的物件，每個物件都包含了許多的屬性（Attribute），大致上可分為幾類：一、物件的辨識資料，如Label、ID、Subject等，用來與其他物件區分的辨識值；二、物件的儲存特性，如Token、Private，描述物件是否永久存在，是否公開使用，或是否受到保護不能匯出等；三、描述物件支援的操作（如Encrypt、Decrypt、Sign、Verify等）；四、放置物件的值，可能是金鑰值或資料值（如Value、Modulus等）。物件可以整理成一個類別階層，子類別除了有自己專屬的屬性外，亦繼承父類別擁有的屬性。例如今天有一個Secret Key物件產生，這個物件則包含了其父類別Key與Storage的屬性，因此在Secret Key應包含Token、Encrypt等屬性。如圖二所示。

《圖二　類別架構》

PKCS#11的屬性樣板

為了搜尋PKCS#11內的物件或是讀取物件的屬性值，經常使用「樣板」（Template）的方式，即是建立一個放置「屬性」的陣列，包含了屬性的代碼與屬性值，使用者可透過這些屬性過濾出需要的物件；在另外一方面，樣板可用來當成設定（Set）或取出（Get）物件的屬性的媒介。使用者可以只填入屬性代碼，API會將屬性值「回填」到樣板陣列中，透過這樣的方式取得屬性值。

PKCS#11的使用者模式與狀態循環

要使用Slot內的物件前，必須建立一個Session，使用C_OpenSession函式選擇一個Slot並開啟一個Session（會議期），才能夠進行進一步的物件操作或使用演算法。而C_OpenSession、C_CloseSession、C_Login、C_Logout、C_Initalize、C_Finalize為PKCS#11主要狀態循環的操作函式。C_Initalize、C_Finalize代表PKCS#11模組與加解密裝置的整體初始化與結束，提供模組或加解密裝置取得或清除系統資源的時機。當呼叫C_Initalize進行初始化，狀態就會進入「初始」的狀態，準備接受應用程式提出開啟交易的請求。而使用者呼叫C_OpenSession之後，狀態會進入「Public Session」的狀態，此時由於並沒有登入選定使用者模式，因此只能操作公用物件。假設使用者呼叫了C_Login，狀態則會進入Private Session，代表可以操作公有與私有物件。如果使用者想要更換登入的使用者模式，則可呼叫C_Logout讓狀態回復到Private Session的狀態，並且重複呼叫C_Login。若使用者使用完成或需切換到另外一個Slot時，則需呼叫C_CloseSession將狀態回覆到初始狀態。除此之外，PKCS#11定義了兩種使用者模式：SO與User，只有在C_Login時選擇User模式時，可以自由操作Slot內的物件，SO模式則是用來做初始化Slot等系統管理功能。

《圖三　PKCS#11狀態循環》

使用JAVA開發PKCS#11程式

一般開發PKCS#11程式大多使用ANSI C，過去使用Java開發PKCS#11的程式，需要以JNI（Java Native Interface）的方式來寫，由於必須跨越C與JAVA兩種語言，且開發動作繁複，因此一直是Java開發導入PKCS#11的障礙。所幸Sun J2SE 1.5以後的版本，開始支援PKCS#11。J2SE提供兩種呼叫PKCS#11的方法，一種是包成JCA/JCE的方式；另外一種叫做PKCS#11 Wrapper，是將PKCS#11所提供的函式與常數，依據PKCS#11 API的形式包裝成Java的類別成員函數與常數，放置在sun.security.pkcs11.wrapper這個包裹裡面。這也是筆者較為推薦的方式，原因其一是PKCS#11開發者可以完全遵循PKCS#11所定義開發模式來開發相關程式，其二是JCA/JCE的方式並沒有完整實做PKCS#11可能提供的所有功能，使得程式開發人員在開發相關程式會有所限制。

在使用C語言開發PKCS#11程式，需要載入PKCS#11模組（.dll 檔案或 .so檔案），取得PKCS#11函式Handle並呼叫C_Initalize進行初始化，在不使用之後還需呼叫C_Finalize並釋放模組，程式開發者必須小心管理模組與狀態，才能維持程式正常不出錯。而PKCS#11 Wrapper的PKCS11類別，程式開發人員僅需呼叫靜態函數getInstance取得一個PKCS11實體，就可以隨心所欲的操作PKCS#11 API所提供的函式，毋需管理PKCS#11模組的狀態，這是因為PKCS#11被設計成一個單體，只有在第一次呼叫getInstance時，程式會載入PKCS#11模組並進行初始化，之後呼叫所取得都是同一個實體，只有在物件被GC清除時才會呼叫C_Finalize並釋放PKCS#11模組。

Java PKCS#11 Wrapper所提供的PKCS11Constants類別放置了所有PKCS#11會使用到的「常數」，受限於篇幅完整詳述，讀者可於RSA Laboratories取得完整PKCS#11的文件；有關於屬性的常數可查詢開頭為CKA的常數，物件類型可查詢開頭為CKO的常數，與金鑰類型相關的可使用CKK開頭的常數，與機制的相關的物件可查詢開頭為CKM的常數，搭配PKCS11類別的PKCS#11成員函數，應可滿足程式開發人員在使用PKCS#11介面的需求。

---作者任職於資策會網路多媒體研究所---