以下是网学网为您推荐的ASP.net-SOAP安全性扩展：数字签名(2)，希望本篇文章对您学习有所帮助。
什么是不可抵赖性？ 除了以上两项安全性要求以外，不可抵赖性也是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的唯一性，并检查其身份是否被指定为目标接收方。
