第六章 Web Content Recovery System 程式介紹
6.2 加密和備份程式
此程式則負責檔案的加密和加密之後的備份工作，以求發生網頁被 竄改之時能有還原網頁之能力，其使用和執行介面是經由 Windows 作 業系統上的檔案管理程式，不需另外開啟程式或特殊介面，我們可以 由圖 6-6 看到增加到 POP 右鍵選單上的「WCR 檔案加密」選項
圖 6-6 WCR 加密程式執行畫面 6.3 解密和還原程式
當檔案需要解密或是由備份中移除、還原時則由此程式來做，主要 用於網頁檔案 update 或是汰舊，另外因為我們的加密對象是檔案名 稱，所以所有檔名皆為無法認出的密文，為了讓使用者能夠方便的找
到檔案並作解密還原的動作，所以我們的解密還原程式就在讀取檔案 列表時即時的將檔名作 DES-X 解密動作，讓在 GUI 介面上看到的檔案 列表是未加密前的檔名，此做法不僅方便使用者另外一方面在解密檔 案時也不需要再作 DES-X 解密動作，其執行畫面如圖 6-7。
圖 6-7 解密還原程式執行畫面 6.4 WCR 主程式
功能說明
起始執行畫面如圖 6-8，主要可使用的功能有四個：
啟動：啟動 WCR TCP Proxy 的功能，啟動後才會開始執行 WCR 的功能。
重新載入虛擬目錄設定：當使用者在 WCR TCP Proxy 執行後修改虛擬
目錄的設定後，需執行此功能來重新載入設定，方能產生效果。
重新讀取設定：用來重新讀取其他細部的設定。
圖 6-8 WCR 主程式執行畫面
最小化：當點下右上角的最小化鍵後，WCR TCP Proxy 會縮到 task bar 上(如圖 6-9)，在 task bar 上的 icon 連點兩下，WCR TCP Proxy 會回 復原來的大小。
圖 6-9 WCR 在最小化在 task bar 畫面 執行結果
在 WCR TCP Proxy 功能啟動後，輸入原始的檔名後，網頁正確的 開啟(圖 6-10)，但實際網頁的名稱都已經經過加密(如圖 6-11)，直接 到 IIS 所在的 port 來開啟同樣的網頁，結果並無法成功的開啟(如圖 6-12)。
圖 6-10 開啟網頁測試畫面
圖 6-11 實際在主機上的檔名畫面
圖 6-12 直接送要求給 IIS 開啟網頁的測試畫面 第七章 WCR 系統架構和問題解決
7.1 WCR 系統架構
整體架構大致分為兩部分：On-line 的主程式和 Off-Line 的加解 密及備份還原程式，其簡單的結構可由圖 7-1 來看：
On-Line 主程式
Off-Line
圖 7-1 WCR 系統簡單架構圖 TCP Proxy
即時檢查 即時還原 即時通知
資料備份還原
檔案加解密 離線檢查
而處理 Client 端瀏覽器 Request 的流程也可以由圖 7-2 清楚了解
轉送到TCPProxy Client端 Web Service Web Service將 Reqeust的檔案 Response給 TCPProxy Client端
TCPProxy Client端將Response
轉送到TCPProxy Server端
TCP Proxy 會 bind 到 80 PORT，然後當 Request 進來時，先將檔名 經 DES-X 加密後再搜尋目錄下檔名以此密文開頭的檔案，找到之後再 將此檔的內容經過 SHA-1 來計算其摘要值，並與檔名中的摘要值部份 比對，以檢查檔案的完整性，如果沒問題再將 Request 中的檔名改為 加密後的檔名，再送往 Web Service，收到 Web Service 的 Response 後將傳回給 Client 端；如果檔案有問題便即時將他從備份檔中還原，
並記錄 log 再以 E-mail 方式通知管理者，最後都由 Web Service 的程 式作 Response 後將傳回給 Client 端。
7.1.1 WCR 加密和備份做法說明
我們使用 DES-X 來加密檔案名稱(不包含路徑)，而以 SHA-1 來計算 檔案內容的訊息摘要值，之後將兩者整合變成該加密後的檔案名稱，
也就是說我們的加密處理只變動檔名部分，不會對檔案內容作任何動 作或處理，至於檔案備份工作則是依照使用者設定的備份路徑將檔案 依照原本所在路徑的架構完整備份下來，舉例來說：當備份路徑為 D:\WCR\Backup 而加密過檔名為
E:\e5b7cd8e07106fbda28cee94b167af6fe8d74d8a014e76387d860346.html 則備份檔案為
D:\WCR\Backup\E\e5b7cd8e07106fbda28cee94b167af6fe8d74d8a014e76 387d860346.html。我們由圖 7-3 可以了解加密和備份程式處理檔案的 流程。
圖 7-3 WCR 加密備份程式流程圖
流程中檔案加密之做法：假設原始檔名為filename.subname，則我 們的加密程式會先將filename 取出並將其作 DES-X 加密，但因對稱式
們採用原本用於 RC5 上面的密文盜用模式(Ciphertext Stealing Mode，
CTS)，做法如下：
1. FileName 長度小於或等於 8 bytes：
我們會在檔案名稱後面補上不足8 bytes 的數字，即若檔名為 a.php 則距離8 bytes 差 3 bytes，所以檔名在 padding 之後便成 a.php333，
所以當檔案名稱不足 8 bytes 時皆會補滿到 8 bytes，當然剛好為 8 bytes 時也會補上 8 個 8，不過在加密之後多補上去的部分會被去除。
2. filename 長度大於等於 8 bytes：
若是filename 長度大於 8 bytes 時我們的做法是：前面滿足 8 bytes 的區段部分我們都以DES-X 的 ECB 模式來操作，而最後兩個區段 (含一個未滿 8 bytes 的區段)我們就改採 CTS mode 的處理方式，其 做法的流程可以分為幾個步驟：
A. 使用傳統的 ECB 技巧對前 n-2 個區段作加密。
B. 將 Pn-1取前面一回合所產生的密文區段Cn-2 作 XOR，所產生 的結果為Yn-1。
C. 將 Y n-1加密成E n-1。
D. 將 E n-1的前L 個位元(L 就是 P n的長度)取出成為 C n。 E. 在 P n的末端補 0，並且與 E n-1進行 XOR 運算來產生 Yn。 F. 將 Yn加密成 C n-1
以上的步驟我們可以用下面的流程圖 7-4 表示：
圖 7-4 DES-X 加密使用 CTS mode 操作流程圖 所以整個檔名加密架構就變成：
﹒ ﹒
﹒ ﹒
至於原本的SubName 則完全保留以求和 Web Service Program 有最大相 容性，因為 99%的 Web Service Program 皆以 SubName 判斷此檔案該如 何處理。
7.1.2 WCR 解密和還原做法說明
為了達成讓使用者可以看到未加密前檔名並且可以直接選擇檔案 或目錄還原，我們除了實作一 GUI 介面讓使用者方便操作之外，更使 用 Shell API 來讀取檔案相關資料(檔案型態、屬性、修改日期等等) 並在做檔案名稱列表之時就先在背景將檔案名稱作 DES-X 解密處理，
FileName SunbName
DES-X encode SHA-1 Msg from content of File
Encrypted FileName SubName
在使用者圈選檔名之後即可直接作解密還原的動作，我們由圖 7-5 可
而其 DES-X 解密和 CTS mode 之處理流程如圖 7-6：
圖 7-6 DES-X 解密使用 CTS mode 操作流程圖
只要將最後兩個區段的加密過程倒過來作即可順利解密獲得明文，其 做法的流程可以分為幾個步驟：
A. 使用傳統的 ECB 技巧對前 n-1 個區段作解密。
B. 在 C n的末端補0。
C. 將 Cn-1解密出來的資料和 Cn作XOR，所產生的結果為 Yn。 D. 將 Y n解密成P n-1。
E. 將C n-1解密出來的前L 個位元(L 就是 C n的長度)取出成為 P n。 7.2 問題解決
1. 在傳送資料時因傳送檔案過大，傳送速度過快，導致網路卡的 Buffer 空間不足而造成錯誤
A：解決方法是在傳送失敗時等待一小段時間再重試直到成功為止。
2. 當資料傳送給 Web Service 在資料還沒送完之前，新的資料進來把 正在使用的Buffer 蓋過去造成資料遺失。
A：解決方法是使用 Queue 來儲存 Buffer 使資料不致遺失。
3. 開發解密還原程式時因為需要讀取檔案或是目錄的詳細資料(如：
檔案型態、屬性、修改日期、大小等等)，所以使用 Microsoft Platform SDK 中的 Shell API 來實作，結果一直找不到如何將設 定讀取目錄資料的 Root 位置方法，只能用其內定的系統目錄當作 Root 來開啟。
A：後來由 Microsoft Platform SDK 的文件中發現其實 Shell API 尚 未實作完成該函式，導致只能開啟內定的系統目錄，針對此點我們 改採用 OLE 的方式繞過 Shell API，藉由 COM 技術呼叫 Windows 作 業系統的 shell32.lib 程式庫直接作設定。
4. 此次使用的 SHA-1 摘要值演算法原本我們再此專題之前就已經有 實作過程式，只是當時開發的環境是 C 語言，剛開始我們直接將其 改寫並封裝成 C++的 Class 來使用，卻發現有部分 C 的寫法對應到 C++的環境和編譯器會發生許多問題，修改多次仍不見改善。
A：最後我們只能重新針對 C++的環境和編譯器撰寫新的 SHA-1 程式，
以求得最大的相同度和較好的效能，和之前程式相比程式碼縮減 15%左右，也沒有任何使用上的問題出現。
第八章 未來發展與心得感想 8.1 未來發展
因為我們 WCR 系統的主程式架構是在 TCP/IP 的應用程式層上面，
幾乎所有主程式的實作部分都可以用 Socket 來達成，所以未來主程式 可以使用跨平台的 Java 來作為開發環境，如此就可以達到跨平台的程 式架構，另外此次僅針對 IIS 來作處理，未來只要能加入各種 Web Service 程式(如:Apache 等)轉換虛擬目錄的對應方法就可以加以處 理，而不需侷限只能搭配 IIS 來使用。
在加密保護和摘要值強度部分因為撰寫程式時都使用 C++物件導向 的設計理念，並將 DES-X 和 SHA-1 演算法的程式部分封裝成 Class，這 樣未來若發現需要更換演算法也只要替換演算法的 Class 即可，不需 要大幅度的修改主要程式部分，甚至可以將此部份的程式包裝成動態 連結程式庫來呼叫。
而在 DES-X 鑰匙的保護上面此次因為開發的語言和環境無法搭配 上現有的 IC 晶片卡來運作(目前實驗室僅有支援 VB、Java 兩種語言的 IC 晶片卡)，未來若能改寫成 Java 版本或是替換新的 IC 晶片卡系統，
即可利用 IC 晶片卡不易被複製和竊取內部資料的特性使 DES-X 鑰匙的 保護更加安全。
最後在檔案備份的部分目前我們採用的方式是將加密過後的檔案
依照原本目錄的結構完整備份下來，未來除了可採單一壓縮檔案或是 使用資料庫來存放備份檔案之外，也可以採用異地備援的方式透過網 路來取得備份資料，如此都可以大大增加系統安全性。
8.2 心得感想 個人心得感想：
從三年級下學期不知道專題要做什麼題目，到題目確定甚至四年級 剛開學換了題目最後能順利完成，這中間的經歷就非課堂上聽老師授 課或是自行研究可以得到的，縱然曾經有過軟體開發的經驗但是面對 許多專題真正在 Run 的過程中遇到的困難和其他阻力有時候還是不知 如何解決，中間經過指導老師的開導和小組間的討論最後將專題順利 的完成，其中學到的觀念和經驗都是個人寶貴的資產，也能成為日後 工作或是研究上借鏡。
這次的專題感謝組長給與的大量技術支援，減少了許多的開發時 間，大體上在程式架構確定後，程式的寫作便很快的進行，其中遇到 的問題大多是寫作上的粗心所造成的錯誤，而非技術上的不足所造成
這次的專題感謝組長給與的大量技術支援，減少了許多的開發時 間，大體上在程式架構確定後，程式的寫作便很快的進行，其中遇到 的問題大多是寫作上的粗心所造成的錯誤，而非技術上的不足所造成