SOAP 安全性擴展：數字簽名

數字簽名使初始用戶和軟件能夠可靠地發送信息。可惜的是，簡單對象訪問協議（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）。 現時標誌是一個由發送方（簽名者）新生成的無重複字符串，這樣目標接收方就能檢查其唯一性了。現時標誌通常能實現爲計數器（一個序列數）或者時間戳。通過添加現時標誌，就可以對多次發送的相同消息加以區分了。

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

正如上面所描述的那樣，對於針對抵賴的安全性來說，在待簽名的應用數據中同時加入現時標誌和目標接收方的身份是非常重要的。清單 3是一個上述訂單消息的擴展示例。請注意，現時標誌（20010711-0001287634）和接收方的身份是被添加到SOAP 正文部分的訂單信息中的。一接收到經簽名的訂單，在線交易服務器就需要確認現時標誌的唯一性，並檢查其身份是否被指定爲目標接收方。

請參閱清單 3再次查看訂單消息。

回頁首

總結

本文解釋了這樣一個事實：儘管 SOAP-DSIG 和 SSL 不提供相同的功能，但它們能爲彼此的不足之處提供互補的功能。在不久的將來，我希望許多企業都能在因特網上通過 HTTP 用 SOAP 交換 XML 文檔。因此，同時使用 SSL 和 SOAP-DSIG 是保護被傳輸的 SOAP 消息的安全以實現不可抵賴性的最有前途的方法。

回頁首

參考資料