技术领域
[0001] 本
发明涉及支付安全领域，尤其涉及一种托管电子签名与验证的方法及系统。
背景技术
[0002] 随着互联网的普及、各种
电子商务活动的飞速发展，电子签名因具有不可抵赖、不可伪造的特点，应用也越来越多，如
网站认证、网上
银行、安全网上公文传送、网上缴费、网上缴税、网上购物和网上报关等；2004年8月发布的《中华人民共和国电子签名法》确立了电子签名的法律效
力，使得电子签名的应用更加广泛。
[0003] 一般情况下，电子签名的私钥都存放在物理设备U_KEY中，做签名时需要将U_KEY连接在电脑或者智能终端上，输入KEY的操作口令，如P I N码，然后才能生成电子签名；近些年来，在智能手机几乎人手必备的情况下，随着移动网络的不断提速，原来电脑端的应用功能也纷纷在智能手机上实现，那么在手机上使用U_KEY就遇到
硬件接口、手机
操作系统兼容性等各种问题；对于用户来说，不需要辅助硬件，只需要移动终端就能完成所有功能操作更能体现使用移动终端带来的便利性、便捷性。
[0004] 现在通过
云服务提供应用功能已经被广泛接受，为托管生成电子签名提供了更好的平台空间；原来在各种电子商务活动应用中使用电子签名的时候需要客户连接U_KEY，有了托管生成电子签名之后就可以不用U_KEY，这样在智能手机等移动终端上就可以不需要辅助硬件完成电子商务活动了。由于过去完成电子签名的私钥控制在用户自己手中，完成电子签名的验证的公钥控制在验证签名
服务器端，因此其可以保证签名的发起和实际签名是由用户控制，因此可以防止它人仿冒用户发起签名，可以保证交易安全和责任划分清楚。如果将电子签名进行委托，如类似委托云服务器来完成，其需要解决的最核心的问题是如何技术上防止和避免受托方私自采用用户的密钥发起用户签名，引起交易安全的
风险。同时如何明确界定各个方的责任。
发明内容
[0005] 针对以上
缺陷，本发明目的在于如何有效的防止托管方在没有用户授权的情况下使用客户的电子签名。
[0006] 为了实现上述目的，本发明提供了一种托管电子签名与验证的方法，其特征在于至少由用户方、凭证管理方和托管签名方三方分别独立工作并共同完成一次用户签名，将用于完成用户电子签名的签名密钥委托独立工作的托管签名方保存，由独立工作的凭证管理方对用户方、托管签名方和验证签名方之间的交互数据增加随机要素，并进行随机要素核验和记录保存；验证签名方完成签名验证操作。
[0007] 用户方为代表具有电子签名需要的用户，其通过智能终端提起和参与电子签名工作。可以是银行的个人用户或单位结算卡用户；
[0008] 凭证管理方可以是由银行或银联等提供最终签名验证的机构来承担；
[0009] 托管签名方要求与签名验证独立运营，各自独立承担责任，其可以是独立提供托管签名服务的企业或其它机构。
[0010] 所述的托管电子签名与验证的方法，其特征在于用户方通过用户认证后通过预先
申请的客户标识先向凭证管理方发起签名申请，签名凭证管理方验证客户标识的合法性后生成本次签名的随机要素并记录，同时将随机要素回复给用户方，用户方接收到本次签名的随机要素后，将至少包括客户标识、应用数据和随机要素的签名申请数据向托管签名方申请签名申请，托管签名方验证用户方和凭证管理方的合法性后，生成正式的电子签名，并将最终的电子签名反馈给用户方再由用户方反馈给凭证管理方，或者托管签名方直接将最终的电子签名直接反馈给凭证管理方，先由凭证管理方核验随机要素的合法性，核验通过后再发送给最终的验证签名方，验证签名方将验证结果反馈给凭证管理方后再反馈给用户方，或者验证签名方将验证结果直接反馈给到用户方。
[0011] 所述的托管电子签名与验证的方法，其特征在于用户方通过托管签名方申请签发用户密钥对，托管签名方根据用户方申请生成用户密钥对，具体为签名密钥和验证密钥，将所述验证密钥发送至验证签名方，托管签名方存储签名密钥，并根据用户申请完成生成正式的电子签名的操作。
[0012] 所述的托管电子签名与验证的方法，其特征在于用户方使用托管签名前需完成委托注册操作，先根据用户注册信息向银联二维系统发起绑卡
请求，验证身份成功后银联二维码系统返回绑卡支付标记，将所述支付标记作为客户标识使用；并将客户标识发送到托管签名方生成密钥对，具体包括签名密钥和验证密钥，托管签名方将客户标识、验证密钥和专用签发设备I D发送到验证签名方，验证签名方根据客户标识、验证密钥和专用签发设备I D生成签发端账户密钥和核验端账户密钥，并保存客户标识、验证密钥、专用签发设备I D和核验端账户密钥，将签发端账户密钥返回到托管签名方保存，同时将客户标识发送到凭证管理方进行登记，完成委托注册操作。
[0013] 一种托管电子签名与验证的系统，其特征在于包括多个客户端、
应用服务器、凭证管理服务器、托管签名服务器和验证签名服务器，各个服务器和客户端分布式设置；
[0014] 所述客户端实现与应用服务器的用户登录及相关认证操作，并发起签名申请；
[0015] 所述应用服务器用于接收客户端操作指令，根据客户端操作指令完成相应操作，根据用户信息获取客户标识，并提供凭证管理服务器与托管签名服务器的数据转发服务；
[0016] 所述凭证管理服务器记录所有合法用户的客户标识，对每次签名申请增加随机要素，并核验托管签名服务器完成签名的随机要素的合法性；
[0017] 所述托管签名服务器用于依用户申请生成用户的客户标识对应的密钥对，并存储签名密钥；同时根据用户申请对用户提交的带有客户标识、随机要素和应用数据的数据完成签名，生成电子签名；
[0018] 所述验证签名服务器存储有合法用户的验证密钥，根据预先存储的验证密钥对提交的电子签名完成合法性验证。
[0019] 所述的托管电子签名与验证的系统，其特征在于客户端通过应用服务器的用户认证后，通过应用服务器发起签名核验申请，应用服务器根据用户信息获取用户的客户标识，根据客户标识先向凭证管理服务器申请包含随机要素的凭证号码，凭证管理服务器验证客户标识的合法性后生成本次签名的凭证号码并返回给应用服务器，同时记录本次签名的凭证号码和使用状态，应用服务器接收到凭证号码后，将客户标识、应用数据和凭证号码作为签名申请数据向托管签名服务器提交签名申请，托管签名服务器根据签名申请数据生成正式的电子签名，并将最终的电子签名反馈给应用服务器。
[0020] 所述的托管电子签名与验证的系统，其特征在于还包括二维码服务器，所述二维码服务器根据应用服务器提交的电子签名生成含有电子签名的交易二维码，并将交易二维码反馈给客户端，由客户端显示在屏幕上。
[0021] 所述的托管电子签名与验证的系统，其特征在于还包括扫描设备，用于扫描读取客户端出示的交易二维码，并合并上交易数据生成向二维码系统发起的交易数据，二维码系统将交易数据发送到应用服务器，应用服务器将含有电子签名的交易数据发送给凭证管理服务器，凭证管理服务器检测交易数据中的客户标识和凭证号码的合法性，检查通过后再将交易数据发送给所述验证签名服务器进行核验，并将核验结果通过凭证管理服务器返回给应用服务器。
[0022] 所述的托管电子签名与验证的系统，其特征在于所述托管签名服务器根据用户申请生成用户密钥对，具体为签名密钥和验证密钥，将所述验证密钥发送至验证签名服务器，将所述签名密钥存储在托管签名服务器中，托管签名服务器接收到签名申请根据预先存储的该用户方所对应的签名密钥完成生成正式的电子签名的操作。
[0023] 所述的托管电子签名与验证的系统，其特征在于用户使用托管签名前需完成委托注册操作，具体为先根据用户注册信息向银联二维系统发起绑卡请求，验证身份成功后银联二维码系统返回绑卡支付标记，将所述支付标记作为客户标识使用；并将客户标识发送到托管签名服务器生成密钥对，具体包括签名密钥和验证密钥，托管签名服务器将客户标识、验证密钥和专用签发设备I D发送到验证签名服务器，验证签名服务器根据客户标识、验证密钥和专用签发设备I D生成签发端账户密钥和核验端账户密钥，并保存客户标识、验证密钥、专用签发设备I D和核验端账户密钥，将签发端账户密钥返回到托管签名服务器保存，同时将客户标识发送到凭证管理服务器进行登记，完成委托注册操作。
[0024] 本发明有益效果：把登录信息管理、交易凭证的随机要素、云端的用户私钥托管、服务器间的可信计算，这几个与可靠电子签名相关的要素进行分布式管理，实现了使用用托管电子签名也能够签出代表用户的可靠电子签名；使用托管电子签名后，客户可以在不需要辅助硬件或专用手机的情况下就能在智能终端上完成需要电子签名的电子商务活动，充分发挥了智能终端的便利性和便捷行。验证方生成随机要素的方法,让托管方很难通过已有随机要素推测出之后的随机要素，能有效防止托管方生成并使用客户的电子签名，让客户使用托管方生成电子签名更加放心，更有利于这种方式在市场上推广。与原有方式相比，验证方增加了凭证管理服务器，但是验证方仍然是只能验证电子签名，没有生成电子签名的能力，不改变原有模式各方功能。
附图说明
[0025] 图1是托管电子签名与验证的系统组成图。
[0027] 图3是电子签名核验的流程图。
具体实施方式
[0028] 下面将结合本发明
实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0029] 本发明的目的是能够让客户方便地在智能终端上使用托管电子签名而不需要附加硬件也不需要使用专用手机，并且能有效防范托管方在没有授权的情况下生成并使用客户的电子签名。
[0030] 通过提出一种多
角色共同参与才可实现客户电子签名的方法。该方法基于一般物理上分布式设置的托管签名服务器、验证签名服务器、凭证管理服务器、应用服务器和智能终端客户端实现的，各个部
门一般都隶属于独立的机构，各种负责签名和核验的某个环节，一般每个环节的各项操作都具有记录，并对该环节承担对应的法律责任，任何一方都无法独自完成一次用户电子签名，因此可以有效防范托管方在没有授权的情况下生成并使用客户的电子签名，有效保证用户交易的安全。
[0031] 用户要使用托管电子签名服务需要通过签署相关协议同意委托托管签名机构提供委托签名的服务，签署完成协议后，首先要完成密钥申请工作。具体注册流程如下：
[0032] 保证法律上委托托管签名服务器的机构获得用户的法律授权，其接收用户委托托管签名服务的合法性。各项协议的签署也可以是通过其它线上等可信的强用户认证的方式进行。交易是作为具体需要应用电子签名的最大场合，因此作为银行卡持有人是最常见的用户，也包括企业用户。用户需要先要完成签署相关授权委托协议，可以要求到银行柜面签约或其它方式签约，智能终端下载手机客户端APP或微信小程序等APP，并注册到应用服务器，该应用服务器一般由银行提供服务或者由银行委托第三方提供服务；可在线签署服务协议，委托托管签名服务器(也可以称为云签发服务器)保管签发密钥或通过其它可信方式实现服务协议和委托托管签名服务器保管签发密钥的协议的签署工作。应用服务器根据用户注册信息向银联二维系统发起绑卡请求，验证身份成功后银联二维码系统返回绑卡的支付标记TOKEN，应用服务器将此绑卡TOKEN作为客户标识使用；应用服务器将客户标识发送到托管签名服务器请求生成密钥对，具体为签名密钥和验证密钥。为了提供其安全性，一般托管签名服务器上设有专用签发设备，托管签名服务器通过专用签发设备计算并获得验证密钥和签名密钥，产生的签名密钥和验证密钥密钥对与专用签发设备的硬件相关，同时还返回专用签发设备I D，应用服务器将获得的客户标识、验证密钥和专用签发设备I D再发送到验证签名服务器，验证签名服务器可以直接存储使用客户标识、验证密钥和专用签发设备I D。为了进一步提高其安全性，验证签名服务器可以进一步的根据客户标识、验证密钥和专用签发设备I D通过其上的专用核验设备生成与专用核验设备硬件相关的签发端账户密钥和核验端账户密钥，并保存客户标识、验证密钥、专用签发设备I D和核验端账户密钥，将签发端账户密钥返回，应用服务器将签发端账户密钥发送到云签发系统保存，应用服务器再将客户标识发送到凭证管理服务器登记。托管签名服务器根据用户申请使用专用签发设备产生与专用签发设备硬件相关性的签名密钥和验证密钥密钥；验证签名服务器根据验证签名服务器生成的验证密钥、专用签发设备I D和客户标识通过专用核验设备产生与专用核验设备硬件相关的签发端账户密钥和核验端账户密钥。两对密钥都与硬件相关，可以保证其产生的密钥的唯一性，保证委托签名服务器和验证签名服务器的唯一性和合法性，保证最后的电子签名由最初委托的托管签名服务器的唯一硬件产生，使得其可以类似达到普通用户通过唯一持有的U_KEY产生签名密钥完成电子签名的安全性。客户标识要求在应用服务器、凭证管理服务器、托管签名系统和验证签名系统都保存，并且具有唯一性。
[0033] 当用户在实际交易场景中，需要用到电子签名时，用户可通过智能终端客户端登录应用服务器后发起需要用到电子签名的应用操作指令；用户登录过程具有强身份核验，保证用户身份的合法性，一般应用服务器上都保留有相关登录过程的数据。以下结合具体的交易应用分别说明具体的电子签名的产生和核验过程。
[0034] 图2是生成电子电子签名的流程图，具体流程如下：
[0035] 步骤1.1：客户端先向应用服务器发起电子签名的请求。
[0036] 步骤1.2：应用服务器接收到电子签名的请求，根据用户的获取用户标识，并将用户标识发送到凭证管理服务器，为该用户标识申请凭证号码。
[0037] 步骤1.3：凭证管理服务器接收到该申请后，先核验用户标识的合法性，合法性核验通过后，生成请求的凭证号码；
[0038] 凭证号码中至少包含有一组随机要素；
[0039] 随机要素可以是一串数字、字母或其它字符，为了保证随机性，随机要素至少包含有6位随机数；
[0040] 以下列举一个凭证号码示例，该凭证号码为16为数字，编码规则如下：“tt ssssssss rrrrrr”2位业务识别号，8位账户计数器，6位随机数。
[0041] 凭证号码后8位作为随机要素使用，包含账户计数器后2位和6位随机数。
[0042] 步骤1.4：凭证管理服务器将凭证号码、使用状态与客户标识相对应保存在凭证管理服务器的
数据库中，并将凭证号码返回给应用服务器；
[0043] 使用状态有两种，分别表示“已使用”和“未使用”；新生成的随机要素使用状态为“未使用”，验证过的随机要素使用状态为已使用；随即要素只能成功验证一次，即验证成功后使用状态改为已验证，使用状态为已验证的随机要素将验证通不过。
[0044] 步骤1.5：应用服务器将客户标识、凭证号码与业务数据一起并发送给托管签名系统；
[0045] 步骤1.6：托管签名系统完成合法性核验后，根据客户标识获得预先存储的签名密钥生成电子签名，并返回应用系统。
[0046] 到此为止，完成了用户的电子签名动作，由于签名的过程增加了凭证管理服务器的参与，并增加了由凭证管理服务器产生和控制的随机要素，托管签名系统无法自行产生或增加该随机要素，其无法独立完成，也就无法自发的发起用户的签名。
[0047] 步骤1.7：应用系统将含有客户标识和电子签名的数据发送到银联二维码系统申请发码；
[0048] 步骤1.8：应用服务器将申请到的二维码返回给智能手机APP，APP将二维码显示在屏幕上。
[0049] 图3是电子签名核验的流程图，具体实施例按照如下步骤进行：
[0050] 步骤2.1：商户扫描通过智能手机APP出示的付款二维码，连同收单商户、订单、金额等信息向二维码系统发起收款请求。
[0051] 步骤2.2：银联二维码系统将含有电子签名的订单信息发送给应用服务器。
[0052] 步骤2.3：应用服务器将含有客户标识和电子签名的交易数据发送到凭证管理服务器。
[0053] 步骤2.4：凭证管理服务器检查凭证号码，包括检查凭证号码是否存在并且与客户标识相对应，检查使用状态是否为未使用，含检查其随机要素的合法性；由于凭证号码内含有随机要素，该随机要素由凭证管理服务器产生和维护，其存在一定时效，其它方无法获知或仿冒，因此由于增加的凭证管理服务器参与其数字签名和签名核验过程，保证托管签名系统无法独自生成合法的数字签名。
[0054] 步骤2.5：凭证管理服务器合法性检查通过后，再将含有客户标识和电子签名的交易数据发送给验证签名服务器；否则直接反馈验证失败；
[0055] 步骤2.6：验证签名服务器根据客户标识和电子签名，采用预先存储的验证密钥进行签名核验，后返回结果给凭证管理服务器；
[0056] 步骤2.7：凭证管理服务器将结果返回给应用服务器；
[0057] 步骤2.8：应用服务器根据返回结果做后续处理。
[0058] 后续处理包括应用服务器在验证后向二维码系统返回成功，二维码系统向发卡行的银行卡前置发起消费请求，银行卡前置检查单位结算卡检查后扣款并返回消费应答，二维码系统通知商户收款结果，二维码系统通知应用付款结果，应用服务器通知APP付款结果，APP提示用户付款已结束，并显示收款商户、实际收款金额和优惠金额等付款信息。
[0059] 为了增加其安全性能，在用户申请密钥时，托管签名服务器根据用户申请使用专用签发设备产生与专用签发设备硬件相关性的签名密钥和验证密钥密钥；同时验证签名服务器根据验证签名服务器生成的验证密钥、专用签发设备I D和客户标识通过专用核验设备产生与专用核验设备硬件相关的签发端账户密钥和核验端账户密钥。
[0060] 其中托管签名服务器同时保存和管理了该用户的签名密钥和签发端账户密钥，验证签名服务器同时保存和管理了该用户的验证密钥和核验端账户密钥；在托管签名服务器同时使用签名密钥和签发端账户密钥完成的电子签名，验证签名服务器必须同时使用验证密钥和核验端账户密钥才能完成签名验核操作。签名密钥、签发端账户密钥、签名密钥和签发端账户密钥都是与产生该
配对密钥的专用核验设备和专用签发设备的硬件相关，且唯一。保证只有唯一的用户委托同意的托管签名服务器和验证签名服务器可产生用户签名和完成对用户签名的验证工作。
[0061] 以上所揭露的仅为本发明一种实施例而已，当然不能以此来限定本发明之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本发明
权利要求所作的等同变化，仍属于本发明所涵盖的范围。
