PKI与WebServicesSecurity标准与应用.doc

6月PKI與Web Services Security標準與應用研究前言自可延伸性標示語言XML（Extensible Markup Language）出現以來，其開放性的標準讓各個不同系統間能夠互相交換資料，同時也讓各個程式間能夠互相通訊。程式設計師在不同作業系統、運用不同程式語言所寫的程式也可以利用XML的互通性達到軟體互通的地步。事實上，這樣的概念已經在網路上利用HTML格式讓網站內容可以在各個平台和軟體上顯現。而現在只要利用Web Services，各個程式間可以利用XML資料來互相存取、交換資料。Web Services的威力就在於它利用了XML的互通性和延伸性，使其相結合並達到許多複雜的作用，一個提供簡單服務的程式可以利用Web Services來交談，並達到傳送複雜的加值服務。在使用Web Services從事商業行為時，對訊息內容的安全性無疑地是一大考量。因此鑑定和授權即為兩項重要的關鍵所在。以目前網路安全性中的加解密和身份認證技術來說，公開金鑰基礎建設（Public Key Infrastructure，PKI）提供了完整且緊密的安全性方案，包括公開金鑰的加解密、數位簽章、數位憑證等。利用PKI和Web Services技術的相結合，可以提供在Web Services交易行為中的安全性、鑑別性、整合性，以及不可否認性。PKI在各國的建置工作早已如火如荼的展開，我國也已經展開政府PKI的建置，且已完成部分CA的建置工作。欲發展網路上的商業行為，對於安全性的建置工作為首先必要條件。第一章、PKI與Web Services Security的技術Web Services的技術標準Web Services的核心技術標準是由全球資訊網聯盟（World Wide Web Consortium，W3C）所制訂，包括WSDL（Web Services Description Language）、SOAP（Simple Object Access Protocol）等核心技術。Web Services的成功應歸功於XML的互通性與可擴展性，W3C於2000年9月即著手制訂XML的通訊協定，利用XML的互通性作為各個應用與應用間通訊之用。2002年1月，W3C成立Web Services Activity，並將原本制訂XML通訊協定的XML Protocol Activity納入，使其研究範圍延伸至Web Services領域。Web Services Activity下的XML Protocol WG即負責制訂Web Services的通訊協定標準，最新的通訊協定標準為SOAP 1.2版。在Web Services的架構中，交易雙方利用SOAP通訊協定傳輸交易訊息時，其內容為一般明文格式，意謂著訊息內容可以被有心人士所攔截並窺視。因此，在傳輸SOAP訊息時，對於具有機密性的資料應該作加密的動作。對稱式加密法加密演算法使用的金鑰加密演算法可分為兩種，一種為對稱式金鑰加密法（Symmetric Key Encryption）、另一為非對稱式金鑰加密法（Asymmetric Key Encryption）或稱為公開金鑰加密法（Public Key Encryption）。前者所使用之加密及解密之金鑰，為相同一把金鑰，意指使用相同一組密碼來加解密。使用對稱式金鑰加密的好處在於其加解密速度快，不會對系統產生太大的負擔，因此若雙方都握有同一把對稱式金鑰，則可對訊息傳送做加解密的動作。非對稱式加密法公開金鑰加密法則是採用兩把不同的金鑰，一把稱為公開金鑰，另一把稱為私密金鑰（Private Key），意即公開金鑰為公開對外，而私密金鑰則不可公開。在公開金鑰演算法中，以私密金鑰加密的資訊只能由相關的公開金鑰所解密，反之亦然。因此當某甲利用某乙的公開金鑰對訊息加密後，只有某乙可以利用其私人所有的私密金鑰將此訊息解密，因此可以保證某甲欲傳送給某乙的訊息只有某乙可以看到。反之，當某乙利用其唯一的私密金鑰對某個文件加密後，任何人都可以用某乙所公開的公開金鑰對此文件解密，因此可以確定此文件確為某乙加密。由此可知公開金鑰的優點在於其安全性和鑑別性高；但是，由於公開金鑰演算法複雜度高，因此其加解密速度比對稱式金鑰演算法要緩慢許多。故一般加密技術都將兩種金鑰技術合併使用。建立Web Services Security建立Web Services Security可以採用前述加解密的方式，也可以採用SSL（Secure Socket Layer）的方式。但使用SSL的問題是SSL只能使用HTTP（Hyper Text Transmission Protocol）通訊協定，而不能用在其他傳輸協定如SMTP（Simple Mail Transfer Protocol）、FTP（File Transfer Protocol）等。另外，使用SSL會產生較大的負荷，因為SSL會對整個SOAP訊息都做加密的動作。因此，另一項方案就是只針對SOAP訊息中需要加密的部分做加密，除可以減少處理時間外，也不會受到傳輸通訊協定的限制。雖然W3C的Web Services Activity在制訂SOAP時，並未提供安全性的要素，但在SOAP訊息的封裝中可以利用XML的延伸性，將金鑰封裝至SOAP訊息中，提供在Web Services訊息中傳送公開金鑰和數位簽章。另外，微軟、IBM及VeriSign也於2002年4月聯合發表網路服務安全規格（WS-Security）。規格中整合了微軟與IBM先前所分別訂定的不同安全規格，後面章節將會針對在Web Services的SOAP訊息中如何加入憑證資訊的技術與應用作說明。另外，在2001年3月，由VeriSign、Microsoft、webMethods三家公司也共同制訂出一項XML金鑰管理規格（XML Key Management Specification，XKMS），其結合XML的互通性和PKI的安全性，並提供一些方法讓應用能夠管理並使用公開金鑰來交換資料。第二章、Web Services中SOAP訊息的安全性特定應用W3C組織的Web Services Activity所制訂的SOAP 1.2版的Messaging Framework文件中，對於SOAP的安全性考量表示，SOAP的訊息架構中並不直接提供控制存取（Access Control）、機密性（Confidentiality）、整合性（Integrity）、和不可否認性（Non-repudiation）等機制。若需使用上述機制，則需要使用SOAP所提供的延伸功能，稱為SOAP可延伸性模式（SOAP Extensibility Model）。SOAP提供了SOAP訊息架構的可延伸模式，讓SOAP訊息的實作者可以在訊息中增加可信賴性、安全性、關連性、路由，及訊息交換格式。另外，SOAP訊息架構的規格中亦強烈建議SOAP訊息的實作者應該要在SOAP的訊息中加入可信賴的功能，而SOAP訊息的接收者則應該判斷其所接受的訊息的可靠度。SOAP可以將應用所定義的資料放在訊息格式的標頭區塊（Header Blocks）或是本體的內容（Body Contents）中，SOAP訊息的封裝格式如下圖一：對加密籌載物（Payload）的請求當傳送者欲對籌載物加密並傳送訊息給接收者時，傳送端的應用會將資料加密，封裝至SOAP訊息中傳送給接收者。而當資料抵達接收端時，接收端的應用可能會使用相同的方式解密，亦即可使用對稱式金鑰來對訊息作加解密。當應用欲對內容加密時，會隨機產生一組對稱式金鑰，並用此金鑰對內容加密，由於對稱式加密法的速度快，因此不會對系統產生太大負擔。但是接收端的應用並不知道這把對稱式金鑰的值，所以接收端需將此把金鑰封裝至SOAP訊息中，並使用接收端的公開金鑰對此對稱式金鑰加密，以確保只有接收端可以使用這把對稱式金鑰。在SOAP訊息中需包含公開金鑰資訊、加密過的對稱式金鑰、加密內文等。本例為將加密的資料置入內文中的封裝格式。表一為原始訊息，表二則為對表一的原始訊息加密後的檔案，原始訊息中各標籤說明如下： ：說明本XML文件版本為XML 1.0版。 ：定義的封裝（Envelope）標籤，由於SOAP訊息採用封裝方式，因此此標籤為最上層的標籤。標籤中的“xmlns:env=http.”定義了前置文字（Prefix）env的XML名稱空間（Namespace）的網址。 ：使用的內文（Body）標籤。 ：為本例所欲加密的資料，其中的“xmlns: m =http”定義了此前置文字m的名稱空間所在。 在表一中，加密的目標為在內文中的標籤中的資料。而在表二中，新增了的標頭標籤，其中新增了許多對加密演算法、金鑰名稱、金鑰訊息的敘述。而原本在標籤中的資料，經過加密後已被 所取代。其標頭中的各標籤說明如下： ：使用的標頭（Header）標籤。 ：為SOAP通訊協定所定義的加密說明標籤，其中的“xmlns:sec=http”定義了此前置文字sec的名稱空間所在。 ：此標籤中擁有標籤，用以指向加密資料的URI位置，在這裡使用指向ID的方式，所指向的ID放在內文標籤中做說明。 ：由於加密資料時會使用臨時產生的對稱式金鑰對資料加密，並再以訊息接受者所擁有的公開金鑰對此對稱式金鑰加密，此標籤即為對此公開金鑰的描述。其中“xmlns: xenc =http”定義了此前置文字xenc的名稱空間所在。另包括ID、文件中使用的對稱式金鑰名稱（CarriedKeyName）、和訊息的收受者（Recipient）等多項屬性。 ：說明加密演算法的位置。 ：公開金鑰的相關描述。其中的“xmlns:ds=http”定義了此前置文字ds的名稱空間所在。此標籤中的子標籤說明了公開金鑰的名稱。 內文標籤的說明如下： ：此標籤取代原本的標籤。其中定義此加密資料的ID為“encrypted-body-entry”，供標頭做指向。 ：此標籤的子標籤的對稱式金鑰為實際對資料作加密的金鑰。事實上這裡所敘述的金鑰也為密碼形式，已經被前述的“someone的RSA公開金鑰”所加密，以此保證只有“someone”本人可以使用這把對稱式金鑰。 ：此標籤的子標籤中為已被對稱式金鑰加密的資料。 訊息標頭和籌載物的加密另一個應用案例為，當兩個交易伙伴在交換訊息時欲對訊息標頭、路由標頭、籌載物進行數位簽章，並對此做簽章驗證。欲傳送訊息者或是送出請求的應用可以對籌載物做數位簽章，而訊息傳送處理器則對訊息標頭、路由標頭做數位簽章。當兩個應用使用加密的籌載物進行通訊時，籌載物並不會對SOAP的處理層（Processing Layer）產生影響，SOAP的處理層會負責對標頭或是籌載物的簽章或是加密的動作。如下圖三所示，傳送端和接受端之間會由傳送端的訊息簽章處理器（Message Signing Handler）和接收端的訊息驗證處理器（Message Verification Handler）之間做成加密的協議。而在標頭中也有可能會加入訊息路由處理器，且亦可被簽章或加密。第三章、Web Services Security的標準研究WS-Security規格提出一套標準SOAP的延伸規格，用於建立安全的Web Services訊息。WS-Security標準提供在Web Services訊息中加入安全性的機制，由於此標準為一廣泛的安全性標準，故WS-Security中並無對於Security Token的限制。規格中包含多種安全模式的應用，如PKI、Kerberos、SSL，且支援在訊息中使用多重Security Token格式、多重Trust Domains、多重簽章格式、和多重加密技術。該規格中也提供了三項主要機制：在訊息中可以傳送Security Token、訊息整合性、和訊息機密性。WS-Security規格說明了如何將Security Token和數位簽章結合至Web Services的SOAP訊息中，使得當交易進行時，可以確保訊息的安全性和鑑別性。以下針對WS-Security規格中關於PKI的安全應用作一說明。Security Header利用的標頭區塊標籤可以在標頭檔中宣告欲使用的Security Token的相關資訊。欲使用多個Security Token，則可重複使用的標籤，參考多個Security Token。Security Tokens在Security Header中可以加入對於Security Token的資訊，資訊內容包含： User Name Token：在安全性標頭中可以選擇是否要提供使用者名稱。 Binary Security Token：提供X.509憑證、Kerberos Tickets或其他非XML格式的Security Tokens的相關資訊，包括ID、Value Type和EncodingType。 XML Tokens：提供XML tokens的資訊。 Token的參考提供對於Security Token的參考，對於金鑰的參考有下列幾種模式： 直接參考：直接指定憑證所在的URI。 Key Identifiers：當不使用直接參考時，建議使用此金鑰識別符號來指定金鑰的ID、Value Type和Encoding Type。數位簽章WS-Security規格提供了數位簽章的功能，讓訊息傳送者可以加入數位簽章以提供訊息的身份辨識。在標籤中可提供對於簽章的相關資訊，包括演算法、簽章的Tokens、簽章訊息、數位簽章的有效日期等資訊。加密在訊息的標頭和本文區塊中都可加入對於加密的相關資訊，其中包括： 標頭中應指明所需加密的資訊的ID做為參考。 加密的金鑰資訊，如前述簽章的金鑰相關資訊。 內文中應指明欲加密的資料和給予ID。 時戳在訊息中可以加入時戳作為證明訊息傳送的時間證明。錯誤訊息WS-Security規格中也提供了當簽章、憑證、金鑰等資訊產生錯誤時的回傳值。X.509憑證在WS-Security中的應用範例WS-Security規格讓訊息傳送者可以將憑證資訊封裝至Web Services訊息中。X.509憑證中包含了憑證所有人的公開金鑰（Public Key）和相關資訊，如憑證所有人名稱（Subject Name）、憑證發送者名稱（Issuer Name）、憑證序號（Serial Number）、憑證用途（Key/Certificate Usage）、有效期限（Valid from/to）、和發送憑證的CA的數位簽章（Digital Signature）。而憑證可經由CRLs的發送、OCSP的Tokens或是其他如XKMS的機制來廢止該憑證。以下針對X.509憑證在Web Services訊息中的應用範例說明。表三中的標籤茲說明如下： ：“xmlns:wsse”說明wsse的XML名稱空間的位置。 ：此標籤包含憑證資訊，Id為此Security Token的名稱，ValueType則表示此Security Token為X.509v3的憑證，EncodingType則表示此為64位元Token。 識別憑證欲識別訊息傳送者的憑證可以直接由憑證內容或是以參考的兩種方式來達到識別的目的。以憑證內容來識別訊息中的X.509憑證是經由中所附的憑證資訊來達到，並利用之中的中所含的資訊來參考。元素中的wsu:Id屬性將參考到中說明的wsu:Id屬性。如何以憑證內容來識別憑證並非WS-Security規格的範圍，而使用WS-Security規格的應用可以利用此來識別憑證。應用範例可參考表三。另外，識別憑證也可以利用參考的方式，若訊息中沒有包含憑證的內容供作直接參考用時，則可利用標籤中的之中的發送者名稱和中的序號提供識別憑證的參考。當在SOAP訊息中使用X.509憑證中的金鑰來作為簽章金鑰時，該簽章演算法必須為一個數位簽章演算法。另外，當在SOAP訊息中使用X.509憑證中的金鑰來作為加密金鑰時，該加密演算法必須為一個公開金鑰加密演算法。另外，當使用X.509憑證時，使用者必須使用WS-Security規格中所定義的錯誤訊息。若實作者需要使用自訂的錯誤訊息時，建議應改採用延伸定義訊息的方式，將自己定義的訊息包含在規格中所定義的錯誤訊息中。 第四章、結論目前電子商務活動正日趨活絡，一般皆預測未來企業間交易將採用Web Services的方式來達成。原本各個企業間由於伺服器和應用的不同，無法將交易完全以網路的方式來進行，但是現在企業可以利用Web Services來交換資訊。也由於Web Services的互通性，使得企業可以減少因為使用不同系統而產生的額外交易成本。另外，也使得原本許多電腦上的應用，也可以經由網路來達成。不過，當一項新的技術來臨時，勢必會產生新的問題。Web Services搭起了不同系統和不同應用間的橋樑，也連帶增加了安全上的顧慮。尤其是利用Web Services來進行交易更是需要高度的安全性保障。公開金鑰基礎建設為目前各國發展電子商務的首要安全考量，不論是商業行為、公文往來，甚或是電子郵件的寄送，都需要仰賴PKI技術的支援，才能提供其可信賴性。因此，將PKI有效整合至Web Services中，將可提供Web Services交易時的安全性及身份識別，而Web Services的架構還需要開發許多新的技術。PKI跟Web Services原本為兩項技術，但若能整合兩項技術的優點，對於電子商務的發展不啻為一大助力。參考資料 XML Key Management Specification/TR/xkms/ XML Signature WG/Signature/ SOAP Version 1.2 Usage Scenarios/TR/2002/WD-xmlp-scenarios-20020626/ SOAP Version 1.2 Part 1: Messaging Framework/TR/2003/PR-soap12-part1-20030507/ Specification: Web Services Security/developerworks/libra