CN105025480A - 用户卡数字签名验证的方法与系统 - Google Patents

Abstract

本公开涉及一种用户卡数字签名验证的方法与系统。该方法包括响应于应用对数字签名的请求，应用后台将签名请求和待签名数据加密并编码为二维码，显示在应用页面上；移动终端内的客户端对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息；响应于二维码中所承载的签名请求，客户端将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡；用户卡在移动终端上展现待签名数据；响应于用户对待签名数据的确认，用户卡利用数字签名的私钥对待签名数据进行数字签名，并由客户端将签名结果返回给应用后台；应用后台对签名结果进行验证。本公开既避免了应用后台与用户之间短信收发的不稳定因素又降低了进行数字签名的成本。

Description

用户卡数字签名验证的方法与系统

技术领域

本公开通信安全领域，特别地，涉及一种用户卡数字签名验证的方法与系统。

背景技术

随着互联网交易的日益普及，为了确保交易的安全性，交易过程中的身份认证变得尤为重要。数字签名能确定消息确实是由发送方签名并发出来的，同时能确定消息的完整性。签名内容如果发生改变，数字签名的值也将发生变化。不同的文件将得到不同的数字签名，从而确保信息传输的完整性、发送者身份的合法性、防止交易抵赖的发生。

用户卡数字签名是目前较为安全的数字签名方式。但是，在用户卡数字签名的实际使用中发现，在需要交易确认时，需要由整个数字签名系统的后台向用户发送待签名的数据短信，在用户确认之后进行数字签名，用户再以上行数据短信的方式返回签名结果才完成交易确认，如图1所示。

在上述的整个签名过程中经常会因为短信延时而导致数字签名业务使用不稳定，同时对用户来说，频繁地发送上行短信也会产生一定的通讯费用，不利于数字签名业务的开展。

发明内容

本公开鉴于以上问题中的至少一个提出了新的技术方案。

本公开在其一个方面提供了一种用户卡数字签名验证的方法，其既避免了应用后台与用户之间短信收发的不稳定因素又降低了进行数字签名的成本。

本公开在其另一方面提供了一种用户卡数字签名验证的系统，其既避免了应用后台与用户之间短信收发的不稳定因素又降低了进行数字签名的成本。

根据本公开，提供一种用户卡数字签名验证的方法，包括：

响应于应用对数字签名的请求，应用后台将签名请求和待签名数据加密并编码为二维码，显示在应用页面上；

移动终端内的客户端对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息；

响应于二维码中所承载的签名请求，移动终端内的客户端将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡；

用户卡在移动终端上展现待签名数据；

响应于用户对待签名数据的确认，用户卡利用数字签名的私钥对待签名数据进行数字签名，并由移动终端内的客户端将签名结果返回给应用后台；

应用后台对签名结果进行验证。

在本公开的一些实施例中，该方法还包括：

在应用后台中预存用于数字签名的公钥，以及在用户卡中预存用于数字签名的私钥。

在本公开的一些实施例中，机卡交互接口为open mobile API。

在本公开的一些实施例中，用户卡以硬件承载方式装载数字签名单元。

在本公开的一些实施例中，移动终端内的客户端通过数据网络将签名结果返回给应用后台。

根据本公开，还提供了一种用户卡数字签名验证的系统，包括应用后台与移动终端，其中，移动终端包括客户端与用户卡，

应用后台，用于响应于应用对数字签名的请求，将签名请求和待签名数据加密并编码为二维码，显示在应用页面上，以及对签名结果进行验证；

移动终端内的客户端，用于对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息，响应于二维码中所承载的签名请求，将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡，将移动终端内的用户卡返回的签名结果返回给应用后台；

移动终端内的用户卡，用于接收在移动终端上展现待签名数据，响应于用户对待签名数据的确认，用户卡利用数字签名的私钥对待签名数据进行数字签名，并将签名结果返回给移动终端内的客户端。

在本公开的一些实施例中，应用后台还预存用于数字签名的公钥，用户卡还预存用于数字签名的私钥。

在本公开的一些实施例中，机卡交互接口为open mobile API。

在本公开的一些实施例中，用户卡以硬件承载方式装载数字签名单元。

在本公开的一些实施例中，移动终端内的客户端通过数据网络将签名结果返回给应用后台。

在本公开的技术方案中，在应用后台与用户之间不再需要通过短信方式交互待签名数据，而是通过扫描二维码方式在应用后台与用户卡之间交互待签名数据。因此，由于弃用了短信方式，一方面省去了发送短信所带来的使用成本，另一方面也避免了由于短信延迟等不稳定因素对数字签名验证的影响。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分。在附图中：

图1是现有技术实现用户卡数字签名验证的示意图。

图2是本公开实现用户卡数字签名验证的示意图。

图3是本公开一个实施例的用户卡数字签名验证的方法的流程示意图。

图4是本公开另一实施例的用户卡数字签名验证的方法的消息示意图。

图5是本公开一个实施例的用户卡数字签名验证的系统的结构示意图。

具体实施方式

下面将参照附图描述本公开。要注意的是，以下的描述在本质上仅是解释性和示例性的，决不作为对本公开及其应用或使用的任何限制。除非另外特别说明，否则，在实施例中阐述的部件和步骤的相对布置以及数字表达式和数值并不限制本公开的范围。另外，本领域技术人员已知的技术、方法和装置可能不被详细讨论，但在适当的情况下意在成为说明书的一部分。

为了可以更方便、稳定且低成本地使用数字签名业务，本公开利用二维码扫描、识别应用以及机卡交互接口等技术实现对关键数据的数字签名。

二维码(即，2D barcode)是利用某种特定的几何图形按一定规律在平面(即，二维方向)分布的黑白相间的图形上记录数据符号信息。在代码编制上，其巧妙地利用了比特流的概念，使用若干个与二进制相对应的几何形体来表示文字与数值等信息，通过图像输入设备或光电扫描设备自动地识读以实现信息的自动处理。二维码具有高密度编码、信息容量大、编码范围广等特点，其可容纳的信息比普通条码高几十倍。

随着智能手机的普及，越来越多的手机具有摄像扫描功能，这样就可以利用二维码扫描来获取待签名数据，再结合移动终端客户端或应用与用户手机卡之间的交互实现数字签名，避免了应用后台与用户之间短信收发的不稳定因素，并且降低了对数字签名业务的使用成本，实现流程如图2所示。

图3是本公开一个实施例的用户卡数字签名验证的方法的流程示意图。

如图3所示，该实施例可以包括以下步骤：

S302，响应于应用对数字签名的请求，应用后台将签名请求和待签名数据加密并编码为二维码，显示在应用页面上；

具体地，应用后台在处理某个应用的认证请求时，如果需要对该应用的关键数据进行数字签名确认，则应用后台将签名请求和待签名数据加密后，利用二维码技术生成二维码，显示在应用页面上并提示用户用移动终端内的客户端扫描该二维码。

S304，移动终端内的客户端对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息；

具体地，一般移动终端都具有摄像功能，移动终端内的客户端此时可以启动该功能扫描显示在应用页面上的二维码。在扫描完二维码后，可以由移动终端内的客户端对该二维码进行解码，识别解码后的信息。

S306，响应于二维码中所承载的签名请求，移动终端内的客户端将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡；

具体地，如果对二维码解码后的信息中包括签名请求，则表明应用后台请求对二维码中所承载的待签名数据进行数字签名。此时，移动终端内的客户端根据该签名请求自动触发数字签名过程。即，将二维码中所承载的待签名数据通过移动终端客户端与用户卡之间的机卡交互接口将待签名数据发送至用户卡。

S308，用户卡在移动终端上展现待签名数据；

具体地，用户卡在接收到移动终端客户端发送的待签名数据后，为了便于用户确认，在显示屏上弹出待签名数据的文本信息。

S310，响应于用户对待签名数据的确认，用户卡利用数字签名的私钥对待签名数据进行数字签名，并由移动终端内的客户端将签名结果返回给应用后台；

具体地，如果移动终端上显示的待签名数据正确无误，则用户可以输入确认信息，此时，用户卡在检测到用户输入的确认信息后，利用预存在用户卡内的数字签名私钥对待签名数据进行数字签名。在数字签名完成后，用户卡将签名结果返回给移动终端客户端，客户端通过数据网络再发送给应用后台，期间无需用户的参与。

S312，应用后台对签名结果进行验证；

需要指出的是，在应用后台中预先存储了针对每个用户进行数字签名所需的公钥。应用后台在接收到用户卡发送的数字签名结果后，利用存储的公钥对数字签名结果进行验证。

在该实施例中，在应用后台与用户之间不再需要通过短信方式交互待签名数据，而是通过扫描二维码方式在应用后台与用户卡之间交互待签名数据。因此，由于弃用了短信方式，一方面省去了发送短信所带来的使用成本，另一方面也避免了由于短信延迟等不稳定因素对数字签名验证的影响。

其中，移动终端内的机卡交互接口可以为open mobile API，其使得移动终端内的应用或客户端能够访问移动终端内的各种不同的安全模块，例如，用户手机卡和嵌入式安全模块。

此外，为了使用户卡具有数字签名功能，可以以硬件承载方式在用户卡内装载数字签名单元。

具体地，用户卡数字签名是以用户手机卡作为一种硬件承载方式装载数字签名单元，将数字签名私钥集成在用户手机卡内，具有安全且方便的优势。移动终端内的客户端或应用与用户手机卡之间的通信可以通过open mobile API来完成，从而实现整个数字签名过程。

另外，在用户卡完成数字签名后，移动终端可以通过数据网络将签名结果返回给应用后台，例如，诸如WiFi等无线网络、诸如3G与4G等移动网络。

接下来，通过具体实例对本公开的技术方案作进一步说明。

图4是本公开另一实施例的用户卡数字签名验证的方法的消息示意图。

如图4所示，数字签名验证过程包括以下步骤：

步骤一，在应用需要进行数字签名时，应用后台可以对诸如签名请求与待签名数据等与数字签名相关的关键数据进行加密后，利用二维码技术编码，生成相应的二维码，并将该二维码显示在应用页面，同时提示用户对其进行扫描。

进一步地，还可以将用户信息和应用信息承载在二维码中发往移动终端客户端，以帮助移动应用或客户端进行流程上的信息判断或信息处理。

其中，待签名数据是指需要用户确认的信息，可以包括但不限于转账信息、使用积分、修改账户等信息。

用户信息可以由登录各应用所需的信息确定。例如，可以为用户账户、用户手机号、用户登录IP等。

步骤二，用户通过手机中的应用安全软件对应用页面显示的二维码进行扫描，并识别其中是否承载签名请求信息。

具体地，可以通过图像识别技术识别出二维码所携带的信息串，再对所识别出来的信息串(例如，字符串)进行解密，查询并识别其中是否有签名请求信息。

步骤三，在查询出二维码中携带了签名请求信息后，应用安全软件通过机卡交互接口open mobile API与用户卡进行交互，传递待签名数据，访问用户卡内的数字签名单元，请求进行数字签名。

步骤四，用户卡将待签名数据呈现给用户，在接收到用户的确认信息后，利用存储在用户卡内的私钥对待签名数据进行数字签名，并将签名结果返回给应用安全软件。

步骤五，应用安全软件通过数据网络将用户信息、签名信息等验证数据返回给应用后台。

需要指出的是，现有方式多通过数据短信(即，OTA短信)与用户卡进行通信，经常会有较大的时延，导致信息无法收到或信息过期，同时用户卡需要发送多次上行短信，也会带来额外的短信费用。而本公开则只要数据网络通畅，至少从用户体验角度来说，基本不存在时延。

步骤六，应用后台对用户签名数据进行解密与验证。

具体地，应用后台利用其内存储的与用户信息相对应的公钥对数字签名结果进行解码，根据解码结果与所使用的公钥就可以确认对相应用户的验证是否通过。如果同时将用户信息返给应用后台，应用后台可以根据用户信息和用户信息与公钥的对应关系直接查找相应公钥进行解密与验证。

步骤七，数字签名验证合法之后即完成了整个过程。

由此可见，整个过程用户只需开启应用安全软件对二维码进行扫描，不需要应用后台向用户发送含待签名数据的数据短信，用户签名完成之后也不需要向应用后台发送含签名结果的数据短信，防止了短信延迟对数字签名的影响，同时由于无需发送短信，因此也降低了用户使用数字签名业务的成本。

本公开签名请求及待签名数据直接通过二维码解析获取，避免了短信延时造成的交易失败风险。手机应用软件和用户卡通过open mobileAPI机卡接口交互，用户卡直接对待签名数据进行数字签名，由应用安全软件自动提交到应用后台进行验证，避免了上行数据短信带来的延时和费用问题。

本领域普通技术人员可以理解，实现上述方法实施例的全部和部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算设备可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤，而前述的存储介质可以包括ROM、RAM、磁碟和光盘等各种可以存储程序代码的介质。

图5是本公开一个实施例的用户卡数字签名验证的系统的结构示意图。

如图5所示，该实施例中的系统50可以包括应用后台502和移动终端504。其中，所述移动终端504包括客户端504a和用户卡504b，

应用后台502，用于响应于应用对数字签名的请求，将签名请求和待签名数据加密编码为二维码并显示在应用页面上，以及应用后台对签名结果进行验证；

移动终端内的客户端504a，用于对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息，响应于二维码中所承载的签名请求，将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡504b，将移动终端内的用户卡504b返回的签名结果返回给应用后台；

移动终端内的用户卡504b，用于接收并在移动终端上展现待签名数据，响应于用户对待签名数据的确认，利用数字签名的私钥对待签名数据进行数字签名，并将签名结果返回给移动终端内的客户端504a。

在该实施例中，在应用后台与用户之间不再需要通过短信方式交互待签名数据，而是通过扫描二维码方式在应用后台与用户卡之间交互待签名数据。因此，由于弃用了短信方式，一方面省去了发送短信所带来的使用成本，另一方面也避免了由于短信延迟等不稳定因素对数字签名验证的影响。

进一步地，应用后台还预存用于数字签名的公钥，用户卡还预存用于数字签名的私钥。

进一步地，机卡交互接口为open mobile API。

此外，用户卡以硬件承载方式装载数字签名单元。

另外，移动终端内的客户端通过数据网络将签名结果返回给应用后台。

上述实施例通过二维码技术和机卡通信技术简化了现有数字签名验证的流程、提高了数字签名验证的成功率、增强了验证过程的安全性。

本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同和相似的部分可以相互参见。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处可以参见方法实施例部分的说明。

本公开上述实施例针对目前用户使用用户卡数字签名业务时必须来回接收和发送数据短信，当短信系统存在不稳定情况时极易造成对数字签名验证的延时，可能影响整个交易过程。同时发送数据短信也带来一定费用，存在稳定性不强、交易费用成本增加的问题，提出了利用终端内的应用安全软件扫描识别二维码，通过获取应用页面信息二维码的方式，直接获取待签名数据，继而通过open mobile API与用户卡进行机卡通信，在用户对待签名数据进行确认后，用户卡再对该待签名数据进行数字签名，将数字签名结果返回给应用安全软件，由应用安全软件通过数据网络提交到应用后台完成签名认证过程，整个数字签名过程稳定性得到提高，同时减少了对该业务的使用成本。

虽然已参照示例性实施例描述了本公开，但应理解，本公开不限于上述的示例性实施例。对于本领域技术人员显然的是，可以在不背离本公开的范围和精神的条件下修改上述的示例性实施例。所附的权利要求的范围应被赋予最宽的解释，以包含所有这样的修改以及等同的结构和功能。

Claims (10)

1.一种用户卡数字签名验证的方法，其特征在于，包括：

响应于应用对数字签名的请求，应用后台将签名请求和待签名数据加密并编码为二维码，显示在应用页面上；

移动终端内的客户端对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息；

响应于二维码中所承载的签名请求，移动终端内的客户端将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡；

用户卡在移动终端上展现待签名数据；

响应于用户对待签名数据的确认，用户卡利用数字签名的私钥对待签名数据进行数字签名，并由移动终端内的客户端将签名结果返回给应用后台；

应用后台对签名结果进行验证。

2.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述方法还包括：

在应用后台中预存用于数字签名的公钥，以及在用户卡中预存用于数字签名的私钥。

3.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述机卡交互接口为open mobile API。

4.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述用户卡以硬件承载方式装载数字签名单元。

5.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述移动终端内的客户端通过数据网络将签名结果返回给所述应用后台。

6.一种用户卡数字签名验证的系统，其特征在于，包括应用后台与移动终端，其中，移动终端包括客户端与用户卡，

所述应用后台，用于响应于应用对数字签名的请求，将签名请求和待签名数据加密并编码为二维码，显示在应用页面上，以及对签名结果进行验证；

所述移动终端内的客户端，用于对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息，响应于二维码中所承载的签名请求，将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡，将移动终端内的用户卡返回的签名结果返回给应用后台；

所述移动终端内的用户卡，用于接收并在移动终端上展现待签名数据，响应于用户对待签名数据的确认，利用数字签名的私钥对待签名数据进行数字签名，并将签名结果返回给移动终端内的客户端。

7.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述应用后台还预存用于数字签名的公钥，所述用户卡还预存用于数字签名的私钥。

8.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述机卡交互接口为open mobile API。

9.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述用户卡以硬件承载方式装载数字签名单元。

10.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述移动终端内的客户端通过数据网络将签名结果返回给所述应用后台。