Web Service上實作XML數位簽章

(1)

逢甲大學

資訊工程學系專題報告

Web Service 上實作 XML 數位簽章

學生 : 賴志軍(四丙)

柯棨鐘(四丙)

指導教授 : 李維斌

中華民國九十一年十一月

(2)

圖表目錄 ………IV 摘要 ………V 第一章導論 ………1 1.1 研究動機與目的 ………1 1.2 何謂 XML 數位簽章 ………2 1.3 系統簡介 ………4 1.4 成果簡介 ………5 第二章 XML 相關簡介………7 2.1 XML 介紹 ………7 2.1.1 XML 基本語法 ………8 2.1.2 宣告一份 XML 文件 ………8 2.1.3 XML 擅於描述結構化資料 ………11 2.2 XML 和 EDI 之比較 ………12 2.3 XML 和 HTML 之比較 ………13 2.4 XML 的優勢 ………14 2.4.1 XML Web Service 為何 ………15 2.4.2 DTD ………16 2.4.3 XML Schema ………18

(3)

2.4.4 SOAP ………19 2.4.5 XML Web Service 的平台 ………20 2.4.6 應用方式之多元化 ………21 2.4.7 XML 未來展望與發展方向 ………22 第三章密碼學介紹 ………24 3.1 密碼學概念 ………24 3.1.1 密碼分析學 ………24 3.1.2 對稱性密碼學………25 3.1.3 非對稱性密碼學………26 3.2 密碼學的應用 ………28 3.2.1 數位簽章概念………28 3.2.2 數位簽章之演算法………30 3.2.2.1 訊息摘要演算法………30 3.2.3 演算法說明………31 3.3 XML SECURITY ………32 3.3.1 XML 加密介紹 ………34 3.3.2 W3C 簽章格式說明 ………35 3.3.3 XML 簽章實作介紹 ………37

(4)

第四章系統架構與問題解決 ………42 4.1 WSDK 介紹與執行架構 ………42 4.1.1 WS-Security 介紹 ………45 4.1.2 SOAP-DSIG 介紹………46 4.1.3 簽章與加密測試 ………53 4.2 專題遇到困難與解決方法………55 4.2.1 XML Q&A ………56 第五章未來發展與心得 ………59 5.1 系統未來展望 ………59 5.2小組心得 ………60 參考資料 ………62

(5)

圖表目錄

圖1-1 工作分配表………5 圖1-2 工作進度Gantt Chart ………6 圖2-2 XML樹狀架構圖 ………11 圖2-2 XML Web Services………15 圖3-1 對稱加密系統 ………25 圖3-2 非對稱加密系統………27 圖3-3 數位簽章資料加解密關係圖 ………29 圖3-4 網路上販售的XML加密程式 ………37 圖3-5 本專題簽章程式 ………38 圖3-6 存放KEY的XML文件………40 圖3-7 簽署xml文件 ………41 圖3-8 驗證文件………41 圖4-1 WSDK架構圖 ………44 圖4-2 Web 服務安全性規範 ………46 圖4-3 安全性權杖內容………51 圖4-4 本專題簽章程式………53 圖4-5 測試程式………54 圖 4-6 測試時間表 ………54

(6)

摘要

XML 的發展近年來可說是一日千里， 1998 年 4 月的時候 W3C 將它定為網路通訊的標準，短短不到 5 年的時間，世界各國的網路工程師、電子商務、文件出版或是標準協定等各領域的專家們都積極投入人力去參與。隨著網際網路的日漸普及，資訊的傳遞普遍利用網路來進行，XML 就是用來傳遞這些資訊的最好方式，雖然 XML 剛發展不久，但靠者 XML 強大方便的特性，XML 勢必成為未來資料交換的標準格式，很快的 XML 將會應用在政府的公文交換或是電子商務上，所以 XML 文件的安全變得會越來越重要了。本專題使用了 XML WEB SERVICES 開發工具，建立了 CLIENT 與 SERVER 兩端，並透過 WEB SERVICE 所提供的 SOAP 協定來進行 XML 文件的交換，並在交換的過程中對 XML 進行簽章與加密的動作。

(7)

第一章導論

研究動機與目的

由於 XML 是一項新技術，在大三下找李維斌老師做專題時， XML 數位簽章的規格與技術都還未成熟，更誇張的是市面上所有中文書籍都沒有 XML 加密的資料，但在老師看好 XML 將來的發展將無可限量的驅使下，決定在國外網站中好好研究最新的 XML 數位簽章技術。為了提供 XML 有更安全的環境，並避免受到不肖份子的惡意破壞，而導致電子交易失敗或政府密文外洩，造成金錢和時間上的重大損失，所以我們要在 XML 交換資料時做數位簽章與加密的動作，來確保 XML 文件的完整性與安全性。 XML 是及近來 Web 服務持續增長和開發的主要支持者。但是，在實現 XML 語言的全部能力之前，還有許多與安全性相關的工作要做。目前，加密整個 XML 文件、測試其完整性和確認其發送方的可靠性是技術還未成熟。但是，越來越有必要對這些功能定義適當的 TAG，以便以進行加密和認證。目前，在與 XML 相關的安全性領域方面開發規範的最重要部分是 XML 加密與 XML 簽章，所以本專題要從這兩個最為重要的部分開始著手。

(8)

1.1 何謂 XML 數位簽章

XML 加密（Xenc）除了在傳送 XML 檔案時使用 DES 來加密整份檔案，W3C 和 IETF 還制定了另一項標準來對一個 XML 文件中的資料和部分內容進行加密。這樣，如果一個文件只是某些敏感部分需要進行保護，你就對可以他們單獨進行加密。對於同一個文件中的不同部分用不同的 Key 進行加密，你就可以把同一個 XML 檔案發給不同的接受者，而接受者只能看見和他相關的部分。一旦採用這個這個方法對一個 XML 檔進行加密，在加密部分的首尾就會出現加密的 TAG，表示該檔是以 W3C 公佈的標準進行加密的。資料本身顯示為一連串的亂碼。這個標準使 XML 資料提供者可以根據用戶的不同對內容進行顆粒化的控制。而且，由於是針對資料本身而非整個檔進行加密，所以整個檔還是可以被 XML 處理器識別和處理。

(9)

XML 簽章（XML-SIG）: XML 簽章和 XML 加密緊密相關並和安全認證簽章相似，也是用於確保 XML 檔案內容沒有被篡改過。為了適應各種不同 OS 與不同 CPU ， XML 簽章規定了 “ 標準化（Canonicalization）”，標準化（Canonicalization）使 XML 簽章可以適應 XML 檔案可能遇到的各種環境，例如 Clint 端使用 Linux， Server 端使用 Window，XML 簽章必須使用標準化，雙方才能簽驗證對方的 XML 簽章。當對內容進行簽章時，canonicalization 使用檔案裏的資料和標識產生一個獨一無二的簽名，忽略了一些諸如段落結束或者跳位字元之類的次要資訊。收到一個檔後，客戶系統就開始進行“XML 簽章解密轉換”，它通過辨認資訊是在標識前還是標識後來區分內容和簽章：內容在標識後，而簽章在標識前。通過比較運算結果和檔中的簽章，可以確認資料的完整性。XML 簽章和 XML 加密結合在一起，可以確保資料發送和接收的一致性。

1.2 系統簡介

(10)

z VS.NET Web Service API

z Web Services Development Kit Technology (WSDK) z VS.NET Framework z IIS 5.0 開發語言: 專題實驗主要是用 C#與 VB.NET 來完成，介面設計是使用 V B.NET 來設計，XML 數位簽章是使用 C#來撰寫，簽章所使用到的標籤都是依照 W3C 的簽章規定來設計，Server 與 Client 溝通是使用 WSDK 的函式庫來寫成的。簽章使用到 RSA 與 SHA 演算法，加密使用到 DES 演算法。

開發環境:

安裝 VS.NET 和 IIS5.0 以及 WSDK，VS.NET 是開發本專題的重要環境，WSDK 是.NET 的 API，是用來開發 WEB SERVICE 的，再加上 XML 簽章，就可以實作我們的專題了。

(11)

Client 端有能力對 XML 文件做簽署加密，Server 也能認證解密 XML 文件，反向執行也可以。為了能讓使用者更方便使用，Key 是內嵌在裡面的，省了使用者管理 Key 的麻煩。只要下載此程式就能使用連上 Server，可以與 Server 交換 XML 文件，輕鬆的簽署驗證 XML 了。賴志軍柯棨鐘資料收集系統分析程式架構程式設計程式撰寫 web services 數位簽章系統整合介面修飾系統測試修改書面報告工作分配表圖 1-1 工作分配表

(12)

(13)

第二章 XML 相關簡介

2.1 XML 介紹

XML 是一九八六年國際標準組織(International Standards Organization, ISO)公佈的一個名為「標準通用標示語言」(Standard Generalized Markup Language, SGML)的精簡版/子集合。一九九八年二月，美國 W3C 組織正式公佈 XML 的 Recommendation 1.0 版語法標準。XML 掌握了SGML 延展性、文件自我描述特性、以及其強大的文件結構化功能，但摒除了SGML 過於龐大複雜以及不易普及化的缺點。字面上來看XML 是一種標示語言，但嚴格來說它和 SGML 一樣是一種「元語言」(meta-language)。「元語言」(meta-language)即是描述語言的語言，例如 meta-FAQ 就是"FAQ 的 FAQ"。換言之，XML 是一種

用來定義其它語言的語法系統。這正是XML 功能強大的主因。它可促進各專業機構、不同產業界、學術界和特定應用領域發展各自標準的文件和訊息，以利資訊的交換、處理和相關衍生性資料加值服務。 XML 文件和訊息的主要特色在於它是結構以及資訊內容導向。結構化紋健和訊息編瑪方法的主要精神在於它可供其它電子資料傳遞、文件出版系統、電腦輔助設計或製造、資料庫管理等系統，在處理重複和共享的資料時，能有效提升其效率和效能，節制資訊系統的開發建置和管理營運成本。這種方法將資訊內容、結構和格式等不相同的文

(14)

件要素予以區分。它保存了文件的資料和結構(有助於原始資料的回溯)，可是卻不指出文件的呈現格式，如果格式的解析在資料最後傳遞時，才依據用戶需求進行最佳化之處理。XML 技術本質上的優勢和特色，使商務資訊流電子化產生根本上的改變，並在應用上提供更多維的可能性。 2.1.1 XML 基本語法 XML 是特地設計來儲存和傳輸資料，以文字為基礎的格式。在許多方面與 HTML 類似。XML 來源檔是由 XML 元素所組成，每一個元素皆含有起始標註 ()，以及位於兩個標註之間的資訊（亦即內容）。一如 HTML，XML 文件包含以標註註解的文字。不過，與 HTML 不同的是：XML 允許無限制的標註組，每一組標註所代表的不是物件的外觀，而是物件的含意。例如，XML 的某元素，可能被標註為價格、訂單編號或產品名稱。完全由文件的作者決定要使用何種資料，以及哪一種標註名稱最合適。 2.1.2 宣告一份 XML 文件 XML 文件的內容應該以 XML 宣告為首，以此說明文件中所使用 XML 規格的版本。例如：

(15)

< ?xml version="1.0"? > < ? x m l v e r s i o n = “ 1 . 0 ” ? > “這一行是 X M L 宣告，表此為 X M L 文件，以及版本為 1 . 0 。以下如 < O r d e r > , < D a t e > , < A d d r e s s > 為自行定義的元素，在 x m l 中並無定義任何元素，所以在 x m l 中必須由文件作者來建立。而每個元素的結尾一定要加上結尾標記，如 < / O r d e r > , < / D a t e > , < / A d d r e s s > ; 另外元素名稱大小寫是有別的。 N o t e : < a d d r e s s b o o k > 此為不合法，元素名稱中不可有空白字元 ” < O r d e r c o n f i r m = “ t r u e ” > ”屬性值的前後一定要加上引號 ” < D a t e > 2 0 0 2 - 0 5 - 1 5 < / D a t e > < R e f e r e n c e > A G L 1 5 3 < / R e f e r e n c e > < D e l i v e r B y > 2 0 0 2 - 0 6 - 1 0 < / D e l i v e r B y > “購買者的名字，所在地地址 ” < N a m e > 金石堂 < / N a m e > < A d d r e s s > < S t r e e t > 福星路 F u _ X i n g R D < / S t r e e t > < L o c a l i t y > 西屯區 < / L o c a l i t y > 4 0 7 < R e g i o n > 台中 T a i c h u n g < / R e g i o n > < C o u n t r y > T a i w a n < / C o u n t r y > < / A d d r e s s > < S e l l e r > “ 銷售者的名字及地址 ” < N a m e > 碁峯 G O T O P < / N a m e > < A d d r e s s > < S t r e e t > 南港路 N a n _ G a n g R D < / S t r e e t > < L o c a l i t y > 南港區 < / L o c a l i t y > 2 2 2

(16)

< R e g i o n > 台北市 T a i p e i < / R e g i o n > < C o u n t r y > T a i w a n < / C o u n t r y > < / A d d r e s s > < / S e l l e r > < L i n e s > “所購買的書名，價格及圖書編號 ” < C o d e t y p e = " I S B N " > 0 7 8 9 7 2 5 0 4 5 < / C o d e > < D e s c r i p t i o n > X M L b y E x a m p l e < / D e s c r i p t i o n > < Q u a n t i t y > 1 5 < / Q u a n t i t y > N T $ 6 2 0 P r o d u c t > “ 第二本購買的書 ” < C o d e t y p e = " I S B N " > 0 6 7 2 3 2 0 5 4 1 < / C o d e > < D e s c r i p t i o n > A p p l i e d X M L S o l u t i o n s < / D e s c r i p t i o n > < Q u a n t i t y > 5 < / Q u a n t i t y > N T $ 4 8 0 < / L i n e s > < / O r d e r > 下圖為 XML 訂單的部分元素樹狀架構元素組成的樹狀結構的高度，並沒有限制，而且元素可以重覆 (ex:Lines 中的 Product)

(17)

根元素為 Order，而且根元素必須是唯一的，也就是 Xml 文件中的所有元素都必須是這個元素的子元素圖 2-1 XML 樹狀架構圖 2.1.3 XML 擅於描述結構化資料對於像電話聯絡簿、名單、交易記錄等結構化的資料，最適合使用XML來存取這些資料。因為XML是一種具有規則、指引、及慣用語法的描述性語言，可以讓你用來設計資料的儲存格式，以便讓電腦進行判讀。而且XML可解決標註(Tag)在擴充性、重複定義，及資料在國

(18)

際化及跨平台上的問題。 2.2 XML 和 EDI 之比較富含特色的商務互動行為必定包含了大量的資訊，傳統上在論及電子商務資訊流時，言必出「電子資料交換」(Electronic Data Interchange, EDI)。EDI 是一種快速可靠的文件資料交換方式，它主要被用於不同公司間不同電腦系統的商業文件交換，特別是上下游工廠(供應鏈)或是交易企業間的資料交換。它藉由電腦的資料處理及通訊功能，傳達一標準格式的電子資料檔案，將交易往來的商業文件，如訂單、訂單回覆、請款對帳單或付款明細表等，透過相關轉換機制和系統，傳達至對方的資料庫或 MIS 系統，以便進一步處理。早期的 EDI 屬於專屬封閉的系統，建置成本高，因此造成一般中小企業的進入障礙。此外，早期的 EDI 系統僅能改善和處理片段的作業流程，但網際網路世代的來臨，卻改變和衝擊傳統的 EDI 生態。相較於 EDI，XML 的主要優勢在於： 1. 只要資料結構、語意和資料值能夠統一，XML 的文件對應用程式來說具有自我定義（self-defining）的特性，亦即 XML 文件不必像 EDI 訊息一樣需要預先設定的特殊格式和結構。

(19)

2. XML 文件內容的標籤元素基本上與通訊協定獨立。因此，XML 文件特別適合在網際網路和全球資訊網的環境中流通傳輸。 3. 相較於 EDI，XML 在編輯器、中介軟體以及應用工具上擁有更多的選擇。這些差異性，將使 XML 的標準化和導入歷程不會像 EDI 走得那樣艱辛。 2.3 XML 和 HTML 之比較現今的 HTML-based 全球資訊網是"呈現導向” （presentation-oriented），換句話說，HTML 語法是用來指定文件在瀏覽器上的呈現方式，這意味了人類可輕易地瞭解 HTML 的檔案內容，但電腦軟體本身卻無法了解 HTML 檔案資料的內容和意義為何。雖然 HTML 的簡單輕便，助長了全球資訊網的迅速普及，但隨著全球資訊網平台上之多媒體及編排上的多樣化殷切需求，以及強調效率和精準的電子商務的興起，HTML 語法已逐漸顯露其捉襟見肘的窘態。雖然許多程式設計人員利用自定的 HTML 標籤以及專屬的軟體來擷取網頁中的資訊內容，但此法卻無法滿足普及化的需求，且造成各行其事的紛亂局面。若資訊本身未經過語意化和結構化來表達，許多的軟體以及搜尋引擎將無法更有效地善用這些資訊。在 XML 的架構下，結構化的資料以及具有意義的資料標籤，將使電腦和軟體得以理解和利

(20)

用網頁或文件和訊息內的資訊，再透過代理程式以及其他自動化程序，電子商務資訊流的自動化將可有效地提升，並從本質上轉變電子商務的環境。 2.4 XML 的優勢 XML 是個跨平台的標準，當你選擇使用 XML 之後，無形中你就是選擇了一堆支援 XML 的相關工具，及許多開發人員在 XML 技術上投資的成果。然而就好像用 SQL 語法來存取資料庫，你還是得自行規劃、設計資料及程式來存取及維護其中的資料。不過好在已經有許多工具及技術資源可供你使用。XML 是 W3C 的標準，它沒有版權的問題，你可以盡量地使用這項技術而不用付任何費用，大量的支援也表示你不會被某一個特定的機構或公司所箝制。

(21)

2.4.1 XML Web Service 為何 XML 輕易地推翻我們建構及使用軟體的方式，使用者與應用程式溝通的方式已因為 Web 而截然不同。藉由提供通用的資料格式，讓資料可以更輕易地被採用以及轉換，XML 正逐步革新應用程式相互通訊以及電腦間互動的方法。以 XML 為基礎的標準，包括 SOAP 與 UDDI，構成了應用程式對應用程式通訊的開放方法，這就是所謂的 XML Web 服務。而 XML Web Service 能讓應用程式共用資料，且不論抓用何種程式語言，均可跨平台呼叫 XML Web 服務

(22)

由圖 2-2 了解 XML Web 服務可以讓應用程式之間透過 Internet 進行通訊，不論作業系統或程式語言為何。XML Web 服務可實作於任何平台，並且是透過公用標準組織 (例如 W3C) 來定義。使用 XML Web 服務時，應用程式不但可以共用資料，還可從其他應用程式呼叫功能，不論該應用程式的建構方式為何。此外，應用程式透過 XML 共用資料時各自獨立，又能同時與彼此構成鬆散的合作群組來執行特定工作。網站的功能是將資料展示給使用者，是伺服器與使用者之間溝通的橋樑。而 XML Web 服務則提供直接管道，讓不同應用程式間彼此互動。電腦內部的應用程式以及遠端系統，可以使用 XML 及 SOAP 訊息，透過 Internet 進行通訊。Web Service 的優點:1.允許在不同平臺上、以不同語言編寫的各種程式以基於標準的方式相互通信。 2.使用標準的 Web 協定 - XML、HTTP 和 TCP/IP。許多公司都已經建立了 Web 基礎結構。

2.4.2 DTD

DTD(Document Type Definition)這項技術可以做到大家交換資料的標準，如果大家採用共同的DTD，如此資訊交流便可以達到無障礙的空間。DTD 使用了正式的文法來詳細說明XML 文件的結構

(23)

與可允許的值。再者，DTD定義出一份XML文件的辭彙，這使得XML 文件可以涵蓋每一個個案，而且所使用的詞彙都是定義於同一份 DTD。另一方面，在XML文件的驗証，可以透過DTD來驗証一份文件是否符合其架構與辭彙，如此一來，XML可以充分的利用標示語言，且藉著DTD的定義，規定出XML文件的架構與辭彙，使得我們往後在使用XML文件，更為有利。但是DTD還是有以下4項缺點: (1) DTD使用的是自己的語法，和文件實例不一樣。 (2) DTD是封閉的架構，包含了XML文件的辭彙規則，卻不易延伸 DTD，片段宣告也無法整合關連 (3) DTD 在資料類型上也很短缺，無法定義其它類型。 (4) DTD使得合乎語法的XML文件更嚴謹與精確，增加編輯XML文件時的困難度。此外，DTD對於XML應用程式有三項特色： (1) 在商業領域模型具有正確且清晰的文件。 (2) 模型和XML剖析器之間以標準的方法來溝通。 (3) 驗証剖析器會找出XML文件的錯誤。

(24)

2.4.3 XML Schema

W3C提供了一種稱為XML Namespace(名稱空間）的規格來讓我們定義元素內容。XML Namespace與XML Schema解決了一些使用XML上的問題。 (1) 對於複雜的問題的辭彙，提供了更好的組織性。 (2) 在轉換XML時，有更強的資料型別檢查。 (3) 較DTD更為精準明確，且富有彈性與延伸性。 (4) 不須要增加剖析器的複雜度，可以直接用XML 的剖析器來存取辭彙定義。以下針對XML Schema及XML Namespace作進一步探討。 XML Namespace解決名稱含糊性與名稱衝突，根據W3C的推薦標準，名稱空間是：名稱的集合，並由一個URI 參照來判斷，在XML 文件中作為元素類型及屬性名稱使用（URI是伺服器上DTD或綱要的位址）。 XML Schema是以XML的語法所撰寫。它允許多重名稱空間的使用，並提供了強大的內容型別，此外，它也是DTD 功能的超集合（superset），功能比DCD（Document Content Description）強，但比

(25)

成 Structure和Data Types兩個部份。 Structures 是用來處理元素及屬性的描述與宣告，它允許XML 設計者指定複雜的元素結構並設定內容允許值的限制。Datatype則是用來設定內容資料型別的標準集合。所以XML Schema與Namespace的結合，幫助我們將現有的綱要延伸，或將大型的複雜的綱要分割成小部分，也使得XML Schema的重覆使用性增強，也解決了DTD各項的缺點(參考2.4.2節)。以下列出XML Schema的效益： (1) 透過辭彙片段的使用而具有較佳的組織及複雜工作的重複使用性。 (2) 轉換XML時具有優秀的資料型別。 (3) 保留DTD的精確性。 (4) 以XML的語法，這允許我們可使用傳統的XML Parser來處理XML Schema。

2.4.4 SOAP

(26)

通訊協定，傳送的資料為使用XML元素加碼的資料。SOAP允許我們透過Internet的通訊協定﹝HTTP﹞來做資訊的交換。在使用HTML瀏覽器的時代，使用者只是等待Web網站下載固定的資訊，但隨著越來越多的需求，網站必須提供更豐富的個人資訊以滿足使用者。借由XML 來做資料的格式，Web 服務可以加以處理成為資訊，這種方式可以提供更多的服務以滿足使用者，增加資訊的附加價值。它的特點如下： (1) SOAP的傳送資料是屬文字內容的XML元素。 (2) SOAP 屬於一種在應用程式間使用HTTP 通訊協定傳送資料的協定。 (3) SOAP是一種XML的基礎，簡單而且擁有很好的擴充性。 SOAP訊息主要是由下列三元素所組成 (1) Envelope 定義SOAP訊息根元素。 (2) Header Envelope的子元素，定義標題資訊，此為選擇元素。 (3) Body Envelope的子元素，內含送出和回應的訊息資料。 2.4.5 XML Web Service 的平台

(27)

跟 .NET 這兩種，不過在考慮到最近.NET 有發展快速的驅勢，且.NET 在效能上優於 J2EE，因此我們以.NET 作為 Web Service 的平台。簡單的說，.NET 就是 Microsoft 為 XML Web 服務所提供的平台。XML Web 服務可讓多個應用程式透過 Internet 彼此通訊並共用資料，不論其作業系統或程式語言為何。 2.4.6 應用方式之多元化以功能的角度來看，XML 給予了一套標準架構用來交換不同形式的資料，例如收據、醫療保險理賠申請單或是專案進度報告等；藉由應用程式介面（Application Program Interface, API）、網站自動化功能、資料庫入口網站等之輔助交換，文件或訊息的傳遞過程中便能夠輕易地被搜尋、複製、解碼或是正確無誤地顯示在最後的結果上。另外為了達到跨網站的搜尋，可以在不同的網站中，事先定義必須共同遵守的 DTD 或是 Schema 的定義，再依照定義來撰寫 XML 文件，如此，因為使用相同的 DTD，既使是不同的網站，呈現的內容也是類似的，就可以簡單的在各個網站內，做資料的搜尋。就是因為 XML 的獨立性與跨平台的功能，所以我們可以合併

(28)

不同的資料來源的結構化資料，如此透過應用程式，便可以整合資料及後端的資料庫內容，再將資料集送到 client 或其它的 server 上，做更多的處理和整合。再加上 XML 本身的開放性、彈性與自我描述性，我們可以直接以資料來做交換及處理的工作。 2.4.7 XML 未來的展望與發展方向目前有許多 XML 的活動，因此我們不敢斷言 XML 將會發展到什麼程度，但我們相信 XML 會對電子商務的起飛帶來幫助，因為 XML，使得電子商務廠商能夠以標準化的方式為產品以及相關資訊(價格、尺寸、顏色、特點等)加上標示，這些將會讓消費者更容易的比較各個網路商店的商品。 XML 可以有效描述出資料的結構，非常有利於電子資料的交換與電子商務上的處理。不僅如此，搜尋引擎在查詢資料時，便可僅針對 XML 定義出來的特定欄位檢索，以增加查詢的效率與準確性。此外， XML 將資料本身與呈現方式的敘述分開，同一份資料可以套用不同的文件樣式，便於在不同的場合中以最合適的形態呈現其實，我們可以將 XML 視為定義文件描述語言的一種媒介語言。目前已經有超過 100 家業者，致力於定義該行業適用的文件描述

(29)

語言。如果 XML 真能成功改變描述資訊的方式，未來網路上資訊的交換將更為開放，而資訊的呈現將可更為多元。

(30)

第三章密碼學介紹

3.1 密碼學概念

密碼學是研究加密和解密變換的一門科學。通常情況下，人們將可懂的文本稱為

明文

；將明文變換成的不可懂的文本稱為

密文

。把明文變換成密文的過程叫

加密

；其逆過程，即把密文變換成明文的過程叫

解密

。明文與密文的相互變換是可逆的變換，並且只存在唯一的、無誤差的可逆變換。完成加密和解密的算法稱為

密碼體制

。在計算機上實現的數據加密算法，其加密或解密變換是由一個密鑰來控制的。

密鑰

是由使用密碼體制的用戶隨機選取的，密鑰成為唯一能控制明文與密文之間變換的關鍵，它通常是一隨機字符串。

3.1.1

密碼分析學：是研究破譯密碼的一門科學。無論任何一種加密算法都是公開的。密碼學是用一種簡單的科學方法來保護資料，因而所有人讀資料都是有經過授權的；除了簡單的加密資料來保護資料，密碼學的技術也被應用於：＊確定被傳送的資料在接收之前是未改變過的。＊確認被傳送的資料確實是來自送件者。

(31)

一般有兩種類型密碼學被使用；symmetric key (對稱性的鑰匙)(圖 3.1.1.2) 和 public key (公開的鑰匙)(也叫非對稱的鑰匙) 密碼學。 3.1.2 對稱性密碼學：對稱性密碼學也叫對稱密鑰加密，它使用單把密鑰。這種密鑰既用於加密，也用於解密。對稱密鑰加密是加密大量數據的一種行之有效的方法。對稱密鑰加密有許多種算法，但所有這些算法都有一個共同的目的-以可還原的方式將

明文

（未加密的數據）轉換為

暗文

。暗文使用加密密鑰編碼，對於沒有解密密鑰的任何人來說它都是沒有意義的。由於對稱密鑰加密在加密和解密時使用相同的密鑰，所以這種加密過程的安全性取決於是否能保證機密密鑰的安全。如圖 3-1

(32)

舉一個簡單的對稱性鑰匙密碼學的範例，假設從朋友處收到一個通知，你和你的朋友同意來加解密你們的訊息，你們將使用下列演算法；每個字母將會上移三個字母，例如 A=C， B=D，而 Y 和 Z 轉一圈回到 A 和 B。這個方程式 ("每個字母上移三個字母") 就是送信者使用來加密訊息的鑰匙；而收信者使用相同的鑰匙來解密，任何人如果沒有鑰匙就不能夠讀此訊息。因為相同的鑰匙視同實用來加密及解密訊息，這個方法是一個對稱鑰匙的演算法。這類的密碼學即是我們所知的秘密鑰匙密碼學，因為此鑰匙必須被秘密保存於送信者和收信者，以保護資料的完整性。 3.1.3 非對稱性密碼學公鑰加密使用兩個密鑰-一個公鑰和一個私鑰，這兩個密鑰在數學上是相關的。為了與對稱密鑰加密相對照，公鑰加密有時也叫做不對稱密鑰加密。在公鑰加密中，公鑰可在通信雙方之間公開傳遞，或在公用儲備庫中發佈，但相關的私鑰是保密的。只有使用私鑰才能解密用公鑰加密的數據。使用私鑰加密的數據只能用公鑰解密。如圖 3-2

(33)

由於它用私鑰加密的數據只有公鑰才能還原，這被用在數位簽章中。每支鑰匙都具有改變內文的功能，私有的鑰匙產生一個私有改變內文的功能，而公開的鑰匙產生一個公開改變內文的功能，這些功能是反向相關的。例如，如果一個功能是用來加密訊息，另外一個功能則被用來解密訊息，不論此改變內文功能的次序為何皆不重要。公開的鑰匙系統的優勢是兩個使用者能夠安全的溝通而不需交換秘密鑰匙。例如，假設一個送信者需要傳送一個信息給一個收信者，而信息的秘密性是必要的，送信者以收信者的公開的鑰匙來加密，而僅有收信者的私有的鑰匙能夠對此信息解密。公開的鑰匙密碼學是非常適合於提供認證完整和不能否認的服務，且公鑰密碼中的私鑰無法記憶，用對稱密碼加密公鑰密碼中的私

(34)

鑰是不錯的用處。 3.2 密碼學的應用密碼學應用的範圍很廣，現今其可應用的有 EDI-企業之間的電子交易、網路安全、密碼技術與數位簽章...等，而且我們所實作的正是密碼學應用中的數位簽章。 3.2.1 數位簽章概念在公開金鑰基礎建設中，由某甲以私密金鑰加密的訊息，只能以某甲的公開金鑰才能解密。由此可知，若一密文能以某甲的公開金鑰解密，那此份訊息必然是以某甲的私密金鑰加密的。因此，以各人的私密金鑰加密後的訊息，具有不可否認的特性，稱為 "數位簽章"，可做為電子訊息簽章的方式。數位簽章的法定效力，將相等於一般的 "手簽章".某些情形下，數位簽章甚至比手寫簽名具有更大的法律效力。例如一份五頁的文件，只簽名在第一頁，沒有人敢保證其它頁沒被竄改過。但這份文件如果經過數位簽章，第三者可以驗證該文件是否有位元被修改過！

(35)

由此可知數位簽章可提供四種重要的安全保證： (1)資料完整性(Integrity)：文件接收者透過數位簽章之核對可確保此文件的完整性，避免被篡改、重送、遺失。 (2)資料來源辨識(Authentication)：文件接收者可確認此文件之發送者的身分，避免被冒名傳送假資料。 (3)資料隱密性(Confidentiality)：文件可以利用金鑰來加密、解密，以達到保密的安全保證。 (4)不可否認性(Non-repudiation)：因為只有文件發送者知道自己的私密金鑰，而且文件具有發送者之數位簽章，使其無法否認發送此文件的事實。下圖為數位簽章資料加解密關係圖

(36)

3.2.2 數位簽章之演算法

電子商務安全規範可分爲安全、認證兩方面的規範，而數位簽章是屬於安全這部分，而安全規範包括加密演算法、報文摘要演算法（Message Digest Algorithms）、安全通信協定(SSL)等方面的規範。

加密演算法包括對稱跟非對稱，前面已介紹過，而我們所使用的演算法 RSA 是屬於非對稱密鑰加密，和報文摘要演算法的 SHA (Secure Hash Algorithm)。

3.2.2.1 訊息摘要演算法

訊息摘要演算法（Message Digest Algorithms）即採用單向 HASH 演算法將需要加密的明文進行摘要，而產生的具有固定長度的單向雜湊（HASH）值。其中，散列函數（Hash Functions）是將一個不同長度的報文轉換成一個數字串（即報文摘要）的公式，該函數不需要密鑰，公式決定了報文摘要的長度。報文摘要對非對稱加密一起，提供數位簽名的方法。訊息摘要演算法主要有安全散列標準、

(37)

MD2 系列標準。

安全散列演算法（Secure Hash Algorithm，簡稱 SHA）：是一種報文摘要演算法，它産生 160 位元的散列值。SHA 已經被美國政府核准作爲標準，即 FIPS 180-1 Secure Hash Standard (SHS)，FIPS 規定必須用 SHS 實施數位簽名演算法。在産生與證實數位簽名中過程中用到的 HASH 函數也有相應的標準做出規定。

3.2.3 演算法說明

下面將介紹我們所使用的演算法:RSA 和 SHA

RSA: RSA 常用在 EDI 安全系統及一般加密系統的實作上，它是一種非對稱式加密演算法的簡稱，由麻省理工學院的三位教授 Rivest Shamir 和 Adleman 所發明，取其姓氏的第一個字母組合而成。所謂非對稱式加密演算法是相對於傳統的對稱式加密演算法改良而成。對稱式加密演算法在進行加密及解密時是使用同一把金鑰(Key)，因此送信與收信雙方在通訊前必需先協調得知該金鑰。由於雙方共享此秘密，因此可能產生否認發送或接收訊息的狀況，責任難以劃分。非對稱式加密演算法則是每個人產生一對金鑰，其中一把為私鑰(Private Key)，另一把為公鑰(Public Key)。加密是以私鑰為之，解密則以公

(38)

鑰為之，因此在通訊前收信者必須先取得發信者的公鑰，但不需要知道發信者的私鑰。由於沒有共享的秘密，因此可以達到不可否認的要求，這也就是所謂數位簽章(Digital Signature)的基礎。

SHA: Secure Hash Algorithm 1 是一種演算法，可承載長度低於 264 位元的訊息並產出一個 160 位元訊息摘要。該大型訊息摘要提供了安全性以反制惡意衝突以及反向攻擊。SHA-1 [NIS94c] 是 SHA 的改版，發表於 1994 年。

3.3 XML Security

XML Security 包含 XML 簽章與加密

，XML 數位簽章與加密可以將 XML 文件 ”整篇 ”加密，然後安全地發送給一個或多個接收方，這是 SSL 或 TLS 的常見功能，但是更令人感興趣的是如何對同一 XML 文件的不同 Tag 進行不同處理動作。此外 XML 最有價值的好處之一就是可以將整篇 XML 分成好幾個部分，然後在本地端保存完整的 XML 文件，再依照對方的需求傳送所需求的部分給對方，進而減少了網路流量。但是，這就帶來了一個問題：如何控制對不同元素的授權。對元素的授權是很重要的，譬如說商家可能需要知道客戶的名稱和位址，但是，無需知道任何正在使用的信用卡的各種詳細資

(39)

訊，就像銀行不需要知道購買貨物的詳細資訊一樣。可能需要防止研究人員看到有關個人醫療記錄的詳細資訊，而管理人員可能正好需要那些詳細資訊，但是應該防止他們查看醫療歷史；而醫生或護士可能需要醫療詳細資訊和一些（但不是全部）個人資料，以上這些例子都是 XML 傳送文件時必須注意到的功能，現在用於處理控制對不同元素授權的機制 W3C 已經規定得相當好。有了一般的加密，對 XML 文件整體進行數位簽章並不是問題了。然而，當需要對文件的不同部分（可能由不同的人）簽章，以及需要與選擇性的方法一起來這樣做時，就會出現困難。也許不可能或者不值得強制不同部分的加密工作由特定人員按特定順序進行，然而成功地處理文件的不同部分將取決於是否知道這點。現今密碼學所做的遠遠不止隱藏資訊，所以利用消息摘要確定文本完整性，數位簽章支援發送方認證，相關的機制用於確保任何一方日後無法拒絕有效事務，此外，由於數位簽章斷言已經使用了特定專用密鑰來認證，所以要小心簽章人是以純文字形式查看文件項的，這可能意味著對由於其他原因而加密的部分內容進行解密。在另一種情況下，作為更大集合中的一部分，可能對已經加密過的資料進行進一步加密。在牽涉單一 XML 文件（可能由一些不同的應用程式和不同的用戶處理在工作流序列中使用的 Web 表單或一系列資料）的事務集中考慮的不同可能性越多，就越可能看到巨大的潛在複雜

(40)

性。

3.3.1 XML 加密介紹

XML 加密語法的核心元素是 EncryptedData 元素，加密的資料可以是任意資料、XML 文件、XML 元素或 XML 元素內容甚至是根。下列幾個範例是介紹 XML 可以針對特定的元素進行加密顯示 John Smith 的銀行帳戶、5000 美元、卡號和有效期的的資訊 • <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'>

<Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Bank of the Internet</Issuer>

只隱藏了信用卡號的加密文件

• <?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'

Type='http://www.w3.org/2001/04/xmlenc#Content'>

<CipherData><CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> 隱藏了全部內容的加密文件 • <?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData><CipherValue>A234D112X/CipherValue></CipherData> </EncryptedData>

(41)

3.3.2 W3C 簽章格式說明本節將會為大家詳細介紹 W3C 所定義的簽章標籤，而下面的範例是對 XML 進行簽章後所產生的 XML 簽章文件，而後面註解是針對該行的標籤坐詳細介紹，看完此節將會對 XML 簽章有進一步的了解 [s01] <Signature xmlns= "http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm= "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> [s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [s06] <Transforms> [s07] <Transform Algorithm= "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> [s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> [s11] </Reference> [s12] </SignedInfo> [s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> [s14] <KeyInfo> [s15a] <KeyValue> [s15b] <RSAKeyValue> [s15c] ...<Q>...</Q><G>...</G><Y>...</Y> [s15d] </RSAKeyValue> [s15e] </KeyValue> [s16] </KeyInfo> [s17] </Signature> [s02-12] SignedInfo 元素是 XML 簽章的資訊。

(42)

[s04] SignatureMethod 是用於將已規範的 SignedInfo 轉換成 SignatureValue 的演算法。 [s05-11] 每個 Reference 元素都包括摘要方法和對已標籤資料物件計算得出的摘要值。 [s05] Reference 的這個可選 URI 屬性標籤要簽章的資料物件。 [s05-08] 該標籤與 transforms 一起是簽章者提供的描述，其內容有關它們如何獲得已摘要形式的已簽章資料物件。 [s06-08] Transforms 是一種可選的處理步驟排序列表，在資源內容之前，對它應用這些步驟。這是解密所需遵循的軌跡。 [s09-10] DigestMethod 是在應用 Transforms（如果已經指定它）之後對資料應用以產生 DigestValue 的演算法。DigestValue 是將資源內容與簽章者密鑰綁定的機制。 [s14-16] KeyInfo 表示用於驗證簽章的 KEY。

(43)

3.3.3 XML 簽章實作介紹圖 3-4 網路上販售的 XML 加密程式上圖是在網路上找到的加密 XML 程式,他的 key 是內嵌於程式之中,所以按一個鍵就能對整份文件中 Tag 內容進行加密,可惜的是並沒有對 XML 進行簽章與認證的動作,此程式的價格是依照 XML 文件的大小來訂定。

(44)

圖 3-5 本專題簽章程式這是我們撰寫的 XML 簽章加密程式,KEY 的存放是參考上一個程式也是內嵌於程式之中 , 這是為了方便不懂密碼學的使用者來使用此程式 , 使用時只要按下簽章鍵,程式就會對 XML 做簽章 , 之後就會使用 SOAP 送往 SERVER 端進行驗證,驗證成功就會輸出結果,當然此程式也能對 XML 做整分文件加密簽章程式主要功能如下 1. 執行:送出未加密的 XML 到 SERVER 端，SERVER 端並作處理資料的動作

(45)

2. 簽章:依照 W3C 的格式對 XML 進行簽章，之後會將 XML 文件送到

SERVER 端驗證，驗證成功便處理資料。

3. 加密:將整份文件加密,丟給 SERVER 端 , SERVER 再進行解密 ,成功後處理資料

(46)

內部簽章程式運作過程

步驟一:生一對 KEY:首先要先建立兩把 key 公鑰與私鑰並以 xml 格式儲存

(47)

步驟二:圖 3-7 簽署 xml 文件

(48)

第四章系統架構與問題解決

本專題目的是提供一個更安全的 XML Web Service ，所以使用到了 WSDK 這個 API，而 WSDK 中提供 WS-Security 函式庫，有了這個函式庫我們可以輕鬆的對 SOAP 中的 XML 進行加解密簽驗章，讓 Client/Server 端能安全地交換 XML 文件，接下來的內容將會詳細的介紹我們所使用到的相關函式庫。

4.1 WSDK 介紹與執行架構

WSDK 是 Microsoft Web Services Development Kit 的縮寫， WSDK 是用來建置 Web 服務的函式庫，採用 Web 服務通訊協定，包括 WS-Security、WS-Routing、DIME 及 WS-Attachments。WSDK 提供低階 API，讓您能直接將這些通訊協定套用到使用 HTTP 傳送的個別 SOAP 訊息。此類別庫也可以與較高階的 ASP.NET Web 服務 API (ASMX) 整合。安全性來說，WS-Security 可以讓您直接控制驗證 XML 訊息的時機及方式，但您必須撰寫程式碼來對應使用者名稱和密碼，或解譯

(49)

特定數位憑證的內容。WSDK 是用來將進階 Web 服務通訊協定套用到 SOAP 訊息上的引擎。這需要將標籤寫入傳出的 SOAP 訊息，並從傳入的 SOAP 訊息中讀取標頭，並還可能要轉換 SOAP 訊息本體；例如，依照 WS-Security 規格中的定義，加密傳出的訊息本體，並解密傳入的訊息本體。此功能包含於下列兩組篩選器：傳出訊息及傳入訊息的篩選器。所有從處理序傳出的訊息—用戶端要求訊息或伺服器回應訊息—都會經過傳出訊息篩選器處理。所有傳入處理序的訊息—給伺服器的要求訊息或給用戶端的回應訊息—都會經過傳入訊息篩選器處理，下圖將說明 SOAP 傳送的處理過程:

(50)

圖 4-1 WSDK 架構圖

(51)

4.1.1 WS-Security 介紹

WS-Security 是 WSDK 中的函式庫，其目標是使應用程式能建構安全的 SOAP 訊息交換，WS-Security 是 IBM 及微軟在過去兩年來所建立的第四個網路服務規格，並且在他們建立了 WS-I（Web Services Interoperability Organization，網路服務相容性組織）之後，WS-I 負責推動網路服務並確保其相容性。兩家公司之前所提出的規格都受到業界的普遍支持：SOAP（Simple Object Access Protocol，簡單物件存取協定），將不同電腦系統整連接在一起的通訊技術，讓企業能夠互動並進行交易；UDDI（Universal Description, Discovery and Integration，通用描述、發現，與整合），讓企業在網路目錄上註冊，可以廣告自己的網路服務以及輕易地找到彼此；以及 WSDL （Web Services Description Language，網路服務描述語言），讓企業能夠程式化來說明網路服務是什麼。 WS-Security 整合了微軟及 IBM 之前分別由 VeriSign 協助製定的兩個不同安全規格。

WS-Security 結合了 IBM、微軟，以及 VeriSign 的努力，作為 SOAP 訊息的一個零組件之用。它概要描述要怎樣使用現有 W3C 的 XML Signature（XML 簽章）及 XML Encryption（XML 加密）等規格。提出的安全標準，其設計能夠在任何線上的授權系統上執行。

(52)

時安全性的增強。這些機制可以用於提供多種安全性模型和加密技術。WS-Security 還提供關聯安全性權杖和 SOAP 的通用機制。 WS-Security 不需要特定類型的安全性權杖。舉例來說，Client 端可能會提供身份證明或是其他信用卡認證的證明。圖 4-2 Web 服務安全性規範

4.1.2 SOAP-DSIG 介紹

WS-Security 中提供對 SOAP 進行數位簽章的函式，此函式叫做 SOAP-DSIG，SOAP 數位簽章，函式內定義用數位方式簽章 SOAP 訊息及確認簽章的句法和處理規則。

(53)

下面的範例將說明 SOAP-DSIG 所定義之 TAG： (001) <?xml version="1.0" encoding="utf-8"?> (002) <S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> (003) <S:Header> (004) <m:path xmlns:m="http://schemas.xmlsoap.org/rp/"> (005) <m:action>http://fabrikam123.com/getQuote</m:action> (006) <m:to>http://fabrikam123.com/stocks</m:to> (007) <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id> (008) </m:path> (009) <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" >

(54)

(010) wsse:UsernameToken Id="MyID"> (011) <wsse:Username>Zoe</wsse:Username> (012) </wsse:UsernameToken> (013) <ds:Signature> (014) <ds:SignedInfo> (015) <ds:CanonicalizationMethod Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"/> (016) <ds:SignatureMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> (017) <ds:Reference URI="#MsgBody"> (018) <ds:DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/>

(55)

(019) <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue> (020) </ds:Reference> (021) </ds:SignedInfo> (022) <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue> (023) <ds:KeyInfo> (024) <wsse:SecurityTokenReference> (025) <wsse:Reference URI="#MyID"/> (026) </wsse:SecurityTokenReference> (027) </ds:KeyInfo> (028) </ds:Signature> (029) </wsse:Security> (030) </S:Header> (031) <S:Body Id="MsgBody"> (032) <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads"> QQQ </tru:StockSymbol>

(56)

(033) </S:Body> (034) </S:Envelope>

開頭兩行是啟動 SOAP。

行（003）啟動與此 SOAP 相關的 HEADER。

行（004）到（008）指定如何路由此 SOAP。

行（009）啟動我們在本規範中定義的 <Security> HEADER。該 HEADER 包含預期接收方的安全性資訊。該元素繼續一直到行（029）為止。行（010）到（012）指定與本消息相關的安全性權杖。這樣，它就定義了使用 <UsernameToken> 的客戶端的

用戶名稱

。請注意，我們在這裏假定服務知道密碼 — 換句話說，這是個共用的密碼。行（013）到（028）指定數位簽章。該簽章確保了被簽署元素的完整性（也就是它們不被修改）。簽章使用了 XML 簽章規範。在本範例中，簽章是根據從用戶密碼生成的密鑰進行的。行（014）到（021）描述了數位簽章。行（015）指定如何規範化（普通化）被簽署的資料。行（017）到（020）選擇被簽署的元素。

(57)

行（017）特別指出 <S:Body> 元素被簽署。在本範例中，只有 SOAP 主體被簽署；一般來說，消息的附加元素（如部分路由 HEADER）應該被包括在簽章中如 XML 簽章規範中所定義。行（022）指定將被簽署的標準化資料形式的簽章值。行（023）到（027）提供關於在何處能找到與此簽章相關的安全性權杖的

暗示

。行（024）到（025）特別指出安全性權杖可以在特定 URL 找到（拉出）。行（031）到（033）包含 SOAP 訊息的

主體

。

名詞解釋:

已簽署的安全性權杖 — 簽署的安全性權杖是由 SERVER 端加密簽署的安全性權杖。圖 4-3 安全性權杖內容

(58)

所有權證明 — 所有權證明是證明過程中用來說明發送方對資訊的認識的資料，這些資訊僅為安全性權杖的聲明發送方所知。完整性 — 完整性是保證資訊在傳輸過程中不被修改的過程。機密性 — 機密性是保護資料使得授權參與者或安全性權杖所有者才能夠流覽資料的過程。摘要 — 摘要是八位元的加密驗證。簽章 — 簽章是所有權證明和摘要的加密認定。並不能夠達到不可抵賴性。附件 — 附件是指與 SOAP 一起傳遞的附加資料，但附件並不是 SOAP 的內容。 SOAP-DSIG 應用在我們專題的簽章鈕上，也就是說按下簽章就會呼叫 SOAP-DSIG 函式裡的功能來簽章我們的 XML 文件。

(59)

圖 4-4 本專題簽章程式 4.1.3 測試簽章與加密系統或程式的測試是一件重要的工作，從測試當中能夠發現系統或程式的錯誤，加以改進後才能讓系統或程式趨於完美的境界。

本次測試是針對 4 份不同大小的 XML 文件做簽章加密與簽章+加密並計算所需執行的時間，4 份文件大小分別為 14KB 64KB 116KB 221KB 按下簽章鈕就會呼叫SOAP-DSIG 函式

(60)

如圖 4-5 所示

圖 4-5 測試程式

圖 4-6 測試時間表簽章加密簽章+加密 14KB XML _{約 0.12 秒} _{約 0.09 秒} _{約 0.15 秒} 64KB XML _{約 0.32 秒} _{約 0.29 秒} _{約 0.66 秒} 116KB XML _{約 0.60 秒} _{約 0.69 秒} _{約 0.95 秒} 221KB XML _{約 1.01 秒} _{約 0.99 秒} _{約 1.33 秒} 由上表可知時間與文件大小成正比，文件越大所需時間越多，但

(61)

是超過 221KB 以上的文件加密時可能會出錯，雖然出錯的次數很少，約 20 次中才會出錯一次，算是小 bug 但仍需要改進，這樣才能使的本系統更完美。

4.2 專題遇到困難與解決方法

這次專題製作過程，最大的問題可以說就是資料收集，還有就是我們缺乏對 XML 有相關研究的人給我們指導，首先遇到的困難就是 XML 簽章很難在市面上的書籍找到資料，所以必須上網路找 XML 簽章的資源來參考，但找到的資料都是些概念的東西，很少提到實作，為了解決困難只能四處尋找國外 XML 討論區，問有關簽章實作的問題，最後終於解決困難，之後我們選擇了 VS.NET 來撰寫簽章的程式，程式一開始要先 parser XML，在並使用.NET 的簽章函式庫對裡面的 Tag 做簽章，簽章的 Tag 必須按照 W3C 的規定來定義，實作簽章的問題到次算是解決了。

(62)

XML 簽章若要使用在 Web Service 上，另一個困難就是我們的 Client 端必須能呼叫 Client 端的函式庫，所以不能使用 ASP 來開發，因為 ASP 是呼叫 Server 端的函式庫，為了克服這個困難，曾經使用到 ActiveX 來編輯 Client 端的程式，後來卻失敗了，最後找到 WSDK 來開發 Client 端，WSDK 能讓 Client 有能力處理 XML 簽章，從以上兩個困難可以知道我們只要遇到問題就必須去找 XML 國外研究與應用的資料，所以時間都花 Research 與消化資料上。為了節省想要學習 XML 學弟妹的寶貴時間，所以我們製作了 XML Q&A。

4.2.1 XML Q&A

問：XML 應用在哪方面? 答：主要是用在電子商務中，此外也包括企業夥伴間、上下游工業中資料的互通有無，行政單位公文的傳送以及醫療單位中病例資料的資源分享，有太多的例子！問：Markup language (標記語言)的特性答：具可攜性、完整性、穩定性、彈性且應用廣泛。

(63)

一言以蔽之，兩者都是處理與使用者互動的瀏覽介有關 CSS 的資料，可查看 htt 問：XML 與 ASP 及 PHP 的比較

答：ASP 事實上不算是語言，它只是 Active Server Pages 的縮寫，在 ASP 中使用的語法實際上是 Visual Basic 的劇本檔 (script)版，最大的缺陷則為 ASP 在微軟 Internet Information Server(IIS)的原生性，這造成它只能用在 Win32 平台的伺服器的限制。ASP 比 PHP 慢又笨重，連穩定性也不好，一些專業人士因為熟悉 Visual Basic 而對 VBScript 的 ASP 出了問題比較好處理。ASP 是 IIS 內建的程式，取得不費力且又容易執行。PHP 版是一種內嵌在 HTML 語法的劇本 (script) 語言，它的語法混合了 C、Java、Perl 及一些特殊的 PHP 風格的語法。主要目的是能更快速地開發動態的網頁。兩者皆可與 XML 互相搭配！問：為何我們仍使用 HTML? 答：因為普及性及歷史性，要轉移至 XML 的技術雖然不難(因為皆屬於 SGML 語言)，但總要點時間，等大家熟悉了這套語言，相信 XML 將會雄霸天下！問：HTML 仍有巢狀結構, 故巢狀結構算是 XML 的優勢?

(64)

答：不是！不過它在網路上的應用因為其文件可包含許多巢狀元素，使其可在多重遠端伺服器中傳送。XML 是目前最複雜的傳送資料格式－網際網路即可視為一個巨大的 XML 資料庫!

(65)

第五章未來發展與心得

5.1 系統未來展望

剛開發本專題時，我們是一點頭緒也沒有，而且時間都花在找資料上，找到有用資料後，我們就開始規劃本專題，考量本組各組員的能力與參考現有資料之後，基本上我們能對XML進行數位簽章並能應用於WEB SERVICE上在實作很足夠了，接下來是介紹我們希望能夠完成的功能，以下就是本專題可以再加強的部分：

(1)利用IC 卡來存放Key：本次系統沒有IC 卡相關設備，Key的管理是採用內嵌於程式之中，但若用IC 卡，則系統將變得更安全更有彈性空間。 (2) 加強人機介面外觀設計：本組組員都沒有美術天分，加上時間短促，所以外觀需要再花時間修改。 (3)客戶端對客戶端能互傳加密文件:本系統只能客戶端對伺服器端互傳文件，要使用於客戶端對客戶端，技術上還需要在突破。 (4)應用於電子商務或公文交換上:本系統可結合訂單系統或是公文

(66)

傳遞系統，對需要的 XML 檔案做簽驗章的動作，可以增加網路上交換文件時的安全性。

5.2 小組心得

三下開始在尋找專題老師時，事實上，我們這一組一點方向也沒有，後來本組組員一起去找李維斌老師請益時，與老師溝通後，知道老師是以網路安全為專長，加上本組各組員平常也有在網際網路上，購物的經驗，因此對這方面，產生了極大的興趣。之後尋問老師有關專題的方向時，老師建議我們做 XML，因為網際網路越來越發達的今天，資料將會更加的豐富，因此收集資料的最有效的方法，就是以 XML 格式來取代 HTML，再加上 XML 本身具有跨平台的特性，所以，在未來 XML 格式將是網際網路的主流。此外，安全防護無論是在現實生活或是虛幻的網際網路上，都是一項重要的、且這也是全人類一直在追求的事物，因此才會有許許多多的加密演算法，加密的過程被創造出來，基於這些理由，我們專題才選定以 Web Service 上實作 XML 數位簽章，不過，由於 XML 的格式，尚未完全的制定完成，雖然現在大部分是以 W3C 的為主，不過 XML 因為可以自已定義 Tag，因此，之後的格式是如何，我們也不能保証會不會改變，在搜尋資料時的難度，也相對的增加，因此我們在

(67)

決定平台時，花了不少時間，請教了助教以及學長後，終於決定以 VS.Net 來作本專題 Web Service 的平台。

在製作專題時，我們學到了不少程式開發的經驗、報告寫作的技巧，以及如何有效的搜尋資料，更學到了分工合作是一項很重要的事，光靠個人，是無法完成這項堅鉅的工作，也真正了解到團隊研發的過程，雖然組員之間有時會鬧的不愉快，但是都是為了專題能夠快點完成，這些是我們作專題得到最大的收獲。

(68)

參考資料：

[1]W3C XML-Signature Syntax and Processing

http://www.w3.org/TR/xmldsig-core/

[2] WSDK Newsgroup

http://msdn.microsoft.com/newsgroups/default.asp?url=/newsg

roups/loadframes.asp?icp=msdn&slcid=us&newsgroup=microsoft.

public.webservices.wsdk

[3] An Introduction to the XML Signatures

http://www.xml.com/pub/a/2001/08/08/xmldsig.html

http://www-106.ibm.com/developerworks/xml/library/s-xmlsec. html/index.html#h5816

[4] Programming with the Web Services Development Kit(WSDK) http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/dnwebsrv/html/progwsdk.asp

[5] The XML for ASP.NET Developers CodeBank contains samples of using different XML related classes within the .NET

Framework.

http://www.xmlforasp.net/

[6] Microsoft's support for the new W3C XML Signature

standardhttp://www.dotnet247.com/247reference/msgs/12/6 0062.aspx

(69)

[8] The System.Security.Cryptography.Xml namespace contains an XML model for exclusive use within the .NET Framework security system.

http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/cpref/html/frlrfSystemSecurityCryptographyXmlSignedXm lClassTopic.asp

[9] A Programmer’s Introductiom to C# ，作者:Eric Gunnerson，旗標出版

[10]JAVA 密碼學，作者:Johnathan Knudsen，O´Reilly 出版

[11]JAVA 安全防護，作者:Scott Oaks ，譯者:高秀美 n，O´Reilly 出版

Web Service上實作XML數位簽章

逢 甲 大 學

資 訊 工 程 學 系 專 題 報 告