xml技术的安全研究

xml技术的安全研究

1公文签名和加密的基本要求和不足随着计算机技术和英特网的快速发展，电子贸易、电子银行、电子电子等业务变得越来越重要。而安全问题是这些应用能否成功的核心问题。目前中国政府正在大力推行政务电子化,其中一个重要的安全问题是如何有效地实现公文的签名和加密。一般来说,公文的签名和加密应该满足下面的几个基本要求。首先,因为公文(包括公文的附件)存储格式的多样性(比如纯文本格式,WPS格式,Word格式等),公文的签名和加密的实现方法就必须能灵活地支持各种不同的公文存储格式。其次,公文流转过程中可能经历修改、批复、不同部门盖章批准等等处理,因此公文的签名和加密实现方法必须有效的支持对公文的更改和多重签名。再次,公文的接收者可能分布在不同的地方和单位,他们的系统环境可能并不相同,因此公文签名和加密应该支持跨平台的应用处理。但是,现有的签名和加密方案,如整体式签名和加密,S/MIME,基于OLE技术的方案等,都存在一些问题,并不能很好地满足上述公文的基本安全性需求。本文首先对各种现有的签名和加密方案进行了比较和分析,并在此基础上提出了一个新的基于安全XML的电子公文方案该方案不仅很好的满足公文的基本安全性需求,而且具有内容结构化,易于与数据库交互的优点。2基于安全rss的公文标准化公文签名的作用之一是提供非否认服务,即公文的签名者不能否认他知晓并同意该公文的内容。公文的加密则提供机密性服务,即不知道解密密钥的第三方无法获知公文的明文内容。根据OSI安全体系结构,在计算机网络通讯协议的七层中,几乎各层都可提供机密性服务,但是只在应用层提供非否认服务。因此能满足公文签名和加密需求的方案都位于应用层,或者是应用相关的。在办公系统中广泛使用低层安全协议如SSL,IPSec等并不能支持非否认的签名功能。如网景公司提出的SSL为SSL连接提供两种安全服务,即机密性服务和报文完整性服务。它实现报文完整性的机制是带密钥的报文鉴别码MAC,由于该密钥是通信双方共享的,仲裁者不能区分报文究竟是哪一方发起的,所以MAC并不能提供非否认的功能。对公文签名和加密的最直接的方法是对公文文件整体签名和加密。比如一个公文是Word文件,sample.doc,那么处理方法是,先对sample.doc用签名算法生成一个签名signature—of—sample,然后将sample.doc+signature—of—sample加密得到sample.sec。公文的接收方先将sample.sec解密得到Nsample.doc+Nsignature—of—sample,然后验证签名,通过后调用阅读程序打开Nsample.doc。这个方案非常简明,而且可以支持各种存储格式的文档,但是它的缺点也是明显的。它很难支持公文的批复,多重签名;不支持对公文的部分签名和加密;严重的依赖于应用程序,通用性差。另一种方案针对Word和WPS等支持OLE对象链接与嵌入的系统。具体实现时一般是把签名和加密等安全功能附加到原有的MSWord或者WPS应用程序中。签名时,先对批复和文件内容用签名算法生成签名结果,存入一个签名OLE对象中,该OLE对象的显示外观可以是一个公章的图像。然后把该签名对象插入文档。验证时,可以调用签名OLE对象中的验证函数实现。加密解密的实现与第一种方法类似。这种方案的一个特点是签名与原文档融为一体,图形化的签名档直观自然。然而它并没有完全解决第一种方案存在的问题,比如对应用程序的依赖,不支持部分签名和加密等。值得一提的一个方案是S/MIME。虽然它是针对安全的电子邮件的协议,但是它的设计思想对一般文档的安全性技术有借鉴意义。MIME是RFC822的扩充,可以支持7个主要的内容类型和总共15个字类型,比如文本,图像,声音等。S/MIME在MIME的基础上增加了安全功能,用内容类型表示可分为:加密数据,签名数据,清澈签名数据,签名并加密的数据。S/MIME不依赖于具体的应用程序,对多种数据格式的支持等等是它的优点。在S/MIME中,各种类型的数据可经过Base64编码并标记其内容类型和子类型后嵌入到一个文件中,方便了传输和储存管理,这是在我们的设计中可以借鉴的。然而由于它只是针对电子邮件设计的标准,扩充性差,缺少开发工具,因此不适宜作为安全的公文标准。基于上面的分析,本文提出一个基于安全XML的公文标准及实现方案。采用安全XML作为公文存储交换格式的好处有:XML易于扩充,可以根据需要定义新的标记;XML是结构化的文档,易于检索分类;XML可以方便的和数据库交互;XML在不同的平台上获得了广泛的支持,开发工具丰富。事实上,XML有望在不久的将来成为广泛采用的通用标准,所以研究基于安全XML的电子公文是很有意义的。3web资源的加密/签名公文处理的安全性是我们考虑的主要问题。下面对我们的系统中用到的XML安全规范和思想作一个简述。这方面要想进一步了解的读者可参考文献等。XML安全规范包括XML加密和XML签名。加密和签名的要素包括(遵从OSI安全体系标准,将加密和签名统称为安全变换):(1)安全变换的粒度:最大的粒度是把整个XML文档加密/签名,最小的粒度是对一个元素(包括开始标记和结束标记)或者一个元素的内容(开始标记和结束标志之间的部分)加密/签名。目前的草案没有对标记的属性值单独加密的支持。(2)安全变换的嵌套:允许对已经加密/签名过的XML文档的再次加密/签名。(3)安全参数:XML提供了加密/签名密钥,加密算法等安全参数的表示方法。一种方法是把安全参数作为XML文档的一个元素,另一种是指向安全参数的外部链接。(4)安全关联:提供了密文数据/签名数据和加密/签名用的安全参数的关联方法。(5)安全变换算法:提供3DES,AES数据加密算法,RSA,3DES密钥加密算法;签名算法DSA;散列算法SHA。(6)安全变换对象:支持对所有的web资源的加密/签名,包括非XML内容。加密/签名相关的安全参数用XML元素封装。被加密/签名的对象可以在XML文档中也可以不在XML文档中。如果不在XML中,可以用索引指向它。如果在XML中,则可用base64编码后作为XML的CDATA对象。除了安全变换外,根据应用的需要,XML的安全规范还支持几种形式变换(Transforms变换),包括规范化(canonicaliztion),base64编码,XSL变换,XPath变换等。由于不同的客户软件对语法格式的不同处理,比如对行分隔符,空标记的不同处理等,导致相同语义的两个文件在文本上的细微差异,从而使得签名/加密的结果大不相同。XML标准采用XML文档规范化(canonicalization)来解决这个问题。Xpath变换可用在下面的情形。比如,一张已经由制表机构签名的空白表格,需要不同的人填写相关的内容后签名。这样某些已经签名的部分就改变,为了使原来的签名继续有效,就应该在签名前将可能会改变的部分排除。4安全公共数据系统的设计4.1定义元素的多种基本特征XML模式比DTD的功能更强大更精确。它除了可以定义文档的语法外,还可以定义元素内容的实际数据类型,限定元素可能出现次数的范围和元素值的范围。下面给出公文的XML模式的开头部分的定义。为了节省篇幅,这里没给出完整的公文模式,请参照下面的公文XML文档的例子。4.2签名的基本内容公文的显示外观必须用样式表进行规范。因为根据签名的安全语义,签名者只对他所看到的表示意见(具体意见与批复相同,当没有批复时就表示一般意义的知晓和批准),所以只有验证者看到的与签名者看到的完全一样时才表明验证正确。签名者签名的内容应包括所用的样式表。在公文的XML文档中,有的部分不显示,比如签名元素中的密钥,散列值等,通过把对应元素的显示属性visibility设置为hidden即可。而签名档可以用指定的公章图像作为显示外观。4.3对签名中的利益的理解公文格式一般包括的内容有:代码,份号,密级,缓急程度,文头,发文字号,签发人,标题,主送,正文,附件,作者,日期,注释,抄送,主题词等。下面给出一个简略的公文例子。注意,在被签名的部分增加了样式表名和批复两个元素。如前所述,必须保证签名验证方看到签名时完全一样的形象,把样式表名也包括在签名内容中。签名验证方应该从其他可信的渠道得到了标准的样式表。另外一个可行的方法是将样式表的散列值加入签名内容中,验证签名前验证样式表的散列值。被签名的内容都在MainText中,在Signature中用“Tobesigned”来指向它。3.4安全服务器配置对小型的应用环境,只需在局域网中增加一台安全服务器,提供CA服务。对于大中型企业就需要考虑系统的伸缩性问题。使用基于IPSec的VPN技术可以在Internet上建立跨地区的虚拟专网,每个局域网内配置一台安全服务器,所有的安全服务器构成严格的层次结构。另一种有吸引力的配置是每个局域网配置安全注册机构服务器,及安全信息发布服务器(发布证书和撤销列表)。整个企业配置一台证书机构(CA)服务器。前一种配置具有很好的可扩放性,但增加了证书认证链管理的负担。公文处理软件系统采用B/S计算模式。在客户端使用XML浏览器访问信息服务器,XML文件从服务器下载;在服务器端提供文档中转,发布和文档数据库。3.5两种软件设计目前XML正处在不断的发展之中,很多新的规范并没得到广泛的支持,比如XML签名规范在2002年2月才成为正式标准。不过已有了相关的开发工具,如IBM公司的XMLSecuritySuite。有两种软件设计模式实现对公文的处理。一个是采用标准浏览器,如微软的IE,通过HTML内嵌的JavaScript和ActiveX控件对公文的签名和加密进行处理。另一种方法是开发独立的Java窗口程序,开发工作量比第一种方法更大,但功能更强大的,更灵活。本系统采用第二种方法实现,开发平台是JDK1.2,使用IBM的XMLJava包处理XML下面是几个实现技术的介绍。3.5.1实现公钥管理系统实现时签名和加密都采用公钥体制。公钥体制包括一对密钥,即私有密钥和公开密钥。一般密钥的管理包括以下几个方面:密钥的产生,登记,分配,启用/停用,替换/更新,撤销,销毁。公钥的管理采用公钥证书的方法,相应要求对公钥证书的管理。在公钥证书管理中的两个重要的概念是证书撤销和证书策略。在系统实现时要考虑的另一个问题是私有密钥的保护。一般说来,实现公钥管理有三种方案。第一种是以用户为中心的管理,每个用户自己产生密钥对,签发公钥证书,维护信任链。这种方式对较小的应用系统或者对安全性要求不高的情况来说是有效的,比如PGP就是用这种方式。第二种方案是采用商业网站的CA服务,这是目前最为广泛使用的方式。比较有名的商业CA公司有美国的VeriSign,GTECyberTrust,中国金融认证中心CFCA。第三种方案是建立专用的公钥基础设施PKI,实现公钥管理的自动化。可采用商用PKI系统如eTrustPKI,或者使用开放源码PKI项目。本系统采用一个企业内部CA服务器提供公钥证书和撤销证书的颁布。在客户端,相关的接口函数有:客户密钥对装入LoadKeyPair();公钥证书查询GetCertificateList();公钥证书获取GetCertifiate(CertficateID);获取公钥证书撤销列表GetCRL();公钥证书状态查询CertificateStatus(CertificateID)。系统初始化时先装入CA根证书,然后装入从CA获得的公开/私有密钥对。私有密钥由用户的口令保护。3.5.2公文签名生成签名是公文处理的重要一环。不同的应用环境下签名的精确语义是不同的。公文流转中可能会有起草者的签名,主管领导的批复和签名,公文颁布时加盖公章等等。因此签名函数的实现应该支持不同语义。另外一个问题是附件的处理。附件可以是任何类型的文件,如Word文件,WPS文件,甚至是声音文件、视频文件。附件的存储方式有两种,一是可以经过Base64编码后放入公文XML文件中,另一种是用链接指向它。它们本身可能已经有签名,也可能没有。在公文签名时可以有多种处理方法,一种是只对附件的名称签名,一种是对附件名和标识号签名,一种是对整个附件采用“分离签名”(detachedsignature)。本系统支持这三种签名方式。步骤如下:首先使用函数SetSignatureMode()设置签名的工作模式,如选择散列函数,签名函数,签名密钥等。有关参数存入SignatureParas对象中。第二步,选择签名密钥对应的显示外观,撰写批复文字。把它们写入相应的公文XML。第三步,从公文XML和批复生成签名DOM。第五步,签名。SignatureContext.sign(Element,SigParas.Key);值得一提的是多重签名,XML签名规范考虑到了这个问题。其方法是使用Xpath变换将他人的批复排除在外,而只对原文签名。这也是基于XML的电子公文方案的一个优点。3.5.3公钥信息验证在上面的步骤生成签名后,Signature元素中包括了生成签名的各种参数,如规范化方法,摘要方法,签名方法,公钥信息等。在签名验证时就要用到这些信息。签名验证时首先要验证公钥证书的有效性(包括正确性,完整性,有效期,撤销情况,证书策略),如果无效,则验证失败;如果通过,就验证签名本身。下面的代码反映了这一点。验证完毕后,如果验证成功,就显示公文内容,用设定的图章作为签名档的显示外观。如果不失败,则在正常的公文显示上增加一个明显的失败标记。3.5.4之间部分加密加密XML文档加密的一个特点是可以对文档部分加密,比如我们可以只对公文的正文部分加密,让其他的部分仍为明文形式,这样就可以做到既有保密安全性,又易于检索、归档管理。正文加密后的公文形式如下