CN110719174B - 基于Ukey的证书签发方法 - Google Patents

Abstract

本申请实施例公开了一种基于电子钥匙Ukey的证书签发方法。该方法包括：证书颁发机构CA接收Ukey发送的终端设备的第一证书请求和第一证书请求签名，第一证书请求签名为该第一证书请求经过Ukey的私钥签名后得到的数字签名；通过第一列表验证该第一证书请求签名，该第一列表包括多个Ukey各自对应的第二证书，第二证书为CA对Ukey发送的第二证书请求生成的证书；在第一证书请求签名验证通过的情况下，对第一证书请求生成终端设备证书，并发送给对应Ukey，以使Ukey将终端设备证书发送给对应终端设备。采用本申请实施例，能够保证证书签发过程所涉及的Ukey和CA的可信任性，以确保整个签发过程的安全性和可靠性。

Description

基于Ukey的证书签发方法

技术领域

本申请涉及信息安全领域，尤其涉及一种基于Ukey的证书签发方法、相关装置及系统。

背景技术

互联网时代，网络信息安全问题已经成为了我国乃至全世界社会关注的焦点，数字证书作为互联网或实际应用中用户终端的“身份证”，其证书签发的安全性和可靠性也受到广泛关注。

数字证书由证书颁发机构(Certificate Authority，CA)颁发，在数字证书签发认证的过程中，CA作为权威的、公正的、可信赖的第三方，其作用是至关重要的；CA就是一个负责发放和管理数字证书的权威机构，而注册审批系统 (Registration Authority，RA)是CA证书发放、管理的延伸，负责证书申请者信息的录入、审核以及证书发放等工作，同时，对发放的证书完成相应的管理功能，发放的数字证书可以存放于硬盘或软盘等介质中，RA作为CA认证体系的一部分，是整个CA中心得以正常运营不可缺少的一部分。

用烧录工具获取数字证书时一般使用账号密码或者电子钥匙(USB key， Ukey)来做登录的权限管理，使用账号密码登录可能存在账号被盗的风险；Ukey 是一种通用串行总线(Universal Serial Bus，USB)接口设备，可以存储用户的密钥或者数字证书，有数字签名、数据加解密、存储证书等功能，但现有使用 Ukey申请数字证书及CA签发数字证书的过程可能发生数据泄露、违法冒用的情况，仍存在安全隐患、不可信性和不可靠性。

发明内容

本申请实施例公开了一种基于Ukey的证书签发方法、相关装置及系统，能够增强证书签发过程的安全性和可靠性，以及签发过程中涉及装置的可信任性。

第一方面，本申请实施例提供了一种基于Ukey的证书签发方法，包括：接收Ukey发送的终端设备的第一证书请求和第一证书请求签名，上述第一证书请求签名为上述第一证书请求经过Ukey的私钥签名后得到的数字签名；通过第一列表验证上述第一证书请求签名，该第一列表包括多个Ukey各自对应的第二证书，上述第二证书为CA对Ukey发送的第二证书请求签发的数字证书；在第一证书请求签名验证通过的情况下，对第一证书请求生成终端设备证书，并发送给Ukey，以使Ukey将该终端设备证书发送给对应终端设备。

在上述方法中，终端设备的第一证书请求需经过Ukey的私钥签名后得到第一证书请求签名，再将第一证书请求和第一证书请求发给CA，而Ukey的私钥是无法导出的，因此增强了数据传输的安全性；同时CA会对第一证书请求签名验证，验证通过的情况下，才会对第一证书请求生成终端设备证书并发送给Ukey，因此保证签发过程中使用的是CA验证通过的可信任Ukey。

在第一方面的一种可选方案中，上述接收Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，上述方法还包括：接收Ukey发送的第二证书请求；对上述第二证书请求生成第二证书，并在第一列表中添加上述第二证书；发送上述第二证书给上述Ukey。

在上述方法中，CA接收终端设备的证书请求前，需生成可信任的Ukey，即对Ukey发送的第二证书请求验证并生成了第二证书，同时在第一列表中添加了该第二证书，至此CA的第一列表中就记录了多个Ukey对应的第二证书；后续Ukey发送的第一证书请求签名都需通过第一列表中对应该Ukey的第二证书验证，验证通过才能签发终端设备的证书，保证了证书签发过程中使用的是经 CA记录和验证过的可信任Ukey。

在第一方面的又一种可选方案中，上述对上述第二证书请求生成第二证书，并在第一列表中添加上述第二证书之后，上述接收Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，该方法还包括：发送CA的公钥给上述Ukey；上述在第一证书请求签名验证通过的情况下，该方法还包括：发送CA的私钥签名至上述Ukey，以使上述Ukey使用上述CA的公钥验证上述CA的私钥签名。

如上述方法描述，在第一证书请求签名验证通过的情况下，CA不仅会发送终端设备证书，还会发送自身的私钥签名给Ukey，Ukey收到后会使用上述CA 的公钥对该CA的私钥签名进行验证，上述CA的公钥是Ukey接收CA发送的第二证书时一同接收的，验证通过的情况下Ukey才会将终端设备证书发给终端设备；因此保证了签发终端设备证书的CA是经过Ukey验证过的可信任CA，增强了证书签发过程的可信任性和可靠性。

在第一方面的又一种可选方案中，对上述第二证书请求生成第二证书，并在第一列表中添加上述第二证书，包括：验证登录CA的后台所使用的Ukey是否有管理员权限；若上述登录CA的后台所使用的Ukey有管理员权限，则对上述第二证书请求生成第二证书，并在第一列表中添加上述第二证书；若上述登录CA的后台所使用的Ukey没有管理员权限，则结束操作。

在上述方法中，只有使用有管理员权限的Ukey登录CA的后台的操作人员才能在第一列表中添加第二证书，对登录CA的后台的操作人员有严格的权限控制，让证书签发过程更为安全可靠。

在第一方面的又一种可选方案中，通过第一列表验证上述第一证书请求签名，包括：查询上述第一列表，确认发送上述第一证书请求和上述第一证书请求签名的Ukey对应的第二证书是否存在；若上述第二证书存在，则使用上述第二证书验证上述第一证书请求签名；若上述第二证书不存在，则验证不通过。

在上述方法中，第一列表中包括多个Ukey各自对应的第二证书，首先需要确认第一列表中发送证书请求的Ukey对应的第二证书，然后使用上述第二证书去验证上述对应Ukey发送的第一证书请求签名，验证通过才会签发终端设备证书，这样就可以追溯到签发的终端设备证书是使用哪个Ukey申请的，Ukey和终端设备证书具有一一对应关系，使得Ukey和终端设备证书的管理更为便捷简单。

在第一方面的又一种可选方案中，第一证书请求为终端设备的非对称密钥对生成的证书请求，第二证书请求为Ukey的非对称密钥对生成的证书请求。

在上述方法中，采用安全性较高的非对称密钥对来生成证书请求，增强证书签发过程中数据传输的安全性和完整性。

第二方面，本申请实施例提供了一种基于Ukey的证书签发方法，包括：接收终端设备发送的第一证书请求；通过Ukey的私钥对上述第一证书请求签名，得到第一证书请求签名；发送上述第一证书请求和上述第一证书请求签名给CA；接收该CA签发的终端设备证书，该终端设备证书是该CA通过第一列表验证上述第一证书请求签名通过的情况下签发的数字证书，上述第一列表包括多个 Ukey各自对应的第二证书，上述第二证书为该CA对Ukey发送的第二证书请求生成的数字证书；发送上述终端设备证书给对应终端设备。

在上述方法中，终端设备的第一证书请求需经过Ukey的私钥签名后得到第一证书请求签名，再将第一证书请求和第一证书请求发给CA，而Ukey的私钥是无法导出的，因此增强了数据传输的安全性；同时CA会对第一证书请求签名验证，验证通过的情况下，才会对第一证书请求生成终端设备证书并发送给Ukey，因此保证签发过程中使用的是CA验证通过的可信任Ukey。

在第二方面的一种可选方案中，上述接收终端设备发送的第一证书请求之前，上述方法还包括：使用非对称密钥对生成第二证书请求；向CA发送上述第二证书请求；接收上述CA发送的第二证书。

在第二方面和第二方面的一种可选方案描述的方法中，CA接收终端设备的证书请求前，需生成可信任的Ukey，即Ukey生成并发送第二证书请求给CA，CA生成对应第二证书请求的第二证书，并添加到第一列表中，至此CA的第一列表中就记录了多个Ukey对应的第二证书，后续Ukey发送的第一证书请求签名都需通过第一列表中对应该Ukey的第二证书验证，验证通过才能签发终端设备的证书，不仅保证了证书签发过程中使用的是经CA记录和验证过的可信任 Ukey，而且可以追溯到签发的终端设备证书是使用哪个Ukey申请的，让Ukey 和终端设备证书的管理更为便捷简单。

在第二方面的又一种可选方案中，上述向CA发送第二证书请求之后，上述接收终端设备发送的第一证书请求之前，上述方法还包括：接收CA的公钥；上述发送第一证书请求和第一证书请求签名给CA之后，上述发送终端设备证书给对应终端设备之前，上述方法还包括：接收CA的私钥签名，以便使用上述CA 的公钥验证上述CA的私钥签名。

在上述方法中，Ukey在接收CA发送的第二证书的同时会接收CA的公钥，上述CA的公钥用于验证CA发送给Ukey的私钥签名，若CA的公钥验证CA 的私钥签名通过，Ukey才会将终端设备证书发给对应终端设备，否则不予签发；因此保证了签发终端设备证书的CA是经过Ukey验证过的可信任CA，增强了证书签发过程的可信任性和可靠性。

在第二方面的又一种可选方案中，第一证书请求为终端设备的非对称密钥对生成的证书请求，第二证书请求为Ukey的非对称密钥对生成的证书请求。

在上述方法中，采用安全性较高的非对称密钥对来生成证书请求，增强证书签发过程中数据传输的安全性和完整性。

第三方面，本申请实施例提供了一种CA，包括：第一接收单元，用于接收 Ukey发送的终端设备的第一证书请求和第一证书请求签名，上述第一证书请求签名为上述第一证书请求经过Ukey的私钥签名后得到的数字签名；第一验证单元，用于通过第一列表验证上述第一证书请求签名，上述第一列表包括多个Ukey 各自对应的第二证书，该第二证书为CA对Ukey发送的第二证书请求签发的数字证书；生成发送单元，用于在上述第一证书请求签名验证通过的情况下，对第一证书请求生成终端设备证书，并发送给Ukey，以使Ukey将该终端设备证书发送给对应终端设备。

在第三方面的一种可选方案中，上述CA还包括第二接收单元、生成添加单元和第一发送单元；第二接收单元，用于在上述第一接收单元接收Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，接收Ukey发送的第二证书请求；生成添加单元，用于对第二证书请求生成第二证书，并在第一列表中添加上述第二证书；第一发送单元，用于发送上述第二证书给上述Ukey。

在第三方面的又一种可选方案中，上述CA还包括第二发送单元；第二发送单元，用于在上述生成添加单元对第二证书请求生成第二证书，并在第一列表中添加上述第二证书之后，上述第一接收单元接收所述Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，发送CA的公钥给Ukey；上述CA还包括第三发送单元；第三发送单元，用于在上述第一证书请求签名验证通过的情况下，发送CA的私钥签名至Ukey，以使Ukey使用CA的公钥验证CA的私钥签名。

在第三方面的又一种可选方案中，上述生成添加单元包括：验证子单元，用于验证登录CA的后台所使用的Ukey是否有管理员权限；生成添加子单元，用于若上述登录CA的后台所使用的Ukey有管理员权限，则对第二证书请求生成第二证书，并在第一列表中添加上述第二证书。

在第三方面的又一种可选方案中，上述第一验证单元包括：查询确认子单元，用于查询第一列表，确认发送第一证书请求和第一证书请求签名的Ukey对应的第二证书是否存在；第二验证子单元，用于在上述第二证书存在的情况下，使用上述第二证书验证上述第一证书请求签名。

在第三方面的又一种可选方案中，第一证书请求为终端设备的非对称密钥对生成的证书请求，第二证书请求为Ukey的非对称密钥对生成的证书请求。

第四方面，本申请实施例提供了一种Ukey，包括：第一接收单元，用于接收终端设备发送的第一证书请求；签名单元，用于通过Ukey的私钥对上述第一证书请求签名，得到第一证书请求签名；第一发送单元，用于发送上述第一证书请求和上述第一证书请求签名给CA；第二接收单元，用于接收该CA签发的终端设备证书，该终端设备证书是该CA通过第一列表验证上述第一证书请求签名通过的情况下签发的数字证书，上述第一列表包括多个Ukey各自对应的第二证书，上述第二证书为该CA对Ukey发送的第二证书请求生成的数字证书；第二发送单元，用于发送上述终端设备证书给对应终端设备。

在第四方面的一种可选方案中，上述Ukey还包括生成单元，第三发送单元和第三接收单元；生成单元，用于在上述第一接收单元接收终端设备发送的第一证书请求之前，使用非对称密钥对生成第二证书请求；第三发送单元，用于向CA发送上述第二证书请求；第三接收单元，用于接收上述CA发送的第二证书。

在第四方面的又一种可选方案中，上述Ukey还包括第四接收单元；第四接收单元，用于在上述第三发送单元向CA发送第二证书请求之后，上述第一接收单元接收终端设备发送的第一证书请求之前，接收CA的公钥；上述Ukey还包括接收验证单元；接收验证单元，用于在上述第一发送单元发送第一证书请求和第一证书请求签名给CA之后，上述第二发送单元发送终端设备证书给对应终端设备之前，接收CA的私钥签名，以便使用上述CA的公钥验证上述CA的私钥签名。

在第四方面的又一种可选方案中，第一证书请求为终端设备的非对称密钥对生成的证书请求，第二证书请求为Ukey的非对称密钥对生成的证书请求。

第五方面，本申请实施例提供了一种CA，包括存储器、处理器以及存储在所述存储器中并可在上述处理器上运行的计算机程序，上述处理器执行上述计算机程序时实现如上述第一方面提供的基于Ukey的证书签发方法。

第六方面，本申请实施例提供了一种Ukey，包括存储器、处理器以及存储在所述存储器中并可在上述处理器上运行的计算机程序，上述处理器执行上述计算机程序时实现如上述第二方面提供的基于Ukey的证书签发方法。

第七方面，本申请实施例提供了一种基于Ukey的证书签发系统。该证书签发系统包括CA、Ukey以及终端设备；其中，上述CA为第三方面，或第三方面的任意一种可能的实现方式所描述的CA；上述Ukey为第四方面，或第四方面的任意一种可能的实现方式所描述的CA；上述终端设备为任意一种可导入数字证书的设备，数字证书的用途包括但不限于：身份认证、加密传输信息和数字签名抗否认等等。

第八方面，本申请实施例提供了一种计算机存储介质，包括计算机指令，当该计算机指令在电子设备上运行时，使得该电子设备执行本申请实施例第一方面或第一方面的任意一种实现方式提供的基于Ukey的证书签发方法。

第九方面，本申请实施例提供了一种计算机存储介质，包括计算机指令，当该计算机指令在电子设备上运行时，使得该电子设备执行本申请实施例第二方面或第二方面的任意一种实现方式提供的基于Ukey的证书签发方法。

第十方面，本申请实施例提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行本申请实施例第一方面或第一方面的任意一种实现方式提供的基于Ukey的证书签发方法。

第十一方面，本申请实施例提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行本申请实施例第二方面或第二方面的任意一种实现方式提供的基于Ukey的证书签发方法。

可以理解地，上述提供的第三方面提供的CA、第五方面提供的CA、第八方面提供的计算机存储介质，以及第十方面提供的计算机程序产品均用于执行第一方面所提供的基于Ukey的证书签发方法，因此，其所能达到的有益效果可参考第一方面所提供的基于Ukey的证书签发方法中的有益效果，此处不再赘述。

可以理解地，上述提供的第四方面提供的Ukey、第六方面提供的Ukey、第九方面提供的计算机存储介质，以及第十一方面提供的计算机程序产品均用于执行第二方面所提供的基于Ukey的证书签发方法，因此，其所能达到的有益效果可参考第二方面所提供的基于Ukey的证书签发方法中的有益效果，此处不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种基于Ukey的证书签发系统的架构示意图；

图2是本申请实施例提供的一种基于Ukey的证书签发方法的流程示意图；

图3是本申请实施例提供的一种生成可信任Ukey方法的流程示意图；

图4是本申请实施例提供的又一种基于Ukey的证书签发方法的流程示意图；

图5是本申请实施例提供的又一种生成可信任Ukey方法的流程示意图；

图6是本申请实施例提供的又一种基于Ukey的证书签发方法的流程示意图；

图7是本申请实施例提供的一种CA的结构示意图；

图8是本申请实施例提供的一种Ukey的结构示意图；

图9是本申请实施例提供的又一种CA的结构示意图；

图10是本申请实施例提供的又一种Ukey的结构示意图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行描述。

请参见图1，图1是本申请实施例提供的一种基于Ukey的证书签发系统的架构示意图，该系统包括CA101，Ukey102及终端设备103；其中上述终端设备 103的数量大于等于N，上述Ukey102的数量大于等于N，N为正整数，颁发给一个终端设备103的数字证书，只能由一个Ukey102向CA101申请签发， Ukey102和终端设备103的数字证书是一一对应关系，也就是Ukey102和终端设备103是一一对应关系；上述CA101可以对上述多个Ukey102发送的证书请求文件生成并添加数字证书，即CA101内部可包含多个Ukey102各自对应的数字证书。

上述CA101可以是能够颁发和管理数字证书的计算机、终端、服务器，不限于此；上述Ukey102可以是通过USB直接与计算机相连、具有密码验证功能的小型存储设备，或是带有安全芯片的数字证书的硬件载体，不限于此；上述终端设备为任意一种可导入数字证书的设备，数字证书的用途包括但不限于：身份认证、加密传输信息和数字签名抗否认等等。

请参见图2，图2是本申请实施例提供的一种基于Ukey的证书签发方法的流程示意图，该方法可以由图1所述的证书签发系统中的CA101来实现，该方法包括但不限于如下步骤：

步骤S201：接收Ukey发送的终端设备的第一证书请求和第一证书请求签名。

具体地，第一证书请求是终端设备使用非对称加密算法创建非对称密钥对，并用非对称密钥对生成的证书签发请求。上述非对称加密算法可包括但不限于： Elgamal算法(一种非对称加密算法)、Rabin算法(一种非对称加密算法)、 Diffie-Hellman算法(一种非对称加密算法)、ECC算法(椭圆曲线加密算法)。上述证书签发请求(Certificate SigningRequest，CSR)是一个发送到CA的请求认证信息，CA对CSR生成的数字证书的常见标准包括但不限于PKI ITU-T X509 标准、PKCS#7加密消息语法标准、PKCS#10证书请求标准和PKCS#12个人信息交换标准等等，当前应用较为广泛的是由PKCS#10证书请求标准定义的，与之对应的CSR可以称之为P10请求，在PKCS#10定义中，CSR有两种编码格式：二进制和文本格式。

上述第一证书请求签名是经过Ukey的私钥对第一证书请求签名后得到的数字签名，需要使用对应Ukey的公钥才能成功解密该第一证书请求签名。数字签名可以理解为附加在数据单元上的一些数据,或是对数据单元所作的密码变换，这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据,防止被人进行伪造。进行数字签名需要使用签名算法，此处的签名算法可以包括但不限于：RSA(一种签名算法)、DSA(一种签名算法)、 ECDSA(一种签名算法)，等等。

步骤S202：通过第一列表验证所述第一证书请求签名。

具体地，CA的第一列表包括多个Ukey的标识信息及各自对应的第二证书，已知发送第一证书请求和第一证书请求签名的Ukey的标识信息，即可在CA的第一列表中确认对应的第二证书是否存在，这个确认的具体执行可根据需求自行选择，如通过人工或计算机程序在CA后台的第一列表中直接查询。

上述的第二证书为CA对Ukey发送的第二证书请求生成的数字证书，数字证书的常见标准包括但不限于PKI ITU-T X509标准、PKCS#7加密消息语法标准、PKCS#10证书请求标准和PKCS#12个人信息交换标准等等，当前应用较为广泛的是由PKCS#10证书请求标准定义的，数字证书的用途包括但不限于：身份认证、加密传输信息和数字签名抗否认等等。

此处的第二证书请求是Ukey使用非对称加密算法创建非对称密钥对，并用非对称密钥对生成的证书签发请求。上述非对称加密算法可包括但不限于： Elgamal算法(一种非对称加密算法)、Rabin算法(一种非对称加密算法)、 Diffie-Hellman算法(一种非对称加密算法)、ECC算法(椭圆曲线加密算法)。上述证书签发请求(Certificate SigningRequest，CSR)是一个发送到CA的请求认证信息，CA对CSR生成的数字证书的常见标准包括但不限于PKI ITU-T X509 标准、PKCS#7加密消息语法标准、PKCS#10证书请求标准和PKCS#12个人信息交换标准等等，当前应用较为广泛的是由PKCS#10证书请求标准定义的，与之对应的CSR可以称之为P10请求，在PKCS#10定义中，CSR有两种编码格式：二进制和文本格式。

若所述Ukey对应的第二证书存在，则使用对应带有所述Ukey公钥的第二证书验证第一证书请求签名。

在步骤S201所示方法的基础上，示例描述一种通过第一列表验证第一证书请求签名的过程，需要说明的是该示例仅为步骤201一种可能的实现方式，不限于此。

现在CA的第一列表已有的证书记录如表1所示。

表1CA的第一列表

Ukey的标识信息	第二证书
		11AA	A
22BB	B
		33CC	C

现接收到一个Ukey发送的第一证书请求和第一证书签名，已知该Ukey的标识信息为22BB，查看第一列表，确认具有标识信息22BB的Ukey对应的第二证书为B，使用证书B验证第一证书请求签名，验证方式可以是使用证书B 的公钥解密第一证书请求签名，将解密结果与第一证书请求进行对比，如果结果相同则验证通过，如果结果不同则验证失败，不限于此。

步骤S203：在第一证书请求签名验证通过的情况下，对第一证书请求生成终端设备证书，发送终端设备证书和CA的私钥签名给Ukey；验证不通过的情况下，结束操作。

具体地，终端设备证书为CA对第一证书请求生成的数字证书，数字证书的常见标准包括但不限于PKI ITU-T X509标准、PKCS#7加密消息语法标准、 PKCS#10证书请求标准和PKCS#12个人信息交换标准等等，当前应用较为广泛的是由PKCS#10证书请求标准定义的，数字证书的用途包括但不限于：身份认证、加密传输信息和数字签名抗否认等等。

CA的私钥签名即为CA自身私钥生成的数字签名，数字签名可以理解为附加在数据单元上的一些数据,或是对数据单元所作的密码变换，这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据,防止被人进行伪造。进行数字签名需要使用签名算法，此处的签名算法可以包括但不限于：RSA(一种签名算法)、DSA(一种签名算法)、ECDSA(一种签名算法)，等等。

请参见图3，图3是本申请实施例提供的一种生成可信任Ukey方法的流程示意图，该方法可以由图1所述的证书签发系统中的CA101来实现，该方法在图2描述的证书签发方法之前实行，包括但不限于如下步骤：

步骤S301：接收Ukey发送的第二证书请求。

具体地，第二证书请求的说明可参照图2的步骤S202中的相关描述。

步骤S302：对第二证书请求生成第二证书，并在第一列表中添加第二证书，发送第二证书和CA的公钥给Ukey。

具体地，第二证书请求中包含了Ukey的标识信息，不同Ukey的标识信息不一样，只要知道标识信息就能对应到唯一的Ukey，上述第一列表包括多个 Ukey的标识信息及各自对应的第二证书，只要知道Ukey的标识信息，就可在第一列表中确认到对应的第二证书。

CA对第二证书请求生成第二证书，并在第一列表中添加该第二证书前先要验证登录CA后台所使用的Ukey是否有管理员权限，这里的Ukey是专门对登录CA后台的操作人员做权限控制的，不用做证书签发。若登录CA后台所使用的Ukey有管理员权限，则对所述第二证书请求生成第二证书，并在第一列表中添加所述第二证书；若登录所述CA的后台所使用的Ukey没有管理员权限，则结束操作。

CA生成第二证书并添加到第一列表后，发送所述第二证书和CA的公钥至对应的Ukey，不仅让CA侧有可信任Ukey的信息记录，而且让可信任Ukey保存有可信任CA的公钥。

在步骤S302所示方法的基础上，示例描述一种对第二证书请求生成第二证书，并在第一列表中添加第二证书的过程，需要说明的是该示例仅为步骤302 一种可能的实现方式，不限于此。

上述表1已示例性示出一种第一列表的存储形式，以此为当前第一列表的状态，详细见表1，需要说明的是该示例仅为第一列表的一种可能存储形式，不限于此。

现接收到一个Ukey发送的第二证书请求，该第二证书请求中包含该Ukey 的标识信息，为44DD，可以看到当前第一列表并无标识信息为44DD的Ukey 的记录，对该第二证书请求生成第二证书D，并将第二证书D添加到第一列表中，表2为添加第二证书D后的第一列表,如表2所示。

表2添加第二证书D后的第一列表

Ukey的标识信息	第二证书
		11AA	A
22BB	B
		33CC	C
44DD	D

CA添加第二证书D到第一列表后，发送第二证书D和CA的公钥给标识信息为44DD的Ukey。

验证登录CA后台所使用的Ukey是否有管理员权限的方法可以是CA后台存储有Ukey的标识信息以及对应的登录权限，查看登录CA后台的Ukey的标识信息并用其查询对应的登录权限是否为管理员权限，不限于此。

在上述实施例中，图3描述的生成可信任Ukey方法可以理解为图2描述的证书签发方法的基础。如图3描述的证书签发方法，Ukey会对终端设备的证书请求进行私钥签名得到证书请求签名，CA会使用图3描述的生成可信任Ukey 方法的第一列表中对应Ukey的第二证书对该证书请求签名进行验证，验证通过才会给Ukey签发终端设备证书，因此保证使用的Ukey是CA记录认证的可信任Ukey，同时使用私钥签名加强数据传输的安全性，以此确保整个证书签发过程的安全可靠性。

请参见图4，图4是本申请实施例提供的又一种基于Ukey的证书签发方法的流程示意图，该方法可以由图1所述的证书签发系统中的Ukey102来实现，该方法包括但不限于如下步骤：

步骤S401：接收终端设备发送的第一证书请求。

具体地，第一证书请求的说明可参照图2的步骤S201中的相关描述。

步骤S402：通过自身私钥对第一证书请求签名，得到第一证书请求签名，发送第一证书请求和第一证书请求签名给CA。

具体地，第一证书请求签名的说明可参照图2的步骤S201中的相关描述。

步骤S403：使用CA的公钥验证CA的私钥签名，验证通过后发送终端设备证书给终端设备，验证不通过则结束操作。

具体地，Ukey使用CA公钥对CA的私钥签名进行验证，验证通过的情况下，认为发送终端设备证书的CA是可信任的，则发送终端设备证书给终端设备；若验证不通过，认为发送终端设备证书的CA是不可信任的，则结束操作。

请参见图5，图5是本申请实施例提供的又一种生成可信任Ukey方法的流程示意图，该方法可以由图1所述的证书签发系统中的Ukey102来实现，该方法在图4描述的证书签发方法之前执行，包括但不限于如下步骤：

步骤S501：Ukey使用非对称密钥对生成第二证书请求，并向CA发送第二证书请求。

具体地，第二证书请求的说明可参照图2的步骤S202的相关描述。

步骤S502：接收CA发送的第二证书和CA的公钥。

具体地，Ukey接收并存储CA的公钥，以便后续验证签发终端设备证书的 CA是否为可信任的CA。

在上述实施例中，图5描述的生成可信任Ukey方法可以理解为图4描述的证书签发方法的基础。如图4描述的证书签发方法，Ukey会对终端设备的证书请求进行私钥签名得到证书请求签名，CA会使用图5描述的生成可信任Ukey 方法的第一列表中对应Ukey的第二证书对该证书请求签名进行验证，验证通过才会给Ukey签发终端设备证书，因此保证使用的Ukey是CA记录认证的可信任Ukey，同时使用私钥签名加强数据传输的安全性，以此确保整个证书签发过程的安全可靠性。

请参见图6，图6是本申请实施例提供的又一种基于Ukey的证书签发方法的流程示意图，该方法可以基于图1所示的证书签发系统来实现，该方法主要分为两个过程：生成可信任Ukey和终端设备申请证书，具体，包括但不限于以下步骤：

生成可信任Ukey的过程主要包括以下S601至S603。

步骤S601：Ukey生成第二证书请求，并发送第二证书请求至CA。

具体地，第二证书请求的生成可参照图3所述方法步骤S301的相关描述，这里不再赘述。

步骤S602：CA对第二证书请求生成第二证书，并在第一列表中添加所述第二证书，发送所述第二证书及CA的公钥至Ukey。

具体地，上述第二证书请求中包含了Ukey的标识信息，不同Ukey的标识信息不一样，只要知道标识信息就能对应到唯一的Ukey，第一列表包括多个 Ukey的标识信息及各自对应的第二证书，只要知道Ukey的标识信息，就可在第一列表中确认到对应的第二证书。

CA对第二证书请求生成第二证书，并在第一列表中添加该第二证书前先要验证登录CA后台所使用的Ukey是否有管理员权限，这里的Ukey是专门对登录CA后台的操作人员做权限控制的，不用做证书签发。若登录CA后台所使用的Ukey有管理员权限，则对上述第二证书请求生成第二证书，并在第一列表中添加该第二证书；若登录CA的后台所使用的Ukey没有管理员权限，则结束操作。

CA生成第二证书并添加到第一列表后，发送该第二证书和CA的公钥至对应的Ukey，不仅让CA侧有可信任Ukey的证书记录，而且让可信任Ukey保存有该可信任CA的公钥。

步骤S603：Ukey接收第二证书和CA的公钥。

具体地，Ukey接收并存储CA的公钥，以便后续验证签发终端设备证书的 CA是否为可信任的CA。

终端设备申请证书的过程主要包括以下S604至S608。

步骤S604：终端设备生成第一证书请求，并发送第一证书请求至Ukey。

具体地，第一证书请求的生成可参照图4所述方法步骤S401的相关描述，这里不再赘述。

步骤S605：Ukey通过自身私钥对第一证书请求签名，得到第一证书请求签名，并发送第一证书请求和第一证书请求签名至CA。

具体地，Ukey对第一证书请求签名采用的签名算法可参照图2所述方法步骤S201的相关描述，这里不再赘述。

步骤S606：CA通过第一列表验证接收的第一证书请求签名，验证通过后对第一证书请求生成终端设备证书，并发送终端设备证书和CA的私钥签名给 Ukey。

具体地，Ukey发送的第一证书请求签名是通过Ukey自身私钥对第一证书请求签名后得到的数字签名，需要使用对应Ukey的公钥才能成功解密该第一证书请求签名。CA的第一列表包括多个Ukey的标识信息及各自对应的第二证书，已知发送第一证书请求和第一证书请求签名的Ukey的标识信息，即可在CA的第一列表中确认对应的第二证书是否存在，这个确认的具体执行可以是通过人工或计算机程序直接在CA后台的第一列表中查询，不限于此。

若Ukey对应的第二证书存在，则使用带有Ukey公钥的对应的第二证书验证第一证书请求签名，验证通过则对第一证书请求生成终端设备的数字证书，并发送终端设备证书和CA的私钥签名给Ukey；若Ukey对应的第二证书不存在，则认为验证不通过，结束操作。

CA的私钥签名采用的签名算法可参照图2所述方法步骤S203的相关描述，这里不再赘述。

步骤S607：Ukey使用CA的公钥验证CA的私钥签名，验证通过后发送终端设备证书给终端设备。

具体地，Ukey使用步骤S603预置的CA的公钥对CA的私钥签名进行验证，验证通过的情况下，认为发送终端设备证书的CA是可信任的，则发送终端设备证书给终端设备；若验证不通过，认为发送终端设备证书的CA是不可信任的，则结束操作。

步骤S608：终端设备接收Ukey发送的终端设备证书。

具体地，终端设备接收终端设备证书并导入到内部的存储单元，至此完成了整个证书申请的过程。

需要说明的是，在本申请实施例提供的方法执行过程中，都需要使用到可信任的Ukey，若中途Ukey拔出会出现证书请求签名失败等情况从而终止证书申请过程，所以上述方法执行过程中需要保证Ukey一直连接。

在本实施例提供的方法中，终端设备的证书请求都需经过可信任Ukey的私钥签名，而Ukey的私钥是无法导出的，让数据传输更加安全；并且，Ukey发送的第一证书请求签名都需经过第一列表中对应Ukey的第二证书验证，验证通过才签发终端设备证书，保证证书签发过程中使用的是可信任的Ukey；同时， Ukey使用预置存储的CA的公钥对CA的私钥签名进行验证，验证通过才发送终端设备证书给终端设备，保证签发终端设备证书的是可信任的CA。

一种可能的实现方式，CA签发的终端设备证书在CA后台存有终端设备证书记录，该记录包括但不限于：标识终端设备唯一性的序列号，证书签发时间，证书有效期开始时间，证书有效期结束时间，申请终端设备证书的Ukey的标识信息等等。若发行公布的终端设备，其序列号非生产终端设备机构记录的可发行公布的设备序列号，则可以在CA的后台查询终端设备证书记录，使用该终端设备的序列号和证书签发时间找到该终端设备的相关记录，确认证书签发时间是否为允许申请证书的时间，以及申请证书的Ukey是否为可信任Ukey的标识信息，若不是允许申请证书的时间和可信任Ukey的标识信息，可以对此终端设备证书进行注销，从而保证了签发终端设备证书的终端设备都是可信任并且有效的。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面提供了本申请实施例的装置。

请参见图7，图7是本申请实施例提供的一种CA的结构示意图，该CA可以包括第二接收单元701、生成添加单元702，第一发送单元703、第二发送单元704、第一接收单元705、第一验证单元706、生成发送单元707和第三发送单元708，其中，各个单元的详细描述如下：

第一接收单元705，用于接收Ukey发送的终端设备的第一证书请求和第一证书请求签名，该第一证书请求签名为上述第一证书请求经过Ukey的私钥签名后得到的数字签名；第一验证单元706，用于通过第一列表验证上述第一证书请求签名，上述第一列表包括多个Ukey各自对应的第二证书，该第二证书为CA 对Ukey发送的第二证书请求签发的数字证书；生成发送单元707，用于在第一证书请求签名验证通过的情况下，对第一证书请求生成终端设备证书，并发送给对应Ukey，以使Ukey将上述终端设备证书发送给对应终端设备。

作为一种可选的实施方式，第二接收单元701，用于在上述第一接收单元 705接收Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，接收 Ukey发送的第二证书请求；生成添加单元702，用于对上述第二证书请求生成第二证书，并在第一列表中添加该第二证书；第一发送单元703，用于发送第二证书给对应Ukey。

作为一种可选的实施方式，第二发送单元704，用于在上述生成添加单元702对第二证书请求生成第二证书，并在第一列表中添加第二证书之后，上述第一接收单元705接收Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，发送CA的公钥给Ukey；第三发送单元708，用于在第一证书请求签名验证通过的情况下，发送CA的私钥签名至Ukey，以使该Ukey使用CA的公钥验证CA的私钥签名。

作为一种可选的实施方式，上述生成添加单元包括：验证子单元，用于验证登录CA的后台所使用的Ukey是否有管理员权限；生成添加子单元，用于在上述登录所述CA的后台所使用的Ukey有管理员权限的情况下，对第二证书请求生成第二证书，并在第一列表中添加该第二证书。

作为一种可选的实施方式，上述第一验证单元包括：查询确认子单元，用于查询第一列表，确认发送第一证书请求和第一证书请求签名的Ukey对应的第二证书是否存在；第二验证子单元，用于在上述第二证书存在的情况下，使用该第二证书验证上述第一证书请求签名。

需要说明的是，在本申请实施例中，各个单元的具体实现还可以对应参照图2和图3所示的方法实施例的相应描述。

请参见图8，图8是本申请实施例提供的一种Ukey的结构示意图，该Ukey 可以包括生成单元801、第三发送单元802、第三接收单元803、第四接收单元 804、第一接收单元805、签名单元806、第一发送单元807、第二接收单元808、接收验证单元809和第二发送单元810，其中，各个单元的详细描述如下：

第一接收单元805，用于接收终端设备发送的第一证书请求；签名单元806，用于通过Ukey的私钥对第一证书请求签名，得到第一证书请求签名；第一发送单元807，用于发送第一证书请求和第一证书请求签名给CA；第二接收单元808，用于接收CA签发的终端设备证书，该终端设备证书是CA通过第一列表验证第一证书请求签名通过的情况下签发的数字证书，上述第一列表包括多个Ukey各自对应的第二证书，该第二证书为CA对Ukey发送的第二证书请求生成的数字证书；第二发送单元810，用于发送终端设备证书给对应终端设备。

作为一种可选的实施方式，生成单元801，用于在上述第一接收单元805接收终端设备发送的第一证书请求之前，使用非对称密钥对生成第二证书请求；第三发送单元802，用于向CA发送第二证书请求；第三接收单元803，用于接收CA发送的第二证书。

作为一种可选的实施方式，第四接收单元804，用于在上述第三发送单元 802向CA发送第二证书请求之后，上述第一接收单元805接收终端设备发送的第一证书请求之前，接收CA的公钥；接收验证单元809，用于在上述第一发送单元807发送第一证书请求和第一证书请求签名给CA之后，上述第二发送单元 810发送终端设备证书给对应终端设备之前，接收CA的私钥签名，以便使用上述CA的公钥验证上述CA的私钥签名。

需要说明的是，在本申请实施例中，各个单元的具体实现还可以对应参照图4和图5所示的方法实施例的相应描述。

请参见图9，图9是本申请实施例提供的又一种CA的结构示意图，该CA90 可以包括处理器901、存储器902和通信接口903，其中，处理器901、存储器 902和通信接口903可通过总线或其他方式连接，本申请实施例以通过总线连接为例。

其中，存储器902可以是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable readonly memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)，不限于此，该存储器902用于存储相关指令及数据；通信接口903用于接收和发送数据；处理器901可以是一个或多个中央处理器(Central Processing Unit，CPU)，即可以是CA90的计算核心及控制中心，用于解析CA90内部的各类指令及数据，在处理器901是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

该CA90中的处理器901用于读取上述存储器902中存储的程序代码，执行的操作参照图2和图3所示方法实施例的相应描述。

请参见图10，图10是本申请实施例提供的又一种Ukey的结构示意图，该 Ukey100可以包括处理器1001、存储器1002和通信接口1003，其中，处理器 1001、存储器1002和通信接口1003可通过总线或其他方式连接，本申请实施例以通过总线连接为例。

其中，存储器1002可以是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable readonly memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)，不限于此，该存储器1002用于存储相关指令及数据；通信接口1003用于接收和发送数据；处理器1001可以是一个或多个中央处理器(Central Processing Unit，CPU)，即可以是CA100的计算核心及控制中心，用于解析CA100内部的各类指令及数据，在处理器1001是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

该CA100中的处理器1001用于读取上述存储器1002中存储的程序代码，执行的操作参照图4和图5所示方法实施例的相应描述。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。上述信号处理装置的各组成模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在所述计算机可读取存储介质中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

综上所述，通过实施本申请实施例，终端设备发送的证书请求都经过Ukey 的私钥加密，增强了数据传输的安全性和完整性；并确保证书签发过程中使用的是可信任的Ukey以及终端设备证书是由可信任的CA颁发的，以此保障了整个证书签发过程的安全性和可靠性。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可存储程序代码的介质。在不冲突的情况下，本实施例和实施方案中的技术特征可以任意组合。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (9)

1.一种基于电子钥匙Ukey的证书签发方法，其特征在于，包括：

接收所述Ukey发送的终端设备的第一证书请求和第一证书请求签名，所述第一证书请求签名为所述第一证书请求经过所述Ukey的私钥签名后得到的数字签名；

通过第一列表验证所述第一证书请求签名，包括：查询所述第一列表，确认发送所述第一证书请求和所述第一证书请求签名的所述Ukey对应的第二证书是否存在；若所述第二证书存在，使用所述第二证书验证所述第一证书请求签名，包括：使用所述Ukey对应的第二证书中携带的所述Ukey的公钥解密所述第一证书请求签名，若解密后的所述第一证书请求签名与所述第一证书请求相同，则验证通过；若所述第二证书不存在，则验证不通过；所述第一列表包括多个Ukey的标识信息以及各自对应的所述第二证书，所述第二证书为证书颁发机构CA对所述Ukey发送的第二证书请求签发的数字证书；

在所述第一证书请求签名验证通过的情况下，对所述第一证书请求生成终端设备证书，并发送给所述Ukey，以使所述Ukey将所述终端设备证书发送给所述终端设备。

2.根据权利要求1所述的方法，其特征在于，所述接收所述Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，所述方法还包括：

接收所述Ukey发送的第二证书请求；

对所述第二证书请求生成所述第二证书，并在所述第一列表中添加所述第二证书；

发送所述第二证书给所述Ukey。

3.根据权利要求2所述的方法，其特征在于，所述对所述第二证书请求生成所述第二证书，并在所述第一列表中添加所述第二证书之后，所述接收所述Ukey发送的终端设备的第一证书请求和第一证书请求签名之前，所述方法还包括：发送所述CA的公钥给所述Ukey；

所述在所述第一证书请求签名验证通过的情况下，所述方法还包括：发送所述CA的私钥签名至所述Ukey，以使所述Ukey使用所述CA的公钥验证所述CA的私钥签名。

4.根据权利要求2或3所述的方法，其特征在于，所述对所述第二证书请求生成所述第二证书，并在所述第一列表中添加所述第二证书，包括：

验证登录所述CA的后台所使用的Ukey是否有管理员权限；

若所述登录所述CA的后台所使用的Ukey有管理员权限，则对所述第二证书请求生成所述第二证书，并在所述第一列表中添加所述第二证书；

若所述登录所述CA的后台所使用的Ukey没有管理员权限，则结束操作。

5.根据权利要求1所述的方法，其特征在于，所述第一证书请求为所述终端设备使用所述终端设备创建的非对称密钥对生成的证书请求，所述第二证书请求为所述Ukey使用所述Ukey创建的非对称密钥对生成的证书请求。

6.一种基于电子钥匙Ukey的证书签发方法，其特征在于，包括：

接收终端设备发送的第一证书请求；

通过所述Ukey的私钥对所述第一证书请求签名，得到第一证书请求签名；

发送所述第一证书请求和第一证书请求签名给证书颁发机构CA；

接收所述CA签发的终端设备证书，所述终端设备证书是所述CA通过第一列表验证所述第一证书请求签名通过的情况下签发的数字证书，所述CA通过第一列表验证所述第一证书请求签名，包括：查询所述第一列表，确认发送所述第一证书请求和所述第一证书请求签名的所述Ukey对应的第二证书是否存在；若所述第二证书存在，使用所述第二证书验证所述第一证书请求签名，包括：所述CA使用所述Ukey对应的第二证书中携带的所述Ukey的公钥解密所述第一证书请求签名，若解密后的所述第一证书请求签名与所述第一证书请求相同，则验证通过；若所述第二证书不存在，则验证不通过；所述第一列表包括多个Ukey的标识信息以及各自对应的所述第二证书，所述第二证书为所述CA对所述Ukey发送的第二证书请求生成的数字证书；

发送所述终端设备证书给所述终端设备。

7.根据权利要求6所述的方法，其特征在于，所述接收终端设备发送的第一证书请求之前，所述方法还包括：

使用非对称密钥对生成所述第二证书请求；

向所述CA发送所述第二证书请求；

接收所述CA发送的所述第二证书。

8.根据权利要求7所述的方法，其特征在于，所述向所述CA发送所述第二证书请求之后，所述接收终端设备发送的第一证书请求之前，所述方法还包括：接收所述CA的公钥；

所述发送所述第一证书请求和第一证书请求签名给所述CA之后，所述发送所述终端设备证书给所述终端设备之前，所述方法还包括：接收所述CA的私钥签名，以便使用所述CA的公钥验证所述CA的私钥签名。

9.根据权利要求6-8任一项所述的方法，其特征在于，所述第一证书请求为所述终端设备使用所述终端设备创建的非对称密钥对生成的证书请求，所述第二证书请求为所述Ukey使用所述Ukey创建的非对称密钥对生成的证书请求。

Images