Windows 環境與 Security 發展工具

本論文程式主要使用 Platform SDK 裡的 CryptoAPI 來開發，CryptoAPI 提供 程式發展公具，讓程式設計師可以透過 CryptoAPI 進行加密、解密、驗證數位憑 證、將資料編碼成 ASN.1(Abstract Syntax Notation One)型式或解碼 ASN.1 的訊 息，開發應用程式的程式設計師可以使用 CryptoAPI 裡的函式而不需要知道底層 硬體的實際運作流程，CryptoAPI 的運作需要 Cryptographic Service Provider(CSP) 的配合才能正確執行密碼函式。要在 windows 平台上開發應用程式，必須先清 楚的了解微軟提供的軟體開發環境並具備 windows 平台相關知識，軟體開發者 須遵循微軟發布的系統發展規則，應用程式才能在 windows 平台上正確的執行，

以下介紹實作本篇論文程式所必備的知識:

(1). 密碼服務管理員(Cryptographic Service Providers)

CSP 是一個實際運作密碼學演算法相關的驗證、編碼、加密等運作的獨立軟

定義名稱 所代表的意義

MS_DEF_PROV "Microsoft Base Cryptographic Provider v1.0"

MS_ENHANCED_PROV "Microsoft Enhanced Cryptographic Provider "

MS_STRONG_PROV "Microsoft Strong Cryptographic Provider"

MS_DEF_RSA_SIG_PROV

"Microsoft RSA Signature Cryptographic Provider"

MS_DEF_RSA_SCHANNEL_PROV

"Microsoft RSA SChannel Cryptographic Provider"

MS_DEF_DSS_PROV "Microsoft Base DSS Cryptographic Provider"

MS_DEF_DSS_DH_PROV

"Microsoft Base DSS and Diffie-Hellman Cryptographic Provider"

MS_ENH_DSS_DH_PROV

"Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider"

MS_DEF_DH_SCHANNEL_PROV

"Microsoft DH SChannel Cryptographic Provider"

MS_SCARD_PROV

"Microsoft Base Smart Card Cryptographic Provider"

式選擇加密、簽章演算法，但實際的密碼運作都交由 CSP 完成。

3. 應用程式不能先前使用者的信用資料或驗證相關訊息，信用資料就是先前其 他使用者透過安全原則(Security Principal) 所建立的身分鑑別實體，例如:密 碼或是 Kerberos 協定票証，將來 CSPs 加入生物指紋的驗證機制時，應用程 式不需修改驗證模組，只需修改傳給 CSPs 的變數資料結構。

(2) 資料編碼與解碼

在安全的通道傳送加密資料必須先序列化(Serialize)，例如:有兩台電腦透過 網路或電話線傳送資料，傳送者的資料需先編碼成 0 與 1 組合而成的串列，資料 訊息才能透過網路或電話線依序傳送給接收者並解碼為原始的資料格式。這段過 程需透過軟體運算與硬體傳送才能完成。

圖 3-1 傳送資料的編碼解碼流程

上圖說明兩台電腦透過網路傳送資料的流程，電腦 1 的應用層將欲傳送的原始資 料交給編碼/解碼層，編碼/解碼層將資料編碼為 byte 資料格式交給硬體層，硬 體層在將 byte 資料轉換為序列化串列並傳送給電腦 2，電腦 2 將硬體層收到序列 化串列以先前敘述的程序逆向解碼為原始資料格式，在這過程中有一個重大的議 題，編碼/解碼層如何將資料編碼或解碼成雙方皆可認可的資料格式呢?大部分的 通訊協定會使用雙方皆認可的抽象資料或抽象物件表示方法，國際上認可的抽象

資料/物件表示法為 ASN.1(Abstract Syntax Notation One)，由 ITU 制定並經由 ISO (International Standard Organization)認可通過，ASN.1 定義在 CCITT Recommenda tion X.208 文件中，故電腦 1 的應用層必須將資料表示為 ASN.1 語法，在傳給編 碼/解碼層，電腦 2 的編碼/解碼層在收到 byte code 後，需將 byte code 編碼為 ASN.1 語法的資料，如此接收者才能正確得到傳送者的原始資料格式。

(3) 金鑰容器(Key Container)

即金鑰儲存庫，用來儲存特並使用者所有的金鑰(公開金鑰和私密金鑰)，每 一個容器都有其獨一無二的容器名稱，當使用 CryptAcquireContext()輸入容器名 稱，就可以得到金鑰容器的 handle。

(4) 憑證貯藏(Certificate Store)

依照字面上解釋，即是憑證永久的貯藏倉庫，當程式使用到某一憑證，

程式設計師可以只在記憶體創造或開啟一憑證貯藏，而不一定將憑證儲藏在永久 的憑證貯藏，此憑證會隨著程式執行結束而消失。憑證貯藏的存在是為了要集中 管理憑證和分類憑證，Windows 預先定義了四種不同的憑證貯藏: 個人(MY Stor -e)、信任的根憑證授權(Root Store)、企業信任(Trust Store)、中繼憑證授權(CA Store)，此四種不同階層的憑證貯藏，即如同先前所述 X.509 階層式架構一樣，

簽發個人憑證(儲存在 MY Store)的發行者公鑰憑證，若亦儲存在信任的根憑證 授權(Root Store)或企業信任(Trust Store)裡，則此個人憑證即受到信任且可以使 用，若簽發個人憑證(儲存在 MY Store)的發行者公鑰憑證，沒有儲存在信任的 根憑證授權(Root Store)或企業信任(Trust Store)裡，則此個人憑證即未受到信任 且不能使用，往上一層來看，若簽發企業信任憑證的發行者公鑰憑證沒有儲存在 中繼的根憑證授權(CA Store)裡，則此企業信任憑證和企業信任憑証所簽發的個 人憑證皆不受到信任且無法使用，這裡的憑證貯藏和 X.509 憑證金字塔制度的觀 念是相通的。

(5) Windows 的憑證資料結構 1. Certificate Context

Certificate Context 為電子憑證的 C 資料結構，包含:憑證貯藏的 handle、一指標指向原始編碼後的憑證體(Certificate Blob)、和一個指向 憑證資訊(Certificate Info)資料結構的指標。CERT_INFO 為憑證的中心 所在，包含憑證所有的基本資訊，其結構如同先前所述 X.509 v3 版本 的電子憑證一般

圖 3-2 CERT_CONTEXT 和 CERT_INFO 關係圖

若程式設計師想要將特定的資料寫入 CERT_INFO，資料需先寫入特定的 資料結構(SDK 先定義好的)，再經由特定函式編碼(CertEncode())，編 碼過後的資料方能寫入 CERT_INFO。

上圖表示將 abc 字串加入 CERT_INFO 資料結構使得憑證的發行者名稱 為 abc 過程，下列步驟詳細說明整個流程:

Ⅰ.宣告發行者名稱的字串，即為包含 abc 的字串。

Ⅱ.產生 CERT_RDN_ATTR 陣列並初始化陣列成員 CERT_RDN_VALUE _BLOB 為發行者名稱 ABC。

Ⅲ. 產生 CERT_RDN 結構並將結構成員指標 PCERT_RDN_ATTR 指向 CERT_RDN_ATTR 起始位址。

Ⅳ. 產生 CERT_NAME_INFO 結構並將結構成員指標 PCERT_RDN 指向 CERT_RDN 起始位址。

Ⅴ.呼叫 CryptEncodeObject()將先前所產生的 abc、CERT_RDN_ATTR、

CERT_RDN、CERT_NAME_BLOB 編碼為 byte 資料型態。

Ⅵ.將編碼後的 byte 資料指派給 CERT_INFO 成員變數 CERT_NAME_

BLOB，如此在 windows 平台上所看到的憑證發行者名稱即為 abc。

3.憑證擴充屬性(Certififcate Extended Properties)

X.509 v3 憑證的憑證擴充屬性欄位值，在憑證產生之後就不能做任 何的更改，只能讀不能寫；憑證擴充屬性屬於憑證本體的一部分，但發 行者簽發時只簽署憑證本體，而不理會憑證擴充屬性，然而，在微軟 Windows 平台上以 CryptoAPI 產生的憑證，CryptoAPI 允許程式設計師 動態增加憑證擴充屬性，要注意的是在 windows 平台上產製的憑證，其

的意義:

․CERT_KEY_PROV_HANDLE_PROP_ID:代表憑證所使用的特定 CSP

․CERT_KEY_PROV_INFO_PROP_ID:代表憑證相對應的私鑰

․CERT_SHA1_HASH_PROP_ID and CERT_MD5_HASH_PROP_ID:這 兩個屬性指出憑證執行雜湊運算時，所支援的雜湊演算法。