一种签名数据的生成及指纹认证请求方法及装置

摘要

本申请公开了一种签名数据的生成及指纹认证请求方法及装置，签名数据的生成包括：在富执行环境中设置指纹名称及绑定的用户；在可信执行环境中采集指纹并生成标识；在可信执行环境中建立标识、指纹名称及绑定的用户之间的映射关系；使用安全元件存储的私钥签名将映射关系生成供公钥验证的签名数据。指纹认证请求包括：接收应用发出的指纹验证请求；在富执行环境中获取该指纹的标识、绑定的用户；使用安全元件存储的公钥对该指纹的标识、绑定的用户进行加密，并用安全元件存储的私钥签名生成供认证中心验证的签名数据后，向指纹验证请求接收端发送携带有加密后的数据以及签名数据的指纹验证请求。

说明书

技术领域

本申请涉及数据安全领域，特别涉及一种签名数据的生成及指纹认证请求方法及装置。

背景技术

现有技术中，对于采用指纹认证的方式而言，在线下操作中，以指付通及支付宝为典型代表，其注册过程复杂，需要引导用户；在线上操作中，指纹认证过程依赖于OEM(Original Equipment Manufacturer，原始设备制造商)提供的API(Application Programming Interface，应用程序编程接口)，以APPle等手机厂商提供指纹接口为典型代表，其由APP(Application，应用)开发者开发应用。在采用指纹认证过程中至少需要执行以下操作：开启手机、打开APP、登录账户、再指纹支付认证。类似的APP还有关团、大众点评信用卡还款等。

可见，现有技术的不足在于：由于指纹认证过程依赖于OEM提供的API，导致认证路径过长，体验差，线下注册流程繁琐。

发明内容

本申请实施例中提供了一种签名数据的生成及指纹认证请求方法及装置，用以提供一种签名数据的生成方案，并在该方案下提供指纹认证请求的方案，用以减短指纹认证过程中认证路径。

本申请实施例中提供了一种签名数据的生成方法，包括如下步骤：

在REE中确定指纹管理对象；

在TEE中采集指纹；

在所述指纹管理对象设置指纹名称及绑定的用户；

在TEE中为采集的指纹生成标识；

在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系；

将所述映射关系传入SE后，使用SE存储的私钥签名生成供公钥验证的第一签名数据。

本申请实施例中提供了一种指纹认证请求方法，包括如下步骤：

接收APP发出的第一指纹验证请求；

在REE中验证该指纹，获取该指纹的标识、该指纹绑定的用户；

将其传入SE后，使用SE存储的公钥对该指纹的标识、该指纹绑定的用户进行加密，并用SE存储的私钥签名生成供认证中心验证的第二签名数据，其中，SE存储的公钥是在上述方法中生成的第一签名数据经公钥验证后返回的，所述加密后的数据是供认证中心用该指纹绑定的用户的私钥解密的；

向指纹验证请求接收端发送第二指纹验证请求，所述第二指纹验证请求中携带有所述加密后的数据以及第二签名数据。

本申请实施例中提供了一种签名数据的生成装置，包括：

指纹管理模块，用于在REE中确定指纹管理对象；

指纹管理TA模块，用于在TEE中采集指纹；

指纹业务模块，用于在所述指纹管理对象设置指纹名称及绑定的用户；

指纹管理TA模块进一步用于在TEE中为采集的指纹生成标识；在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系；将所述映射关系传入SE后，使用SE存储的私钥签名生成供公钥验证的第一签名数据。

本申请实施例中提供了一种指纹认证请求装置，包括：

指纹管理模块，用于接收APP发出的第一指纹验证请求；在REE中验证该指纹；

指纹管理TA模块，用于获取该指纹的标识、该指纹绑定的用户；将其传入SE后，使用SE存储的公钥对该指纹的标识、该指纹绑定的用户进行加密，并用SE存储的私钥签名生成供认证中心验证的第二签名数据，其中，SE存储的公钥是在上述方法中生成的第一签名数据经公钥验证后返回的，所述加密后的数据是供认证中心用该指纹绑定的用户的私钥解密的；

指纹管理模块进一步用于向指纹验证请求接收端发送第二指纹验证请求，所述第二指纹验证请求中携带有所述加密后的数据以及第二签名数据。

本申请有益效果如下：

在本申请实施例提供的技术方案中，在REE(Rich Execution Environment，富执行环境；也叫做Rich OS，即手机操作系统Android、IOS等)中确定指纹管理对象后，在TEE(Trusted Execution Environment，可信执行环境)中采集指纹并为该指纹生成标识；然后将REE中设置的指纹名称及绑定的用户送至TEE中与该指纹标识建立映射关系，最后使用SE(Secure element，安全元件)存储的私钥签名生成供公钥验证的第一签名数据。由于TEE中最后生成的第一签名数据只来自REE中确定指纹管理对象的APP，使得在TEE中事实上只有一个TA(trustAPP，可信APP)，也即在REE中确定指纹管理对象的APP；并且，由于是在REE中的指纹管理对象设置指纹名称及绑定用户的，因此账户体系显然是与REE集成的，可以预见，在采用该第一签名数据进行支付等认证时，指纹的绑定和支付都可以在TEE中实现，在保证了安全的前提下，可以通过统一的账号体系，将账户体系和REE深入集成，减少整个支付路径，实现不开启native(本地)应用即可完成支付。

具体的，则是在指纹认证请求时，当REE接收到诸如需要认证的支付等类型的APP发出的第一指纹验证请求后，由于REE的指纹管理对象中存在指纹名称及绑定用户，因此REE可以验证该指纹，并获取该指纹的标识、该指纹绑定的用户；再传入TEE后，使用SE存储的公钥进行加密，并用SE存储的私钥签名生成供认证中心验证的第二签名数据，此时其中SE存储的公钥则是第一签名数据经公钥验证后返回的，而加密后的数据也是供认证中心用该指纹绑定的用户的私钥解密的；最后，向指纹验证请求接收端发送的是携带有加密后的数据以及第二签名数据的第二指纹验证请求。

由于在REE接收到APP需要认证的请求后，即转入TEE中形成发送给认证中心等接收端的指纹验证请求，这期间，是在TEE的保障下由REE直接与认证中心形成的验证过程，不再依赖于OEM提供的API，需要认证的APP不再需要依靠APPle等手机厂商提供指纹接口，也无需独自完成整个认证流程，

附图说明

图1为本申请实施例中签名数据的生成方法实施流程示意图；

图2为本申请实施例中指纹支付中的账户处理流程示意图；

图3为本申请实施例中指纹认证请求方法实施流程示意图；

图4为本申请实施例中指纹支付中的认证请求处理流程示意图；

图5为本申请实施例中签名数据的生成装置结构示意图；

图6为本申请实施例中指纹认证请求装置结构示意图。

具体实施方式

下面结合附图对本申请的具体实施方式进行说明。

下面先对现有网络安全中的认证过程进行简单说明，下面具体将以Bob和Alice这两个虚拟人物来进行实例说明。

CA(Certificate Authority，证书授权中心，或称证书授权机构，也可简称认证中心)作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任，Bob从CA中心获得一个数字证书的流程可以为：

1、Bob首先创建他自己的密钥对(key pair)，包含公钥和私钥；

2、Bob通过网络把他的公钥送到CA中心，公钥中包含了Bob的个人鉴别信息(他的名字、地址、所用设备的序列号等等)。这些信息是证书所必需的；

3、这个证书申请在CA中心服务器上会一直处于等待(pending)状态，直到CA中心的某人开始处理Bob的请求；

4、在CA中心的某人鉴定并确认了Bob确实是那个提交公钥的人。为了确定Bob和密钥之间的对应关系，这个确认过程会通过某种人和人之间、带外的方式进行；

5、Bob定期地对CA服务器进行查询，希望他的证书申请过程能完成并已可取回；

6、CA中心创建并签署一个包含Bob的公钥及个人信息的证书，从而保证密钥的确实性；

7、Bob查询CA服务器，发现证书已准备好，马上下载证书并将证书存储起来；

8、Bob现在可以使用证书来发布他的公钥，而其他使用Bob证书的人可以通过检验CA中心的签名(检验CA签名需要CA的公钥)来验证证书的确实性。

与本申请实施例有关的步骤为：

第2步的“Bob通过网络把他的公钥送到CA中心，公钥中包含了Bob的个人鉴别信息(他的名字、地址、所用设备的序列号等等)。这些信息是证书所必需的”；下述实施例中，将映射关系传入SE后，使用SE存储的私钥签名生成供公钥验证的第一签名数据，该第一签名数据即用以供网络侧的CA等设备生成证书。

下述实施例中，将其传入SE后，使用SE存储的公钥对该指纹的标识、该指纹绑定的用户进行加密，并用SE存储的私钥签名生成供认证中心验证的第二签名数据，其中，加密后的数据是供认证中心用该指纹绑定的用户的私钥解密的，SE存储的公钥是生成第一签名数据经公钥验证后返回的，也即第8步中的使用证书发布的公钥。

图1为签名数据的生成方法实施流程示意图，如图所示，可以包括如下步骤：

步骤101、在REE中确定指纹管理对象；

步骤102、在TEE中采集指纹；

步骤103、在所述指纹管理对象设置指纹名称及绑定的用户；

步骤104、在TEE中为采集的指纹生成标识；

步骤105、在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系；

步骤106、将所述映射关系传入SE后，使用SE存储的私钥签名生成供公钥验证的第一签名数据。

实施中，步骤102、103、104并无绝对的时序关系，只要保证在步骤105建立映射关系之前，能够在TEE中获得这三个数据即可，这是容易为本领域技术人员知晓的，不再赘述。

实施中，在TEE中采集指纹，可以是通过TEE提供给REE的API，在TEE中采集指纹。

实施中，在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系时，标识可以是通过TEE提供给REE的API提供给TEE的。

具体的，手机执行环境可分为REE、TEE、SE(Secure Element，安全元件；如SIM(Subscriber Identity Module，用户身份识别模块)卡、NFC(NearField Communication，近距离无线通讯技术)的安全模块等)。从安全性、可开发、运行体验上看，TEE取得了最佳平衡，TEE能够兼顾安全性、可开发性、运行体验。

TEE是由GP(GlobalPlatform，跨行业的国际标准组织)提出的，是一套开放的安全体系架构，以低成本解决移动安全应用问题，即针对移动支付、移动商务、数字版权等安全业务提供适度安全解决方案。

TEE的思路是在智能终端内部构建一个硬件可信环境，作为TEE可信环境与原有系统环境交换的桥梁，这个可信环境与原有系统环境并行，共用一套、实际是并行嵌入一个嵌入式安全系统，该嵌入式安全系统可以通过安全API与原有操作系统进行通信。

本实施例中，采用通用的API即可，具体的如：TEE CLIENT。

实施中，下述步骤之一或者其组合可以是通过TA执行的：

在TEE中采集指纹；

在TEE中为采集的指纹生成标识；

在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系；

将所述映射关系传入SE后，使用SE存储的私钥签名生成供公钥验证的签名数据。

下面以实例来进行说明，以便更好地理解本方案的实施。

图2为指纹支付中的账户处理流程示意图，为了更好地理解实施，图中用以执行各步骤的功能模块分别有：用于对用户进行管理，管理指纹支付业务的指纹业务模块，用于确定、管理指纹管理对象的指纹管理模块，TEE提供给REE通信的API：TEE CLIENT，用于管理指纹采集的可信APP：指纹管理TA模块，用于采集指纹的传感器：指纹sensor模决，用于存储密钥的SE；

另外，按业界习惯，图中的实线表示消息调用，虚线表示调用返回。

实施时，本实施例可以用于解决帐号绑定的处理，该过程可以在两个时机实施，一个是在REE第一次激活的时候；另一个是在REE的设置里面录入。实施中的REE指的是终端的REE，例如：ios、android、winphone等，实施中对REE没有特别要求，一般的REE都可在其上实施本例。本实施例中，在REE的录入过程中即可直接实现绑定，需要注意的，从本实施例的实施可以看出并不需要再在支付APP中实现绑定。下面以录入过程中的实施为例进行说明。

则如图所示，可以包括如下步骤：

步骤201、指纹业务模块向指纹管理模块获取指纹管理对象；

具体的，指纹业务模块可以通过调用指纹管理模块获取指纹管理对象。

步骤202、指纹管理模块创建指纹管理对象；

步骤203、指纹管理模块向指纹业务模块返回指纹管理对象指令：FP_manage；

步骤204、指纹业务模块通过通过指纹管理对象调用指纹录入接口，录入指纹；

具体的，指纹业务模块可以通过TEE CLIENT调用到TEE中的指纹管理TA模块，开始录入指纹。

步骤205、指纹管理TA模块初始化指纹sensor模块；

步骤206、指纹管理TA模块向指纹sensor模块发送采集指纹指令；

步骤207、指纹sensor模块采集指纹数据；

具体的，指纹sensor模块采集指纹数据并返回指纹采集状态直到录入成功或超时。

步骤208、指纹sensor模块将采集的指纹状态返回指纹业务模块；

步骤209、指纹业务模块设置指纹名称并绑定用户；

具体的，指纹业务模块可以通过调用指纹管理对象设置指纹名称并绑定指纹接口。

步骤210、指纹管理TA模块生成指纹唯一ID；

步骤211、指纹管理TA模块绑定用户名；

步骤212、指纹管理TA模块设置指纹名称；

具体的，在TEE的指纹管理TA模块生成指纹特征的对应唯一ID，绑定当前用户名称，设置指纹名称。

步骤213、指纹管理TA模块将签名绑定数据传入SE；

具体的，将绑定数据传入SE，使用SE存储的私钥签名数据。

步骤214、各模块记录账户开通。

具体的，在指纹TA管理模块记录当前用户开通记录，并返回签名数据；服务端用公钥验证签名，并记录开通状态，返回客户端；客户端更改绑定状态。

下面对后续采用上述方案形成签名数据并在CA等设备形成证书，并为终端获取后的认证请求实施流程进行说明。

图3为指纹认证请求方法实施流程示意图，如图所示，可以包括如下步骤：

步骤301、接收APP发出的第一指纹验证请求；

步骤302、在REE中验证该指纹，获取该指纹的标识、该指纹绑定的用户；

步骤303、将其传入SE后，使用SE存储的公钥对该指纹的标识、该指纹绑定的用户进行加密，并用SE存储的私钥签名生成供认证中心验证的第二签名数据；

其中，SE存储的公钥是在采用上述签名数据的生成方法中生成的第一签名数据经公钥验证后返回的，加密后的数据是供认证中心用该指纹绑定的用户的私钥解密的；

步骤304、向指纹验证请求接收端发送第二指纹验证请求，所述第二指纹验证请求中携带有所述加密后的数据以及第二签名数据。

实施中，APP可以是包含支付功能的APP，例如支付宝。

实施中，第一指纹验证请求可以是在用户在APP中选择指纹支付后发出的，具体的，例如在卡片中心生成订单卡片，显示支付方式后，用户选择了指纹支付后发出第一指纹验证请求。

实施中，第一指纹验证请求和/或第二指纹验证请求是通过APP的卡片中心发出的。

下面以实例来进行说明，以便更好地理解本方案的实施。

图4为指纹支付中的认证请求处理流程示意图，为了更好地理解实施，图中用以执行各步骤的功能模块分别有：用于确定、管理指纹管理对象的指纹管理模块，用于管理指纹采集的可信APP：指纹管理TA模块，用于存储密钥的SE；

位于终端例的、配合实施的其他现有的功能模块分别有：用于发起业务的业务方APP，用于将订单数据可视化显示的卡片中心，用于提供支付服务的支付服务模块，

图中用以执行各步骤的网络侧的、配合实施的现有的功能实体设备分别有：提供线上服务的线上服务模块，用于提供推送服务的push(推送)服务模块，用于进行认证的认证中心。

需要说明的是，网络侧的各模块都是常规功能模块，提供常规的基本服务，仅用于示意，这些功能模块可能在不同的公司、不同的业务架构下、不同的行业中会有不同的称呼，但是，结合附图，其完成的功能对本领域技术人员来说是明了的。

另外，按业界习惯，图中的实线表示消息调用，虚线表示调用返回。

本例实施时，在终端上已在激活REE的时候绑定了某一账号，例如支付宝、淘宝等账号，例中将以支付宝帐号的实施为例进行说明。

步骤401、用户通过业务方APP购买物品；

具体的，任何第三方需要支付的APP都可以视为本实施例中的业务方。

步骤402、业务方APP向线上服务模块请求生成订单；

具体的，在业务方选购商品，向其线上服务请求，生成订单。

步骤403、线上服务模块生成订单；

步骤404、线上服务模块向push服务模块调用push；

步骤405、push服务模块生成订单模版；

步骤406、push服务模块想卡片中心下发订单；

具体的，在本例中，业务方线上服务模块调用的是alipay(支付宝)的push服务，push服务模块根据业务方的数据生成卡片模板，下发模板到卡片中心。卡片模版可以是一个订单内容，可以是一笔收益，还可以是一次信用卡还款提醒等。

步骤407、卡片中心生成订单卡片；

具体的，卡片中心生成订单卡片，显示支付方式，当然在实践中并不限于指纹支付。卡片中心在本例中的功能主要是将订单数据可视化显示，显示生成订单的日期、金额等。订单卡片一般包括了订单号、购买物品、金额、付款方式等内容。

步骤408、卡片中心向支付服务模块发出指纹支付请求；

步骤409、支付服务模块向指纹管理模块发出指纹认证请求；

步骤410、指纹管理模块向指纹管理TA模块生成认证数据；

步骤411、指纹管理TA模块组装消息数据；

具体的，组装的消息数据可以包括：指纹的标识、该指纹绑定的用户及设备信息等。其中，设备信息可以是IMEI(International Mobile Equipment Identity，移动设备国际识别码，又称为国际移动设备标识)等信息，用以说明这个用户在这个设备上开通了指纹，在其他设备上不具备这个功能。

步骤412、指纹管理TA模块向SE发送要求签名的数据；

步骤413、SE对数据进行签名；

具体的，在SE，将使用SE存储的公钥对该指纹的标识、该指纹绑定的用户及设备信息进行加密，并用SE存储的私钥签名生成供认证中心验证的第二签名数据，其中，SE存储的公钥是采用上述签名数据的生成方法中生成的第一签名数据经公钥验证后返回的，加密后的数据是供认证中心用该指纹绑定的用户的私钥解密的。

步骤414、SE将签名数据返回卡片中心；

具体的，本例中用户选择指纹支付，指纹管理模块验证指纹特征。使用SE中存储的服务端公钥对指纹特征ID+用户名+设备信息加密并用预置在SE的私钥签名并返回数据。

步骤415、卡片中心向认证中心携带签名数据请求认证；

步骤416、认证中心进行认证；

步骤417、认证中心向卡片中心响应支付成功；

具体的，卡片中心上传签名数据到认证中心，认证中心验证签名并用特定用户私钥解密，在认证通过后下发认证状态。

步骤418、卡片中心更改订单状态。

基于同一申请构思，本申请实施例中还提供了一种签名数据的生成装置、以及一种指纹认证请求装置，由于这些装置解决问题的原理与一种签名数据的生成方法、以及一种指纹认证请求方法相似，因此这些装置的实施可以参见方法的实施，重复之处不再赘述。

图5为签名数据的生成装置结构示意图，如图所示，装置中可以包括：

指纹管理模块501，用于在REE中确定指纹管理对象；

指纹管理TA模块502，用于在TEE中采集指纹；

指纹业务模块503，用于在所述指纹管理对象设置指纹名称及绑定的用户；

指纹管理TA模块进一步用于在TEE中为采集的指纹生成标识；在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系；将所述映射关系传入SE后，使用SE存储的私钥签名生成供公钥验证的第一签名数据。

实施中，指纹管理模块可以进一步用于通过TEE提供给REE的API，通知指纹管理TA模块在TEE中采集指纹。

实施中，指纹业务模块，用于在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系时，采用的所述标识可以是通过TEE提供给REE的API提供的。

实施中，指纹管理TA模块可以进一步用于通过TA执行以下功能之一或者其组合：

在TEE中采集指纹；

在TEE中为采集的指纹生成标识；

在TEE中建立所述标识、指纹名称及绑定的用户之间的映射关系；

将所述映射关系传入SE后，使用SE存储的私钥签名生成供公钥验证的签名数据。

图6为指纹认证请求装置结构示意图，如图所示，装置中可以包括：

指纹管理模块501，用于接收APP发出的第一指纹验证请求；在REE中验证该指纹；

指纹管理TA模块502，用于获取该指纹的标识、该指纹绑定的用户；将其传入SE后，使用SE存储的公钥对该指纹的标识、该指纹绑定的用户进行加密，并用SE存储的私钥签名生成供认证中心验证的第二签名数据，其中，SE存储的公钥是在如权利要求1所述的方法中生成的第一签名数据经公钥验证后返回的，所述加密后的数据是供认证中心用该指纹绑定的用户的私钥解密的；

指纹管理模块进一步用于向指纹验证请求接收端发送第二指纹验证请求，所述第二指纹验证请求中携带有所述加密后的数据以及第二签名数据。

实施中，指纹管理模块可以进一步用于接收包含支付功能的APP发出的第一指纹验证请求。

实施中，指纹管理模块可以进一步用于接收在用户在APP中选择指纹支付后发出的第一指纹验证请求。

实施中，指纹管理模块可以进一步用于接收通过APP的卡片中心发出的第一指纹验证请求；和/或，通过APP的卡片中心向指纹验证请求接收端发送第二指纹验证请求。

为了描述的方便，以上所述装置的各部分以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本中请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

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