基于XML的密钥管理规范研究

2023-01-02

1 基于XML的密钥管理规范的实现

1.1 服务器端实现

在面向XML的密钥管理子层的服务器端的设计实现中, 最为关键的是对XKMS服务 (即密钥信息服务X-KISS和密钥注册服务X-KRSS) 的设计实现。至于密钥基础支撑层面, 我们在此不作详细的实现论述, 因为它是基于成熟的技术和C语言实现的, 是XKMS服务的基础支撑, 不是本论文的研究重点。XKMS服务器包括X-KISS服务器和X-KRSS服务器等。它们的实现基本上都遵循同样的操作步骤:第一步就是用X K MS Web服务的U R L创建一条传输通道, 如支持SOAP的传输。第二步就是创建一条请求信息, 然后通过传输通道发送给X K M S服务器。请求信息主要有:X K M-SLocate、XK MSV alidate、XK MSRegister、XKMSRevoke和XKMSRecovery。

1.1.1 X-K R SS服务器工作过程

密钥对可以在客户端产生, XKMS也支持在服务器端生成密钥对。由于密钥恢复、密钥废除和密钥注册的工作过程几乎是一样的, 所以下面重点从密钥注册的角度进行分析说明, 包括以下几个步骤: (1) 应用程序把瘦XKMS客户端嵌入到其中, 使用它来注册证书 (指密钥和相关的属性信息) 。 (2) 应用程序通过瘦XKMS客户端把“XKMS Register”请求发送给XKMS服务。 (3) XKMS服务器端收到“XKMS Register”请求之后, 就转交给核心PKI处理:执行标准的注册功能。 (4) XKMS服务器收到核心PKI的确认信息, 就把证书返回给终端用户或者应用程序。该证书是放在XKMS注册应答信息中的, 而消息是被XKMS服务器签名的。 (5) 客户端程序验证XKMS注册应答中的签名。然后采用标准的加密技术框架在本地保存证书。

1.1.2 X-K ISS服务器工作过程

应用程序中的标准加密功能可以检查签名的合法性, 例如用签名消息检查公钥的哈希值。为了检查签名的有效性, XKMS客户端需要检查证书本身的状态;也就是要验证证书本身是否合法有效。XKMS客户端先生成一个“XKMS Validate”请求, 发给XKMS服务。本质上是要求XKMS服务器去查出被验证者的证书状态。XKMS服务器收到“XKMS Validate”请求后, 执行一系列的验证任务。如果是X.509证书, 就会进行证书路径验证, 如从LDAP得到CRL, 检查OC SP, 策略映射等。这样, 证书状态就能被确定为合法、废除和冻结 (或者叫悬空) 三种状态的其中一种。最后XKMS服务器把被验证者的证书状态返回给客户端应用程序作为应答。在验证过程中, XKMS服务器需要做很多的验证步骤, 像访问不同的LDAP, 检查CRL等。对于客户端程序而言, 它所需要做的工作仅仅是请求XKMS服务器去验证而矣。所有困难的、繁琐的工作都由XKMS服务器去完成。如果是在传统的 (非XKMS) 的PKI应用模式中, 客户端需要自己直接去完成那一系列的验证任务。因此, XKMS服务模式充分减少了客户端的工作量, 提高了XKMS服务的易用性。检索 (Locate) 过程和验证过程基本一致。XKMS客户端先发送一条“XKMS Locate”请求给X K M S服务器。X K M S服务器从收到的“XKMS Locate”请求中取出客户的Email地址, 接着通过对不同的LDAP目录搜索, 找到与该特定Email地址相关联的证书。XKMS服务器找到证书后, 就返回“X KMS Locate”应答消息给客户端应用程序。这样检索者就可以使用该商业客户的公钥来加密在交易事务中需要保密的信息内容, 然后再使用检索者自己的私钥对加密后的消息进行签名操作。从前面的XKMS服务中的几个关键业务实现过程可以看出, XKMS服务模式确实是把诸如注册、验证和检索等复杂的PKI功能从客户端转移到了服务器端去实现。这样, XKMS服务器端的功能就由服务器端的各种业务组件去实现完成。所以客户端从此不再需要LDAP、OCSP和其他的需要直接操作的注册功能了。

1.2 客户端实现

1.2.1 SOA P传输通道的建立

在执行XKMS服务相关操作前, 第一步是用XKMS Web服务的URL来创建一条基于SO A P通信的传输通道。代码如下:X m l T r a n s p o r t S O A Pt r a n s p o r t=n e w XmlTransportSOA P (url) ;在传输通道创建成功之后, 向XKMS Web服务的请求就能利用它来实现。

1.2.2 密钥的注册

为了保证XKMS服务器上的每步操作有据可查以及系统本身的安全性, 所以XKMS服务器不接受没有签名的验证请求。因此, 在执行验证之前必须先注册一个密钥, 这样才能用所注册的密钥对验证请求进行签名。密钥的产生有两种情况:服务器端产生和客户端产生。它们各自的注册过程是不一样的。如果是客户端自己生成密钥, 采用带外数据共享秘密认证的办法来注册密钥, 注册成功就得到一个对应的密钥名称。这个密钥名称用于检索和验证。

1.2.3 检索

有些发给XKMS服务器的请求是必须签名的。例如某个密钥在私有的和未公开的权限空间中进行注册的, 要检索这样的密钥, 就必须对检索请求进行签名, 而该签名密钥也以同样的权限方式进行注册。所有来自XKMS服务器的响应都经过签名。因此, 收到XKMS服务器应答后, 需要对该消息的签名进行验证 (使用XML签名API) 。

1.2.4 验证

验证密钥和检索密钥很相似。区别在于验证响应包含了被确认的密钥的状态信息。在请求中还可以声明需要验证哪些数据项。例如:String responses[]={“KeyN ame”, “K eyV a lue”, “V alid ityInter val”, “KeyUsage”, “Status”}。

通过上面的语句可以要求验证密钥名称、密钥值、有效期、密钥使用和状态等信息。验证请求必须是签名的。如果还没有签名私钥, 需要生成一个密钥对, 在XKMS上注册公钥, 再使用私钥对验证消息签名。

2 结语

XML密钥管理 (X KMS) 支持新出现的PKI应用开发, 因为未来的PK I应用发展趋势之一是复杂繁重的实现向基于服务端的组件模式发展。这种发展趋势正是XKMS实现的基本出发点, 所以我们说XKMS能适应未来的PKI应用开发。

摘要:本文研究了XKMS的具体实现, 通过对XKMS服务器端 (即XML密钥信息服务规范X-KISS和XML密钥注册服务规范X-KRSS) 和客户端的设计, 实现密钥注册、验证、签名等功能。

关键词:Web服务,XML安全,公钥基础设施,密钥管理规范

参考文献

[1] Mack Hendricks, Ben Galbraith, 等.Java Web服务编程指南[M].北京:电子工业出版社, 2002.

[2] Srinivas.Network and Web Services Security Concepts Using Java[C].Pro-ceedings of Web Congress, 2003:238~238.

上一篇:检验申请单设计的建议和改进措施下一篇:老年糖尿病患者护理干预效果的临床观察