一种数据发送的方法及设备与流程

文档序号:17428948发布日期:2019-04-17 03:14阅读:213来源:国知局
一种数据发送的方法及设备与流程

本申请涉及终端技术领域,特别涉及一种数据发送的方法及设备。



背景技术:

随着终端硬件技术的发展,生物特征技术得以在终端上实现,大大提高了用户操作的便捷性。例如,指纹认证技术可以基于内置在终端中的指纹传感器实现。再例如,人脸识别认证技术可以基于终端上的摄像头实现。又例如,声纹识别认证技术可以基于终端上的麦克风实现。

其中,生物认证技术作为一种身份认证的手段,可以应用于互联网服务、安防、交通等领域。例如,如图1所示,为将指纹认证技术应用于移动支付领域的应用场景的示意图。用户在使用终端上安装的支付类应用(例如支付宝)完成一笔在线支付时,需要输入用户的指纹进行身份验证,以保证资金的安全性。具体的,终端在通过指纹传感器检测到指纹后,对指纹传感器检测到的指纹进行验证,并将验证结果发送到应用服务器。应用服务器若确定验证结果指示终端的验证通过,则向终端发送在线支付服务授权成功响应,从而使得用户可以使用终端完成在线支付。但是,应用服务器若确定验证结果指示终端的验证不通过,则向终端发送在线支付服务授权失败响应,从而限制终端使用在线支付服务,导致用户使用终端在线支付失败。

为了确保验证结果在从终端发送给应用服务器的过程中完整性、不可抵赖性得以满足,需要针对应用的客户端和服务器建立一个可信通道。其中针对应用的客户端指的是安装在终端上的应用。现有技术中,终端在可信执行环境(trustexecutionenvironment,tee)生成并保存针对应用的非对称密钥对,针对应用的非对称密钥对包括针对应用的公钥和针对应用的私钥。以下将针对应用的公钥简称为应用公钥,将针对应用的私钥简称为应用私钥。终端将应用公钥发送给应用服务器,应用服务器在接收到应用公钥后,保存应用公钥。从而使得终端和应用服务器之间针对应用的客户端和服务器建立了一个可信的通道。若终端需要将验证结果发送给应用服务器,则终端向应用服务器发送使用应用私钥对验证结果的签名以及验证结果,应用服务器可以使用应用公钥对签名进行验证,若验证通过,则确认验证结果有效,否则确定验证结果无效。在验证结果有效的情况下,进一步对验证结果进行判断。

但是,如何保证应用公钥从终端发送给应用服务器的过程中完整性、不可抵赖性得以满足。现有技术中,可以使用设备私钥和设备公钥建立终端与应用服务器之间的可信通道,来发送应用公钥。具体的,终端可以将使用设备私钥对应用公钥的签名以及应用公钥发送给应用服务器。应用服务器在接收到使用设备私钥对应用公钥的签名以及应用公钥后,使用设备公钥对上述签名进行验证,若验证通过,则应用服务器存储应用公钥,若验证不通过,则应用服务器可以向终端发送重新获取应用公钥的请求。其中设备私钥和设备公钥可以为一对密钥,且设备公钥为在终端生产阶段由生产服务器(设备商)提供给应用服务器(应用服务提供商)的。出于对安全的考虑,一般情况下,每台终端对应一对设备公私钥,则设备商需要在生产阶段将每台终端对应的设备公钥提供给应用服务提供商,容易导致泄露设备商的终端产品的制造周期和产能等敏感信息。



技术实现要素:

本申请实施例提供了一种数据发送的方法及设备,有助于在提高数据传输的可靠性、不可抵赖性和安全性时,避免泄露设备商终端产品的制造周期和产能等敏感信息。

第一方面,本申请实施例提供的一种数据发送的方法,包括:

终端接收认证授权ca签发的设备证书,并生成第一密钥对,其中第一密钥对包括第一公钥和第一私钥。然后,终端向第一证书服务器发送第一证书注册请求,第一证书注册请求包括所述第一公钥。终端接收第一证书服务器发送的根据第一证书注册请求签发的第一证书,第一证书包括所述第一公钥,且第一证书与设备证书不同。终端针对第一应用生成第二密钥对,第二密钥对包括第二公钥和第二私钥。终端使用第一私钥签发针对第一应用的应用证书,并将应用证书发送给第一应用对应的第一应用服务器,应用证书包括第二公钥。终端使用第二私钥对待发送给第一应用服务器的数据进行签名,并将签名后的数据发送给第一应用服务器。

本申请实施例中由于终端和第一应用服务器之间可以通过应用证书和第二私钥建立可信通道,因而与现有技术相比,不但有助于提高数据传输的可靠性、不可抵赖性和安全性,而且有助于避免向应用提供商泄露设备商的终端产品的制造周期和产能等敏感信息;此外,本申请实施例中终端是通过第一私钥来签发应用证书的,且第一私钥为第一证书对应的私钥,第一证书为与设备证书不同的证书,因此本申请实施例还有助于降低泄露设备证书的证书序列号的风险,进而有助于保护用户隐私。

在一种可能的设计中,终端可以在下列时机向第一证书服务器发起签发第一证书的流程:终端首次开机时、终端进行重置操作时、或者第一时刻。其中,第一时刻为预设时长内的任一时刻,终端在预设时长后到达第二证书的有效期,第二证书为第一证书服务器签发第一证书之前签发的证书,第二证书对应的私钥用于在第一证书签发之前签发应用证书。

例如,终端首次开机时,向第一证书服务器发起签发第一证书的流程,则终端在首次开机时,生成第一密钥对。再例如,终端进行重置操作时,向第一证书服务器发起签发第一证书的流程,则终端在进行重置操作时,生成第一密钥对。又例如,终端在第一时刻,向第一证书服务器发起签发第一证书的流程,则终端在第一时刻,生成第一密钥。

在一种可能的设计中,终端向第二证书服务器发送证书验证请求,并在接收到第二证书服务器发送的第一证书验证响应后,使用第一私钥签发针对第一应用的应用证书。其中,证书验证请求用于指示第二证书服务器验证第一证书是否有效,第一证书验证响应指示第一证书有效。从而有助于第二证书服务器可以实现对第一证书的灵活管控,以便于及时发现第一私钥无法用于针对第一应用签发应用证书的情况。

在一种可能的设计中,应用证书还包括证书参数。其中,证书参数包括应用证书的证书序列号、和应用证书的有效期中的至少一个。且证书参数是第二证书服务器通过第一证书验证响应指示给终端的。通过上述技术方案,可以进一步有助于第二证书服务器对第一证书的灵活管控。

在一种可能的设计中,第一证书验证响应为授权码。从而有助于简化第二证书服务器的处理流程,降低终端数据处理的复杂度。

在一种可能的设计中,终端接收到第二证书服务器发送的第二证书验证响应,则向第一证书服务器发起重新签发第一证书的流程。其中,第二证书验证响应指示第一证书失效。有助于提高终端和第一应服务器之间通信的安全可靠性。

在一种可能的设计中,终端验证所述应用证书有效后,使用第二私钥对待发送给第一应用服务器的数据进行签名。通过上述技术方案,有助于对应用证书的灵活管控,提高终端向第一应用服务器发送数据的可靠性和不可抵赖性。

在一种可能的设计中,终端验证应用证书失效,则针对第一应用重新执行应用证书的签发流程。有助于提高终端和第一应服务器之间通信的安全可靠性。

在一种可能的设计中,第一证书服务器和第二证书服务器为不同的证书服务器。有助于降低证书服务器的处理能力和容量的要求。

在一种可能的设计中,第一证书服务器和第二证书服务器为相同的证书服务器。有助于简化实现方式。

在一种可能的设计中,第二证书服务器为第二证书服务器集群中的一个证书服务器。通过上述技术方案,有助于进一步降低对单个第二证书服务器的处理能力和容量的要求,而且有助于提升系统整体的容量,以及提高系统的可靠性。

在一种可能的设计中,第一证书服务器为第一证书服务器集群中的一个证书服务器。有助于进一步降低对单个第一证书服务器的处理能力和容量的要求,而且有助于提升系统整体的容量,以及提高系统的可靠性。

在一种可能的设计中,第一证书的证书序列号与设备证书的证书序列号不同。有助于避免设备证书的证书序列号被滥用,从而有助于保护用户的隐私。

在一种可能的设计中,第一证书的有效期小于设备证书的有效期。由于第一证书的有效期较短,因而第一证书的更新时间较短,从而使得应用证书的更新时间变短,有助于提高终端和第一应用服务器之间通信的安全性。

第二方面,本申请实施例提供的一种数据发送的方法,包括:

第一证书服务器接收到终端发送的第一证书注册请求后,使用第一服务器证书对应的私钥签发第一证书。其中,第一证书注册请求包括第一公钥,且所述第一私钥用于终端签发应用证书。第一公钥和第一私钥互为第一密钥对。第一服务器证书为所述第一证书服务器的证书,第一证书与终端的设备证书不同。

本申请实施例中由于通过第一私钥来签发应用证书的,且第一私钥为第一证书对应的私钥,第一证书为与设备证书不同的证书,因此本申请实施例还有助于降低泄露设备证书的证书序列号的风险,进而有助于保护用户隐私。

在一种可能的设计中,第一证书服务器为第一证书服务器集群中的一个证书服务器。有助于进一步降低对单个第一证书服务器的处理能力和容量的要求,而且有助于提升系统整体的容量,以及提高系统的可靠性。

在一种可能的设计中,第一证书的证书序列号与设备证书的证书序列号不同。有助于避免设备证书的证书序列号被滥用,从而有助于保护用户的隐私。

在一种可能的设计中,第一证书的有效期小于设备证书的有效期。由于第一证书的有效期较短,因而第一证书的更新时间较短,从而使得应用证书的更新时间变短,有助于提高终端和第一应用服务器之间通信的安全性。

第三方面,本申请实施例提供的另一种数据发送的方法,包括:

终端接收认证授权ca签发的设备证书,并向第一证书服务器发送第一证书注册请求。终端接收第一证书服务器发送的第一证书注册响应。其中第一证书注册响应包括第一证书和加密后的第一私钥,第一证书包括第一公钥、且第一证书是由第一证书服务器签发的;第一公钥和所述第一私钥互为第一密钥对、且由第一证书服务器生成;第一证书与所述设备证书不同;终端针对第一应用生成第二密钥对,第二密钥对包括第二公钥和第二私钥。终端使用第一私钥签发针对第一应用的应用证书,并将应用证书发送给第一应用对应的第一应用服务器,应用证书包括第二公钥。终端使用第二私钥对待发送给第一应用服务器的数据进行签名,并将签名后的数据发送给第一应用服务器。

本申请实施例中由于终端和第一应用服务器之间可以通过应用证书和第二私钥建立可信通道,因而与现有技术相比,不但有助于提高数据传输的可靠性、不可抵赖性和安全性,而且有助于避免向应用提供商泄露设备商的终端产品的制造周期和产能等敏感信息;另外,本申请实施例中终端是通过第一私钥来签发应用证书的,且第一私钥为第一证书对应的私钥,第一证书为与设备证书不同的证书,因此本申请实施例还有助于降低泄露设备证书的证书序列号的风险,进而有助于保护用户隐私。此外,与第一方面提供的数据发送的方法不同的是,本申请实施例中由于是由第一证书服务器生成第一对称密钥对的,因此第一证书服务器还可以同时为多个终端签发第一证书,从而有助于提高签发第一证书的效率。

在一种可能的设计中,终端可以在下列时机向第一证书服务器发起签发第一证书的流程:终端首次开机时、终端进行重置操作时、或者第一时刻。其中,第一时刻为预设时长内的任一时刻,终端在预设时长后到达第二证书的有效期,第二证书为第一证书服务器签发第一证书之前签发的证书,第二证书对应的私钥用于在第一证书签发之前签发应用证书。

例如,终端首次开机时,向第一证书服务器发起签发第一证书的流程,则终端在首次开机时,向第一证书服务器发送第一证书注册请求。再例如,终端进行重置操作时,向第一证书服务器发起签发第一证书的流程,则终端在进行重置操作时,向第一证书服务器发送第一证书注册请求。又例如,终端在第一时刻,向第一证书服务器发起签发第一证书的流程,则终端在第一时刻,向第一证书服务器发送第一证书注册请求。

此外,第三方面中其它可能的设计,可以参见第一方面提供的方法中的相关可能的设计,在此不再赘述。

第四方面,本申请实施例提供的另一种数据发送的方法,包括:

第一证书服务器接收到终端发送的第一证书注册请求后,生成第一密钥对。其中第一密钥对包括第一公钥和第一私钥。然后,第一证书服务器使用第一服务器证书对应的私钥签发第一证书,以及对第一私钥加密;第一证书与终端的设备证书不同。第一证书服务器向终端发送第一证书注册响应。第一证书注册响应包括第一证书和加密的第一私钥。第一私钥用于终端签发应用证书。

本申请实施例中由于通过第一私钥来签发应用证书的,且第一私钥为第一证书对应的私钥,第一证书为与设备证书不同的证书,因此本申请实施例还有助于降低泄露设备证书的证书序列号的风险,进而有助于保护用户隐私。

需要说明的是,第四方面中其它可能的设计,可以参见第二方面提供的方法中的相关可能的设计,在此不再赘述。

第五方面,本申请实施例提供的另一种数据发送的方法,包括:

终端接收认证授权ca签发的设备证书。终端针对第一应用生成第一密钥对,第一密钥对包括第一公钥和第一私钥。终端向证书服务器发送证书验证请求,证书验证请求用于指示证书服务器验证设备证书是否有效。终端在接收到第一证书验证响应,则使用设备证书对应的私钥签发针对第一应用的应用证书,并将应用证书发送给第一应用对应的第一应用服务器,应用证书包括所述第一公钥;第一证书验证响应指示设备证书有效。终端使用第一私钥对待发送给第一应用服务器的数据进行签名,并将签名后的数据发送给第一应用服务器。

本申请实施例中由于终端和第一应用服务器之间可以通过应用证书和第一私钥建立可信通道,因而与现有技术相比,不但有助于提高数据传输的可靠性、不可抵赖性和安全性,而且有助于避免向应用提供商泄露设备商的终端产品的制造周期和产能等敏感信息;另外本申请实施例中由于终端在使用应用证书对应的第一私钥对待发送给第一应用服务器的数据进行签名之前,验证应用证书是否有效,因而有助于进一步提高数据传输的安全性、可靠性和不可抵赖性。

需要说明的是,第五方面中其它可能的设计,可以参见第一方面提供的方法中的相关可能的设计,在此不再赘述。

第六方面,本申请实施例提供的另一种数据发送的方法,包括:

证书服务器接收终端发送的证书验证请求,证书验证请求用于指示证书服务器验证终端的设备证书是否有效。然后,证书服务器验证设备证书是否有效,并在验证设备证书有效时,向终端发送第一证书验证响应,其中,第一证书验证响应指示设备证书有效。本申请实施例中由于证书服务器可以验证设备证书是否有效,因而有助于避免设备证书被滥用。

第七方面,本申请实施例提供的一种电子设备,包括收发器、存储器和处理器。其中,所述处理器与所述存储器和所述收发器耦接;所述收发器用于发送或接收数据;所述存储器用于存储程序指令;所述处理器用于调用所述存储器存储的所述程序指令,结合所述收发器执行上述各个方面及其可能的设计提供的数据发送方法。

第八方面,本申请实施例还提供了一种电子设备,所述电子设备包括执行上述各个方面及其可能的设计提供的数据发送方法的装置。

第九方面,本申请实施例还提供了一种计算机存储介质,该计算机存储介质存储有程序指令,当所述程序指令在电子设备上运行时,使得所述电子设备执行上述各个方面及其可能的设计提供的数据发送方法。

第十方面,本申请实施例还提供了一种计算机程序产品,当所述计算机程序产品在电子设备上运行时,使得所述电子设备执行上述各个方面及其可能的设计提供的数据发送方法。

第十一方面,本申请实施例还提供了一种芯片,所述芯片与电子设备的存储器和收发器耦接,当所述芯片运行时,实现上述各个方面及其可能的设计提供的数据发送方法。

需要说明的是,本申请中各个实施例所涉及的藕接是指两个部件彼此直接或间接的连接。这种连接可以允许两个部件之间进行通信。

另外,第七方面至第十一方面中任一种可能设计方式所带来的技术效果可参见第一方面至第六方面中不同设计方式所带来的技术效果,此处不再赘述。

附图说明

图1为将指纹认证技术应用于移动支付领域的应用场景的示意图;

图2为本申请实施例适用的一种系统架构图;

图3为本申请实施例提供的一种数据发送的方法;

图4为本申请实施例提供的另一种数据发送的方法;

图5为本申请实施例提供的另一种数据发送的方法;

图6为本申请实施例提供的一种电子设备的结构示意图;

图7为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

本申请实施例中“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b的情况,其中a、b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一(项)个”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a、b或c中的至少一项(个),可以表示:a,b,c,a和b,a和c,b和c,或a、b和c,其中a、b、c可以是单个,也可以是多个。

图2示出了本申请实施例适用的一种系统架构图。如图2所示,本申请实施例的系统架构包括公钥基础设施(publickeyinfrastructure,pki)系统、终端、证书服务器系统和第一应用服务器。

其中,pki系统可以用于签发和管理证书。示例的,pki系统可以用于为终端签发设备证书,也可以为证书服务器签发服务器证书。一般情况下,pki系统是通过认证授权(certificateauthority,ca)来签发证书的。在本申请实施例中,pki系统可以包括一级或多级ca,当pki系统包括多级ca时,例如,在如图2所示的pki系统包括一级ca、第一二级ca和第二二级ca,证书服务器系统包括第一证书服务器的情况下,第一二级ca可以用于为终端签发设备证书,第二二级ca可以用于为第一证书服务器签发第一服务器证书。此外,需要说明的是,本申请实施例中,在pki系统为证书服务器签发服务器证书的情况下,用于为终端签发设备证书的ca和用于为第一证书服务器签发第一服务器证书的ca可以相同,也可以不同。

本申请实施例中的终端又可称之为终端设备(terminalequipment)或者用户设备(userequipment,ue)等。示例的,终端可以为手机、平板电脑(pad)、笔记本电脑、个人数字助理(personaldigitalassistant,pda)、销售终端(pointofsales,pos)、车载电脑、智能音箱、机顶盒、增强现实(augmentedreality,ar)设备、虚拟现实(virtualreality,vr)或者智能汽车等,本申请实施例对此不作限定。另外,本申请实施例的终端可以支持一种或多种应用。比如以下应用中的一个或多个:绘图应用、演示应用、字处理应用、游戏应用、电话应用、视频播放器应用、音乐播放器应用、电子邮件应用、即时消息收发应用、照片管理应用、相机应用、浏览器应用、日历应用、时钟应用、支付应用和健康管理应用等。用户可以基于自身的需求在终端上安装相应的应用。

示例的,如图2所示,本申请实施例的终端包括应用、富执行环境(richexecutionenvironment,ree)和安全执行环境。

其中,应用为安装在终端上的应用,例如第一应用,第一应用可以为原生应用(nativeapplication)(例如设置、桌面、文件管理等),第一应用也可以为第三方应用(例如支付宝、微信等)。

ree可用于运行通用操作系统,例如安卓(android)操作系统、ios操作系统、linux操作系统等,从而为实现应用功能的实现提供软件和硬件的支撑。其中,ree包括证书管理客户端和密钥管理模块,证书管理客户端用于证书服务器系统中的证书服务器如第一证书服务器等访问安全执行环境。密钥管理模块用于针对应用如第一应用调用安全执行环境中的程序,例如密钥管理可信程序(trustapplet,ta),生成密钥对或者读取数据等。需要说明的是,本申请实施例中ree还可以包括其它模块,用以完成相应的功能。

安全执行环境可用于存储密码学算法(例如密钥生成算法、签名以及哈希算法等),以实现密钥对的生成、签名等,还可用于存储密钥和证书等。本申请实施例中的安全执行环境可以为具备共享硬件或共享部分硬件的安全执行环境,也可以为具备独立硬件的安全执行环境。例如,本申请实施例的安全执行环境可以为tee,也可以为安全单元(secureelement,se),还可以为回放保护内存块(replayprotectedmemoryblock,rpmb)等。其中,tee可以为基于trustzone等资源隔离/虚拟化技术实现的可信执行环境,它一般具备一个与普通操作系统(operatingsystem,os)共享的硬件,运行一个特定的安全os。该特定的安全os与普通os共享中央处理器(centralprocessingunit,cpu)和硬件,则存在部分硬件外设仅允许特定的安全os访问。安全单元(secureelement,se)为具备独立硬件的安全执行环境,可以在独立的硬件上运行一独立安全操作系统(一般可称之为cardos,简称为cos)。还需要说明的是,独立安全操作系统具备加载和执行定制代码的能力。

示例的,如图2所示,本申请实施例的安全执行环境包括证书管理ta和密钥管理ta。证书管理ta用于存储相关证书(例如设备证书、第一证书、应用证书等)和密钥(例如设备证书对应的私钥、第一证书对应的私钥等)、以及用于生成第一密钥对等。例如,在安全执行环境为javacard的情况下,证书管理ta可以为一个加载到javacard芯片的applet(小应用程序)。再例如,在安全执行环境为tee的情况下,证书管理ta可以为一个加载到tee的可信应用ta。需要说明的是,无论安全执行环境的实现方式为哪种情况,证书管理ta会提供接口,用以证书管理客户端在需要时能够调用证书管理ta。密钥管理ta用于针对应用(例如第一应用)生成第二密钥对。需要说明的是,本申请实施例中安全执行环境除了包括上述模块以外,还可以包括其它模块。还需要说明的是,本申请实施例终端除了包括应用、ree和安全执行环境以外,还可以包括其它部分,本申请实施例对此不作限定。

本申请实施例中证书服务器系统可以包括一个或多个证书服务器集群,也可以包括一个或多个证书服务器。其中,第一证书服务器为证书服务器系统包括的一个证书服务器,第一证书服务器可以用于签发第一证书。需要说明的是,在一些实施例中,第一证书服务器还可以用于在终端签发应用证书的过程中验证第一证书是否有效。另外,在证书服务器系统包括第一证书服务器和第二证书服务器时,第一证书服务器可以用于签发第一证书,而第二证书服务器用于在终端签发应用证书的过程中验证第一证书是否有效。第一证书服务器和第二证书服务器为物理上独立部署的两个证书服务器,也可以是逻辑上区分的两个证书服务器。

本申请实施例中,第一证书服务器的证书为第一服务器证书,第二证书服务器的证书为第二服务器证书,第一服务器证书和第二服务器证书可以为pki系统中相同的ca签发的,也可以为不同的ca签发的。更进一步的,为了提高系统整体的处理容量,第一证书服务器可以为第一证书服务器集群中的一个证书服务器,第二证书服务器可以为第二证书服务器集群中的一个证书服务器,其中第一证书服务器集群中的证书服务器均用于签发第一证书,第一证书服务器集群中每个证书服务器具备一个私钥,例如第一证书服务器集群包括m个证书服务器,则第一证书服务器包括m个私钥,m为正整数,且每个私钥分别对应一个服务器证书。类似的,第二证书服务器集群中的证书服务器均用于在终端签发应用证书的过程中验证第一证书是否有效。第二证书服务器集群中每个证书服务器具备一个私钥,例如第二证书服务器集群包括n个证书服务器,则第一证书服务器包括n个私钥,n为正整数,且每个私钥分别对应一个服务器证书。

需要说明的是,第一证书服务器集群和第二证书服务器集群中证书服务器的证书可以通过pki系统中相同的ca签发,也可以通过pki系统中不同的ca签发。

还需要说明的是,本申请实施例中,终端在需要申请签发第一证书时,可以采用随机或负载均衡策略向第一证书服务器集群中的第i个第一证书服务器发送第一证书注册请求。例如,i的取值可以为device_idmodm,其中,device_id为终端的标识,m为第一证书服务器集群中证书服务器的总个数。类似的,终端从第二证书服务器集群中选择用于验证第一证书是否有效的第二证书服务器的方式可以为随机的,也可以为基于预设的负载均衡策略确定的。

以第一证书服务器为例,第一证书服务器包括证书管理模块和硬件加密模块(hardwaresecuritymodule,hsm)。需要说明的是,本申请实施例中hsm又可称之为加密机。

其中,证书管理模块主要用于与其它设备(如终端)之间交互数据。hsm可以是独立的硬件加密机设备,也可以是作为一台服务器的内置插卡等,对此本申请实施例不作限定。具体的,hsm可用于生成、管理和存储密钥、以及具有加解密、签名、验证签名等功能。另外,hsm还可以用于存储密码学算法(例如密钥生成、加解密、签名、签名验证和哈希算法等)。需要说明的是,考虑到存储的安全性,hsm需要具备temperresistance(抗干扰)能力,密码学算法需要具备防止侧信道攻击能力。

需要说明的是,对于第一证书服务器的证书(即上述的第一服务器证书)可以由pki系统签发,也可以自签发。

为了使得用户在使用终端上安装的应用的过程中,保证终端向该应用的应用服务器发送数据的可靠性和完整性,本申请实施例提供了一种数据发送的方法。

下面结合图2所示的系统架构图对本申请实施例数据发送的方法进行具体介绍。

如图3所示,本申请实施例数据发送的方法,包括以下步骤。

步骤301,终端向公钥基础设施(publickeyinfrastructure,pki)系统发送证书签名请求(cerificatesigningrequest,csr)。

示例的,csr中包括用于生成设备证书的相关参数。例如,用于生成设备证书的相关参数可以包括以下参数中的至少一个:设备公钥、设备标识(例如国际移动设备标识(internationalmobileequipmentidentity,imei))、设备密钥对标识等。需要说明的是,设备密钥对可以是在终端生产阶段由终端生成的。具体的,设备密钥对包括设备公钥和设备私钥。通常情况下,设备公钥和设备私钥为一对非对称密钥。

步骤302,pki系统接收到csr后,为终端签发设备证书。

示例的,设备证书可以包括设以下一个或多个参数:设备证书序列号、设备公钥、设备证书发行机构、设备证书有效期、设备证书所使用的签名算法、设备证书版本信息等。需要说明的是,设备证书序列号可以为设备标识,也可以是基于设备标识得到的,用于唯一标识终端。

在具体实现时,pki系统是通过ca来为终端签发设备证书的。例如,如图3所示,pki系统包括一级ca、第一二级ca和第二二级ca,可以由一级ca为终端签发设备证书,也可以由第一二级ca为终端签发设备证书,还可以由第二二级ca为终端签发设备证书。以一级ca为终端签发设备证书为例,在具体实现时,由一级ca使用一级ca的证书对应的私钥为终端签发设备证书,设备证书包括一级ca的证书对应的私钥对设备证书所包括的一个或多个参数(例如证书序列号、设备公钥、设备证书发行机构等)的签名。需要说明的是,一级ca的证书又可称之为根证书。

步骤303,终端接收到pki系统签发的设备证书后,将设备证书保存到安全执行环境中。

以图3所示的终端结构为例,终端可以调用证书管理ta,由证书管理ta将设备证书保存在安全执行环境中。需要说明的是,终端接收到设备证书后,可以保存该设备证书。为了进一步保证设备证书的安全性,可以把设备证书保存到安全的存储空间中,安全的存储空间例如为安全执行环境。

步骤304,终端生成第一密钥对。其中,第一密钥对包括第一公钥和第一私钥。

需要说明的是,本申请实施例中的第一密钥对可以为非对称密钥对。示例的,终端生成第一密钥对所使用的算法可以为随机算法,也可以为rsa算法,还可以为椭圆曲线密码学(ellipticcurvecryptography,ecc)算法等,对此不作限定。例如,终端使用rsa算法生成第一密钥对的情况下,密钥长度可以为设置为1536~2048位或者2048位以上。再例如,终端使用ecc算法生成第一密钥对的情况下,密钥长度可以设置为192~256位或者256位以上。

为了提高安全性,在一些实施例中,终端是在安全执行环境内生成第一密钥对的。以图3所示的终端的结构为例,终端可以通过调用证书管理客户端向证书管理ta发送第一密钥对生成请求,证书管理ta接收到第一密钥对生成请求后,生成第一密钥对。

另外,为了便于终端后续使用第一密钥对,终端保存第一密钥对。为了提高终端保存第一密钥对时的安全性,在一些实施例中,终端可以将第一密钥对保存到安全执行环境中。以图3所示的终端的结构为例,终端可以通过调用证书管理ta,保存第一密钥对。还需要说明的是,为了便于查找第一密钥对,终端还生成第一密钥对标识,用于对第一密钥对进行标识。本申请实施例中的第一密钥对标识可以为符号、序列号等,对此不作限定。

步骤305,终端向第一证书服务器发送第一证书注册请求,第一证书注册请求包括第一公钥。

需要说明的是,为了提高终端与第一证书服务器之间数据传输的安全性,在执行步骤305之前在终端与第一证书服务器之间建立安全通道,实现加密传输。例如,可以基于安全套接字层超文本传输(typertexttransferprotocoloversecuresocketlayer,https)协议在终端与第一证书服务器之间建立安全通道,也可以基于其它传输加密协议在终端与第一证书服务器之间建立安全通道,对此本申请实施例不作限定。

在一些实施例中,为了便于第一证书服务器确定第一证书注册请求的完整性和可靠性,第一证书注册请求中还包括第一签名,其中第一签名为可信根对应的私钥的签名。示例的,可信根对应的私钥所签名的数据包括第一公钥。另外,在一些实施例中,第一证书注册请求中除了包括公钥和第一签名以外,还可以携带终端的设备标识、第一密钥对标识等数据。在这种情况下,可信根对应的私钥所签名的数据除了包括第一公钥以外,还可以包括终端的设备标识、第一密钥对标识等数据。

需要说明的是,以图3所示的终端的结构为例,终端是通过调用证书管理ta,得到第一签名的。由证书管理ta将第一签名以及可信根对应的私钥所签名的数据(例如第一公钥、终端的设备标识、第一密钥对标识等)发送给证书管理客户端,证书管理客户端接收到第一签名以及可信根对应的私钥所签名的数据后,生成第一证书注册请求,并由证书管理客户端将第一证书注册请求发送给第一证书服务器。

在本申请实施例中,可信根对应的私钥所签名的数据可以满足自定义格式的要求,也可以满足pkcs#10定义的csr格式的要求。一般情况下,csr格式的要求可信根对应的私钥所签名的数据包括证书版本号、设备标识、公钥、密钥用途、其他扩展信息等。例如,自定义格式的要求可信根对应的私钥所签名的数据包括公钥、设备标识和密钥对标识,则第一证书注册请求可以包括第一签名、第一公钥、终端的设备标识和第一密钥对标识。

此外,本申请实施例的可信根可以为设备证书,也可以为预先配置在第一证书服务器中的一个公钥。其中,可信根对应的私钥预先存储在终端的安全执行环境中。具体的,在可信根为公钥的情况下,该公钥和该公钥对应的私钥可以互为对称密钥对,也可以互为非对称密钥对。

需要说明的是,在终端生产阶段将可信根与可信根对应的私钥预先存储在终端中,并在终端生产阶段将可信根预先存储到第一证书服务器中。

在可信根与可信根对应的私钥互为对称密钥对的情况下,该可信根与可信根对应的私钥可以是基于3des、或者aes等算法得到的。密钥长度可以在128~256位之间,也可以根据实际需求进行相应的设定。在可信根与可信根对应的私钥互为非对称密钥对的情况下,该可信根与可信根对应的私钥可以是基于rsa、或者ecc等算法得到的。当采用rsa算法得到可信根与可信根对应的私钥是,密钥长度可以在1536位以上;当采用ecc算法得到可信根与可信根对应的私钥是,密钥长度可以在192位以上。另外,也可以根据实际需求选择相应的密钥算法和密钥长度生成可信根与可信根对应的私钥。

此外,对于终端来说,在可信根与可信根对应的私钥互为对称密钥对或者非对称密钥对时,一个可信根和可信根对应的私钥组成的密钥对可以对应一个终端,也可以对应多个终端。例如当一个可信根和可信根对应的私钥组成的密钥对对应多个终端的情况下,可以通过下列方式实现,例如每批次生产的终端对应一个可信根和可信根对应的私钥组成的密钥对,或者,相同型号的终端对应一个可信根和可信根对应的私钥组成的密钥对。通常情况下,考虑到安全性,一般采用一个终端对应一个可信根和可信根对应的私钥组成的密钥对。

需要说明的是,对于一个终端对应一个可信根和可信根对应的私钥组成的密钥对,可以通过下列方式在终端预先存储可信根对应的私钥,在第一证书服务器预先存储可信根:

终端在生产阶段生成密钥对,其中密钥对中包括的公钥为可信根,密钥对中包括的私钥为可信根对应的私钥。然后,终端将可信根发送给生产装备,并将可信根和可信根对应的私钥存储到安全执行环境中。生成装备接收到可信根后,将可信根存储到生产服务器中,由生产服务器将可信根发送给第一证书服务器。其中,生产服务器为终端生产阶段所使用的服务器。

另外,对于一个或多个终端对应一个可信根和可信根对应的私钥组成的密钥对的情况,可以通过下列方式在终端预先存储可信根对应的私钥,在第一证书服务器预先存储可信根:

由生产服务器在终端生产阶段生成密钥对,其中密钥对中包括的公钥为可信根,密钥对中包括的私钥为可信根对应的私钥。然后,生产服务器将可信根发送给第一证书服务器,将可信根和可信根对应的私钥发送给生产装备,由生产装备将可信根和可信根对应的私钥写入到终端中。

在可信根为证书的情况下,可以通过pki系统在终端生产阶段签发可信根,其中pki系统签发可信根所使用的公钥可以为终端在生产阶段生成的密钥对中包括的公钥,也可以为在终端生产阶段写入到终端的密钥对所包括的公钥。第一证书服务器可以从pki系统获取看可信根,也可以使用pki系统中签发可信根的ca或者签发可信根的ca的下级ca等为第一证书服务器签发第一服务器证书。示例的,本申请实施例中,可信根为证书的情况下,可信根可以为设备证书。

需要说明的是,本申请实施例不限于上述开通可信根的方式,只要能够可信根能够用于标识终端,使得第一证书服务器能够通过可信根验证终端发送的第一签名有被伪冒即可。在本申请实施例中,第一证书服务器接收到可信根后,需要基于可信根对终端进行认证,在认证通过后,保存可信根。示例的,下面以可信根为设备证书为例,对第一证书服务器使用设备证书对终端进行认证的方法进行说明,具体包括以下步骤:

步骤1,终端将设备证书发送给第一证书服务器。步骤2,第一证书服务器接收到设备证书后,对设备证书进行验证。具体的,可以通过追溯到证书链的底端逐级向上验证,例如,以图3所示的系统框架为例,设备证书是第一二级ca签发的,第一二级ca的证书是一级ca签发的,一级ca的证书为根证书,则第一证书服务器对设备证书进行验证,即第一证书服务器对由根证书、第一二级ca证书和设备证书组成的证书链进行验证,第一证书服务器首先使用根证书验证第一二级ca证书通过后,在使用第一二级ca证书验证设备证书,若验证通过,则第一证书服务器对设备证书的验证通过。需要说明的是,在第一证书服务器对由根证书、第一二级ca证书和设备证书组成的证书链中任何一个证书验证未通过的情况下,则第一证书服务器验证设备证书未通过,则确定设备证书为非法或无效证书。步骤3,第一证书服务器在验证设备证书通过的情况下,向终端发送一个随机挑战字。步骤4,终端接收到随机挑战字后,使用设备证书对应的私钥对该随机挑战字进行签名,并将使用设备证书对应的私钥对该随机挑战字的签名返回给第一证书服务器。步骤5,第一证书服务器接收到使用设备证书对应的私钥对该随机挑战字的签名后,使用设备证书验证上述签名,若验证通过,则确定终端没有被伪冒,即设备认证通过。

需要说明的是,上述仅为第一证书服务器使用可信根对终端进行认证的方法的一个示例,本申请实施例不限定通过可信根对终端进行认证的方法。

步骤306,第一证书服务器接收到第一证书注册请求后,为终端签发第一证书。其中,第一证书包括第一公钥,第一证书与设备证书不同。

在一些实施例中,第一证书注册请求包括第一签名的情况下,第一证书服务器使用可信根对第一签名进行验证,示例的,第一证书服务器可以根据设备标识,从预先存储的可信根中获取该设备标识所标识的终端对应的可信根,然后使用该可信根对第一签名进行验证。终端可以将设备标识可以携带在第一证书注册请求中发送给第一证书服务器,第一证书服务器可以从第一证书注册请求中获取设备标识。此外,第一证书服务器还可以从终端生产阶段的数据库中获取设备标识所标识的终端对应的可信根。在一些实施例中,第一证书服务器也可以通过设备证书获取可信根。

当第一证书服务器对第一签名验证通过时,第一证书服务器为终端分配第一证书的证书序列号。其中,第一证书的证书序列号也可以用于标识终端,然后使用第一服务器证书对应的私钥为终端签发第一证书。其中,本申请实施例中第一证书可以采用x.509格式。第一证书中包括第一公钥、第一证书的证书序列号和第二签名,此外,第一证书中还可以包括证书名称、版本号、证书有效期等。第二签名为第一证书服务器使用第一服务器证书对应的私钥对第一证书中包括的一个或多个参数(例如第一公钥、第一证书的证书序列号、证书有效期、版本号、证书名称等)的签名。需要说明的是,第一服务器证书为第一证书服务器的证书,用于标识第一证书服务器,可以是由第一证书服务器自签发的,也可以是由pki系统通过ca签发的,本申请实施例对第一服务器证书的签发方式不作限定。

本申请实施例中第一证书服务器可以基于随机算法为终端分配第一证书的证书序列号,也可以根据设备标识和第一密钥对标识基于预设算法为终端分配第一证书的证书序列号,还可以根据设备证书的证书序列号确定第一证书序列号。例如,本申请实施例可以根据设备证书的证书序列号基于下列算法确定第一证书序列号:

第一证书序列号=hmac(设备证书的证书序列号,server_secret,random1)+random1,其中server_secret为仅有第一证书服务器知道的秘密值,可保存在hsm中。random1为随机值。hmac为密码学哈希算法,如hmac-sha256。

需要说明的是,本申请实施例第一服务器证书为终端分配第一证书的证书序列号的算法不作限定。

当第一证书服务器对第一签名验证未通过时,第一证书服务器向终端返回验证结果,以便终端重新注册第一证书。

另外,还需要说明的是,第一证书和设备证书不同可以指的是,第一证书的证书序列号和设备证书的证书序列号不同,也可以指的是用于签发第一证书的机构和用于签发设备证书的机构不同,还可以指的是第一证书的有效期和设备证书的有效期不同等。由于本申请实施例中采用第一私钥签发应用证书,因此,为了进一步提高应用证书的安全性,在一些实施例中,第一证书的有效期小于设备证书的有效期,例如第一证书的有效期可以设置为半年、2个月或者更短等。此外,本申请实施例中第一证书中还可以包括用于指示第一私钥使用的最大次数的参数、以及证书/密钥的层级数。例如,证书/密钥的层级数用于指示第一私钥是否可以用于签发其它证书。证书/密钥的层级数还可以指示第一私钥签发的证书是否可以继续签发其它证书。

步骤307,终端接收到第一证书服务器为终端签发的第一证书后,将第一证书保存到安全执行环境中。

以图3所示的系统架构中终端的架构为例,终端通过调用证书管理客户端模块接收第一证书服务器签发的第一证书,并在接收到第一证书后,调用证书管理ta,使用第一服务器证书对第一证书进行验证,并在验证通过后,将第一证书存储到安全执行环境中。

在本申请实施例中,第一证书服务器可以在向终端发送第一证书时,将第一服务器证书发送给终端,终端在接收到第一服务器证书和第一证书后,在第一服务器证书为第一证书服务器自签名的情况下,第一证书服务器对第一证书进行验证,指的是对由第一服务器证书和第一证书组成的证书链进行验证。在第一服务器证书为pki系统签发给第一证书服务器的情况下,例如,以图3所示的系统架构中的pki系统为例,第二二级ca向第一证书服务器签发第一服务器证书,而第二二级ca的证书为一级ca签发的,一级ca的证书为pki系统的根证书,因此,终端要从pki系统获取根证书、第二二级ca的证书,对由根证书、第二二级ca的证书、第一服务器证书和第一证书组成的证书链进行验证,若证书链验证通过,则第一证书服务器对第一证书验证通过,若证书链验证未通过,则终端可以重新发起签发第一证书的流程。

此外需要说明的是,本申请实施例中终端在第一证书服务器对证书链验证通过后,还可以将第一服务器证书保存到安全执行环境中,并将第一服务器证书锁定保存(即不允许再次修改和删除)。

步骤308,终端针对第一应用,生成第二密钥对。其中,第二密钥对包括第二公钥和第二私钥。

本申请实施例中终端可以响应于首次启动第一应用的操作,针对第一应用生成第二密钥对,也可以在首次运行第一应用的业务时,生成第二密钥对。示例的,终端可以根据针对第一应用预设的密钥算法生成第二密钥对,其中针对第一应用预设的密钥算法可以预先规定密钥的长度、生成密钥对的过程中所使用的参数等。例如,终端可以根据针对第一应用预设的密钥算法生成一个ecc256bit的密钥对,其曲线参数为secp256k1。再例如,针对第一应用预设的密钥算法还可以为随机算法。

可以理解的是,为了便于后续使用第二密钥对,以及考虑到安全性,终端将第二密钥对保存到安全执行环境中。

以图3所示的系统架构中终端的结构为例。终端通过第一应用调用密钥管理模块,向密钥管理ta发送密钥对生成请求,密钥管理ta基于预设的密钥算法生成第二密钥对。密钥管理ta并将第二密钥对存储到安全执行环境中。

此外,为了便于后续查找第二密钥对,在一些实施例中,终端还生成第二密钥对标识。示例的,终端调用密钥管理ta生成第二密钥对标识,并将第二密钥对标识存储到安全执行环境中。

步骤309,终端使用第一私钥签发针对第一应用的应用证书,并将应用证书发送给第一应用对应的第一应用服务器。

需要说明的是,终端使用第一私钥签发针对第一应用的应用证书可以是由终端独立签发的。示例的,以图3所示的系统架构中终端架构为例,终端调用密钥管理ta生成第二密钥对后,将第二公钥通过密钥管理模块发送给第一应用,然后,第一应用调用证书管理模块,通过证书管理模块向证书管理ta发送应用证书注册请求,其中,应用证书注册请求中包括第二公钥,证书管理ta接收到应用证书注册请求后,使用第一私钥签发针对第一应用的应用证书。可以理解的是,针对第一应用的应用证书包括第一公钥。除此之外,针对第一应用的应用证书还可以包括应用证书的证书序列号、应用证书的有效期、应用证书的层级数、第二私钥的最大使用次数、签发机构、第三签名等,其中第三签名为证书管理ta使用第一私钥对应用证书上包括的一个或多个参数(例如第一公钥、应用证书的证书序列号、应用证书的有效期等)的签名。其中,在针对第一应用的应用证书是由终端独立完成的情况下,应用证书上所包括的各个参数均是由终端获取或生成的。

另外,在一些实施例中,为了防止第一私钥的泄露或滥用,本申请实施例中的终端可以在确定第一证书有效后,使用第一私钥签发针对第一应用的应用证书。具体的,本申请实施例中可以由终端验证第一证书是否有效,也可以通过第一证书服务器来验证第一证书是否有效,还可以通过证书服务器系统中的第二证书服务器来验证第一证书是否有效。其中第二证书服务器和第一证书服务器为不同的服务器。本申请实施例中验证第一证书是否有效指的是,验证第一证书的有效期是否超期、第一证书的证书序列号是否在证书吊销列表(certificatesigningrequest,crl)中、第一私钥是否达到最大使用次数等。

下面以第二证书服务器为例,对本申请实施例验证第一证书是否有效的方法进行详细说明。

终端向第二证书服务器发送证书验证请求,其中证书验证请求用于验证第一证书是否有效。第二证书服务器接收到终端发送的证书验证请求后,对第一证书进行验证,并在验证第一证书有效后,向终端发送第一证书验证响应,第一证书验证响应指示第一证书有效。

其中,第二证书服务器可以只对第一证书是否有效进行验证,还可以在对第一证书是否有效进行验证,并在验证第一证书有效后,通过第一证书验证响应携带第二证书服务器下发给终端的针对第一应用的应用证书的参数。

在一些实施例中,证书验证请求可以包括第四签名以及签名数据,第四签名为终端使用第一私钥对签名数据的签名。

示例的,在第二证书服务器只对第一证书是否有效进行验证的情况下,签名数据可以包括应用证书的证书序列号、第一证书的证书序列号等参数,应用证书的证书序列号为终端生成的。此外,签名数据中还可以包括随机挑战字,其中随机挑战字用于防重放攻击,可以为终端生成的,也可以为第二证书服务器下发给终端的,当随机挑战字为第二证书服务器下发给终端时,签名数据中可以不包括随机挑战字,但是第四签名为终端使用第一私钥对签名数据和随机挑战字的签名。第二证书服务器接收到证书验证请求后,首先验证第一证书是否有效,当第一证书有效时,使用第一证书验证第四签名,若使用第一证书验证第四签名通过,则向终端发送第一证书验证响应,第一证书验证响应指示第一证书有效。例如,第一证书验证响应可以为授权码,授权码为第二证书服务器使用第二服务器证书对应的私钥对应用证书的证书序列号和时间戳(timestamp)的签名。终端接收到第一证书验证响应后,使用第二服务器证书对授权码进行验证,若验证通过则确定第一证书有效。

又示例的,在第二证书服务器对第一证书是否有效进行验证,并在第一证书有效时向终端发送针对第一应用的应用证书的参数的情况下,签名数据可以包括第一证书的证书序列号、应用标识、第二密钥对标识、随机挑战字、时间戳、单调计数器等。其中,随机挑战字用于防重放攻击,可以为终端生成的,也可以为第二证书服务器下发给终端的,在随机挑战字为第二证书服务器下发给终端的情况下,签名数据中也可以不包括随机挑战字,但是第四签名为终端使用第一私钥对签名数据和随机挑战字的签名。第二证书服务器接收到证书验证请求后,首先验证第一证书的是否有效,若第一证书有效,则使用第一证书验证第四签名,若验证通过,则根据应用标识和/或第二密钥对标识,确定下发给终端的针对第一应用的应用证书的参数,例如,应用证书的证书序列号、应用证书的有效期等。

示例的,应用证书的证书序列号可以由第二证书服务器根据随机算法得到的,也可以是由第二证书服务器根据第一证书的证书序列号、应用标识(例如第一应用的包名、第一应用的名称等)、第二密钥对标识,基于预设密钥算法得到的。其中,应用证书的证书序列号是唯一的。例如,应用证书的证书序列号=hmac(第一证书的证书序列号,应用标识,第二密钥对标识,server_secret2,random2)+应用标识+第二密钥对标识+random2。server_secret2为仅有第二证书服务器知道的秘密值,可保存在hsm中。random2为随机值。hmac为密码学哈希算法,如hmac-sha256。

此外,需要说明的是,第二证书服务器下发给终端的针对第一应用的应用证书的参数的含义和用途可以由第二证书服务器和终端事先约定好,例如针对第一应用的应用证书中的部分证书参数可以由终端确定,如应用证书的签发机构、签发日期、签名算法等,针对第一应用的应用证书中的另一部分证书参数可以由第二证书服务器确定,例如应用证书的证书序列号、应用证书的有效期、第二私钥的最大使用次数、证书/密钥的层级数等。需要说明的是,对于不同的应用,第二证书服务器和终端事先约定可以不同,例如,对于第一应用,由第二证书服务器确定应用证书的证书序列号,由终端确定应用证书的有效期;而对于第二应用,由第二证书服务器确定应用证书的有效期,而终端确定应用证书的序列号。

第二证书服务器在确定需要下发给终端的针对第一应用的应用证书的参数后,使用第二证书服务器对应的私钥对需要下发给终端的针对第一应用的应用证书的参数进行签名,得到第五签名。第二证书服务器向终端发送第一证书验证响应,第一证书验证响应包括需要下发给终端的针对第一应用的应用证书的参数以及第五签名时,第一证书验证响应指示第一证书有效。

在这种情况下,终端接收到第一证书验证响应后,使用第二服务器证书对第五签名进行验证,若验证通过,则根据第二证书服务器下发给终端的针对第一应用的应用证书的参数,使用第一私钥签发针对第一应用的应用证书。

在另一些实施例中,第二证书服务器验证第一证书无效,向终端发送第二证书验证响应,第二证书验证响应指示第一证书无效。终端接收到第二证书服务器发送的第二证书验证响应后,向第一证书服务器发起重新签发第一证书的流程。示例的,终端接收到第二证书服务器发送的第二证书验证响应后,重新执行步骤304~步骤307,签发新的第一证书。

示例的,终端将应用证书发送给第一应用对应的第一应用服务器,可以通过下列方式具体实现:终端的第一应用通过证书管理客户端调用证书管理ta,从安全执行环境获取应用证书,然后将应用证书发送给第一应用服务器。

步骤310,第一应用服务器接收到应用证书后,对应用证书进行验证,若验证通过保存应用证书。

示例的,本申请实施例中第一应用服务器对应用证书进行验证可以通过下列方式实现:

在第一服务器证书是由第一证书服务器自签发的情况下,第一应用服务器可以对由第一服务器证书、第一证书和应用证书组成的证书链进行验证。

在第一服务器证书是由pki系统中的第二二级ca签发的情况下,第一应用服务器可以对由根证书、第二二级ca的证书、第一服务器证书、第一证书和应用证书组成的证书链进行验证。

步骤311,终端使用第二私钥对待发送给第一应用服务器的数据进行签名,并将签名后的数据发送给第一应用服务器。

在一些实施例中,终端验证应用证书是否有效,例如,验证应用证书的有效期是否超期、应用证书的证书序列号是否在crl中等。终端在验证应用证书有效后,使用第二私钥对待发送给第一应用服务器的数据进行签名。考虑到安全性,终端调用证书管理ta在安全执行环境内验证应用证书是否有效。

终端当验证应用证书失效,例如应用证书的有效期超期、或者应用证书的证书序列号在crl中,则针对第一应用重新执行应用证书的签发流程。

步骤312,第一应用服务器接收到终端发送的签名后数据。

由于图3所示的数据发送的方法中,应用证书是通过第一证书对应的第一私钥签发的,而第一证书与设备证书不同,因而与采用设备证书对应的签发应用证书相比,避免了用户隐私的泄露。

本申请实施例如图3所示的数据发送方法中,终端可以在首次开机、或者重置时,向第一证书服务器发起签发第一证书的流程。示例的,终端在首次开机、或者重置时,执行步骤304~步骤307。本申请实施例中的重置指的是将终端的设置恢复或还原为出厂设置。

此外,本申请实施例中终端还可以在第一时刻,向第一证书服务器发起签发第一证书的流程;其中第一时刻为预设时长内的任一时刻,终端在预设时长后到达第二证书的有效期,第二证书为第一证书服务器签发所述第一证书之前签发的证书,第二证书对应的私钥用于在第一证书签发之前签发应用证书。

例如,第一证书0可以在终端生产阶段预置到终端中,第一证书0可以为设备证书,也可以为使用第一证书服务器对应的私钥签发的证书。终端可以使用第一证书0对应的私钥签发应用证书。例如第一证书0的有效期为从2018年1月1号到2018年6月5号,预设时长为5天,则终端2018年6月1号至2018年6月5号之间的任一时刻,可以发起签发第一证书1的流程,然后并在签发第一证书1后,吊销第一证书0,使用签发后的第一证书1代替第一证书0。以此类推,在第一证书0即将到期时,可以通过申请签发第一证书2来代替第一证书1。具体的,签发第一证书的过程可以参见本申请实施例中图3所示的步骤304~步骤307。

以签发第一证书1、吊销第一证书0为例,终端向第一证书服务器发送的第一证书注册请求中除了包括新生成的第一公钥以外,还包括第一证书0的证书序列号或者第一证书0,以使得第一证书服务器在签发第一证书1后,将第一证书0的证书序列号增加到crl中或者删除第一证书0。另外,为了使得第一证书服务器确定接收到的第一证书注册请求的可靠性和完整性,第一证书注册请求中还可以包括使用第一证书0对应的私钥的签名,其中使用第一证书0对应的私钥的签名的数据可以包括新生成的第一公钥、第一证书0的证书序列号或者第一证书0等。

由于终端集中上市,使得终端在首次开机时向证书服务器发起签发第一证书的流程,有可能会导致证书服务器侧处理的请求较多,提高证书服务器的成本,而通过在终端生产阶段预置第一证书,使得证书服务器接收到签发第一证书的请求随机化,将对第一证书服务器的请求分散到一定的时间范围内,降低了对服务器的资源要求。

此外,终端当检测到第一私钥丢失或者无法使用时,也可以向第一证书服务器发起重新签发第一证书的流程。

还需要说明的是,本申请实施例中,第一证书服务器可以为一种终端签发两个第一证书,其中一个第一证书用于签发应用证书,另一个第一证书用于终端验证。

另外,为了提高第一证书的签发效率,还可以由第一证书服务器生成第一密钥对,为终端签发第一证书,使得第一证书服务器可以同时为多个终端签发第一证书。在此过程中为了保证第一证书服务器和终端之间数据传输的可靠性、完整性和安全性,在终端生产阶段第一证书服务器预置两个可信根,在终端预置该两个可信根分别对应的私钥。其中可信根的具体实现方式可参见图2数据发送的方法中可信根的具体实现方式,在此不再赘述。以可信根和可信根对应的私钥为非对称密钥对为例,例如,在终端生产阶段第一证书服务器预置公钥a和公钥b,在终端预置私钥a和私钥b,私钥a和公钥a互为非对称密钥对,私钥b和公钥b互为非对称密钥对。下面以在终端生产阶段第一证书服务器预置公钥a和公钥b,在终端预置私钥a和私钥b为例,对本申请实施例提供的另一数据发送的方法进行详细介绍。

示例的,如图4所示,本申请实施例提供的另一数据发送的方法,包括以下步骤。

步骤401,终端向pki系统发送csr。

步骤402,pki系统接收到csr后,为终端签发设备证书。

步骤403,终端接收到pki系统签发的设备证书后,将设备证书保存到安全执行环境中。

其中步骤401~步骤403的具体实现方式可参见本申请实施例中图3数据发送的方法中步骤301~步骤303的相关介绍,在此不再赘述。

步骤404,终端向第一证书服务器发送第一证书注册请求。

为了使得第一证书服务器确定第一证书注册请求是终端发送给第一证书服务器的,第一证书注册请求包括签名1和签名数据,其中签名1为终端使用私钥1对签名数据的签名,签名数据包括随机挑战字1,其中,随机挑战字1用于防重放攻击。在一些实施例中,随机挑战字1为第一证书服务器发送给终端的。第一证书服务器是在接收到终端发送的获取随机挑战字的请求发送给终端的。示例的,终端可以在首次开机时,向第一证书服务器发送获取随机挑战字的请求,也可以在重置时,向第一证书服务器发送随机挑战字的请求,还可以在需要更新或删除第一证书时向第一证书服务器发送获取随机挑战字的请求。需要说明的是,签名数据除了可以包括随机挑战字1以外,还可以包括设备标识、私钥1与公钥1组成的非对称密钥对1的标识等。设备标识和非对称密钥对1的标识可以便于第一证书服务器在接收到第一证书注册请求后获取公钥1对签名1进行验证。

以图2所示的系统架构中的终端架构为例,终端通过调用证书管理客户端向第一证书服务器发送获取随机挑战字的请求,第一证书服务器响应于获取随机挑战字的请求向终端发送随机挑战字1,终端调用证书管理客户端接收第一证书服务器发送的随机挑战字1。终端调用证书管理客户端将随机挑战字发送给证书管理ta,证书管理ta在安全执行环境中使用私钥1对随机挑战字1、设备标识、非对称密钥对1的标识等进行签名得到签名1。然后证书管理ta将签名1及除随机挑战字1以外的相关签名数据(如设备标识、非对称密钥对1的标识等)发送给证书管理客户端。证书管理客户端通过第一证书注册请求将签名1及除随机挑战字1以外的相关签名数据发送给第一证书服务器。

为了保证终端向第一证书服务器发送第一证书注册请求的安全性,在终端向第一证书服务器发送第一证书注册请求之前,建立终端与第一证书服务器之间数据传输的安全通道,以实现数据的加密传输,例如,可以基于https协议建立终端与第一证书服务器之间数据传输的安全通道,也可以基于其它协议,对此本申请实施例不作限定。

步骤405,第一证书服务器接收到第一证书注册请求后,生成第一密钥对,其中第一密钥对包括第一公钥和第一私钥。需要说明的是,通常情况下,第一密钥对为非对称密钥对。

示例的,在第一证书注册请求包括签名1和除随机挑战字以外的相关签名数据的情况下,第一证书服务器根据设备标识、非对称密钥对1的标识获取公钥1,使用公钥1对签名1进行验证,若验证通过,则确定对终端认证通过。然后第一证书服务器生成第一密钥对。需要说明的是,在多个终端的设备证书相同的情况下,第一证书服务器可以提前生成第一密钥对并将第一密钥对与设备标识的对应关系保存在第一证书服务器的hsm中,然后第一证书服务器可以通过设备标识,获取第一密钥对。

步骤406,第一证书服务器使用第一服务器证书对应的私钥签发第一证书,其中第一证书包括第一公钥。第一证书与设备证书不同。

需要说明的是,第一证书还包括第一服务器证书对应的私钥的签名、第一证书的证书序列号、第一证书的有效期等。其中第一证书的证书序列号是由第一证书服务器为终端分配的,具体的分配方式可以参见图3所示的数据发送方法中第一证书的证书序列号的分配方式,在此不再赘述。

步骤407,第一证书服务器向终端发送第一证书注册响应,第一证书注册响应包括第一证书和加密后的第一私钥。

示例的,第一私钥是使用公钥b加密的。另外,为了保证第一私钥的完整性和可靠性,在一些实施例中,第一证书服务器使用第一服务器证书对应的私钥对第一私钥进行签名,得到签名2,然后使用公钥b对签名2和第一私钥进行加密。在一些实施例中,为了防重放攻击,终端还可以将随机挑战字2携带在第一证书注册请求中发送给第一证书服务器。第一证书服务器使用第一服务器证书对应的私钥对第一私钥和随机挑战字2进行签名,得到签名2。

此外,本申请实施例中还可以先使用公钥b对第一私钥加密,并使用第一服务器证书对应的私钥对随机挑战字2和加密后的第一私钥进行签名,得到签名2。然后第一证书服务器将签名2、以及加密后的第一私钥携带在第一证书注册请求中发送给终端。

步骤408,终端接收第一证书服务器发送的第一证书注册响应,并将第一证书和第一私钥保存到安全执行环境中。

在一些实施例中,终端通过调用证书管理客户端接收第一证书注册响应,将第一证书注册响应发送给证书管理ta,证书管理ta从第一证书注册响应中获取第一证书和第一私钥,并将第一证书和第一私钥保存到安全执行环境中。

例如,第一证书注册响应包括第一证书、使用公钥b加密的第一私钥和使用第一服务器证书对应的私钥对随机挑战字2和加密的第一私钥进行签名得到的签名2,在第一证书服务器证书为pki系统中第二二级ca签发的情况下,证书管理ta可以获取根证书、第二二级ca的证书和第一服务器证书,对由根证书、第二二级ca证书、第一服务器证书和第一证书组成的证书链进行验证;证书管理ta使用第一服务器证书对签名2进行验证,若第一证书和签名2的验证均通过,则证书管理ta根据私钥2对加密的第一私钥进行解密,得到第一私钥,并将第一证书和第一私钥存储到安全执行环境中。

再例如,第一证书注册响应包括第一证书、使用公钥b加密的第一私钥和签名2,签名2为使用第一服务器证书对应的私钥对随机挑战字2和第一私钥进行签名得到的。证书管理ta对第一证书进行验证,以及使用私钥b对使用公钥b加密的第一私钥和签名2解密得到第一私钥和签名2,然后使用第一服务器证书对签名2进行验证,并在第一证书和签名2验证均通过后,将第一证书和第一私钥存储到安全执行环境中。

步骤409,终端针对第一应用生成第二密钥对,第二密钥对包括第二公钥和第二私钥。

步骤410,终端使用所述第一私钥签发针对所述第一应用的应用证书,并将应用证书发送给第一应用对应的第一应用服务器,应用证书包括第二公钥。

步骤411,第一应用服务器接收到应用证书后,对应用证书进行验证,若验证通过,则保存应用证书。

步骤412,终端使用第二私钥对待发送给第一应用服务器的数据进行签名,并将签名后的数据发送给第一应用服务器。

步骤413,第一应用服务器接收到终端发送的签名后数据,使用应用证书验证签名后的数据,若验证通过,则根据该数据,进行相应的处理。

其中,步骤409~步骤413的具体实现方式可参见图3所述的数据发送方法中步骤308~步骤312的具体实现方式,在此不再赘述。

此外,图4所示的数据发送方法中终端发起向第一证书服务器签发第一证书的流程的触发方式,也可参见图3所示的数据发送方法中终端发起向第一证书服务器签发第一证书的流程的触发方式,在此不再赘述。

本申请实施例中还可以无需签发第一证书,直接使用设备证书签发应用证书,考虑到安全性,在签发应用证书之前,终端可以通过第二证书服务器对设备证书的有效性进行相应的验证,在确定设备证书有效后,再使用设备证书对应的私钥签发应用证书。

示例的,如图5所示,本申请实施例提供了另一种数据发送的方法包括以下步骤。

步骤501,终端向pki系统发送csr。

步骤502,pki系统接收到csr后,为终端签发设备证书。

步骤503,终端接收到pki系统签发的设备证书后,将设备证书保存到安全执行环境中。

其中步骤501~步骤503的具体实现方式可参见本申请实施例中图3数据发送的方法中步骤301~步骤303的相关介绍,在此不再赘述。

步骤504,终端针对第一应用生成第二密钥对,密钥对包括第二公钥和第二私钥;

步骤505,终端向第二证书服务器发送证书验证请求,证书验证请求用于指示证书服务器验证设备证书是否有效。

步骤506,第二证书服务器接收到证书验证请求后,验证设备证书是否有效,若设备证书有效,则向终端发送第一证书验证响应。

需要说明的是,第二证书服务器验证设备证书是否有效的方式可以参见图3所示的数据发送的方法中第二服务器验证第一证书是否有效的方式。另外,在一些实施例中,在第二证书服务器验证设备证书有效的情况下,还可以第二证书服务器通过第一证书验证响应向终端下发针对第一应用的应用证书的证书参数,例如应用证书的证书序列号、应用证书的有效期等。具体的,第二证书服务器通过第一证书验证响应向终端下发针对第一应用的应用证书的证书参数的方式,也可参见图3所示的数据发送方法中第二证书服务器通过第一证书验证响应向终端下发针对第一应用的应用证书的证书参数的方式。

在另一些实施例中,第一证书响应还可以为授权码,其中授权码的具体实现方式可参见图3所示的数据发送方法中授权码的实现方式。

步骤507,终端接收到第一证书验证响应后,则使用设备证书对应的私钥签发针对第一应用的应用证书,并将应用证书发送给第一应用对应的第一应用服务器,应用证书包括第二公钥;第一证书验证响应指示设备证书有效。

步骤508,第一应用服务器接收到应用证书后,对应用证书进行验证,若验证通过,则保存应用证书。

步骤509,终端使用第一私钥对待发送给第一应用服务器的数据进行签名,并将签名后的数据发送给第一应用服务器。

步骤510,第一应用服务器接收到终端发送的签名后数据,使用应用证书验证签名后的数据,若验证通过,则根据该数据,进行相应的处理。

其中,步骤504、步骤507~步骤510的具体实现方式可参见图3所述的数据发送方法中步骤308~步骤312的具体实现方式,在此不再赘述。

在一些实例中,第二证书服务器若验证设备证书失效,可以向终端发送第二证书验证响应,第二证书验证响应指示所述设备证书失效;终端接收到第二证书验证响应后,向用户提示设备证书失效的信息。例如,终端可以通过在显示屏上显示提示信息,来提示用户设备证书失效的信息。

需要说明的是,本申请实施例涉及的使用证书对签名进行验证,或者使用公钥对签名进行验证的方式可参见现有技术中的验证方式,也可以采用其他的验证方式,本申请实施例对签名验证的具体实现方式不作限定。

本申请实施例中的上述各个实施例可相互结合使用,也可以单独使用,以实现不同的技术效果。

上述本申请提供的实施例中,从终端、pki系统、第一证书服务器、第二证书服务器和应用服务器作为执行主体的角度对本申请实施例提供数据发送的方法进行了介绍。为了实现上述本申请实施例提供数据发送的方法中的各功能,终端可以包括硬件结构和/或软件模块,以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行,取决于技术方案的特定应用和设计约束条件。

基于相同的构思,如图6所示,本申请实施例提供了一种电子设备600,包括处理模块610和收发模块620。其中,处理模块610与收发模块620耦接,本申请实施例中的耦接是装置、单元或模块之间的间接耦合或通信连接,可以是电性,机械或其它的形式,用于装置、单元或模块之间的信息交互。

在一些实施例中,电子设备600用以执行图3所示的数据发送方法中终端执行的步骤,则收发模块620用于执行图3所示的数据发送方法中的步骤301、步骤302、步骤305、步骤306、步骤309以及步骤311;处理模块610用于执行图3所示的数据发送方法中的步骤303、步骤304、步骤307、和步骤308。

在另一些实施例中,电子设备600用以执行图4所示的数据发送方法中终端执行的步骤,则收发模块620用于执行图4所示的数据发送方法中的步骤401、步骤402、步骤404、步骤407、步骤410以及步骤412;处理模块610用于执行图4所示的数据发送方法中的步骤403、步骤408、和步骤409。

在另一些实施例中,电子设备600用以执行图5所示的数据发送方法中终端执行的步骤,则收发模块620用于执行图5所示的数据发送方法中的步骤501、步骤502、步骤505、步骤506、步骤507以及步骤508;处理模块610用于执行图4所示的数据发送方法中的步骤503、和步骤504。

在另一些实施例中,电子设备600用以执行图3所示的数据发送方法中第一证书服务器执行的步骤,则收发模块620用于执行图3所示的数据发送方法中的步骤305和步骤306;处理模块610用于生成第一证书。

在另一些实施例中,电子设备600用以执行图4所示的数据发送方法中第一证书服务器执行的步骤,则收发模块620用于执行图4所示的数据发送方法中的步骤404和步骤407;处理模块610用于执行图4所示的数据发送方法中的步骤405和步骤406。

在另一些实施例中,电子设备600用以执行图5所示的数据发送方法中第二证书服务器执行的步骤,则收发模块620用于执行图5所示的数据发送方法中的步骤505和步骤506;处理模块610用于执行图4所示的数据发送方法中的验证设备证书是否有效的步骤。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

基于相同的构思,图7所示为本申请实施例提供的一种装置700。装置700包括处理模块701和收发模块702。其中,收发模块702用于接收或发送数据,可以通过收发机实现。具体的,收发模块702为具有收发功能的模块,可以包括接收模块和发送模块,其中接收模块用于接收数据,发送模块用于发送数据。若装置700为终端设备,处理模块701用于执行图4所示的通信方法中由终端设备执行的步骤。若装置700为网络设备,处理模块701用于执行图4所示的通信方法中由网络设备执行的步骤。

基于相同的构思,如图7所示,本申请提供的一种电子设备700。示例的,电子设备700包括至少一个处理器710、存储器720和收发器730。其中,处理器710与存储器720和收发器730耦合,本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接,可以是电性,机械或其它的形式,用于装置、单元或模块之间的信息交互。

其中,收发器730用于接收或发送数据。收发器730可以包括接收机和发送机,接收机用于接收数据,发送机用于发送数据。存储器720用于存储程序指令。处理器710用于调用存储器720中存储的程序指令,结合收发器730执行本申请实施例图3、图4或图5所示的数据发送的方法。

其中,处理器710可以采用通用的中央处理器(centralprocessingunit,cpu)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit,asic),或者一个或多个集成电路,用于执行相关操作,以实现本申请实施例所提供的技术方案。

需要说明的是,在电子设备700为终端的情况下,处理器710调用存储器720中存储的程序指令,实现本申请实施例图3、图4或图5所示的数据发送的方法中由终端执行的步骤。在电子设备700为第一证书服务器的情况下,处理器710调用存储器720中存储的程序指令,实现本申请实施例图3或图4所示的数据发送的方法中由第一证书服务器执行的步骤。在电子设备700为第二证书服务器的情况下,处理器710调用存储器720中存储的程序指令,实现本申请实施例图3、图4或图5所示的数据发送的方法中由第二证书服务器执行的步骤。

应注意,尽管图7所示的电子设备700仅仅示出了处理器710、收发器730和存储器720,但是在具体实现过程中,本领域的技术人员应当明白,该电子设备700还包含实现正常运行所必须的其他器件。同时,根据具体需要,本领域的技术人员应当明白,该电子设备700还可包含实现其他附加功能的硬件器件。此外,本领域的技术人员应当明白,该电子设备700也可仅仅包含实现本申请实施例所必须的器件或模块,而不必包含图7中所示的全部器件。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

所属领域的技术人员可以清楚地了解到本申请实施例可以用硬件实现,或固件实现,或它们的组合方式来实现。当使用软件实现时,可以将上述功能存储在计算机可读介质中或作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质,其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是计算机能够存取的任何可用介质。以此为例但不限于:计算机可读介质可以包括ram、rom、电可擦可编程只读存储器(electricallyerasableprogrammablereadonlymemory,eeprom)、只读光盘(compactdiscread-onlymemory,cd-rom)或其他光盘存储、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质。此外。任何连接可以适当的成为计算机可读介质。例如,如果软件是使用同轴电缆、光纤光缆、双绞线、数字用户线(digitalsubscriberline,dsl)或者诸如红外线、无线电和微波之类的无线技术从网站、服务器或者其他远程源传输的,那么同轴电缆、光纤光缆、双绞线、dsl或者诸如红外线、无线和微波之类的无线技术包括在所属介质的定影中。如本申请实施例所使用的,盘(disk)和碟(disc)包括压缩光碟(compactdisc,cd)、激光碟、光碟、数字通用光碟(digitalvideodisc,dvd)、软盘和蓝光光碟,其中盘通常磁性的复制数据,而碟则用激光来光学的复制数据。上面的组合也应当包括在计算机可读介质的保护范围之内。

显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1