JavaSE6基于JSR105的XML签名之理论篇

　　XML签名技术，这项在W3C建议中指定的XML签名语法及处理方法（XML-Signature Syntax and Processing），成为解决SOA开发中消息级安全性方案的基础。被普遍接受的OASIS标准WS-安全性（WS-Security）正是构建在这一技术(以及XML加密)基础之上。JSR-105规范又对在Java平台应用XML签名技术进一步标准化，并且将成为即将到来的Java SE 6发行版本的一个组成部分。本系列文章（《理论篇》与《实践篇》）将基于Java SE 6的试发行版本对JSR-105作入门性介绍；在第二篇（即《实践篇》）中，我们将讨论一个具体的应用案例。

　　一、 数据一致性和消息认证

　　XML数字签名的主要目的是确保数据一致性。RFC 2828，因特网安全词汇表（Internet Security Glossary），把"一致性"定义为"在一种未授权的或偶然方式下确保数据没有改变、破坏或丢失的属性"。在这种意义上，与一个校验和一起存储或传递数据就可以实现数据的一致性。严格地说，XML签名能够实现比这种一致性更为丰富的内涵-它能够为在RFC 2828中所谓的消息认证提供支持。

　　二、 签名元素结构

　　实质上，XML签名使用XML语义描述一个数字签名。下列层次捕获顶级的元素和属性以及它们之间的结构化关系。

 

＜Signature ID?＞ ＜CanonicalizationMethod/＞ (＜Reference URI? ＞ ＜DigestMethod＞ ＜/Reference＞)+ ＜SignatureValue＞ (＜Object ID?＞)*

　　在此，Reference担当连接要签名的数据对象与一个XML签名之间的桥梁作用(通过URI属性)。一个应用程序选择这里的digest方法来计算一个数据对象的digest值，并且把这二者作为相应的Reference元素的一部分。

　　对于digest方法，W3C建议实现对SHA-1的支持。而且，这种实现通常还支持其它交互式单向哈希函数-例如SHA-256，SHA-512和RIPEMD 160。

　　实际上，我们很少直接从数据对象本身计算一个digest值。通常，一个应用程序需要首先对数据对象应用一些转换。例如，我们可以使用XPath来从一个XML文档中仅提取关键元素以实现签名；或者，我们也可能在使用XSLT经过一些转换后对一个XML文档进行签名。这样的转换是在Transforms元素中指定的-其中包含一个有关实现转换算法及其它相关信息的Transforms的有序列，当然也包括在相应的Reference元素之内。

　　SignedInfo是数字签名算法实际应用的元素。该算法通过SignatureMethod元素捕获；W3C建议中要求实现对DSA_SHA1，RSA_SHA1和HMAC_SHA1(由JSR-105所注释)的支持。前两个是基于公钥的，而HMAC是一种对称密钥密码学算法。|||

　　三、 签名过程

　　在XML签名中，签名过程包括两个步骤。首先，它计算每一步的digest值以及确定要签名的每一个数据对象，并且把该值包括为相应的Reference元素的一部分。在第二步中，它使用一个密码学密钥在SignedInfo元素上应用一种数字签名算法来生成签名值，并且把它包括为结果Reference元素的一部分。

　　第二步的实际机制往往随着数字签名算法的不同而不同，或更通常的是，因算法类别的不同而不同。

　　实践中，一个数字签名算法从未直接操作给定SignedInfo的XML格式，而是操作由SignedInfo元素的物理描述转换而来的流数据(八位)。为了允许SignedInfo元素的逻辑上的等价表示，这种到八位的流的转换基于SignedInfo元素的规范形式。存在两个W3C规范，Canonical XML和Exclusive XML Canonicalization，定义了XML的规范化。获得一个给定XML文档(或元素)的规范形式的方法是很复杂的。但是，一般地，所有的XML签名应用程序需要实现的就是，基于它们的上下文环境从四种已定义规范化方法中进行现成的选择-EXCLUSIVE，EXCLUSIVE_WITH_COMMENTS，INCLUSIVE和INCLUSIVE_WITH_COMMENTS(列举于JSR-105注释中)。注意，SignedInfo中的CanonicalizationMethod元素负责捕获这一选择。

　　四、 XML签名中的核心校验

　　XML签名中确保数据一致性和消息认证的机制基于核心校验过程。它包括两部分：引用校验和签名校验。

　　引用校验验证在一个XML签名中的每一个Reference元素都是有效的。在此，单词"有效"的含义是：在对相应的数据对象(一般情况下通过URI属性加以引用)应用相同的转换之后，使用在Reference元素中指定的digest方法，我们应该能够获得一个已经记录在Reference元素中的相同的digest值。这个digest值就是我们以前提及的校验和。这种校验对XML签名中的数据一致性提供了支持。

　　签名校验的实际机制依赖于在SignedInfo元素中引用的特定的签名算法(更精确地说是，签名算法的类别)。它们的共同要求是，校验应用程序必须拥有相应的密码学密钥：使用HMAC_SHA1(或使用其它哈希函数的HMAC)加密的密钥，或使用RSA_SHA1和DSA_SHA1(或使用其它哈希函数的RSA和DSA)加密的公共密钥。

　　References是SignedInfo元素的一部分，这是确保实现在XML签名中的消息认证(这是一种比数据一致性更为安全的属性)的结构机制。

　　五、 三种类型的XML签名

　　W3C建议允许签名任何数字数据，并且这包括一个XML文档，一个文档的XML元素以及一个XML元素的内容（作为特定的情形）。

　　当我们谈及一个XML签名时，我们实际上指的是一个XML文档，它把Signature(在命名空间http://www.w3.org/2000/09/XMLdsig#中定义)包含为一个元素(这可以是根元素)。但是，该文档可能还包含其它元素，这其中最为重要的当然要数要签名的原始数据对象。

　　根据那些数据对象在一个XML Signature文档中与Signature元素的关联方式，我们考虑三种不同类型的XML签名。

　　· Enveloping-数据对象包含在与Signature元素相同的XML文档中，并且被进一步包含在Signature元素(例如作为Object的子元素)中。

　　· Enveloped-数据对象包含在与Signature元素相同的XML文档中，并且实际上把Signature包括为一个子元素。

　　· Detached-Signature引用外部网络资源，或数据对象包含在与Signature元素相同的XML文档中，但是作为一个兄弟元素或它的兄弟元素的一个子元素。

　　【注意】一些关于XML签名的文章中让读者感觉到这是一个独占分类的XML签名；另一些则含蓄地建议，在enveloping或enveloped签名中，实际上在包含该签名的XML文档中还存在一个Envelop元素；而且，还有一些文章则暗示：对一个enveloping签名来说，Signature是XML文档的根元素。其实，所有这些都不对。

　　六、 Object和KeyInfo

　　在我们继续介绍JSR-105之前，我们需要简短地讨论两个可选的签名子元素-Object和KeyInfo。

　　W3C建议中的Object元素是一个占位符，用于在一个XML签名应用程序承载实现若干不同目的之信息。例如，一种可能的应用是，一个Object包含一个enveloping签名中被签名的数据对象。这正是我们的示例所适用的情形。

　　XML签名的KeyInfo元素可以用于签名应用程序实现与加密(私有)密钥相关信息的通讯，以便校验程序可以获得相关的(公共)密钥。在接下来的【实践篇】中，我们的示例将包括若干场所来说明KeyInfo的使用情形。