Java SE 6基于JSR105的XML签名(一)

Java SE 6基于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?>
 <SignedInfo>
  <CanonicalizationMethod/>
   <SignatureMethod/>
   (<Reference URI? >
    (<Transforms>)?
    <DigestMethod>
    <DigestValue>
    </Reference>)+
   </SignedInfo>
 <SignatureValue>
 (<KeyInfo>)?
 (<Object ID?>)*
</Signature>

  在这个示例中,?表示零个或一个出现,+表示一个或多个出现,而*表示零或多个出现。在此,所有的元素和属性被定义于命名空间http://www.w3.org/2000/09/XMLdsig#。

  在此,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的使用情形。



凡是有该标志的文章,都是该blog博主Caoer(草儿)原创,凡是索引、收藏
、转载请注明来处和原文作者。非常感谢。

你可能感兴趣的:(Java SE 6基于JSR105的XML签名(一))