作为一种Internet上的信息交换格式，XML的普及性仍然在增长——而与信息交换有关的一个重要问题是安全。没有保证信息的安全性和可靠性的机制，任何信息交换格式都是不完整的。这是Manish Verma的系列文章中的第一篇，讨论了在保护XML中发挥着至关重要作用的技术。本文主要阐述了基本的保密技术、定义了XML上下文中的安全性、XML规范化以及PKI基础设施，并提供了逐步生成密钥的指南。第2部分将讨论XML加密和XML签名。这一组文章将帮助您实际掌握用于保护XML消息的基本技术。

　　对于本文的目的而言， 安全性一词涉及到，从一个客户机经过数量不定的中间机器到达最终目的地，在这一往复过程中对XML的保护。请注意，一个XML消息的不同部分可能有不同的最终目的地。保护有效载荷的不同部分，从而使预期的接收群体能够阅读它们，而同时又对其他所有中间机器保持加密状态。

　　保护XML的基本粒度单位是元素。加密的粒度还可以进一步细化，规定加密的类型是 元素还是内容。元素加密对整个元素（包括属性）加密，并使用 EncryptedData元素代替它。内容加密基本上意味着只加密元素的子节点，并用EncryptedData元素代替。

　　安全意味着什么？

　　安全这个术语包含了以下几个方面：

　　·机密性保证只有预期的接收者阅读XML中预期的部分。要保证机密性，重要的是加密XML——XML Encryption是加密XML的标准。
　　·完整性保证XML在从源到最终目的地的传输过程中不会被改变。XML Signature标准允许发送者在要保证完整性的内容后面附加数字签名。
　　·真实性是保证XML确实是由声明发送它的人发送的。随内容一起发送的XML签名可以帮助确保发送者的身份。有效载荷的接收者可以使用发送者的公开密钥验证数字签名。如果数字签名是有效的，身份就得到了确认，否则就不能确认。
　　·抗否认性用于保证发送者不能否认发送了XML。由发送者的私钥生成的附在XML上的XML签名保证了发送者的不可驳性。

　　XML规范化是什么？

　　您可以创建看起来不同但拥有相同数据或者相同语义值的XML文档。区别可能在于实体的结构、属性的排列、字符的编码或者不起眼的空白。因为存在这种物理差异，任何XML文档都不能进行字节级的等价测试。问题就在于此：数字签名依赖于字节级的等价测试，但是可能有两个逻辑上相同但包含不同字节序列的XML文档。

　　因此，如果您以数字方式签署了一些XML标记，接下来改变了一些属性的顺序——或者增加或去掉一些不重要的空白，但没有从逻辑上改变XML，然后再验证数字签名的时候的就会失败。要保证每次验证逻辑等价的XML——不管物理表示如何——的数字签名都能成功，您必须保证XML使用公认的标准格式。这个标准称为规范化，它是序列化XML的标准机制。规范化有两种形式：

　　·常规规范化：当序列化XML的一部分时，祖先元素的上下文和所有的名称空间声明以及 target=_blank>XML加密中：

　　·消息的发送方使用接受方的公钥加密消息并发送。
　　·消息的接收方使用所拥有的相应的私钥解密消息。除了拥有对应私钥的人，其他任何人都不能解密消息，从而保证了它的机密性。

　　在XML数字签名中:

　　·发送方使用自己的私钥数字签署要发送的消息。
　　·接收方使用发送方的对应公钥验证数字签名。

　　生成公钥-私钥对

　　这一部分介绍生成公钥-私钥对的过程，这是加密和数字签名的基础。

　　步骤1. 基本设置

　　您需要为Java Cryptographic Extension(JCE)安装并注册一个密码提供程序。JCE提供程序必须支持生成公钥和私钥的RSA算法。这是因为与本文配套的示例代码所使用的XML加密实现，只支持公私密钥对的RSA1_5算法类型。

　　在JDK 1.4中，SunJCE提供程序是预先配置好的。这个SunJCE提供程序不适合生成非对称密钥，因为它没有包含RSA算法类型的实现。附带的示例代码使用了开放源代码的JCE提供程序ISNetworks，它包括了对RSA的支持。

　　首先，要保证JCE提供程序能够使用。可以通过把提供程序的.jar文件放到CLASSPATH中实现。

　　其次，配置JCE提供程序。编辑JAVA_HOMElibsecurity目录下的java.security文件，增加下面一行：

　　security.provider.n=com.isnetworks.provider.jce.ISNetworksProvider
Java Runtime Environment(JRE)选择JCE提供程序来载入JVM。JCE提供程序的选择是基于优先顺序的。用n表示替优先顺序，JRE通过它来挑选 — 数字越低，优先权越高。

　　提供程序的注册也可以通过代码动态完成。请参阅Dynamically registering a JCE provider。

　　如果安装了安全管理器，对于使用JCE的applet或应用程序必须授权许可。必须为每种提供程序指定许可权限。权限可以在策略文件中指定。

　　您可以通过在”ext”目录下作为一组扩展安装提供程序的.jar文件，更清楚地控制这种许可授权事务。

　　步骤2. 生成密钥对

　　清单1中的代码段说明了如何生成密钥对。

　　清单1. 生成密钥对

　　KeyPairGenerator pairgen = null;
try {
pairgen = KeyPairGenerator.getInstance(“RSA”, “ISNetworks”);
} catch (NoSuchAlgorithmException e) {
System.out.println(“There is no such algorithm for generating the keys”);
e.printStackTrace();
} catch (NoSuchProviderException e) {
System.out.println(“Not a valid Provider”);
e.printStackTrace();
}
SecureRandom random = new SecureRandom();
int KEYSIZE = 1024;
pairgen.initialize(KEYSIZE, random);
KeyPair keyPair = pairgen.generateKeyPair();
 
　　首先，取得一个实现了RSA算法的KeyPairGenerator对象。

　　为KeyPairGenerator对象提供密钥大小和一个随机数，然后调用generateKeyPair方法得到公私密钥对。一定要掌握好这些密钥——您将大量使用它们加密和数字签名。

　　生成共享密钥

　　您还需要一个共享密钥。在 “算法类型” 一节已经提到，共享密钥用于加密XML内容，而公私密钥对用于加密共享密钥，内嵌到内容中。
　
　　为了有较好的加密响应时间，而又不采用其他渠道发送共享密钥，这种戏法是必要的。使用共享密钥加密XML内容可以保证较好的加密响应时间，而密钥对用于加密共享密钥本身。

　　使用共享密钥加密非常快。共享密钥用于加密大量数据，即XML的真正内容。使用公司密钥加密很慢，而且直接与加密的数据大小成正比。因为共享密钥通常比内容小，公钥只用于加密共享密钥，而把共享密钥本身嵌到内容中。

　　本文所附示例代码中的XML加密实现对内容加密只能识别Triple-DES算法。清单2说明了如何使用Triple-DES生成共享密钥。

　　清单2. 生成共享密钥

Key ky = null;
KeyGenerator kg = null;
try {
kg = KeyGenerator.getInstance(“DESede”, “ISNetworks”);
} catch (NoSuchAlgorithmException e) {
System.out.println(
“There is no such algorithm for generating the shared secret”);
e.printStackTrace();
} catch (NoSuchProviderException e) {
System.out.println(“Not a valid Provider”);
e.printStackTrace();
}
ky = kg.generateKey();
 
　　首先，获得一个实现了Triple-DES算法的KeyGenerator对象。

　　对KeyGenerator对象调用generateKey方法获取共享密钥。这个共享密钥用于加密XML内容。共享密钥本身使用上一步生成的公钥加密并嵌入XML内容中。

　　结束语

　　XML在公共网络上的数据交换中发挥着卓越的作用。因此，XML安全标准以及如何采用、解释和在不同的技术平台上实现这些标准受到了更多的关注。本文中，我客观地定义了安全性及其基本技术，即XML规范化和PKI基础设施，在实现XML的安全交换中发挥着重要的作用。在这个基础上更进一步，本系列的下一篇文章中我将讨论XML加密和XML数字签名，并提供使用它们的详细指南。

　　关于作者
　
　　Manish Verma是Second Foundation的首席架构师，这是一家全球性的IT服务企业。Manish在软件开发生命期的方方面面有10年的经验，曾经设计过使用全然不同的系统的客户组织的集成策略。Manish在集成方面的专长建立在理解各种技术的基础上，包括各种不同的遗留系统、.NET、Java技术和最新的中间件技术。在进入Second Foundation之前，Manish先后在Quark Inc.、Hewlett Packard、Endura Software和The Williams Company做过软件架构师和技术主管。您可以通过mverma@secf.com与Manish联系。