第七章 WCR 系統架構及問題解決
7.1 WCR 系統架構
7.1.2 WCR 解密和還原做法說明
﹒ ﹒
至於原本的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 的過程中遇到的困難和其他阻力有時候還是不知 如何解決，中間經過指導老師的開導和小組間的討論最後將專題順利 的完成，其中學到的觀念和經驗都是個人寶貴的資產，也能成為日後 工作或是研究上借鏡。
這次的專題感謝組長給與的大量技術支援，減少了許多的開發時 間，大體上在程式架構確定後，程式的寫作便很快的進行，其中遇到 的問題大多是寫作上的粗心所造成的錯誤，而非技術上的不足所造成 的，雖然技術上都還可以，但還是學到了不少東西，畢竟有些東西是 寫下去才會發現的問題，一開始曾經考慮要使用低階的方法來寫，但 考量的時間上來不及所以改採用高階的作法，也就是目前所使用的架
構。專題令我最困擾的不是程式的方面而是文件的寫作，因為沒有相 關的經驗所以在文件的撰寫上顯的相當生疏。
小組心得感想：
我們的專題原先是”Transfer for Telephone to IP Phone”想藉 由嵌入式系統來實作，達到由一般電話轉接到 IP Phone 上面的功能，
在開始階段的規劃和程式設定、撰寫都算順利，但是最後卻發生我們 選定的嵌入式整合系統無發搭配上 A/D Converter，國內又有許多 IC 需要大量訂購才能買到，最後改換題目為現在的 Web Content Recovery System，縱使沒能完成預定目標但是其中我們也對 IP Phone、嵌入式 系統、H.323 標準等等有更深入的認識和了解，而其後的 WCR 系統雖然 開發時間較為短，但是我們也竭盡全力讓系統能夠完備，除了考量未 來發展以較高階的 Socket 為開發基礎，更將許多部分都預留可擴充和 改良的空間，藉由如此的過程將課堂上所學的系統規劃和軟體工程應 用於其上，雖然最後因為專題時程關係沒能將 IC 晶片卡和異地備援的 功能加入不過我們依然收穫良多，最後由衷感謝長期給我們指導與鼓 勵的指導老師，沒有老師的指導我們的專題也無法順利完成，以上即 是我們專題的心得與感想。
參考資料：
1. FIPS PUB 46-3,Data Encrypt Standsrd(DES)
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
2. RSA's FAQ about Today's Cryptography (DES section)
http://www.rsasecurity.com/rsalabs/faq/3-2-1.html
3. FIPS PUB 81,DES Mode of Operation
http://www.itl.nist.gov/fipspubs/fip81.htm
4. Block ciphers and modes of operation. DES, AES. External ...
http://www.cs.ucd.ie/staff/vmatyas/home/COMP4015_lect04.pdf
5. What is DESXhttp://www.rsasecurity.com/rsalabs/faq/3-2-7.html
6. The Data Encryption Standard`s Volume.http://www.ams.org/notices/200003/fea-landau.pdf
7. FIPS PUB 180-1, Secure Hash Standardhttp://www.itl.nist.gov/fipspubs/fip180-1.htm
8. Secure Hash Standardhttp://www.jura.ch/lcp/cours/dm/codage/moderne/fips180-2.pdf
9. CRYPTOGRAPHY AND NETWORK SECURITY Second Edition，作者：
William Stallings，pp.64-117、pp.358-376，編號：ISBN 975-566-870-7
10. RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
ftp://ftp.isi.edu/in-notes/rfc2616.txt
11. IIS 5.0 線上說明文件，Internet Information Service 5.0