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 Psrotocl）是交换XML 文档的标
准消息层，也是Web 服务的主要构件之一。
. 与SOAP 紧密相关的技术包括UDDI（通用描述、发现和集成，Universal Description，
Discovery，and Integration）以及WSDL（Web 服务描述语言，Web Service Description
Language）。
. SOAP-DSIG 定义了一种向SOAP 消息中附加XML 签名的数据格式。
签名的句法和处理规则。本文讨论了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 Psrotocl）是交换XML 文档的标
准消息层，也是Web 服务的主要构件之一。
. 与SOAP 紧密相关的技术包括UDDI（通用描述、发现和集成，Universal Description，
Discovery，and Integration）以及WSDL（Web 服务描述语言，Web Service Description
Language）。
. SOAP-DSIG 定义了一种向SOAP 消息中附加XML 签名的数据格式。