用消息交換增強ebXML的安全性

2019-11-18 12:48:43

字體：大中小

來源：轉載

供稿：網友

　　本文是兩篇有關ebxml安全性的文章中的第一篇，主要討論消息層。假如需要了解對ebXML概念的一般性介紹，以及研究一些基于功能階段實現普通ebXML交互的全部用例，請參看ebXML簡介。本文將重點解釋消息級別的安全性和ebXML消息傳送（ebMS）的安全策略機制。
　　
　　本文開頭綜述了消息層安全性的優勢。文中簡要討論了消息層安全性和瞬時套接層安全性之間的區別。在摘要中提出的概念對于理解有關ebMS消息層安全性方面內容的其他部分極為重要。接下來將深入研究如何使用協作協議輪廓（Collaboration PRotocol Profile，CPP）和協作協議協定（Collaboration Protocol Agreement，CPA）來為ebXML消息層描述安全性策略。
　　
　　什么是消息層安全性？
　　
　　在實際情況中，大多數ebXML消息都有基于獨有XML的消息層安全性需求，包括數字簽名、認證、數據私密性、以及內容產生的威脅保護。這些消息層機制提供了超過和在瞬時應用程序層安全性（例如SSL/TLS）之上的保護。實際的ebXML部署利用應用程序層安全性機制和套接層傳輸機制。
　　
　　ebXML提供的消息層安全性標準依靠于昂貴的XML安全性操作，例如XML簽名和XML加密。盡管兩種標準都使用了昂貴的加密處理，但是在這些標準中執行XML處理所需的時間遠遠超過了執行加密操作所需的時間，因為綜合XML解析、轉換、模式驗證和消息標準化的費用昂貴。本文認為通過將XML處理和加密處理分離到一個安全的、加固的XML網關設施中（XML防火墻），可以實現顯著的性能提升并具有安全性優勢。
　　
　　根據普遍存在的價格經濟的和受信的傳輸層機制（例如SSL/TLS或VPN技術）而產生的消息層安全性需求經常使初學者感到困惑。術語消息層安全性是指穩定的安全特性，它適用于任何類型的基于協議的消息交換，不管是通過HTTP、SMTP、FTP或是其他協議。
　　
　　在消息層安全性的情況中，無論消息單位是XML文件還是二進制附件，它都是經過加密或簽名的，或者既經過加密又包含簽名的。對于XML文檔來說，由于XML的結構化特性，具體的操作可能具有高度的顆粒性。
　　
　　將消息層安全性應用于有效負荷可以解決傳輸層機制不能很好處理的安全性問題，例如安全特性的持久性。舉例來說，在SSL連接中，安全特性應用于套接字，并且任何寫入或者從套接字中讀出的數據都是經過加密和驗證的。但是，假如將套接字拆開，那么就沒有辦法辨別來自套接字的部分數據是否應用了安全特性。此外，在多次反射通道的情況中，數據在已經中止SSL連接的任何地方都是清楚地。這種情況稱做SSL安全性“鴻溝”，如圖1所示：
　　　用消息交換增強ebXML的安全性（圖一）

　　圖1：SSL安全性鴻溝
　　
　　消息層安全性機制在ebXML和其他基于XML的Web服務協議中使用廣泛。他們幫助為長時間運行的事務或者以多次反射方式涵蓋多種域的事務提供持久性認證、數據加密和發送方驗證。消息層安全性的用途包括剩余數據保護，即數據經過簽名和加密之后再插入到數據庫中。
　　
　　CPP安全策略
　　
　　為了理解CPP如何描述安全策略，有必要首先檢查CPP實例的外部結構。一個CPP實例由五個直接子元素定義，如清單1所示。元素的基數用一個簡單的BNF語法描述。加（+）號表示一個或多個，問號（？）表示0或1，星號（*）表示0個或多個，沒有符號則表示只能是1個。
　　
　　清單1：協作協議輪廓（CPP）XML結構
　　
　　<CollaborationProtocolProfile>
　　(<PartyInfo>)　+
　　(<SimplePart>) +
　　(<Packaging>)　+
　　(<Signature>)　?
　　(<Comment>)　　*
　　</CollaborationProtocolProfile>　　不需要考慮清單1中的全部元素。有關ebMS消息層安全性的大部分安全策略信息位于<PartyInfo>元素和<Packaging>元素之中。讀者可能注重到清單1的例子中有一個<Signature>元素。這是一個可選的W3C XML Signature，CPP的創建者可以提供它用于驗證機制。對CPP來說，通常只有一個簽名者，但是CPA假如進行派生則可能有其他簽名者。就驗證這個目的而言，ebMS對CPP自身和實際的交換信息都利用了XML Signature，熟悉到這一點很重要。接下來兩段將敘述<PartyInfo>元素和<Packaging>元素中所內嵌的策略信息。
　　
　　<PartyInfo>元素
　　
　　<PartyInfo>元素描述了適用于特定貿易合作伙伴的實現細節。一個CPP可以擁有多個<PartyInfo>元素，因為大型企業可能需要從多個方面以不同的角色和業務來進行描述。<PartyInfo>元素的結構如清單2所示。
　　
　　清單2 <PartyInfo>的結構。
　　
　　<PartyInfo>
　　(<PartyID>)　+
　　(<PartyRef>) +
　　(<CollaborationRole>) +
　　(<Certificate>) +
　　(<SecurityDetails>) +
　　(<DeliveryChannel>) +
　　(<Transport>) +
　　(<DocExchange>) +
　　(<OverrideMshActionBinding>) *
　　</PartyInfo>　　用來描繪ebXML事務的安全策略的三個重要子元素是：<Certificate>元素、<CollaborationRole>元素和<DocExchange>元素。目前，<SecurityDetails>元素被用作一個擴展點，不傳遞直接策略。<Certificate>元素是CPP的中心內容，它是一個包含ebXML事務所用的公鑰的X.509認證清單。這種結構很普通，可以在 CPP 里的其他地方引用。<CollaborationRole>元素帶有子元素，用于描述原有消息層之外的安全策略項。它可以映射為特定的PKI實現，用于ebXML會話中非透明的（例如：非XML的）有效載荷。
　　
　　最后，<DocExchange>元素為實際運行時ebXML安全策略奠定基礎。這個元素包含了對發送者和接收者的安全策略都很重要的信息。非凡值得注重的是，它定義了三個重要的子元素：<SenderNonRepudiation>、<SenderDigitalEnvelope>和<NamespaceSupported>。清單3直觀地展示了這些內容的層次。
　　
　　清單3 <DocExchange>層次結構
　　
　　<PartyInfo>
　　<DocExchange>
　　<ebXMLSenderBinding>
　　<SenderNonRepudiation>
　　<SenderDigitalEnvelope>
　　<NamespaceSupported>
　　<SenderNonRepudiation>元素定義了計算XML簽名時要用到的參數，其中包括協議（協議通常就是W3C XML簽名）、用來排列摘要信息的哈希函數（如SHA-1）、具體的簽名算法（如RSA或DSA）、以及一個指向簽名所用的X.509證書的引用。以這里，引用可以指向<Certificate>，<PartyInfo>元素的一個直接子元素。
　　
　　<SenderDigitalEnvelope>參考所使用的加密機制。術語數字信封（digital envelope）源于消息層安全性事實，如ebXML里所用，一般來講，使用快速的對稱密鑰（symmetric key）來加密有效載荷，然后依靠接收者的公鑰來加密對稱密鑰，這樣更有效率。從這個意義上來講，原始對稱密鑰就是被另一個密鑰給封住了。對于ebXML，數字信封的推薦機制是XML加密，但也可以被使用二進制機制如S/MIME和PGP/MIME。<SenderDigitalEnvelope>元素指定了協議類型、版本以及所用的加密算法。
　　
　　最后一個元素，<NamespaceSupported>，可以用來消除XML安全規范的不同版本之間的歧義，如XML簽名和SAML。<NamespaceSupported>元素的作用是直接指定相應安全規范的名稱空間（因而也指定了版本）。清單4給出了<SenderNonRepudiation>元素和<SenderDigitalEnvelope>元素的一個例子。
　　
　　清單4 安全策略元素示例
　　
　　<SenderNonRepudiation>
　　<NonRepudiationProtocol>
　　http://www.w3.org/2000/09/xmldsig#
　　</NonRepudiationProtocol>
　　
　　<HashFunction>
　　http://www.w3.org/2000/09/xmldsig#sha1
　　</HashFunction>
　　
　　<SignatureAlgorithm>
　　http://www.w3.org/2000/09/xmldsig#dsa-sha1
　　</SignatureAlgorithm>
　　
　　<SigningCertificateRef certId="CompanyA_SigningCert"/>
　　</SenderNonRepudiation>
　　
　　<SenderDigitalEnvelope>
　　<DigitalEnvelopeProtocol version="2.0">
　　S/MIME
　　</DigitalEnvelopeProtocol>
　　
　　<EncryptionAlgorithm>
　　DES-CBC
　　</EncryptionAlgorithm>
　　<SenderDigitalEnvelope>
　　在清單4中的例子中,發送者支持消息層鑒權的XML簽名,使用DSA算法和SHA-1哈希函數進行。對于數據私密性，則使用S/MIME v2.0機制,帶有56位CBC模式的DES鍵。
　　
　　在這時看來，似乎消息層安全機制所有必需信息都已經被指明了，但還有個問題，那就是如何把這些操作應用到ebMS消息。EbMS規范使用了一個含有幾個組成部分的MIME信封。驅動程序包括一些場景，在其中ebMS消息的各個部分被加密或簽名。這正是<Packaging>元素的工作。<Packaging>元素描述了需要被簽名或被加密的ebMS消息部件，以及無需加密的應該留給別人去修改、更新或改變的部件。
　　
　　<Packaging>元素
　　
　　<Packaging>元素描述了ebMS消息的哪些部分要簽名和加密，哪些部分不需要。
　　
　　查看<Packaging>元素是如何工作的。首先請查看ebMS消息的消息結構，它是根據帶附件的SOAP協議(SwA)定義的。SwA的結構則是根據一套名為SOAP消息包的MIME包來定義的。每條SwA消息都是一個消息包的集合，主要SOAP有效載荷位于第一個MIME容器里。圖2直觀地展示了ebMS消息與應用層之間其他部分的關系。
　　　用消息交換增強ebXML的安全性（圖二）