3﹒1 系統需求
3﹒2 系統核心設計
3﹒2－1 使用者權限問題 3﹒2－2 加密使用之 API
3﹒2－3 滑鼠右鍵蹦出式選單功能 3﹒2－4 自解檔之應用
3﹒3 系統流程
3﹒1 系統需求 系統需求規格書
功能 一 : 使用者身份驗證
Function 使用者身份驗證
Description 使用本系統時，系統會要求使用者先登入，使用者必 須輸入帳號和密碼，系統驗證通過以後才會開放使用 者的權限進入本系統 ;若是第一次使用本系統，則必 須申請新的帳號及密碼才可使用本系統
Inputs 新使用者申請： 申請新帳號、密碼 使用者登入 ： 輸入帳號、密碼
Source 使用者的帳號、密碼都是由使用者輸入，但使用者帳 號、密碼是否存在、正確皆由系統來驗證
Outputs 新使用者申請時，其資料會新增在系統內建的一個記 錄使用者資料的檔案內，若其申請的帳號有重複等錯 誤發生或者使用者登入帳號密碼有誤時，系統會蹦出 錯誤訊息來通知使用者
Destination 目的在保護使用者的隱私 Requires 記錄使用者資料的檔案 Pre-condition 必須安裝本系統
Side-effects 無
功能 二 : 加密與解密
Function 加密解密
Description 通過系統驗證以後，會進入本系統的核心，每個使用 者可以對尚未被他人加密的檔案或資料夾加解密 Inputs 對檔案作加密、解密
對屬於使用者的加解密檔案作修改、存取
Source 對任何檔案的加解密都是由使用者來執行，但是使用 者是否有權限由系統來判定
Outputs 加解密任何檔案都會產生一個和原檔相關聯的案，而 對於他人的機密檔案，系統不開放權限給予使用 Destination 目的在保護機密檔案
Pre-condition 必須先有使用者驗證通過的步驟 Side-effects 無
以下將針對系統的功能性需求和非功能性需求作討論 Functional requirements
1﹒ 系統操作流程必須讓使用者能非常流暢的完成，每個按鈕、工具 名稱盡可能讓使用者一看就懂，不要用容易讓使用者誤會的文字。
2﹒ 系統對於所有他人尚未加密的檔案都能執行加解密的功能。
3﹒ 每個使用者都必須有屬於自己登入系統時的帳號(ID)、密碼(PW)，
而系統必須將所有使用者的 ID、PW 另外儲存在一個文件內並且保 護。
4﹒ 系統另提供自解檔的功能，在傳送機密檔案時即使對方電腦中沒 安裝本系統也可享有加解密的功能。
Non-Functional requirements
1﹒ 作業系統需求 2000pro 2000server XP 記憶體空間需求大小 3 MB
2﹒ 系統開發使用的程式語言是 Visual C++，必需具備視窗程式、加 解密以及 windows 中 Registry 等觀念。
3﹒ 除安裝本系統來執行相關加解密運作以外，也可利用自解檔的功 能。
4﹒ 本系統設計不可透露任何和使用者有關的資料。
3﹒2 系統核心設計 3﹒2－1 使用者權限問題
在系統設計上，首先，系統會先要求你輸入使用者名稱和密碼。
當使用者輸入的密碼和原先不符時，將無法對檔案或資料夾進行加 解密。而在實作上，KEY 的產生和使用者的密碼產生關聯性。當使 用者輸入密碼後，密碼會經由 hash function 產生一個 hash value，
然後再將此 hash value 當作是 key 要產生的一個必備參數來產生 key。所以當一個非法的使用者想要解密一個不是自己所加密的檔 案時，將導致加解密失敗。
由於 Microsoft 所提供的加解密函式絕大多數均會和系統登錄 的使用者產生關聯性，這將造成的這將造成在 A 電腦中加密的檔案 無法移到 B 電腦中解密。最後所採用的做法便是將使用者的 KEY 經 由加密後存放到檔案中的某個位置，在解密時先將 KEY 解密，在用 此 KEY 來解密。
3﹒2－2 加密使用之 API Cryptography API（Crypto API）簡介
微軟最先在 1996 關注於密碼系統問題，之後發展出 Crypto API (1.0 and 2.0) 和 CAPICOM 兩套密碼系統。在 windows 系統中 藉由 advapi32.dll 提供我們 Crypto API 函式庫，這個函式庫提供 應用程式開發者在 Win32 環境下使用加密、驗證等安全服務時的標 準加密介面，並且包裝一些複雜的演算法，免除了我們自行實做上 的困難；透過 Crypto API，我們可以輕易的保護所需保護的資料。
目前 Crypto API 分為 Crypto API 1.0 和 Crypto API 2.0 2 個版本，描述如下： Crypto API 1.0 提供包含對密碼系統的支援、
密鑰交換、管理、Cryptographic Service Providers（CSP）。Crypto API 2.0 則添加了對證書管理的支援、Cryptographic Service Provider 系統結構的可插入結構並可以通過使用不同的 CSP 來擴展 不同的安全功能。目前支援 Crypto API 的系統有 Windows 95 OSR2，
Windows 98/Me、Windows SP3, Windows 2000/XP。
Crypto API 在系統中的地位
GINA Authenticode Network Interface
Smart Card Based Components
閱讀器
Crypto API
編碼標準 Secure Channel
認證及通道加密
Crypto API 的應用
應用程序
安全通道
證書管理服務
Crypto API 證書的
儲存 RSA base CSP
Fortezza CSP
Smart card CSP
密碼數 據庫
圖 3﹒2 Crypto API 的應用圖
Crypto API 的結構
圖 3﹒3 Crypto API 的結構表
Crypto API 的功能是爲應用程式開發者提供在 Win32 環境下 使用加密、驗證等安全服務時的標準加密介面。CryptoAPI 之上是 應用程式，之下是 CSP（Cryptographic Service Provider）。CSP 是一個真正執行加密功能的獨立模組，典型的 CSP 有微軟 RSA Base Provider。目前任何一個加密服務提供者若想成爲微軟的合法的 CSP，就必須獲得微軟授予的一個簽名文件，該簽名文件保證了微軟 Crypto API 識別該 CSP。對於 Microsoft 的合法的 CSP，微軟會提 供與其 Crypto API 介面的規範，介面的位置在圖中的“- - - - ” 線處。微軟提供的 CSP 安裝程式會將該 CSP 的各個文件安放到相應 的目錄下，並在 Windows NT/98 註冊表中按 CSP 的類型和名稱爲該 CSP 註冊。Crypto API 使用系統註冊表存儲一個 CSP 資料庫，CSP 資料庫中記錄了所有已安裝到一個電腦中的 CSP。
Crypto API 的提供 5 類函數
＊Base cryptographic functions
•Context functions: 連接 CSP
•Key generation functions：生成和存儲密鑰
•Key exchange functions：交換或傳輸密鑰
＊Certificate encode/decode functions
＊Certificate store functions
＊Simplified message functions, used to
•encrypt and decrypt messages and data
•sign messages and data
•verify the authenticity of signatures on received messages and related data
＊Low-level message functions
關於 CSP( Cryptographic Service Provider)
由於編碼演算法很複雜，容易變動又常有專利權的問題，所以 Crypto API 通常以模組的架構來提供應用程式呼叫；支援 Crypto API 的模組又稱之為『編碼服務提供者』。CSP 是真正執行加密工作
(4) Microsoft 使用 RSA Base Provider 在作業系統中提供一個 CSP，使用 RSA 公司的公鑰加密演算法，更多的 CSP 可以根據
–特定的密鑰長度;
–特定的分組加密演算法的缺省模式
（7）若兩個或多個應用間欲交換密鑰和加密的消息，那麽它們必須 使用同一類型的 CSP。
下面表格表示預定的 CSP 類型
Provide Type Key
exchange
SignatureEncryption Hashing
PROV_RSA_FULL RSA RSA RC2, RC4 MD5, SHA
PROV_RSA_AES RSA RSA RC2, RC4,AES MD5, SHA
PROV_RSA_SIG None RSA None MD5,
SHA PROV_RSA_SCHANNEL RSA RSA RC4,DES,3DES,+ MD5,SHA
PROV_DSS None DSS None MD5,SHA
PROV_DSS_DH DH DSS CYLINK MEK MD5,SHA PROV_DH_SCHANNEL DH DSS DES,3DES MD5,SHA PROV_FORTEZZA KEA DSS Skipjack SHA PROV_MS_EXCHANGE RSA RSA CAST MD5
PROV_SSL RSA RSA Varies Varies
表 3﹒1 預定的 CSP 類型圖
關於 CryptoAPI 密鑰庫(Key Storage) 包括一個或多個密鑰容器（Key Containers）。每個密鑰容器中含屬 於一個特定用戶的所有密鑰對。每個密鑰容器被賦予一個唯一的名 字；以這個名字做函數 CryptAcquireContext 的參數，從而獲得指 向這個密鑰容器的控制碼。CSP 將永久保存每一個密鑰容器，包括 保存每個密鑰容器中的公/私鑰對，但在一個 Session 完後 CSP 將不 保存這個 Session 在密鑰容器中的會話密鑰。（注: 一個 Session 是指從使用函數 CryptAcquireContext 到使用函數
CryptReleaseContext 期間的階段。當一個 Session 結束後，所有 的使用 hProv 控制碼創建的會話密鑰和 Hash 值都變爲無效）。
關於加解密的密鑰
•會話密鑰由應用程式用 CryptGenKey 或 CryptDeriveKey 函數創建
•會話密鑰被安全保存在 CSP 中
Blob 資料結構存儲離開了 CSP 內部的密鑰。通常密鑰總是在 CSP 內 部被安全地保存，應用程式只能通過控制碼訪問密鑰，而 Key Blob 則例外。當使用 CryptExportKey 函數從 CSP 中導出密鑰時，Key Blob 將要被創建。之後的某一時間，使用 CryptImportKey 函數將密鑰導 入到某個 CSP 中（通常是另一個不同的機器上的不同的 CSP）。因此，
Key Blob 是在不同的 CSP 之間安全傳送密鑰的儲存體。
Key Blob 有一個標準的資訊頭和位於資訊頭之後的一段表示 密鑰本身的資料組成。通常應用程式不訪問 Key Blob 內部，而是把 Key Blob 當作一個透明的物件。由於公/私鑰對的私鑰部分需要絕 對保密，所以私鑰要用對稱加密演算法加密。加密 Private Key Blob 時，除了 BLOBHEADER 之外的所有部分都要加密。但加密所用的演算 法和密鑰（或密鑰參數）不與該 Key Blob 存儲在一起，應用程式負 責管理這些資訊。
【注意事項】
(1) 如果你的機器曾運行過這種資料加密程式，那當然可以正確地運 行。如果是第一次才運行此程式，那將會出現問題，錯誤就在 CryptAcquireContext 的使用上。在使用 CryptEncrypt 進行資料 加密之前，需要取得當前機器所使用的密鑰容器，而
CryptAcquireContext ( & hProv , NULL , NULL , PROV _ RSA _ FULL , 0 ) 就是用於連接所使用的 CSP，如果當前機器未曾設 置過此的密鑰容器， CryptAcquireContext 使用就會出錯。因此 必須爲機器創建缺少的密鑰容器。創建缺少的密鑰容器也需要調 用 Crypto API 進行。下面介紹一種創建缺省的密鑰容器的控制 臺程式 InitUser.c【附錄】
【附錄】本程式的功能爲：
1.用你的機器名稱 User Name 創建一個缺省的密鑰容器。
2.在密鑰容器中創建一個數位簽名密鑰對。
3.在密鑰容器中創建一個密鑰交換對。
本程式在一台機器上只須執行一次，執行之後，你將會看到在 系統註冊表的 HKEY_CURRENT_USER\Software\microsoft 下多了一 個主鍵： Cryptography\UserKeys，並填入一些十六進位的值。之
後，你就可以順利地使用資料加密程式了，甚至可以使用數位簽名
(3) 其加解密涵式主要為 CryptEncrypt()和 CryptDecrypt()，格式如 下：
BOOL WINAPI CryptEncrypt(
HCRYPTKEY hKey , HCRYPTHASH hHash , BOOL Final ,
DWORD dwFlags , BYTE* pbData ,
DWORD* pdwDataLen , DWORD dwBufLen );
BOOL WINAPI CryptDecrypt(
HCRYPTKEY hKey , HCRYPTHASH hHash , BOOL Final ,
DWORD dwFlags , BYTE* pbData ,
DWORD* pdwDataLen );
其他加解密的函式
EncryptFile 和 DecryptFile 函式說明：
在程式開發過程中，經常遇到需要保護用戶資訊和私有資料不 參數 lpFileName 可以是檔案名，也可以是目錄名,如果是目錄
名，那麽以後在該目錄下創建的文件都將被自動加密。如果函數執
行成功，將返回非零值，否則，返回值爲零，可以通過 GetLastError() 函數得到錯誤代碼。
行成功，將返回非零值，否則，返回值爲零，可以通過 GetLastError() 函數得到錯誤代碼。