r>[0060]如图4所示，数字签名验证过程包括以下步骤:
[0061]步骤一，在应用需要进行数字签名时，应用后台可以对诸如签名请求与待签名数据等与数字签名相关的关键数据进行加密后，利用二维码技术编码，生成相应的二维码，并将该二维码显示在应用页面，同时提示用户对其进行扫描。
[0062]进一步地，还可以将用户信息和应用信息承载在二维码中发往移动终端客户端，以帮助移动应用或客户端进行流程上的信息判断或信息处理。
[0063]其中，待签名数据是指需要用户确认的信息，可以包括但不限于转账信息、使用积分、修改账户等信息。
[0064]用户信息可以由登录各应用所需的信息确定。例如，可以为用户账户、用户手机号、用户登录IP等。
[0065]步骤二，用户通过手机中的应用安全软件对应用页面显示的二维码进行扫描，并识别其中是否承载签名请求信息。
[0066]具体地，可以通过图像识别技术识别出二维码所携带的信息串，再对所识别出来的信息串(例如，字符串)进行解密，查询并识别其中是否有签名请求信息。
[0067]步骤三，在查询出二维码中携带了签名请求信息后，应用安全软件通过机卡交互接口 open mobile API与用户卡进行交互，传递待签名数据，访问用户卡内的数字签名单元，请求进行数字签名。
[0068]步骤四，用户卡将待签名数据呈现给用户，在接收到用户的确认信息后，利用存储在用户卡内的私钥对待签名数据进行数字签名，并将签名结果返回给应用安全软件。
[0069]步骤五，应用安全软件通过数据网络将用户信息、签名信息等验证数据返回给应用后台。
[0070]需要指出的是，现有方式多通过数据短信(即，OTA短信)与用户卡进行通信，经常会有较大的时延，导致信息无法收到或信息过期，同时用户卡需要发送多次上行短信，也会带来额外的短信费用。而本公开则只要数据网络通畅，至少从用户体验角度来说，基本不存在时延。
[0071]步骤六，应用后台对用户签名数据进行解密与验证。
[0072]具体地，应用后台利用其内存储的与用户信息相对应的公钥对数字签名结果进行解码，根据解码结果与所使用的公钥就可以确认对相应用户的验证是否通过。如果同时将用户信息返给应用后台，应用后台可以根据用户信息和用户信息与公钥的对应关系直接查找相应公钥进行解密与验证。
[0073]步骤七，数字签名验证合法之后即完成了整个过程。
[0074]由此可见，整个过程用户只需开启应用安全软件对二维码进行扫描，不需要应用后台向用户发送含待签名数据的数据短信，用户签名完成之后也不需要向应用后台发送含签名结果的数据短信，防止了短信延迟对数字签名的影响，同时由于无需发送短信，因此也降低了用户使用数字签名业务的成本。
[0075]本公开签名请求及待签名数据直接通过二维码解析获取，避免了短信延时造成的交易失败风险。手机应用软件和用户卡通过open mobileAPI机卡接口交互,用户卡直接对待签名数据进行数字签名，由应用安全软件自动提交到应用后台进行验证，避免了上行数据短信带来的延时和费用问题。
[0076]本领域普通技术人员可以理解，实现上述方法实施例的全部和部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算设备可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤，而前述的存储介质可以包括ROM、RAM、磁碟和光盘等各种可以存储程序代码的介质。
[0077]图5是本公开一个实施例的用户卡数字签名验证的系统的结构示意图。
[0078]如图5所示，该实施例中的系统50可以包括应用后台502和移动终端504。其中，所述移动终端504包括客户端504a和用户卡504b，
[0079]应用后台502，用于响应于应用对数字签名的请求，将签名请求和待签名数据加密编码为二维码并显示在应用页面上，以及应用后台对签名结果进行验证；
[0080]移动终端内的客户端504a，用于对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息，响应于二维码中所承载的签名请求，将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡504b，将移动终端内的用户卡504b返回的签名结果返回给应用后台；
[0081]移动终端内的用户卡504b，用于接收并在移动终端上展现待签名数据，响应于用户对待签名数据的确认，利用数字签名的私钥对待签名数据进行数字签名，并将签名结果返回给移动终端内的客户端504a。
[0082]在该实施例中，在应用后台与用户之间不再需要通过短信方式交互待签名数据，而是通过扫描二维码方式在应用后台与用户卡之间交互待签名数据。因此，由于弃用了短信方式，一方面省去了发送短信所带来的使用成本，另一方面也避免了由于短信延迟等不稳定因素对数字签名验证的影响。
[0083]进一步地，应用后台还预存用于数字签名的公钥，用户卡还预存用于数字签名的私钥。
[0084]进一步地,机卡交互接口为open mobile API。
[0085]此外，用户卡以硬件承载方式装载数字签名单元。
[0086]另外，移动终端内的客户端通过数据网络将签名结果返回给应用后台。
[0087]上述实施例通过二维码技术和机卡通信技术简化了现有数字签名验证的流程、提高了数字签名验证的成功率、增强了验证过程的安全性。
[0088]本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同和相似的部分可以相互参见。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处可以参见方法实施例部分的说明。
[0089]本公开上述实施例针对目前用户使用用户卡数字签名业务时必须来回接收和发送数据短信，当短信系统存在不稳定情况时极易造成对数字签名验证的延时，可能影响整个交易过程。同时发送数据短信也带来一定费用，存在稳定性不强、交易费用成本增加的问题，提出了利用终端内的应用安全软件扫描识别二维码，通过获取应用页面信息二维码的方式，直接获取待签名数据，继而通过open mobile API与用户卡进行机卡通信，在用户对待签名数据进行确认后，用户卡再对该待签名数据进行数字签名，将数字签名结果返回给应用安全软件，由应用安全软件通过数据网络提交到应用后台完成签名认证过程，整个数字签名过程稳定性得到提高，同时减少了对该业务的使用成本。
[0090]虽然已参照示例性实施例描述了本公开，但应理解，本公开不限于上述的示例性实施例。对于本领域技术人员显然的是，可以在不背离本公开的范围和精神的条件下修改上述的示例性实施例。所附的权利要求的范围应被赋予最宽的解释，以包含所有这样的修改以及等同的结构和功能。
【主权项】
1.一种用户卡数字签名验证的方法，其特征在于，包括: 响应于应用对数字签名的请求，应用后台将签名请求和待签名数据加密并编码为二维码,显示在应用页面上； 移动终端内的客户端对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息； 响应于二维码中所承载的签名请求，移动终端内的客户端将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡； 用户卡在移动终端上展现待签名数据； 响应于用户对待签名数据的确认，用户卡利用数字签名的私钥对待签名数据进行数字签名，并由移动终端内的客户端将签名结果返回给应用后台； 应用后台对签名结果进行验证。2.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述方法还包括: 在应用后台中预存用于数字签名的公钥，以及在用户卡中预存用于数字签名的私钥。3.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述机卡交互接P % open mobile API。4.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述用户卡以硬件承载方式装载数字签名单元。5.根据权利要求1所述的用户卡数字签名验证的方法，其特征在于，所述移动终端内的客户端通过数据网络将签名结果返回给所述应用后台。6.一种用户卡数字签名验证的系统，其特征在于，包括应用后台与移动终端，其中，移动终端包括客户端与用户卡， 所述应用后台，用于响应于应用对数字签名的请求，将签名请求和待签名数据加密并编码为二维码，显示在应用页面上，以及对签名结果进行验证； 所述移动终端内的客户端，用于对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息，响应于二维码中所承载的签名请求，将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡，将移动终端内的用户卡返回的签名结果返回给应用后台； 所述移动终端内的用户卡，用于接收并在移动终端上展现待签名数据，响应于用户对待签名数据的确认，利用数字签名的私钥对待签名数据进行数字签名，并将签名结果返回给移动终端内的客户端。7.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述应用后台还预存用于数字签名的公钥，所述用户卡还预存用于数字签名的私钥。8.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述机卡交互接P % open mobile API。9.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述用户卡以硬件承载方式装载数字签名单元。10.根据权利要求6所述的用户卡数字签名验证的系统，其特征在于，所述移动终端内的客户端通过数据网络将签名结果返回给所述应用后台。
【专利摘要】本公开涉及一种用户卡数字签名验证的方法与系统。该方法包括响应于应用对数字签名的请求，应用后台将签名请求和待签名数据加密并编码为二维码，显示在应用页面上；移动终端内的客户端对显示在应用页面上的二维码进行扫描，并识别出二维码所承载的信息；响应于二维码中所承载的签名请求，客户端将二维码中所承载的待签名数据通过机卡交互接口发送至移动终端内的用户卡；用户卡在移动终端上展现待签名数据；响应于用户对待签名数据的确认，用户卡利用数字签名的私钥对待签名数据进行数字签名，并由客户端将签名结果返回给应用后台；应用后台对签名结果进行验证。本公开既避免了应用后台与用户之间短信收发的不稳定因素又降低了进行数字签名的成本。
【IPC分类】H04W12/06
【公开号】CN105025480
【申请号】CN201410176006
【发明人】黎艳, 郭建昌, 卢燕青, 郭茂文, 杨穗珊, 杨敏维
【申请人】中国电信股份有限公司
【公开日】2015年11月4日
【申请日】2014年4月29日