一种申请证书的方法和系统

本发明涉及计算机领域，更具体地，涉及移动端的金融交易安全领域。

在现有的移动交易中，安装有APP(例如银行APP)的移动终端在申请数字证书时，通常可以将证书申请请求发送到银行，银行在将给请求转发到CA认证中心。

但是，在现有技术中，证书的发送与所持有的设备没有任何关联，即证书的发放不依赖于特定终端。

这造成的缺陷在于，APP中相应的安全措施可能会被劫持或者篡改，从而在其他终端上也可以进行交易。这大大降低了移动交易的安全性。

本发明的目的在于客户现有技术中证书申请安全级别较低的缺陷。

根据本发明的第一方面，提供一种申请证书的方法，包括：第一步骤，用户终端向银行子系统发送证书申请请求，所述证书申请请求包括用户终端的设备ID；第二步骤，所述银行子系统将所述证书申请请求发送给所述认证中心；第三步骤，所述认证中心中的移动密钥中心根据所述证书申请请求中的设备ID，确定所述用户终端的真伪，如果所述用户终端为真，则将所述证书申请请求发送给所述银行子系统，所述银行子系统将所述证书申请请求发送给所述认证中心的证书认证服务器，以从所述证书认证服务器中申请证书。

根据本发明的一个实施方式，其中，所述用户终端包括安全单元SE，可信执行环境TEE和富执行环境REE，其中，所述SE用于存储密钥；所述TEE中用于存储与所述密钥相对应的可信应用TA；以及运行在所述REE中的APP，所述APP的运行基于所述SE中的密钥和TEE中的TA；所述第一步骤包括：所述SE中的Applet生成密钥对，并将所述密钥对中的公钥发送给所述TA；所述TA将所述公钥和设备ID发送给REE中的APP；所述APP生成包括所述设备ID的证书申请请求，并将所述证书申请请求发送给所述银行子系统。

根据本发明的一个实施方式，其中，所述银行子系统包括应用服务器和证书注册审核系统RA，所述第二步骤包括：所述应用服务器接收所述证书申请请求；所述应用服务器将所接收到的证书申请请求转发给所述RA。

根据本发明的一个实施方式，其中，所述第三步骤包括：移动密钥中心从所述RA中接收证书申请请求，并根据所述证书申请请求中的设备ID，确定所述用户终端的真伪；如果所述用户终端为真，则将所述证书申请请求发送给RA；所述RA将所述证书申请请求发送给所述认证中心的证书认证服务器CA，以从所述证书认证服务器中申请证书。

根据本发明的一个实施方式，将所申请的证书存储在所述用户终端的SE中或存储在TEE中。

根据本发明第二方面，提供一种申请证书的系统，包括：用户终端、与所述用户终端通信的银行子系统以及与所述银行子系统通信的认证中心，其中，用户终端配置为，向银行子系统发送证书申请请求，所述证书申请请求包括用户终端的设备ID；所述银行子系统配置为，将所述证书申请请求发送给所述认证中心；所述认证中心包括移动密钥中心和证书认证服务器，所述移动密钥中心根据所述证书申请请求中的设备ID，确定所述用户终端的真伪，如果所述用户终端为真，则将所述证书申请请求发送给所述银行子系统，所述银行子系统将所述证书申请请求发送给所述证书认证服务器，以从所述证书认证服务器中申请证书。

根据本发明的一个实施方式，其中，所述用户终端包括安全单元SE，可信执行环境TEE和富执行环境REE，其中，所述SE用于存储密钥；所述TEE中用于存储与所述密钥相对应的可信应用TA；以及运行在所述REE中的APP，所述APP的运行基于所述SE中的密钥和TEE中的TA；其中，所述SE中的Applet生成密钥对，并将所述密钥对中的公钥发送给所述TA；所述TA将所述公钥和设备ID发送给REE中的APP；所述APP生成包括所述设备ID的证书申请请求，并将所述证书申请请求发送给所述银行子系统。

根据本发明的一个实施方式，其中，所述银行子系统包括应用服务器和证书注册审核系统RA，所述应用服务器配置为接收所述证书申请请求；所述应用服务器配置为将所接收到的证书申请请求转发给所述RA。

根据本发明的一个实施方式，其中，移动密钥中心配置为从所述RA中接收证书申请请求，并根据所述证书申请请求中的设备ID，确定所述用户终端的真伪；如果所述用户终端为真，则将所述证书申请请求发送给RA；所述RA配置为将所述证书申请请求发送给所述认证中心的证书认证服务器CA，以从所述证书认证服务器中申请证书。

将所申请的证书存储在所述用户终端的SE中或存储在TEE中。

根据本发明，能够使得证书的申请与特定的移动设备关联起来，防止由于安全措施被篡改或者劫持而导致的安全性降低或丧失。

图1示出了根据本发明第一方面的一种申请证书的方法的流程图；

图2示出了根据本发明第二方面的证书申请系统的框图；

图3示出了根据本发明的实施方式的用户终端的结构示意图；

图4a示出了根据本发明的一个实施方式的存储密钥的SE的空间的示意图；以及

图4b示出了根据本发明的一个实施方式的存储TA的TEE的空间的示意图。

下面结合附图对本发明的较佳实施例进行详细阐述，参考标号是指本发明中的组件、技术，以便本发明的优点和特征在适合的环境下实现能更易于被理解。下面的描述是对本发明权利要求的具体化，并且与权利要求相关的其它没有明确说明的具体实现也属于权利要求的范围。

图1示出了根据本发明第一方面的一种申请证书的方法的流程图；图2示出了根据本发明第二方面的证书申请系统的框图。

如图2所示，本发明的系统包括：用户终端210、与所述用户终端210通信的银行子系统220以及与所述银行子系统220通信的认证中心230，其中。

如图1和图2所示，本发明的方法包括：第一步骤S1，用户终端210向银行子系统220发送证书申请请求，所述证书申请请求包括用户终端的设备ID；第二步骤S2，所述银行子系统220将所述证书申请请求发送给所述认证中心230。

在现有技术中，认证中心230包含证书认证服务器CA 231，所述CA 231用于接收证书申请请求并发放所需的证书。

CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书。

如果用户想得到一份属于自己的证书，应先生成公私密钥对，然后直接或者间接向CA提出申请(申请中包含公钥)。在CA判明申请者的身份后，并且CA将该公钥与申请者的身份信息绑在一起，便形成证书发给申请者。

如果一个用户想鉴别另一个证书的真伪，他就用颁发该证书的CA的公钥对那个证书的签名进行验证，一旦验证通过，该证书就被认为是有效的。

而在本发明中，如图1和图2所示，在第三步骤S3，所述认证中心230还包括移动密钥中心232，该移动密钥中心232根据所述证书申请请求中的设备ID，确定所述用户终端210的真伪，如果所述用户终端210为真，则将所述证书申请请求发送给所述银行子系统220，所述银行子系统220将所述证书申请请求发送给所述认证中心230的证书认证服务器231，以从所述证书认证服务器231中申请证书。

从图1和图2中可以看出，与现有技术不同的是，在认证中心230处，还设置了移动密钥中心232。银行子系统需要先在移动密钥中心232处确定移动终端210的真伪，或者确定移动终端210的有效性，只有被判定为有效的移动终端210才能进一步获取证书。

设备ID可以是手机芯片中内置的能够标识该设备唯一性的标识码，例如可以是一串特定于设备的秘钥，可以是一个手机的证书等等。

下面结合图3详细描述根据本发明的用户终端的构成以及操作过程。

如图3所示，本发明的用户终端可以包括安全单元SE，可信执行环境TEE和富执行环境REE，其中，SE中具有预设的空间，用于存储密钥；所述TEE中用于存储与所述密钥相对应的可信应用TA；以及运行在所述REE中的APP，所述APP的运行基于所述SE中的密钥和TEE中的TA。

图3中SE中的密钥可以由设置在SE中Applet来生成，并存储在SE中。SE中存储的密钥(具体而言为私钥)无法被导出到SE之外。

安全元件SE，通常以芯片形式提供。为防止外部恶意解析攻击，保护数据安全，在芯片中具有加密/解密逻辑电路。在携带电话中的UICC(一种SIM规格)，SD等芯片也实现了同样的功能。在北美和日本，以UIM/UICC作为安全元件成为了主流。但在世界上以信用卡公司主导的方案中，也出现了SD和专门的IC芯片作为SE。

在携带电话为媒体的电子货币解决方案中，为保证其中保存的电子货币数据，不被恶意阅读修改，必须采用独立于OS的专门环境来保存数据。专门环境可以是用软件来实现，也可以用硬件来实现。但是最直接最安全的方法是使用硬件作为解决方案。保存于SE中的敏感数据不能被OS直接操作，因此从理论上无法对其进行攻击。

SE普遍采用Java Card技术，其中Java Card防火墙是运行时环境JCRE的强制保护措施，并且是和Java技术的保护分开的。防火墙机制避免了最频繁的、可预见的安全隐患：导致敏感数据被泄露给其它applet开发者的设计缺陷。

所述SE中的Applet生成密钥对，并将所述密钥对中的公钥发送给所述TA；所述TA将所述公钥和设备ID发送给REE中的APP；所述APP生成包括所述设备ID的证书申请请求，并将所述证书申请请求发送给所述银行子系统。

该证书申请请求例如可以是PKCS