学步园

郭 路
Technical Manager
2001 年 6 月

XML语言是一种面向数据的标记规范，与HTML不同，XML标记通常总是力求准确清晰地说明数据本身的涵义，即使对于一些非常陌生的XML文件，人们也很容易理解其所要表达的内容，从这个意义上讲，XML数据是完全开放的。由于在XML规范中并不提供对数据的保密措施，因此，一旦含有商业信息的XML文档被别有用心的人直接得到，泄密几乎是必然的。要设计一个基于XML传递数据的商业系统，信息安全是非常关键的问题，通过对B2B供应链的分析，我们可以发现影响系统XML数据安全保密的因素主要有以下几点：

• 监听网络端口或信道，数据在传输的过程中被截取；
• 存在本地或网络存储器中的XML文件被打开阅读；
• 通过浏览器等工具非法访问B2B网站的XML数据；
• 应用层中处理XML数据的组件被非法调用或修改；
• 用户口令泄漏或存在后门可以进入前端管理界面；
• 使用木马或陷阱等手段，记录并分析业务流片断；
• 修改、捏造请求或返回信息以得到应用的控制权；
• 获取网络中以文件形式共享的DTD/Schema、XSL。

一般而言，在B2B供应链中，前台的B2B网站由于其开放性，因此受攻击的风险较大；而后台的ERP/MRP管理系统可以说涵盖了企业所有重要的事务处理，因此数据的机密级别往往会更高。基于目前的计算机开发技术所限，通常B/S结构的应用系统其安全性较C/S结构更低，这也是影响Intranet在企业内部网中普及的一个重要原因。通常在B2B供应链系统中传输处理的XML文档多以动态的数据流形式存在，生存周期很短，必须用指定的应用程序调用而不能直接打开文件，因此，要保障系统中的XML数据安全，除了实际使用过程中加强对计算机系统的全面管理外，在开发设计时选择好的加密机制也很重要，通常对XML数据的加密有以下几种主要方法：

数据秘钥加密
XML数据是基于文本文件的，因此可以使用经典的加密算法对XML数据进行加密，通常我们称XML源数据为明文，加密后产生的目标数据为密文，由明文产生密文的过程称为加密，而由密文恢复明文的过程称为解密。设明文为M，密文N，则可用如下公式表示数据的加密解密过程，其中E为加密算法，F为解密算法：

• E（M）＝N
• F（N）＝M

上述公式具有很大的缺陷，即任何人只要破译了解密算法F，就可以由密文N算出明文M，此时为了保障数据安全，就必须修改或替换算法E和F，而这意味着要修改系统程序，显然是不切实际的。现代密码学通过秘钥解决此问题，所谓秘钥一般是由数字或字符组成的关键字，并作为加密/解密算法的参数代入，当加密算法E和明文M固定时，采用不同的加密秘钥K将得到不同的密文N，而此时由密文N恢复出明文M同样需要一个解密秘钥K解，根据加密/解密算法的不同，K解可以与加密秘钥K相同或不同，修改后的加密/解密公式表示如下：

E（M，K）＝N         //K为随机产生的关键字
F（N，K解）＝M       //K解等于K或与K匹配

一般我们称K解等于K的秘钥算法为对称算法或单钥算法，此时当有数据在不同计算机间交互时，发送方首先用秘钥K将明文加密，然后传输至接收方，并由接收方采用同样的秘钥解密得到明文。这种方法的一个难题在于，如何使接收方安全地得到发送方随机产生的秘钥K，解决的办法有好多种，这里仅介绍其中最简单的两种，实际设计中可根据系统的要求灵活应变，有关更复杂严密的方法也可参看Kerberos、DASS等安全标准：

• 点对点秘钥安全：为不同计算机上的应用A与B建立一初始通信秘钥K1，此秘钥可手工输入或编程时设定，并且未被使用过加密数据，因此认为是安全的。当A、B两方要通信时，发送方产生随机秘钥K2，并用K1将K2和XML数据加密，传输至接收方，接收方收到信息，用K1解密后，销毁K1，保存K2，并通知发送方接收成功，发送方得到响应后销毁K1，保存K2，否则重发数据，K2为下一次双方通信的加密秘钥；
• 通过可信第三方的安全服务：在网络中建立秘钥数据库C（即安全服务器），每个在C注册的应用都有一个不同的用户秘钥，该秘钥仅用于应用与数据库C间的通信，由数据库C产生发给应用，一般是定期更换，可以认为是安全的。当A和B通信时，发送方首先将事件告知数据库C，由C产生随机秘钥K，并将K用A、B各自的用户秘钥Ka与Kb加密后交给A、B，然后双方便可用解密后得到秘钥K对XML数据进行加密/解密。

DES是最流行的对称秘钥算法，该算法在七十年代由IBM的密码学专家发明，经过NSA（美国国家安全局）的评估与修改，先后被NIST、ISO等权威机构作为工业标准发布，可以免费用于商业应用。DES采用分组密码技术，即将明文分为长度为64bit的单元组，然后用一个随机产生的56bit数字秘钥对每一组进行加密，并输出长度为64bit的密文，其基本加密步骤如下所示：

1. 对64bit的明文单元组进行初始置换IP，如将第1位换到第50位，第50位换到第28位，第28位换到第3位……，并建立置换记录表S，然后将置换结果分为32bit的左右两部分R和L；
2. 秘钥置换，将56bit的秘钥分为28bit的左右两部分，每部分分别循环左移1或2位，然后从移动后产生的56位秘钥中选出48位作为压缩秘钥K缩；
3. 扩展置换，将单元组右半部分R切分为每4位一小组输入，经过E-盒运算，得到6位的输出结果，即将32bit的R扩展为48位的R扩；
4. S-盒代替，将R扩与压缩秘钥K缩作异或运算得到48bit的输入数据Ri，将Rs输入指定的8个S-盒，经过替换得到一个32位（8个4位分组）的输出Ro；
5. P-盒置换，对Ro进行动态的P-盒置换，并将置换结果（32bit数据）与单元组左半部分L异或得到新的右半部分R_，然后将左、右半部分L与R_交换；
6. 重复步骤2～5，使该组合操作共循环16轮；
7. 将单元组的左、右半部分交换后合并，并进行与初始置换IP相逆的末置换IP－1，即得到该单元组的最终加密结果。

DES的解密算法与加密算法基本一致，差别在于压缩秘钥K缩的产生不同，二者顺序正好相反，设加密过程中16轮加密的压缩秘钥依次为K1，K2，K3……K16，则解密过程中的压缩秘钥便为K16……K3,K2,K1。DES的算法复杂难懂，但却很容易通过计算机实现，本文在此给出DES算法的C源程序，对DES算法有兴趣的人可参看Bruce Schneier所著的《Applied Cryptography Protocols，algorithms，and source code in C》一书。

有关DES的争论主要集中在其安全性上，尽管一直没有确实的证据，仍有许多密码学家对DES的可靠性表示担心，其原因主要有二：

• DES采用56位秘钥与固定的S-盒，而这都是由NSA制定的，并且没有给出这样做的理由，人们担心NSA会在算法中嵌入后门，这样便可以用简单的方法对数据解密；
• DES是受分析与攻击最多的秘钥算法，随着差分分析技术与线性分析技术的公开，使得大型DES破译机的制造成本与破译时间大大降低。

为了提高DES算法的强度，人们提出了基于加密分组的链接模式（如CBC、OFB、CFB等）及DES的各种变型技术，如多重DES和更换S-盒等，其中有些已被证实了具有强化作用（如三重DES），而大多数还缺少数学上的验证支持。

除了DES外，目前较为流行的对称秘钥算法还有IDEA、FEAL、LOKI、Lucifer、RC2、RC4、RC5、Blowfish、GOST、CAST、SAFER、SEAL等，这些算法大多只具有美国专利（这意味着你至少可以在国内免费使用），有关它们的算法介绍与源程序代码在互联网新闻组上都可得到。

与对称秘钥算法相对应的是公开秘钥算法（又称双钥加密或不对称加密），该算法要求秘钥成对出现，即K解<>K并且不能实现由K->K解或K解->K的直接推导。通常秘钥K作为公开秘钥在网络中发布，任何人都可以此秘钥为加密秘钥加密数据并发给接收方，而接收方用另一个匹配的秘钥K解（私人秘钥）作为解密秘钥将数据解密，公开秘钥算法的最大优点就在于它不存在秘钥传送所带来的泄密问题，因为其公开秘钥本来就可以随意获得。

RSA是目前应用最为广泛的公开秘钥算法，也是最容易理解和实现的公开秘钥算法，它是1977年由R.Rivest、A.Shamir和L.Adleman三人提出的。其基本算法如下：

1. 选择两个大素数p 和q（通常为100到200位的十进制数）， 计算：n = p * q；
2. 随机选择加密秘钥e，要求 e 和 ( p - 1 ) * ( q - 1 ) 互质；
3. 利用 Euclid 算法计算解密秘钥d,满足e * d = 1 ( mod ( p - 1 ) * ( q - 1 ) )其中n和d也要互质；
4. 数e和 n是公钥，d是私钥。两个素数p和q不再需要，应该丢弃，不要让任何人知道；
5. 加密信息 m（二进制表示）时，首先把m分成等长数据块 m1 ,m2,...,mi （采用二进制数），块长s ，其中 2^s <= n,s
6. 尽可能的大（s为小于n的2的最大次幂）；
7. 加密公式：ci = mi^e ( mod n )
8. 解密公式：mi = ci^d ( mod n ) （其中ci为密文分组，mi为明文分组）

RSA算法的安全性完全依赖于分解大数的难度（即得到两个大素数p、q相乘结果很容易，但要由此结果分解得到大素数p、q却非常困难，这也是目前绝大多数公开秘钥算法设计的基本思路），需要指出的是，就纯技术的角度而言，这种逻辑是并不合理的，因为事实上它所基于的仅仅是一种猜测（类似于歌德巴赫猜想），目前在数学上还从未有人能证明过必须先要分解n才能从c和e中计算出m，如果有一天有人能够找到比穷举法有效得多的因式分解法或RSA中的后门，那么，所有用RSA加密的机密数据就有可能被一览无遗。

RSA公开秘钥算法的主要缺点在于1）加密/解密速度太慢，一般而言，与DES相比较，RSA的软件实现要慢一百倍，硬件实现要慢一千倍；2)处理数据量小，最多只能有其秘钥的模数大小，如一个1024的RSA公共秘钥最多只能加密1013位数据（多出11位长度要用于编码）。

事实上，在B2B供应链中，我们并不直接使用RSA加密业务数据，而是将它与DES等对称秘钥算法混合使用，即先用DES对称秘钥加密业务数据，然后用RSA公钥加密DES秘钥，并将加密后的业务数据与对称秘钥一起发给RSA私钥持有者（即业务数据的接收端）。这样，既避免了对称秘钥传递时的安全性问题，又消除了RSA算法速度太慢的缺点。

对于XML格式的数据，秘钥加密不仅可用于全文加密，也可用于元素级的加密，这在实际应用中有着非常广泛的意义。它不仅使数据加密可以精确到子元素，而且可以在一个文档中无缝结合加密与未加密数据。以下是一张用XML描述的药材模拟报价单：

<?xml version="1.0"  encoding="UTF-8"?>
<Price Sheet>
<addresser name="浙江思能" ></addresser>
<addressee name＝"杭州胡庆余堂药业"><Price><铁皮石斛>
<EncryptedElement algorithm="DES/CBC" contentType="text/xml" encoding="base64">
vJqNpDrQT1vmCVbyGJfIwdIDBYoGXGmutgz6TVGoPuKVG7IxNEN50iKw8pmtxFixz5hOChOXgTtPqk
tQhEHO5+vLOLAFgIioDIRQGHHmHng3CLd+8tvrT8wxPBCRSMUpx4d2TGXW2tqSepam0ZxdmwUXwNSAg
aR8hmiromD+bh+tDomPv7eFZ4no5ft3JG3t0trLlwVupF/5vaIJimUSmuUkkgyG8x9AcS/kXJxHpm
M=peqGzIMf+8Aa</EncryptedElement>
<ValidTime>2001-1-1至2001-2-1</ValidTime></铁皮石斛></Price></addressee>
<addressee name=" 哈尔滨制药六厂">
...... ..... ......
...... ..... ......
</Price Sheet>

在这份报价单中，药材价格是非公开的，因此原料商可以根据市场需求、生产成本、产量等因素定好药材价格后，先产生一张原始的报价单，然后将其中的价格部分加密（本例中所使用的算法是DES/CBC），并交给代理（可以是一计算机消息队列），代理根据单据上的不同收件人（addressee）将对应的报价部分提取转发，整个过程中代理始终不曾知道药材的报价。显然，本例中若采用全文加密会麻烦的多（需要为每个制药商建立一张报价单，并在文件外部指定收件人）。

通信协议加密
XML是完全面向数据的，因此可以和任何通讯协议相结合，通常我们在XML数据传递的网络编程中使用较多的有TCP/IP、IPX/SPX（通常用于后台内部网）、Socket、HTTP、SOAP、XML-RPC、CORBA（IIOP）等协议。由于在B2B供应链中，XML数据主要以异地的输入输出流形式存在（包括表单等业务信息与RPC调用命令，而很少有永久性质的本地XML物理文档存在），因此，我们可以使用面向通讯安全的网络安全协议来实现XML数据传输的安全性。

通常，实现通信协议的加密有如下两种方式：

1. 手工加密数据传输包，即以人工的方式将通信协议包中的数据分组进行加密，这种方式从实际编程上与单纯的数据加密没有什么不同，不过有两点需要注意：
   • 对分组数据进行加密后，通常数据的长度与校验值都会改变，因此要记得修改分组头中相应的字段定义部分；
   • 单个分组数据加密后也必须由单个分组打包发送，尤其是在某些无连接的通讯协议如IP、UDP、IPX中，不至于由一个包丢失引起整个分组数据的无效。

   采用手工加密XML数据传输包时基于实际通信协议的不同，可以选择使用不同的加密策略。比如当采用Socket（传输层）编程时，我们需要建立一个进程之间的安全通道，实现端对端的安全通信，此时所有经过此通道的数据都将被加密。而当采用HTTP、SOAP等应用层协议时，我们就可以选择采用端对端加密还是应用级加密，比如使用SOAP协议传输XML文档时，我们就可以实现对某个指定元素的加密。这是由于应用层协议通常都可以理解所传送文档的内部结构，而传输层协议则没有这种能力。

2. 使用安全网络协议，所谓网络安全协议是基于某一层网络协议之上或对应于某种网络协议的安全保密规范。即使用对称秘钥加密、公开秘钥加密、数字签名、CA证书等方法，按照指定的步骤，通过建立安全连接的方法，达到保证网络数据安全传输的目的。

目前在电子商务领域较为流行的网络安全协议有SSL、SET、PCT、TLSP、S－HTTP、IPSec、PPTP、S/MIME、PGP 、MOSS、PEM等。其中S－HTTP是HTTP的安全增强版本，由CommerceNet公司于1994年制定，S-HTTP提供了基于HTTP框架的数据安全规范以及完整的客户机/服务器认证机制。S/MIME、MOSS、PEM、PGP是电子邮件的安全传输标准，PEM是由IRTF安全研究小组设计的邮件保密与增强规范，它的实现基于PKI公钥基础结构并遵循X.509认证协议，PEM提供了数据加密、鉴别、消息完整性及秘钥管理等功能，目前基于PEM的具体实现有TIS/PEM、RIPEM、MSP等多种软件模型。S/MIME是由RSA公司于1995年提出电子邮件安全协议，与较为传统的PEM不同，由于其内部采用了MIME的消息格式，因此不仅能发送文本，还可以携带各种附加文档，如包含国际字符集、HTML、音频、语音邮件、图象、多媒体等不同类型的数据内容，目前大多数电子邮件产品都包含了对S/MIME的内部支持。PGP是由美国人Phil Zimmermann开发的一个免费电子邮件（也可用于一般文件）加密工具包。PGP缺省采用IDEA进行数据加密，RSA（秘钥长度最大为2047位）进行秘钥管理与数字签名，PKZIP作为数据预压缩算法，MD5作为单向散列算法。PGP符合PEM的绝大多数规范, 但不要求必须遵循PKI基础结构，而是采用了分布式的信任模型，即每个用户都可维护一个公钥环，PGP与S/MIME是目前最为流行的两个电子邮件安全协议。PPTP是微软制定的用于建立虚拟专用网络（VPN）的连接协议，PPTP允许客户机以拨号方式建立虚拟通道访问Internet上的异构网络（如IPX或NetBEUI）。PPTP的底层传输协议必须为IP，它采用了RAS公司的RC4作为数据加密方法，保证了在PPTP客户端与服务器之间的安全通信。IPSec是由IETF安全小组制定的面向TCP/IP网络安全的协议集，主要包括两个安全协议AH（验证头）和ESP（封装安全载荷），以及密钥管理协议IKE。其中AH提供无连接的完整性、数据发起验证和重放保护；ESP除了AH的全部功能外还可另外提供数据流加密；密钥管理协议IKE则负责提供共享的安全参数和密钥协商。这些协议均独立于算法，这种模块化的设计允许只改变不同的算法而不影响实现的其它部分。SET是由Visa与MasterCard公司共同开发的用于互联网安全信用卡数据传输的协议套件，它主要提供客户、商家和银行之间的认证，并确保交易数据的安全性、完整可靠性和交易的不可否认性，特别是保证不将客户银行卡号暴露给商家。SET采用公钥密码体制和X.509数字证书标准，属于典型的PKI应用，由于其严密卓越的安全特性，SET已成为目前公认的网上交易国际安全标准。不过由于目前在国内的电子商务领域中尤其是B2B市场中，还很少使用网上支付的交易方式，因此SET的实际应用非常有限。SSL是由Netscape制定的互联网安全通信协议，目前的版本为SSL 3.0，使用SSL可以建立一条点对点的安全信道用于实时的数据交互。PCT协议是微软制定的SSL2改进版本，据微软称其安全性能要远远高于SSL2，二者格式上的主要差别在于它们版本号字段的最显著位(The Most Significant Bit)取值有所不同: SSL该位取0，PCT该位取1。TLSP是基于TCP/IP的传输层安全协议，提供了类似于SSL3的安全性能 由ITEF的TLS安全技术小组制定，并作为安全标准草案向IESG正式提交。

SSL是目前电子商务中应用最为广泛的安全协议，其实现模式非常适合编程开发。由于SSL提供传输层的通信加密而与应用层协议独立无关，因此各种高层的应用层协议(如HTTP、FTP、TELNET、SOAP、WDDX等)能透明的建立于SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作，在此之后应用层协议所传送的所有数据都会被加密，从而保证通信的安全性。如前面所述，由于目前国内B2B市场还很少使用网上支付，因此安全性很高的SET协议几乎不太可能用到，而SSL由于其使用范围广（可结合大多数互联网通信协议），所需费用少（可以到网上免费下载基于各种操作系统平台、各种编程语言的工具包），实现方便（比如和IPSec相比较）、安全性高（经过多年实践检验），所以已成为一般网络数据安全通信的首选方案。本文将在下面对SSL的实现作简要介绍：

SSL协议包括SSL记录协议和SSL握手协议两部分，前者指定传输数据的具体格式。后者则负责在支持SSL的客户端和服务器端之间建立安全传输通道，并实现：

• 在客户端验证服务器；
• 允许客户端和服务器选择双方都支持的加密算法；
• 在服务器端验证客户（可选）；
• 用公钥加密算法产生"共享安全信息"；
• 建立加密SSL连接。

在SSL协议中，所有的传输数据都被封装在记录中。记录是由记录头和长度不为0的记录数据组成的。所有的SSL通信包括握手消息、安全空白记录和应用数据都使用SSL记录层。SSL记录协议包括了记录头和记录数据格式的规定。SSL的记录头可以是两个或三个字节长的编码。SSL记录头的包含的信息包括：记录头的长度、记录数据的长度、记录数据中是否有粘贴数据。其中粘贴数据是在使用块加密算法时，填充实际数据，使其长度恰好是块的整数倍。最高位为1时，不含有粘贴数据，记录头的长度为两个字节，记录数据的最大长度为32767个字节；最高位为0时，含有粘贴数据，记录头的长度为三个字节，记录数据的最大长度为16383个字节。

SSL协议同时使用对称密钥算法和公钥加密算法。前者在速度上比后者要快很多，但是后者可以实现更好的安全验证。一个SSL传输过程首先需要握手：用公钥加密算法使服务器端在客户端得到验证，以后就可以使双方用商议成功的对称密钥来更快速的加密、解密数据。其基本过程描述如下：

1. 客户端向服务器端发送客户端SSL版本号、加密算法设置、随机产生的数据和其他服务器需要用于根客户端通讯的数据；
2. 服务器向客户端发送服务器的SSL版本号、加密算法设置、随机产生的数据和其他客户端需要用于根服务器通讯的数据。另外，服务器还要发送自己的证书，如果客户端正在请求需要认证的信息，那么服务器同时也要请求获得客户端的证书；
3. 客户端用服务器发送的信息验证服务器身份，如果认证不成功，用户就将得到一个警告，然后加密数据连接将无法建立；如果成功，则继续下一步；
4. 用户用握手过程至今产生的所有数据，创建连接所用的"关键安全信息"，用服务器的公钥加密（在第二步中传送的服务器证书中得到），传送给服务器；
5. 如果服务器也请求客户端验证，那么客户端将对另外一份不同于上次用于建立加密连接使用的数据进行签名。在这种情况下，客户端会把这次产生的加密数据和自己的证书同时传送给服务器；
6. 如果服务器也请求客户端验证，服务器将试图验证客户端身份。如果客户端不能获得认证，连接将被中止；如果被成功认证，服务器用自己的私钥解密"关键安全信息"并分解（其中包含产生秘钥的参数条件）；
7. 服务器和客户端同时产生会话秘钥K，之后所有数据传输都用基于秘钥K的对称密钥算法来交流数据；
8. 客户端向服务器发送信息说明以后的所有信息都将用会话秘钥K加密。至此，它会传送一个单独的信息标示客户端的握手部分已经宣告结束；
9. 服务器也向客户端发送信息说明以后的所有信息都将用会话秘钥K加密。至此，它会传送一个单独的信息标示服务器端的握手部分已经宣告结束；
10. SSL握手过程成功结束，一个SSL数据传送过程建立。客户端和服务器开始用会话秘钥K加密、解密双方交互的所有数据。

一个SSL传输过程大致如此，但是还有很重要的一点不能忽略--即利用证书在客户端和服务器端进行身份验证。一个支持SSL的客户端软件通过下列步骤认证服务器的身份：

1. 服务器端传送的证书中获得相关信息（在SSL中有函数支持，在程序中有相关例子）；
2. 当天的时间是否在证书的合法期限内；
3. 签发证书的机关是否客户端信任的；
4. 签发证书的公钥是否符合签发者的数字签名；
5. 证书中的服务器域名是否符合服务器自己真正的域名；
6. 服务器被验证成功，客户继续进行握手过程。

一个支持SSL的服务器通过下列步骤认证客户端的身份：

1. 1. 客户端传送的证书中获得相关信息；
2. 2. 用户的公钥是否符合用户的数字签名；
3. 3. 当天的时间是否在证书的合法期限内；
4. 4. 签发证书的机关是否服务器信任的；
5. 5. 签发证书的机关是否服务器端信任的；
6. 6. 用户的证书是否被列在服务器的LDAP里用户的信息中；
7. 7. 得到验证的用户是否仍然又权限访问请求的服务器资源；

目前IANA（Internet号码分配当局）已经为具备SSL功能的应用分配了固定端口号，例如，带SSL的 HTTP(https)被分配的端口号为443，带SSL的SMTP(ssmtp)被分配的端口号为465，带SSL的NNTP(snntp)被分配的端口号为563。有关面向不同操作系统与编程语言的SSL免费开发工具包及技术资料可到 http://www.openssl.org上获得。

关于作者 郭路，杭州大学计算机系92届本科应用专业，曾先后就职于浙江省纺织经贸总公司计算机中心、思能软件、华企、飞时达等软件公司，担任技术主管，主要从事于企业 MIS、GIS、ERP 及电子商务项目的开发管理和系统分析，对 IBM、微软、SUN、Autodesk 等公司的企业级产品有较深的研究及理解。 mailto:gl2_public@sina.com