XML 签名: 幕后

哪些人可以通过认证得到信任？

文档选项

将此页作为电子邮件发送

对此页的评价

帮助我们改进这些内容

级别: 初级

Larry Loeb, 作家, 安全电子交易

2001 年 12 月 01 日

XML 数字签名标准（XML Digital SignatureStandard）确立了 XML在非安全网络（如因特网）上有效的自签方法。这项工作不需要一个已建立的PKI，而可能需要使用可信的 XML 服务器进行认证。因此，每家企业不得不估计外购这一日益关键的商业功能的潜在安全性风险。

 

XML 签名有一个 W3C 候选方案，它看上去非常象最终方案，但这项工作仍处于进展中，并在本文写作时还未正式提升到“草稿标准（Draft Standard）”阶段（请参阅 参考资料 ）。 “因特网工程工作组（Internet Engineering Task Force (IETF)）”称它为 RFC 3075。据这个候选方案的作者列表上的作者（包括 W3、MIT 和 Microsoft 的人员）判断，因特网行业显然正在严肃地考虑这一问题。

回页首

 

依照 RFC，设计的 XML 签名带有多个目标，可提供“对任何数据类型的完整性、消息认证、和／或签名者认证服务， 无论是在包括该签名的 XML 内部还是在别处。 ”（我加粗了后半句话是因为如果采用并实现候选方案，它对于因特网的工作方式将有重大意义。稍后将详细说明。）这些目标自然雄心勃勃，并且如果放在上下文中考虑，涉及面也很广泛。这些签名及其相关过程有一个终极目标，通过使用 XML，为 Web 提供基于服务器的缺省基本安全性服务。

然而，作者们只理解其工作的一部分。候选方案包含这样一段：“XML 签名……没有规范地指定如何将密钥与个人或社会团体相关联，也没有指定正在引用并签名的数据的含意。 因此，虽然这个规范是安全 XML 应用程序的重要组成部分，但它本身不足以处理所有应用程序安全性／信任事宜，特别在有关将已签名的 XML（或其它数据格式）用作人与人之间通信和协议的基础方面。这种应用程序必须指定附加密钥、算法、处理和再现需要。”简而言之，作者们正在告诫人们，不要将这项工作视作技术上的万能药；必须在其它安全性措施中使用它。这一点很明智，但回避了 XML 幕后是什么这个实质问题。

回页首

 

这里还有一个隐含的假设，作一些检验就会发现这相当明显。XML 既基于 Web 又基于服务器。与 Java 的“无需带宽，装入 servlet”方法相反，它是一种瘦客户机方法。因此，XML 签名将使用 Web（通过 XML 中的 URL）来找出编码或解码事物的方法。 可以从语法上确切地指定它如何使用 Web（随后的技术讨论中将进行演示）， 但这种讨论忽略了要使用什么 URL 的实质问题。即，如果签名需要因特网资源来完成其操作，那么谁将提供这些资源呢？如果这种签名成为消息和事务认证所广泛使用的“信号灯”，则 XML 代码中所指向的任何一个 URL 都可以成为认证服务的实际标准。

但不仅如此。真正的认证服务的使用最有可能出现在 Web 购物中；而不是出现在象安全电子邮件这类应用中。贸易商想要知道他从客户那里接收到的订单是否有效，所以将坚持某种形式的可接受认证。这种问题首先由使用安全网络进行操作的“电子数据交换（Electronic Data Interchange (EDI)）”系统解决。在不可靠的因特网上，先前解决过的相同的操作问题仍然存在。XML 签名过程打算以清扫方式处理这一问题，但这种清扫是问题的一部分。这种少有人知的候选方案将方法种子引入其中，使一些公司垄断因特网认证服务。

让我假定一种情况。设想某一商业现货供应（Commercial Off The Shelf (COTS)）软件公司决定成为认证服务，所有事情必须先通过这个认证服务才能完成。再进一步假定这家 COTS 的专用操作系统可以在大多数研究中的已部署系统上找到。然后，COTS 供应商生产出其 OS 的 Xtra 专用版，它包含了将 XML 签名（和 仅 XML 签名）用于安全性的客户机。 所有 XML 代码都指向该供应商的服务器以提供信息，这有点象非公用的 PKI 基础结构。 这种客户机广泛用于认证，因为这种 OS 被广泛使用，所以很容易将它设置为缺省值。另外，上述的制造商将它作为缺省安全性机制嵌入其流行的“免费”浏览器。

再加些点缀，假设每次这种客户机将供应商的服务器用于认证时，供应商就开始向某人（可能是贸易商，也可能间接地是客户）收取费用。 瞧!垄断和收入同流合污了。

现在，在诚心诚意地使用了这些安全性服务后，贸易商可能会发现这些服务实际上并没有解决根本问题 ― 即信用卡公司的“退费（chargebacks）”。这些退费问题 ― 人们承认他们与贸易商有协议或合同，但他们声称贸易商没有按承诺执行部分或所有方面（象没有交货、订单被取消或其它一些原因） ― 是信用卡发行者商业模型的一部分，并且超出了 XML 签名规范的作用范围。确实，在美国， Fair Credit Billing Act（15 U.S.C. 1666-1666j）保护客户与发行银行就帐单的正确性（包括商品／服务的数量、总金额、时间和交付／接收）进行争论的权利。不能通过合同否认这些权利。

我将总结上一部分。

因此，即使有合适的象 XML 签名这样的方案正在使用，它们可能也不会解决它们应该解决的现实世界的问题。假定可能有贪婪的公司不负责任地胡乱建立因特网垄断业务，那么使用这种技术可以结束这种令人不满的局面。这并不意味着开发者在相当长的时间里一定要使用这种模式以提供兼容性；但也不要认为它只是一个有魔力的咒语。除最大型公司以外的那些公司可能开发独特的认证服务，使用它们可能需要对 XML 代码稍做改写。 真正的问题可能是对制造商提供的 XML 签名代码的绝对接受。所以，让我们看一下技术规范，同时也要注意理解随着服务的发展可能需要哪些更改。

回页首

 

注意，在随后的示例中， 可以用您想到的一些专利软件供应商的 URL 代替 W3C 地址。这样看上去更现实。下面的讨论很大程度上借鉴了候选规范，因为它们与供应商无关。

XML 签名的第一个有用的特性是，它可应用于任何类型的数字内容（有时称为数据对象），包括 XML。 一个 XML 签名可应用于一个或多个资源的内容。对在签名的同一个 XML 文档内的数据执行封装式签名，所以对于签名元素本身以外的数据还有一个分离签名。更具体地讲， 当前的 XML 签名规范定义一种 XML 签名元素类型和一个 XML 签名应用程序；每一个的一致性要求在文档中分别用模式定义和散文方式指定。

回页首

 

看一下签名元素。首先编摘数据对象摘要（“摘要”是变长数据对象的定长表示，并且使用一个类似 SHA-1 的算法创建），产生的值（和其它信息）被放在一个元素中。然后，对该元素进行编摘并使用密码签名。签名元素的结构如下（其中，“?”表示 0 或 1 次出现，“+”表示 1 次或多次出现，“*”表示 0 或多次出现）：

清单 1

 <Signature>      <SignedInfo>       (CanonicalizationMethod)       (SignatureMethod)       (<Reference (URI=)? >         (Transforms)?         (DigestMethod)         (DigestValue)       </Reference>)+     </SignedInfo>     (SignatureValue)     (KeyInfo)?    (Object)*   </Signature>

回页首

 

考虑一个带一些真实数据的简单示例。 以下是 XML 规范中 HTML4 内容的分离签名。先给出 XML，随后提供每个分别列出的代码行的注释。在讨论中还假设您已经对专用／公用密钥密码术方法有一些经验并且熟悉概念。如果不是这样，可以仔细阅读 developerWorks 上出色的介绍性文章。（请参阅 参考资料。）

清单 2

 [s01] <Signature Id="MyFirstSignature" xmlns=            "http://www.w3.org/2000/09/xmldsig#">    [s02]   <SignedInfo>    [s03]   <CanonicalizationMethod Algorithm=            "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>    [s04]   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>    [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">    [s06]     <Transforms>    [s07]       <Transform Algorithm=            "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>    [s08]     </Transforms>    [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>    [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>    [s11]   </Reference>    [s12]   </SignedInfo>    [s13]   <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>    [s14]   <KeyInfo>    [s15a]    <KeyValue>   [s15b]      <DSAKeyValue>    [s15c]        <p>...</p><Q>...</Q><G>...</G><Y>...</Y>    [s15d]      </DSAKeyValue>    [s15e]    </KeyValue>    [s16]   </KeyInfo>    [s17] </Signature>

[s02-12] 必需的 SignedInfo 元素是实际签名的信息。SignedInfo 的核心验证由两个必要过程组成：对 SignedInfo 的签名验证和 SignedInfo 内部每个 Reference 摘要的验证。计算 SignatureValue 所使用的算法也包括在已签名的信息中， 而 SignatureValue 元素在 SignedInfo 之外。

[s03] CanonicalizationMethod 标识了一种算法，这种算法被用来规范化 SignedInfo 元素，然后该元素作为签名操作的一部分被编摘。规范化（Canonicalization）是一种方法，过程使用该方法处理可包含在同一数据元素内部的不同数据流，例如，可以包含两种不同方法来表示文本。规范化是解释原始数据以使空格显示为空格而不显示为 ASCII 码的方法。

[s04] SignatureMethod 是用于将已规范化的 SignedInfo 转换成 SignatureValue 的算法。这是编摘算法、密钥从属算法和可能的其它算法的组合。为算法名签名以抵抗攻击，该攻击是基于替换成效率更低的算法。要提高应用程序的互操作性，候选方案指定一组需要实现的签名算法，虽然它们的使用任凭签名创建者处理。

[s05-11] 每个 Reference 元素都包括摘要方法和对已标识数据对象计算得出的摘要值。它还可能包括产生对摘要操作的输入的转换。数据对象的签名是通过计算其摘要值并对该值的签名进行的。稍后通过引用和签名验证来检查该签名，这些验证将重新创建摘要值并确保它与该数据对象中的内容匹配。

[s05] Reference 的这个可选 URI 属性标识要签名的数据对象。 在一个 Signature 中，至多可以对一个 Reference 省略该属性。（为了确保明确地匹配引用和对象， 要强加这个限制。）

[s05-08] 该标识与 transforms 一起是签名者提供的描述，其内容有关它们如何获得已编摘形式的已签名数据对象（即，已编摘的内容）。验证者还可能以另一种方法获得已编摘的内容，只要摘要验证这种方法。

[s06-08] Transforms 是一种可选的处理步骤排序列表，在编摘资源内容之前，对它应用这些步骤。这是解密所需遵循的轨迹。Transforms 可以包括如规范化、编码／解码（包括压缩／扩张）、XSLT 和 XPath 等操作。XPath 转换有些复杂，因为它们允许签名者派生出省略一部分源文档的 XML 文档，并将 XML 树限制为它原来的那样。因此，未包含部分可以更改，而不影响签名有效性。 如果不存在 Transforms 元素，则直接编摘资源内容。应该记住，即使在候选方案中指定了基本缺省设置，还是允许用户指定的转换。

[s09-10] DigestMethod 是在应用 Transforms（如果已经指定它）之后对数据应用以产生 DigestValue 的算法。DigestValue 的签名是将资源内容与签名者密钥绑定的机制。

[s14-16] KeyInfo 表示用于验证签名的密钥。标识机制可以包括证书、密钥名称和密钥协议算法。KeyInfo 是可选的有两个原因。首先，签名者可能不希望向所有文档处理方披露任何密钥信息。为什么总要告诉人家？其次，该信息在应用程序上下文中可能是已知的，并且不需要明确表示。由于 KeyInfo 在 SignedInfo 之外，所以如果签名者希望将密钥信息与签名绑定，那么 Reference 可以容易地将 KeyInfo 作为签名的一部分标识并将其包括在内。

回页首

 

XML 是 作者 Donald Knuth 的格言“所有计算机问题都可以通过其它途径解决。”的代码化表示。整个 XML 语法被设计成利用基于 Web 的重定向服务。虽然可以接受向可信伙伴外包关键商业服务，但在缺省情况下，最好不要将外包作为未来几年中电子商务的重要组成部分。

另外，还必须强调对于安全性分析而言，理解 XML 所使用的上下文（实际正在签名的数据）与代码本身的实际签名同样重要。任何转向其他 Web 服务商业模型的无意或无知缺省使用，都可能因其使一个组织开放和不安全而终止 - 更不用说潜在的昂贵开销了。 知道您在 Web 上究竟去向何方（以及是谁让您去那里！）目前来说似乎是一门很理智的操作课程。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请阅读 W3C 建议书， "XML Schema Part 1: Structures" （由 D. Beech、M. Maloney、N. Mendelsohn 和 H. Thompson 于 2001 年 5 月合著）， 它指定了 XML 模式（XML Schema）定义语言如何提供用于描述结构和约束 XML 1.0 文档内容的设施。
  
  
• "XML Schema Part 2: Datatypes" （由 P. Biron, A. Malhotra. 于 2001 年 5 月著）是 XML 模式语言规范的第二部分。 它定义了用于在 XML 模式中定义数据类型的设施以及其它 XML 规范。
  
  
• RFC 2807 列出了 XML 数字签名（XML Digital Signature）规范的设计原理、作用范围和要求。它包括涉及签名语法、数据模型、格式、密码处理方面的要求，以及外部要求和协调。
  
  
• W3C 工作草案（W3C Working Draft） "XML-Signature Requirements" （J. Reagle. 于 2000 年 4 月著）列出了 XML 数字签名规范的设计原理、作用范围和要求。
  
  
• 有关该标准的公众意见应该发送给 [e-mail] 上相应的邮件列表。
  
  
• 有关 XML 加密和 XML 签名的简介，请查看 developerWorks 上由 Murdoch Mactaggart 所著的 Enabling XML security。
  
  
• 有关“公用密钥基础结构（Public Key Infrastructure）”的基础知识，请阅读 Joe Rudich 的 developerWorks 文章 PKI: A primer
  
  
• 当然，您可以在 developerWorks“安全性”主题 中找到许多安全性文章，而且对于使用该语言的开发者来说，我们的 XML 专区始终是一个极好的资源。
  
  
• The XML Security Suite ，可在 alphaWorks 上获得， 它为 XML 文档提供了如数字签名、加密和访问控制等安全性特征。
  
  
• IBM security services 可以帮助您确定您的风险有哪些，然后设计一个安全性程序来处理它们。
  
  
• RFC 3075， XML-Signature Syntax and Processing是用于候选方案的 IETF 规范。
  

回页首

关于作者

Larry Loeb 为上个世纪主要的计算机杂志“dead tree”写了很多文章，另外，他还是 BYTE 杂志的顾问编辑和发起 WebWeek 的资深编辑。作为 BIX 上的 Macintosh Exchange 和 VARBusiness Exchange 的编辑，他从 uucp 用“bang”寻址的时代（相对 !decvax 而存在的世界）就开始上网了。他还写了一本关于安全性电子交易因特网协议的书。他的第一台 Mac 有 128K 内存。他第一台 1130 有 4K，和他的第一台 1401 一样。可以通过 [e-mail] 给他发邮件

精练的总结要仔细考虑的示例签名元素烦人的部分在规范中没有涉及的内容概述简介