Doug Tidwell 数码福音传道者, XML 开发组 2000 年 4 月
随着越来越多的公司在通过网络传输结构化数据时采用 XML,文档的安全性变得愈加重要。这篇文章介绍有关网络安全的基本知识,对 XML 安全组件的组成进行说明,并且通过一些示例说明 XML 安全组件中的技术如何增强网络商务的安全性。
网络安全概述 随着越来越多的公司在通过网络传输结构化数据时采用 XML,文档的安全性变得愈加重要。世界互联网联盟 (W3C) 和因特网工程任务组 (IETF) 正在制定用于数字签名的 XML 词汇表。东京研究实验室则已开发出 XML 安全组件,该安全组件是 XML 签名规范的原型。XML 安全组件可以从 IBM 的 alphaWorks 获得,包括自动生成 XML 数字签名的工具。 在通过网络传输保密数据时,应保证以下四点:
- 机密性―其他任何人都不能访问或复制该数据。
- 完整性―该数据从发送者到达接收者的过程中未被更改。
- 身份验证―该文档确实发自所指的发送者。
- 无争议―发送者不可否认该文档确由其发送,也不能否认文档的内容。
SSL 能够提供前三项功能,而 XML 安全组件则能同时提供上述四项功能 创建安全会话 创建安全会话包含多个步骤:
- 安全服务器获得适当的安全认证(CA)。
- 安全服务器将其公钥发送至客户端。
- 客户端使用服务器的公钥产生 预置密码(由客户端生成的一个 随机数,但比一般的随机数要复杂得多)。服务器利用私钥对预置密码解密。
- 服务器在预置密码的基础上生成新的密码。服务器知道该密码,且只能被产生该预置密码的客户端解密与使用。
此过程将创建一个会话,其在特定客户端与服务器间的所有的数据交换均被加密。只有服务器和特定客户端能够相互进行数据解密。这样,机密性、完整性和身份验证均已包括。然而,SSL 不能实现无争议性,如果我的系统中有一个文 件,你可以否认曾发送过这个文件,或者可以否认文件内现有内容是你所发送的。无争议性是由 XML 安全组件所提供的一项功能。 XML 安全组件 XML 安全组件提供多项重要功能:
- XML 签名。此项功能的实现基于世界互联网联盟 (W3C) 和 因特网工程任务组 (IETF) 正在开发的 XML 签名核心语法和处理规范。(参见 资源)
- W3C 规范 XML 的工作草案的实现。(参见 资源。)
- 元素级加密。
以下各部分将分别讨论上述功能及其如何增强网络安全。 XML 签名 W3C 和 IETF 正共同致力于一项基于 XML 的数字签名的计划。该计划定义一个 <signature> 元素,其中包含处理数字签名所需的全部信息。 每个数字签名均可归结为以下三类之一:
- 一个包含在
<signature> 元素中的 XML 元素 - 一个由 URI 索引的外部 XML 文档
- 一个由 URI 索引得外部非 XML 资源
本文例子将向您展示如何创建这些资源。如果您想了解全部细节,请参见 XML 签名方案的最新草案(参见 资源
彩色代码 这篇文章的特点是彩色代码清单,这是我们在 dW 进行的一项新尝试。为产生彩色编码清单,使用了两种开放源码的工具。首先,使用 Emacs 加载文件 (Java、HTML、XML、以及其他任何文件)。Emacs 对关键字、注解、函数名和其它十来种编程语言结构分别定义颜色。使用 Emacs 加载文件并对文件着色后,使用了 HTMLize 软件包,一个使用曾经流行一时的 Emacs Lisp 语言编写的开放源码的工具。HTMLize 将 Emacs 中显示的清单原样照搬,再将其转换为 HTML。最终得到一个完全彩色代码的文件,以突出其中的关键字、注释、函数名等。
我们非常希望了解您对这些经过改进的新代码清单的看法。
如果您想亲自进行这一操作,参见 资源,其中包含了相关的链接。 | 为了说明 XML 签名的工作原理,我生成了一个关于莎士比亚的十四行诗的名为 signature.xml 的签名文件,该文件已经应用在我的很多的XML例子中(可以通过 HTML格式浏览,也可以 下载此文档。) 在这个签名文件里,带符号的元素是十四行诗,包含在 <dsig:Object> 元素中。而实际的签名包含在 <SignatureValue> 元素中,此外该文档的签名人则由 <X509Data> 元素说明。 关于示例程序 通过若干程序范例来说明 XML 安全组件的不同功能。如果想要深入了解这里所讨论的 程序例子,则需要几个文件。有关如何获得这些文件的信息,请参见 资源
- XML 安全控件 将
xss4j.jar 和 /xss4j/samples 添加至您的 classpath 中。
- Java 2 Development Kit 1.2 版或更高版本。 请确认这是您的系统默认的 JDK。
- JavaMail 包中的 mail.jar 文件 将此文件添加至
classpath 。
- Java 密码扩展系统的一个实现 在 Sun 的网站中可以找到密码服务提供者的目录。为避免输出过于复杂,这里的例子采用了 OpenJCE,一个免费的开放源码的库。将
jce.zip 添加至classpath中。
- IBM XML 语法分析器第 2 版和 Java 3.0.1 版 文件
xml4j.jar 必须位于classpath中。 创建证书 在生成数字签名前,首先要获得一份证书。尽管可以通过证书授权机构(CA)得到一份证书,但是在这里的例子中,你将充当自己的 CA。要创建在 signature.xml 中使用的 X.509 认证,可用 Java 2 的 keytool 命令: 清单 1、keytool命令
keytool -genkey -dname "CN=Doug Tidwell, OU=developerWorks, O=IBM,
L=Research Triangle Park, S=North Carolina, C=US" -keypass openstds
-storepass security -alias xss4j
| 在 keytool 命令中,特异名(dname)由普通名(CN)、组织单元(OU)、组织(O)、区域 (L)、州(S)和国家(C)组成。对于整个因特网,特异名被设计为唯一的。密匙库 (-storepass) 的密码为 security ,此证书的私钥的密码 (-keypass) 为 openstds ,而 xss4j 则是认证 (-alias) 的别名。 对内部 XML 资源签名 要创建数字签名,可以使用 SampleSign 应用程序。这个程序是 XML 安全组件附带的,可以在 xss4j/samples 目录中找到。我们的第一个签名将应用于内部 XML 资源。也就是说数字签名和 XML 资源都在同一文件中。下面说明如何对 sonnet.xml 进行签名, 以生成 signature.xml : 清单 2、SampleSign应用
java SampleSign xss4j security openstds -embxml
file:///d:/xss4j/samples/sonnet.xml > signature.xml
| (随便说一句,此命令为单行输入。)请注意,别名、私钥密码、密匙库密码同清单 1 的 keytool 命令是相同的。另外还应注意这里用 file: URL 代替了简单 的文件名,而输出内容则送至(用 >操作符)文件 signature.xml 。这条命令的执行结果是 signature.xml 中显示的文档。 对外部 XML 资源签名 对外部 XML 资源签名表明 <Signature> 文件包含 XML 资源的 URL,而不是资源本身。要创建这种数字签名,应使用 -extxml 选项: 清单 3、带有 -extxml 选项的 SampleSign 应用
java SampleSign xss4j security openstds -extxml
file:///d:/xss4j/samples/sonnet.xml > external-signature.xml
| 这将产生一个同 signature.xml 相似的文件,只是实际的 XML 文件未被包含在 <Signature> 中。 对非 XML 资源签名 最后的这个签名示例将为非 XML 资源生成一个数字签名。在这个例子中用到一个 GIF 文件,包含 developerWorks 的标识: 要创建数字签名,使用 -ext 选项: 清单 4、带有 -ext 选项的 SampleSign 应用
java SampleSign xss4j security openstds -ext
file:///d:/xss4j/samples/dwlogo.gif > external-gif-signature.xml
| 验证数字签名 XML 安全组件提供了一个实用程序 SampleVerify,用于验证数字签名。使用它, 可以检查给定的签名,以确认被签名的资源没有改变,此外还能检查该签名是否同发送者的证书信息相符。如果签名有效,清单 5 会显示出应当得到的结果: 清单 5、SampleVerify 应用
java SampleVerify -dom < external-signature.xml
Signer: CN=Doug Tidwell, OU=developerWorks, O=IBM, L=Research Triangle
Park, ST=North Carolina, C=US
SignedInfo Bytes: 1069
----------------------------------------
--> Location: file:///d:/xss4j/samples/sonnet.xml
Validity: Ok
--> SignedInfo: Ok
--> All: Ok
----------------------------------------
| 如果签名的文件被改动,该签名将不再有效。为了说明这种情况,可在 <line> 元素后面加一个空格,把 <line>My mistress' eyes are nothing like the sun,</line> 改成 <line>My mistress' eyes are nothing like the sun, </line> 。 当再次检查签名,其结果将如清单 6 所示: 清单 6、SampleVerify 应用(改过的文件)
java SampleVerify -dom < external-signature.xml
Signer: CN=Doug Tidwell, OU=developerWorks, O=IBM, L=Research Triangle
Park, ST=North Carolina, C=US
SignedInfo Bytes: 1069
----------------------------------------
--> Location: file:///d:/xss4j/samples/sonnet.xml
Validity: NG
Reason: Digests were mismatched.
--> SignedInfo: Ok
-->
All: NG
----------------------------------------
| 由于改动过的 XML 文件同数字签名不符,这样就可以知道不能信任该文件。(如果原始文件签署者以外的其他人试图冒充该数字签名的创建者,在 SignedInfo 信息中便会显示出来。) 无争议性的乐趣 数字签名的最有用之处是能提供无争议性。如果你传送给我一份签署的文件,我能知道你就是发送者,因为签名中包括了你的公钥。另外,由于签名是基于文件内容的,所以对文件的任何改变都会使签名不符。 规范的XML 规范形式 为计算数字签名,需要一个通用的方法来表示所有的 XML 文件。可以采用 W3C 的规范 XML 事物最简单的形式(韦氏学院字典,在线版)标准来进行。 即使两个 XML 文件不完全相同,它们在 XML 应用中的作用可能是一样的。看一看下面这两个元素: 清单 7、等价但不相同的 XML
<img src="dwlogo.gif" width="225" height="30"/>
<img src="dwlogo.gif" height="30" width="225"/>
| 如果对这两个元素进行简单的字符串比较,它们显然是不同的。然而,从 XML 处理的角度来看,它们是等价的。按照 XML 1.0 推荐标准,属性的顺序是不重要的。在 XML 源码文件中,其它非重要差异还包括属性间的空格数量 以及源文件中是否实际包含带默认值的属性。为解决这一问题,W3C 正在为 XML文档定义一个规范形式。 XML 安全组件提供了一个应用程序 — XML Canonicalizer (XML 规范器),这是对 W3C 将要出台的规范 XML 标准的原型的一个实现。要将 XML 文件转换为规范形式,可以用下面两个命令之一: 清单 8、XML 规范器
java C14nDOM sonnet.xml canonical-sonnet-DOM.xml
java C14nSAX sonnet.xml canonical-sonnet-SAX.xml
| C14nDOM 应用程序使用 DOM 语法分析器,而 C14nSAX 应用程序则使用 SAX 语法分析器。虽然可以使用这些应用程序来生成 XML 文件的规范形式,但是它们仍主要用于 XML 签名代码。(随便说一句,c14n 缩写是指 canonicalization 的拼写以字母 c 开始,以字母 n 结束,中间有 14 个字母。类似地,您也会经常看到 internationalization 被写成 i18n)。 因为 XML 签名代码使用规范形式产生数字签名,所以可以对原始文件进行适当改动而不影响数字签名的有效性。例如,在标记中添加一些空格。将下行:
sonnet type="Shakespearean"
| 更改为
sonnet
type="Shakespearean"
| 进行这一更改后,再次运行 SampleVerify 应用程序,以确认数字签名仍然有效: 清单 9、SampleVerify 应用程序 (文件的规范形式)
java SampleVerify -dom external-signature.xml
Signer: CN=Doug Tidwell, OU=developerWorks, O=IBM, L=Research Triangle
Park, ST=North Carolina, C=US
SignedInfo Bytes: 1069
----------------------------------------
--> Location: file:///d:/xss4j/samples/sonnet.xml
Validity: Ok
--> SignedInfo: Ok
--> All: Ok
----------------------------------------
| 尽管文件不同,然而其差异没有语义重要性。因为 XML 安全组件使用 XML 文件的规范形式,语义上不重要的差异被忽略。 元素级加密 XML 的一个长处在于可以选择元素名,从而使标记文件更具可读性。作为一个例子,参见清单 10 中用XML 编写的客户订单。(也可以 下载该文件)。 清单 10、 custorder.xml
<?xml version="1.0"?>
<!DOCTYPE customer_order SYSTEM "custord.dtd">
<customer_order>
<items>
<item>
<name>Turnip Twaddler</name>
<qty>3</qty>
<price>9.95</price>
</item>
<item>
<name>Snipe Curdler</name>
<qty>1</qty>
<price>19.95</price>
</item>
</items>
<customer>
<name>Doug Tidwell</name>
<street>1234 Main Street</street>
<city state="NC">Raleigh</city>
<zip>11111</zip>
</customer>
<credit_payment>
<card_issuer>American Express</card_issuer>
<card_number>1234 567890 12345</card_number>
<expiration_date month="10" year="2004"/>
</credit_payment>
</customer_order>
| 这个文件包括三部分, <items> 元素列出顾客定购的各项内容, <customer> 元素包含了客户的信息,而 <credit_payment> 部分描述了用于支付该订单的的信用卡信息。(致初级网络窃贼:实际上,上面的信息不是我的信用卡号码。如果你能利用此信息购买商品和服务,请不要忘了跟我说一声。) 早期的因特网用户不愿意使用信用卡进行在线购物。这时,许多电子商务支持者指出无论如何信用卡支付总是要冒一定风险的。通常我把信用卡交给饭店的服务员,我相信我的信用卡不会被用来支付我的餐费以外的其它东西。同样,当我在线购买时,我相信商家不会用我的信用卡支付未经我认可的款项。 利用 XML 安全组件的元素级加密功能,可以对敏感信息进行加密。这样,商家也不能看见这些信息。商家可以把加密信息传给信用卡处理机构,这些机构拥有正确的密匙,可对敏感信息解密。这样将能极大地提高现行的典型处理方式的安全性。 为了说明元素级加密,我对 XML 安全组件所带的 CipherTest.java 文件稍做更改。(参见 被修改文件的源文件。) 我将对所做的更改进行说明,以对元素级加密的工作原理进行解释。 对 CipherTest.java 的第一项改变是导入 OpenJCE 库,然后将 ABAProvider 类定义为密码提供者: 清单 11、CipherTest.java 更改 (导入 OpenJCE 类)
import au.net.aba.crypto.*;
import au.net.aba.crypto.provider.*;
import au.net.aba.crypto.spec.*;...
public class CipherTest {
public static void main(String[] args) {
if (args.length < 3) {
System.err.println("Usage: CipherTest -e|-d passphrase infile outfile");
return;
}
java.security.Security.
addProvider(new au.net.aba.crypto.provider.ABAProvider());
| 替代调用 java.security.Security.addProvider 方法,可以修改 java.security 文件 (见 JavaHome/lib/security ),将下面一行:
"security.provider.1=sun.security.provider.Sun"
| 替换为:
"security.provider.1=au.net.aba.crypto.provider.ABAProvider"
| 其它更改只剩下修改代码,使之能够对任何 <credit_payment> 元素进行加密: 清单 12、 CipherTest.java 更改 (加密元素)
if (n.getNodeType() == Node.ELEMENT_NODE) {
//System.out.println(((Element)n).getTagName());
if ((ne != null &&
((Element)n).getTagName().equals(
"credit_payment"))
||
(nd != null &&
((Element)n).getTagName().equals("EncryptedElement"))) {
child = n;
break;
| 要演示这一功能,可以运行 CipherTest,同原始的 XML 文件进行对比。应用程序 CipherTest 在命令行中使用了一个密码: 清单 13、 CipherTest 应用程序
java CipherTest -e security custorder.xml encrypted-custorder.xml | 这将创建 encrypted-custorder.xml 文件,如清单 14 所示。(也可以 下载这个文件。) 清单 14、 encrypted-custorder.xml
<?xml version="1.0"?><customer_order>
<items>
<item>
<name>Turnip Twaddler</name>
<qty>3</qty>
<price>9.95</price>
</item>
<item>
<name>Snipe Curdler</name>
<qty>1</qty>
<price>19.95</price>
</item>
</items>
<customer>
<name>Doug Tidwell</name>
<street>1234 Main Street</street>
<city state="NC">Raleigh</city>
<zip>11111</zip>
</customer>
<EncryptedElement algorithm="DES/CBC/PKCS5Padding" contentType="text/xml"
encoding="base64" iv="S5Rirg//pNQ="> vJqNpDrQT1vmCVbyGJfIwdIDBYoGXGmutgz6TVGoPuKVG7I
xNEN50iKw8pmtxFixz5hOChOXgTtPqktQhEHO5+vLOLAFgIioDIRQGHHmHng3CLd+8tvrT8wxPBCRSMUpx4
d2TGXW2tqSepam0ZxdmwUXwNSAgaR8hmiromD+bh+tDomPv7eFZ4no5ft3JG3t0trLlwVupF/5vaIJimUSm
uUkkgyG8x9AcS/kXJxHpmM=peqGzIMf+8A=
</EncryptedElement>
</customer_order>
| 在这个加密的 XML 文件中,元素 <credit_payment> 被替换为 <EncryptedElement> 元素。文件中没有任何参数指示共对多少个元素进行加密、加密元素名称、加密元素的结构或顺序等。为保证加密文件的保密性,我们在源文件中没有使用 <!DOCTYPE 声明。加密文件不能使用 DTD,也不能包括任何可能显示加密元素结构的索引。如果对带有 <!DOCTYPE 声明的 XML 文件进行加密,解密过程不能工作。(得到的错误信息没有什么帮助;将显示 java.lang.NullPointerException at CipherTest.main(CipherTest.java:83) ,或其它同样没用的提示信息。) 要恢复原始文件,使用 -d (decrypt/解密) 选项代替 -e (encrypt/加密) 选项。确认你用的密码是相同的。 清单 15、 CipherTest 应用程序 (-d 选项)
java CipherTest -d security encrypted-custorder.xml restored-custorder.xml
| 这会将加密文件恢复为原始状态。注意,元素级加密使用规范的 XML,所以恢复后的文件同原始文件的语法可能并不完全一样。然而,然而,这些差异在语义上都不是特别重要。 其它工具 XML 安全组件另外还提供了两种工具,包括一个 ASN.1 到 XML 的翻译器和多种 DOMHASH 工具。ASN.1 到 XML 的翻译器自动在 ASN.1 数据(如 X.509 认证和 LDAP 数据)和 XML 间进行翻译。(有关 ASN.1 的详细信息,参见资源)。DOMHASH 是一种算法,为 XML 文件树中一个给定节点生成唯一的哈希数。XML 安全组件中所包括的 DOMHASH 工具计算给定节点的哈希数,另外还提供了一套 DOMHASH 测试工具。alphaWorks 包含一个 DOMHASH 应用程序,叫做 XMLTreeDiff(参见 资源);它使用 DOMHASH 来确定两个 DOM 树的差异。 总结 XML 安全组件提供了多项功能,以增强 XML 文件的安全性。所有这些技术都能为现有的网络安全体系所应用。随着 XML 文件交换日益重要,XML 安全组件中的技术将提供重要的安全功能。最重要的是,这些技术建立在开放的新兴标准下,而且能在任何支持 Java 的平台上进行工作。如果你对这种即将被全世界所采用的安全技术感兴趣,XML 安全组件确实值得一看。 参考资料
关于作者 Doug Tidwell 是 IBM 高级程序员。他具有 16 年以上的编程经验,同基于标记的应用程序打交道也已经愈 10 年。正如 IBM 的 Simon Phipps 所说,他作为一名“数码福音传道者”,其工作就是“化繁为简”。在其雇主的特殊安排下,他正致力于巧克力软糖的研究。他拥有 Vanderbilt 大学计算机科学硕士学位和 Georgia 大学英语学士学位。可以通过电子邮件 dtidwell@us.ibm.com 同他联系。 | |