安全|安全性 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的补遗）的撰稿人之一。可以通过satoshihjp.ibm.com与他联系。
