SOAP安全性擴展：數字簽名

2024-07-21 02:21:49

字體：大中小

來源：轉載

供稿：網友

　　soap安全性擴展：數字簽名（soap-dsig）定義了用數字方式簽名soap消息及確認簽名的句法和處理規則。本文討論了soap-dsig和ssl有著怎樣的關系，并描述了這兩項技術是如何互補的。

數字簽名使初始用戶和軟件能夠可靠地發送信息。可惜的是，簡單對象訪問協議（simple object access protocol，soap）1.1并不包括簽名消息的規定，因此也無此安全性。我和我的同伴們曾建議在soap中加入數字簽名技術（它隨即被萬維網聯盟收錄為soap-dsig附注），來定義用數字方式簽名soap消息以及確認簽名的句法和處理規則。該技術從此被應用到了ibm、microsoft以及其它公司外發產品中。

然而soap-dsig必須使用安全套接字層（secure sockets layer，ssl），這是一種在web站點中得到了最廣泛運用的安全性技術。因此我們應該提出這樣一個問題：soap-dsig和ssl有著怎樣的關系？這兩項技術的區別又是什么呢？

本文回答了這些問題，并描述了這兩項技術是如何在各自的不足之處與對方實現互補的。同樣，由于http（也就是http上的soap）應用相當廣泛，因此本文將主要把http作為傳輸層進行重點討論。然而，您應當注意，soap和soap-dsig都是獨立于傳輸而存在的，因而能在其它傳輸協議上使用，如smtp、ftp以及mq。在使用其它傳輸協議時，您需要了解soap-dsig與那個傳輸層（例如，smtp中的s/mime）中相應的安全性有著怎樣的關系，這也是我稍后將在本文中說明的內容。

介紹
盡管http最初只是作為一個傳輸html文檔的協議開發的，而現在您通過web站點上的cgi腳本或java servlet就能用它來訂購產品和服務。在因特網上訂購產品時，您可能需要發送信用卡號碼等的個人信息。然而，您應該只把該信息以安全的方式發送給值得信任的http服務器，這樣就沒有敵對的第三方能截獲并竊取該信息了。開發ssl就是為了解決這些保密性和服務器身份驗證問題的，它現已得到了廣泛使用。

與這些企業對客戶（b2c）的應用不同，在企業對企業（b2b）的應用中，不是由人用瀏覽器來顯示html文檔，而是由計算機來處理訂單。且比如商品訂單等數據可能會用xml而不是html格式進行描述，并通過http和soap進行交換。

soap是一個用來交換任意xml文檔的標準消息傳遞層，也是web服務的主要構件之一。除了soap以外還有其它相關技術，如通用描述、發現和集成（universal description，discovery and integration，uddi）以及web服務描述語言（web service description language，wsdl），但本文并不想討論這些技術。（需要關于在本文中提及的技術的鏈接，請參閱參考資料部分。）

在開發基于soap的web服務和b2b應用時，安全性問題仍然很重要。特別是在企業間的商業交易中，不可抵賴性的安全性要求需要得到滿足。soap-dsig就是針對這個目的提出的。本文回答了下列問題：什么是不可抵賴性？soap-dsig和ssl是如何結合起來以實現不可抵賴性的？

消息傳送的安全性要求
每一個soap消息都有一個soap信封和soap編碼。soap信封是一個能用來裝載任何xml文檔的數據結構。soap編碼被用于將非xml數據編碼為xml文檔，這樣它就能被裝在soap信封中進行傳輸了。通常，這一編碼旨在用于類似遠程過程調用（rpc）的應用中。由于本文中主要討論的是soap信封，而并不直接涉及soap編碼，因此它適用于任何一種基于soap的應用，包括rpc和b2b應用。

在開始部分，我將概述一下從一臺計算機（發送方）到另一臺計算機（接收方）的消息傳輸的一般安全性要求。確切地說，我將談到消息身份驗證、發送方/接收方身份驗證以及不可抵賴性。請注意，這里所描述的安全性要求并不是soap所專有的，它們能適用于任何種類的消息傳輸。

第一個要求就是機密性加密。由于機密性要求是通過使用ssl來滿足，而不是由soap-dsig解決的，因此本文中將不作討論。我所關注的安全性要求是身份驗證。請考慮一下下面兩個問題：

●從發送方的角度來看：在發送消息的時候，目標接收方的身份是如何得到驗證的呢？
●從接收方的角度來看：在接收消息時，發送方的身份和消息的內容是如何得到驗證的呢？
在這里，我將身份驗證看作是兩種安全性要求的結合。一種是消息創建者的身份驗證，它被稱為消息身份驗證。另一種是發送方和接收方身份的驗證，它被稱為發送方/接收方身份驗證。在可能存在不可靠或惡意的計算機的網絡環境中，消息的創建者和消息的發送方不總是相同的。例如，一旦有惡意的一方以某種方式竊取了由發送方創建的合法消息，該消息就有可能被轉發給任何人。因此，這一差異就很重要。

這兩種類型的身份驗證牽涉到以下幾個方面：

●消息身份驗證：
消息身份驗證保證了被傳輸的消息不會在途中被修改，且消息創建者的身份不會被冒用。通常，消息身份驗證能通過在被傳輸的消息中附加一個數字簽名或者消息身份驗證代碼（message authentication code，mac）來實現。在這里您需要注意的是消息身份驗證無法保證是誰發送了該消息。
●發送方/接收方身份驗證：
發送方及接收方身份驗證保證了發送方和接收方分別就是他們所聲稱的人。也就是說，發送方能夠確認其意愿中的消息接收方的身份，而接收方能確認消息發送方的身份。請注意，發送方/接收方身份驗證無法保證是誰創建了該消息。
在下一部分中，我將概述一下實現以上兩項安全性要求的安全性技術。

消息身份驗證技術
正如上文所提到的，為滿足消息身份驗證的要求，用到了兩項通用技術：消息身份驗證代碼（message authentication code）和數字簽名。這里列出了它們的一些優缺點。

●消息身份驗證代碼（message authentication code，mac）：
ssl將mac附加到被傳輸的消息中，soap-dsig也能用來附加mac。由于mac的計算要比數字簽名快，因此它對于諸如ssl等數據傳輸量很大的傳輸層安全性來說是實用的。然而，由于mac是通過一個在發送方和接收方之間共享的密鑰來進行計算的，因此它只能保證被傳輸的消息不是由發送方就是由接收方創建的。換句話來說，從某個第三方的角度來說，您無法確定該消息究竟是由發送方創建的還是由接收方創建的。
●數字簽名：
soap-dsig的最初動機是在soap消息中附加數字簽名。特別地，soap-dsig定義了向soap消息中附加xml簽名的數據格式。由于數字簽名是建立在公用密鑰密碼術基礎上的，因此計算一個數字簽名所花的時間往往要比計算一個mac長得多。而由于發送方和接收方不再需要共享一個密鑰，因此您就能識別消息創建者的身份了，也就是說，它保證了簽名者就是創建者。
發送方/接收方身份驗證技術
發送方/接收方身份驗證有兩種廣泛使用的技術。請注意，http客戶機（服務器）可以是發送方也可以是接收方。

●密碼身份驗證：
這是個應用廣泛的機制，事實上amazon.com就使用了這種機制。典型的示例包括http基本身份驗證以及基于表單的身份驗證。它可以用于發送方身份驗證，在這種情況下http客戶機應該用來發送消息。http客戶既能通過發送其身份及密碼向http服務器證實自己的身份。由于密碼需要保密，因此通常用ssl來發送。
●ssl服務器/客戶機身份驗證：
這是一種基于http服務器和客戶機的公用密鑰證書對它們的身份進行雙向驗證的技術。ssl服務器身份驗證特別在因特網上得到了廣泛的應用，例如在amazon.com。另一方面，ssl客戶機身份驗證是可選的，目前也尚未應用在很多web站點上。然而，在某些公用密鑰證書被分發給了每個帳戶持有者的情況下，比如在在線交易中，ssl客戶機身份驗證就會被用來驗證帳戶持有者的身份。
就安全性來說，密碼身份驗證無法與ssl身份驗證進行直接的比較。但是由于ssl需要公用密鑰證書以及相應的專用密鑰（它們必須被簽發并得到管理），因此管理一個基于密碼身份驗證的系統要比管理一個基于ssl身份驗證的系統要容易一些。因為密鑰的撤銷及更新必須有一個證書撤銷列表（certificate revocation list，crl），所以對于發布與管理公用密鑰證書以及相應的專用密鑰的要求也會變得越來越高。

什么是不可抵賴性？
除了以上兩項安全性要求以外，不可抵賴性也是b2b應用中相當重要的一個要求。對不可抵賴性的需求因惡意發送方而引起。不可抵賴性保證了惡意發送方無法在事后抵賴其創建并發送特定消息的事實。這就意味著不可抵賴性保證了消息的發送方與消息的創建者為同一人。

例如，假設甲企業創建并發送了一個購買訂單給乙企業。當乙企業處理了訂單并開出了匯票以后，甲企業應該無法抵賴發送購買訂單這一事實。為了滿足不可抵賴性的要求，會同時需要消息身份驗證和發送方身份驗證。（接收方身份驗證與不可抵賴性無關）

使用數字簽名的消息身份驗證還不能滿足不可抵賴性的條件。因為僅僅有數字簽名并無法保證發送方就是他們自己所聲稱的人，消息的傳輸很容易遭受惡意第三方諸如再現攻擊等技術的襲擊。

例如，假設甲企業將一個帶有數字簽名的購買訂單發送到乙企業。另外，假設另有一個惡意的丙企業通過某種途徑獲取了一個訂單的副本。如果丙企業將該訂單重復發送給乙企業，那么乙企業就會將其當作另一個來自甲企業的訂單（來自丙企業的再現攻擊）。同樣，惡意的甲企業也可以抵賴第二份訂單，并聲稱這第二份訂單是惡意的丙企業再現攻擊的結果，盡管事實上它是甲企業發送的訂單。當然，用mac進行的消息身份驗證對不可抵賴性來說沒有用，因為正如上文所提到的那樣，沒有人能確定該消息究竟是由發送方創建的還是由接收方創建的。

與此類似的是，發送方身份驗證也無法滿足不可抵賴性的條件。由于無法保證消息在途中未被修改，惡意的發送方可以聲稱接收方收到的消息在途中已被修改，盡管該消息是由惡意的發送方所創建的。

總的來說，為了滿足不可抵賴性的要求，有必要在用數字簽名滿足消息身份驗證的要求的同時滿足發送方身份驗證的要求。

如何為實現不可抵賴性而使用soap-dsig和ssl
現在，我將從不可抵賴性的角度分析一下soap-dsig與ssl之間的關系。作為這一分析的環境，我將首先描述一種典型的情景，在這種情況下，一對請求/響應消息經過了soap-dsig的簽名，并使用http進行交換。下面是一個請求消息的示例。在清單1中，<soap-env:body>元素包含了代表購買ibm股票的訂單的應用數據。此外，使用soap-dsig，該<soap-env:body>元素就獲得了簽名，且生成的簽名（<soap-sec:signature>元素）就包括在soap的頭部分中。在該示例中，用來簽名消息的密鑰是通過<ds:keyname>元素（“michael”）來識別的，這樣也就保證了該soap消息是由用戶michael創建的。也就是說，soap-dsig被用來滿足消息身份驗證的要求。最后，經簽名的soap消息（<soap-env:envelope>元素）被放在一個http post請求的有效負載中，并被發送到一個在線交易服務器上。請注意，該http請求可以通過ssl發送。

請參閱清單1來了解典型的soap-dsig請求消息。
接收該訂單時，在線交易服務器即創建收據，并將它作為http響應發送給michael。以類似的方法，收據可以用soap-dsig來簽名。清單2是一個收據的示例。
請參閱清單2了解對soap消息的響應。
這些清單顯示了soap消息是如何獲得簽名并在http上進行交換的。請注意，這一點很重要，您可以通過在ssl上交換上述http消息來同時使用soap-dsig和ssl。表1總結了哪些安全性要求能通過soap-dsig和ssl來滿足。ssl提供了機密性和發送方/接收方身份驗證。ssl還有將mac添加到被傳輸的消息中去的功能。另一方面，soap-dsig不僅能在被傳輸的消息中加入mac，還能加入數字簽名，但這對于發送方/接收方身份驗證來說仍是不夠的，因為它還容易受到像再現攻擊那樣的攻擊。因此，soap-dsig和ssl為彼此的不足之處提供了互補的功能。

表1：用soap-dsig和ssl 1滿足的安全性要求
技術
得到滿足的安全性要求
ssl
機密性、發送方/接收方身份驗證以及用mac進行的消息身份驗證
soap-dsig
用mac和數字簽名實現的消息身份驗證
請記住，為了滿足不可抵賴性的要求，您至少需要同時保證使用了用數字簽名的消息身份驗證以及發送方身份驗證。因此，同時使用soap-dsig和ssl（帶有客戶機身份驗證）是實現不可抵賴性的第一步。確切地說，就是您用soap-dsig進行使用數字簽名的消息身份驗證，用ssl客戶機/服務器身份驗證進行發送方/接收方身份驗證。請注意，soap-dsig和ssl自身都不能保證不可抵賴性。

此外，有一個要點需要記住，必須始終保證soap消息的簽名者即是消息的發送者。為實現這一目的，我建議在soap-dsig和ssl中使用一個公共專用密鑰和相應的公用密鑰證書。確切地說，在上面的示例中，就是用來簽名http請求中訂單的專用密鑰應該與用于ssl客戶機身份驗證的密鑰相同。同樣地，用來在http響應中簽名收據的專用密鑰也應與用于ssl服務器身份驗證的密鑰相同。從確認簽名的角度來說，為了確認訂單的簽名（或收據的簽名），確認方可以在通過ssl進行身份驗證時使用ssl客戶機的公用密鑰證書（或者ssl服務器的公用密鑰證書）。在這種情況下，上述示例消息中的<ds:keyinfo>元素就能省略。

努力實現更多的安全b2b應用
我們需要問一問，在b2b應用中為實現不可抵賴性同時使用soap-dsig和ssl條件是否充分。遺憾的是，從嚴格的安全角度而言，答案是否定的。現在我會考慮惡意接收方的攻擊，并詳細描述如何保護應用免受這樣的攻擊。應用的設計和開發人員必須負責提供這種保護，因為soap-dsig未對這種攻擊作出任何定義。

正如上文所提到的，來自某個惡意第三方的再現攻擊是最容易遭受到的攻擊。而ssl能保護應用免遭再現攻擊。由于ssl為實現保密性而對被傳輸的消息作了加密，因此沒有一個惡意的第三方能竊取這些消息。即使有惡意第三方能夠竊取消息，除非他能攻破ssl客戶機/服務器身份驗證，否則也無法將消息向其它方重發。所以看起來同時使用soap-dsig和ssl對于實現不可抵賴性來說已經足夠了，那么我現在就提供兩個來自惡意接收方（而非第三方）的攻擊。

請設想一下，一個惡意的接收方聲稱兩次收到了來自發送方的消息，盡管發送方只發送過一次。由于數字簽名方案無法保證消息被發送方簽名并發送的次數，那么也就沒有人能確定惡意接收方聲明的真實性。因此，惡意的接收方就可能得逞。反過來說，惡意的發送方也可能聲稱他僅發送過一次消息，即使事實上它發送了不止一次。為了讓應用能避免此類攻擊或模糊性，應用的設計者或開發者應在待簽名的應用數據中加入一個nonce（現時標志）。nonce是一個由發送方（簽名者）新生成的無重復字符串，這樣目標接收方就能檢查其唯一性了。nonce通常能實現為計數器（一個序列數）或者時間郵戳。通過添加nonce，就可以對多次發送的相同消息加以區分了。

請再設想一下，惡意接收方收到了經簽名的soap消息，并將其轉發給另一個惡意方。如果該惡意方聲稱從發送方收到了經簽名的消息的話，會發生什么情況呢？由于數字簽名方案無法保證誰是經簽名的消息的目標接收方，那么也就沒有人能確定惡意方聲明的真實性。因此，惡意方也就可能得逞。為了讓應用能避免此類攻擊或模糊點，應用的設計者或開發者們應該在待簽名的應用數據中加入目標接收方的身份。該身份可以用接收方的名字、接收方的公用密鑰證書或以其它方式來表示。

正如上面所描述的那樣，對于針對抵賴的安全性來說，在待簽名的應用數據中同時加入nonce和目標接收方的身份是非常重要的。清單3是一個上述訂單消息的擴展示例。請注意，nonce（20010711-0001287634）和接收方的身份是被添加到soap正文部分的訂單信息中的。一接收到經簽名的訂單，在線交易服務器就需要確認nonce的唯一性，并檢查其身份是否被指定為目標接收方。
請參閱清單3再次查看訂單消息。
總結
本文解釋了這樣一個事實：盡管soap-dsig和ssl不提供相同的功能，但它們能為彼此的不足之處提供互補的功能。在不久的將來，我希望許多企業都能在因特網上通過http用soap交換xml文檔。因此，同時使用ssl和soap-dsig是保護被傳輸的soap消息的安全以實現不可抵賴性的最有前途的方法。

參考資料

soap安全性擴展：數字簽名（soap-dsig）作為w3c附注被發表。
soap-dsig在websphere application server version 4.0中得到了實現。
ssl在許多電子商務站點得到了應用，包括amazon.com。
soap（簡單對象訪問協議，simple object access protocl）是交換xml文檔的標準消息層，也是web服務的主要構件之一。
與soap緊密相關的技術包括uddi（通用描述、發現和集成，universal description，discovery，and integration）以及wsdl（web服務描述語言，web service description language）。
soap-dsig定義了一種向soap消息中附加xml簽名的數據格式。
近來，w3c為xml加密的標準化創建了一個xml加密工作組，并已發布了一個工作草案。
感興趣的讀者可以在ibm alphaworks的web service toolkit中找到一個soap加密的原型實現。

關于作者
羽田知史是ibm東京研究實驗室的研究人員，從事消息傳遞的研究工作。他是soapsecurity extensions：digital signatures note（已被萬維網聯盟接受作為soap1.1的補遺）的撰稿人之一。可以通過[email protected]與他聯系。

上一篇：完整的網站間共享數據的WebService

下一篇：簡單對象訪問協議：SOAP的應用