數位簽章

C ：憑證(Certificate)

d ：發文方製作之訊息摘要(Digest)

2. 使用RSA演算法將訊息摘要以發文方之私鑰加密形成此發文方之數位簽章 S = ESKs (H(M))。

3. 將本文加上數位簽章及發送方之公開金鑰憑證( M & S & C )傳送至接收方。

4. 接收方先以發送方憑證欄位中之憑證中心簽章來驗證發送方之憑證是否有效 並確認發文者之身分。

5. 如確認憑證無誤，則以發送方憑證內的公鑰將簽章 S 解密，得到發文方之訊 息摘要d = DPKs ( ESKs (H (m)))

6. 收文方將收到之本文 M 內容以雜湊函數(Hash)運算，得到參考訊息摘要 d＇= H(m) 。

7. 再將此訊息摘要d′與發文方之訊息摘要 d 比對，若 d′=d ，則表示來文於 傳輸過程中未被修改，收文方以此確認發文方之身分未被造假；反之d′ ≠ d ， 則代表來文已被篡改，。

相同文件由不同發文者簽署時，簽章不同，相同發文者簽署不同文件時，簽 章也不同，簽章檢驗容易，可由任何第三者來執行。驗證簽章內容一致時可以確 定:

1. 發文者身分 (身分不可否認性) 2. 明文內容完整性 (內容未被竄改)

但未加入保密機制，故其他人可以看見明文內容。

圖 2-10 數位簽章流程圖

第五節 Secure Socket Layer(SSL)

SSL 為Secure Socket Layer 的簡稱，最早在1994 年Netscape 所提出的標準 草案，經多次的改進升級，目前最新版是1996 年11 月提出3.0 IETF(Internet Engineering Task Force)，其工作位於應用層的HTTP協定與會議層的TCP協定之 間。SSL 已廣泛被業界所接受,成為 Internet 的通訊安全國際標準，除 Netscape 的產品外, 包括微軟的IE 等很多其他產品均支持SSL 的通訊協議。因為SSL 的 式演算法的金鑰(Session Key)，盡而建立與用戶端的加密訊息通道。

2. Record

由於對稱加密金鑰由用戶端產生，使用伺服器的公開金要加密後在傳送到網 路，所以只有擁有私密金鑰的伺服器才能解密獲得正確的對稱示金鑰，伺服 器與用戶端就可以使用此對稱是金鑰加密需要傳輸的資料，以及解密對方傳 送的資料。

圖 2-11 SSL 連線 Handshake 流程

第六節 DiskOnKey USB Flash Disk

DiskOnKey 為傳輸速度全世界最快的 USB 外接快閃式硬碟，由以色列的 M- Systems 公司所開發，DiskOnKey 平台以新型 DOK T4 晶片為動力，讀取速度 1000KBytes/sec，可攜式 USB 界面快閃記憶體產品是目前的大熱門，這項技術的 實用性的確不容小覷。目前在同級產品中，最棒的似乎是 M-Systems 所推出的 DiskOnKey 。M-Systems DiskOnKey 採用了許多新技術（如 KeySafe 與 MyKey）

來保護 DiskOnKey 中的資料。裡頭 32 位元的 ARM7 處理器能讓您直接 DiskOn Key 執行一些工具程式，透過加密提供所向披靡的資料保障。此外 DiskOnKey 還附上了一個資料安全軟體 KeySafe，這個軟體就存放在 DiskOnKey 裡。

利用 DiskOnKey 的 KeySafe 軟體，使用者可以設定 Safe Partition 密碼，Safe Partition 的容量大小可以由使用者利用 KeySafe 調整，即使整個 DiskOnKey 的 容量都設為 Safe Partition 都可以，若進入 Safe Partition 的密碼輸入錯誤 3 次，

Key Safe 會自動格式化 DiskOnKey。

DiskOnKey 還具有一項特點-Hidden Area，以 DiskOnKey version 3.x 來說，

具有 15K 的 Hidden Area 可供 M-System 的協力開發廠商開發應用程式存取隱藏

第三章

系統架構與流程

第一節 視窗平台上安全(Security)相關的發展工具與環境

1.1 程式開發工具設定

在 Microsoft Windows 平台上開發應用程式，必須依照 Microsoft MSDN Libr -ary 所發表的 Security 相關知識，並使用微軟發布的函式庫 Platform SDK，Platfo -rm SDK 為一個免費下載的函式庫，程式原始碼並不公開，但提供各式各樣的 SDK(System Develop Kit) 讓有意在 Microsoft 作業系統上開發軟體的程式設計 師使用，以下介紹程式開發前準備工作:

Ⅰ.準備軟體

Microsoft Visual C++ 6.0 以上版本

Microsoft Platform SDK 最新版本(下載網址:

http://www.microsoft.com/msdownload/platformsdk/sdkupdate/)

Ⅱ.設定 Library Path

Platform SDK 下載並安裝完成後，還需在 Visual C++裡設定 Library Path 和 Include Path，Platform SDK 會預設安裝於 C:\Program Files\Microsoft SDK。

1. 開啟 Visual C++ 6.0 主視窗上方 Tools->Options->Directories，在 Show Dir -ectories for:選項中選擇 include files 並將 C:\Program Files\Microsoft SDK

\include 加入 Directories 裡，要注意的是使用者必須把 C:\Program Files

\Microsoft SDK\include 欄位提升到最高的欄位，否則在編譯程式時，會 因為 compiler 先讀取到舊的 include files 造成編譯錯誤。

2. 開啟 Visual C++ 6.0 主視窗上方 Tools->Options->Directories，在 Show Dir -ectories for:選項中選擇 Library files 並將 C:\Program Files\Microsoft SDK

\Lib 加入 Directories 裡，要注意的是使用者必須把 C:\Program Files\ Micro -soft SDK\Lib 欄位提升到最高的欄位，否則在編譯程式時，會因為 comp -iler 先讀取到舊的 Library files 造成未知的編譯錯誤。

1.2 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 憑證的憑證擴充屬性欄位值，在憑證產生之後就不能做任 何的更改，只能讀不能寫；憑證擴充屬性屬於憑證本體的一部分，但發 行者簽發時只簽署憑證本體，而不理會憑證擴充屬性，然而，在微軟

X.509 v3 憑證的憑證擴充屬性欄位值，在憑證產生之後就不能做任 何的更改，只能讀不能寫；憑證擴充屬性屬於憑證本體的一部分，但發 行者簽發時只簽署憑證本體，而不理會憑證擴充屬性，然而，在微軟