内容


SOAP 安全性扩展:数字签名

SOAP-DSIG 和 SSL

Comments

数字签名使初始用户和软件能够可靠地发送信息。可惜的是,简单对象访问协议(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 消息的安全以实现不可抵赖性的最有前途的方法。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=21409
ArticleTitle=SOAP 安全性扩展:数字签名
publish-date=08012001