技术领域
[0001] 本
发明涉及互联网技术领域，尤其涉及一种电子现金系统。
背景技术
[0002] 随着计算机和互联网技术的飞速发展，
电子商务已经深入到现代社会中人们生活运作的各个方面。然而，人们在享受电子商务所带来的巨大便利的同时，信息安全与个人隐私问题也日益凸显。传统的现金交易手段无法有效保证电子商务的安全性与隐私性，同时，人们也不愿意通过互联网频繁传送他们的个人信息与信用卡账号，因此商业上需要更多的网络隐私和网络匿名相关的服务。在这种需求的推动下，电子现金(Electronic Cash,E-cash)的概念应运而生。
[0003] 电子现金是一种以数据形式流通的
货币。电子现金系统利用
密码学工具把现金数值转换成为一系列的加密序列数，使现金脱离于传统纸张或金属，存储于
软件或者
智能卡中。设计电子现金系统的目的是实现人们在通信网络上进行正常的电子现金交易，电子现金这一变革手段必将逐步成熟，一定能为广大消费者接受。因此，为保证我国电子商务的健康发展，研制自己的网络安全
支付系统，尤其是电子现金系统势在必行。
[0004] 尽管电子现金具有很多优点与特性，但是其涉及的一些关键性技术仍然亟待发明。首要的问题便是如何确保系统的安全；其次，如何使人们真正接受并使用电子现金的关键在于要保证电子现金同传统
纸币一样难以被伪造和复制：为了实现难以被伪造，电子现金系统将不可伪造的数字签名作为一笔现金来进行交易。然而，与传统货币不同的是，电子现金的数字化特点导致它很容易被复制，所以在许多电子现金系统中，会存在在不同的交易中支付同一笔电子现金的行为，即重复花费行为。为了避免重复花费行为的滋生，一些电子现金系统将用户的身份信息以一种隐藏的方式编码进电子现金中，使用户在支付时仍然保持匿名性，如果侦测到重复花费行为，该用户身份则会被揭开。除此之外，目前提出的电子现金系统中，在每个协议进行时都需要双方进行至少三次交互，这对通信效率和网络的安全要求很高，所以如何减少双方交互的次数也是一个在实际应用中非常重要的问题。
[0005] 总体来说，设计安全的电子现金系统的宗旨是解决交易中传统纸币带来的各种限制因素，同时有效保护用户的匿名性，使之逐渐成为电子支付的一种重要工具，引领现金交易向着数字化与智能化方向发展。
发明内容
[0006] (一)要解决的技术问题
[0007] 针对
现有技术中的问题，本发明提供一种电子现金系统，该系统，用户客户端Ui向地方
银行
服务器LBj发送取款
请求，LBj为Ui的开户银行服务器；LBj根据取款请求生成电子现金M发送给Ui；Ui验证M的有效性；当验证结果为有效时，导出并保存M，解决可交易中传统纸币带来的各种限制因素，同时有效保护用户的匿名性。
[0008] (二)技术方案
[0009] 为了达到上述目的，本发明采用的主要技术方案包括：
[0010] 一种电子现金系统，所述系统，包括：用户客户端和地方银行服务器；
[0011] S401，所述用户客户端Ui向地方银行服务器LBj发送取款请求，所述LBj为所述Ui的开户银行服务器；
[0012] S402，所述LBj根据所述取款请求生成电子现金M发送给所述Ui；所述LBj更新所述Ui的用户账户表；
[0013] S403，所述Ui验证所述M的有效性；
[0014] S404，当验证结果为有效时，导出并保存所述M；
[0015] S405当验证结果为无效时，重复执行步骤S401及后续步骤。
[0016] (三)有益效果
[0017] 本发明的有益效果是：用户客户端Ui向地方银行服务器LBj发送取款请求，LBj为Ui的开户银行服务器；LBj根据取款请求生成电子现金M发送给Ui；Ui验证M的有效性；当验证结果为有效时，导出并保存M，解决可交易中传统纸币带来的各种限制因素，同时有效保护用户的匿名性。
附图说明
[0018] 图1是本发明一种电子现金系统架构图；
[0019] 图2是本发明另一种电子现金系统架构图；
[0020] 图3是本发明另一种电子现金系统架构图；
[0021] 图4是本发明另一种电子现金系统架构图；
[0022] 图5是本发明具体实施方式的注册过程的
流程图；
[0023] 图6是本发明具体实施方式的开户流程图；
[0024] 图7是本发明具体实施方式的取款过程流程图；
[0025] 图8是本发明具体实施方式的支付过程流程图；
[0026] 图9是本发明具体实施方式的存款过程流程图。
具体实施方式
[0027] 为了更好的解释本发明，以便于理解，下面结合附图，通过具体实施方式，对本发明作详细描述。
[0028] 电子现金涉及的一些关键性技术仍然亟待发明。首要的问题便是如何确保系统的安全；其次，如何使人们真正接受并使用电子现金的关键在于要保证电子现金同传统纸币一样难以被伪造和复制：为了实现难以被伪造，电子现金系统将不可伪造的数字签名作为一笔现金来进行交易。然而，与传统货币不同的是，电子现金的数字化特点导致它很容易被复制，所以在许多电子现金系统中，会存在在不同的交易中支付同一笔电子现金的行为，即重复花费行为。为了避免重复花费行为的滋生，一些电子现金系统将用户的身份信息以一种隐藏的方式编码进电子现金中，使用户在支付时仍然保持匿名性，如果侦测到重复花费行为，该用户身份则会被揭开。除此之外，目前提出的电子现金系统中，在每个协议进行时都需要双方进行至少三次交互，这对通信效率和网络的安全要求很高，所以如何减少双方交互的次数也是一个在实际应用中非常重要的问题。
[0029] 基于此，本发明提供一种电子现金系统，至少包括：用户客户端和地方银行服务器，用户客户端Ui向地方银行服务器LBj发送取款请求，LBj为Ui的开户银行服务器；LBj根据取款请求生成电子现金M发送给Ui；Ui验证M的有效性；当验证结果为有效时，导出并保存M，解决可交易中传统纸币带来的各种限制因素，同时有效保护用户的匿名性。
[0030] 参见图1，本
实施例提供的电子现金系统，包括：用户客户端和地方银行服务器。通过图1所示的由用户客户端和地方银行服务器组成的电子现金系统，可实现用户通过用户客户端从地方银行服务器中提取电子现金的功能。
[0031] 除此之外，参见图2，本实施例提供的电子现金系统，还包括：中央银行服务器。通过图2所示的由用户客户端、地方银行服务器和中央银行服务器组成的电子现金系统，可实现如下功能：1)电子现金系统的初始化。2)客户端的注册和地方银行服务器的注册。3)用户通过用户客户端在地方银行服务器开户。4)用户通过用户客户端从地方银行服务器中提取电子现金。5)中央银行服务器监控非法交易。
[0032] 除此之外，参见图3，本实施例提供的电子现金系统，还包括：商家客户端。通过图3所示的由用户客户端、地方银行服务器、中央银行服务器和商家客户端组成的电子现金系统，可实现如下功能：1)电子现金系统的初始化。2)客户端的注册和地方银行服务器的注册。3)用户通过用户客户端在地方银行服务器开户。4)用户通过用户客户端从地方银行服务器中提取电子现金。5)用户通过用户客户端向商家客户端支付购物
费用。6)商家通过商家客户端在地方银行服务器中存入电子现金。7)中央银行服务器监控非法交易。8)两客户端的电子现金仲裁。
[0033] 其中，客户端可以为用户客户端，也可以为商家客户端，2)用户客户端的注册、商家客户端的注册和地方银行服务器的注册。7)为仲裁2个用户客户端间的电子交易纠纷，或者，仲裁2个商家客户端间的电子交易纠纷，或者，仲裁1个用户客户端和1个商家客户端间的电子交易纠纷。
[0034] 下面以图4所示的电子现金系统架构为例，对本发明提供的电子现金系统的运行流程进行详细说明。
[0035] 本发明的电子现金系统，参与的实体主要有以下四种：中央银行(Central Bank，CB)、地方银行(Local Bank，LB)，消费者(Customer，C)以及商家(Merchant，M)。其中中央银行可以看做群签名方案中的群管理者与开启者，地方银行可以看做群签名方案中的签名者以及仲裁者，而消费者与商家则充当了群签名方案中验证者的
角色。
[0036] 所述的中央银行CB为系统的建立者，作为中央金融机构，负责管理地方银行以及发布电子现金验证信息，并为合法的地方银行与用户颁发银行证书与用户证书，并管理维护用户注册表，其中为用户标识符；
[0037] 所述的地方银行LB为电子现金发行者，拥有中央银行办法的银行资格证书，负责为用户开户并管理其电子现金账户，具体来讲，客户取款时，除此之外，地方银行应具有客户身份以及电子现金真伪验证能
力。
[0038] 所述的消费者C为电子现金合法拥有者，通过开户协议与地方银行进行交互，得到属于自己的账户，其中包含一定数值的电子现金，消费者C在与商家M进行交易时，可以用支付协议将相应数值的电子现金支付给商家。
[0039] 所述的商家M为电子现金合法拥有者，得到消费者发送的电子现金时可以离线验证电子现金的合法性，并存入自己的账户。
[0040] 因此本发明的电子现金系统为支持多银行的公平离线电子现金系统。
[0041] 如图4所示，中央银行CB为合法的地方银行LB、消费者C以及商家M颁发证书，对于系统内的消费者C，还需向中央银行CB发送自己的追踪密钥以便管理。地方银行LB通过中央银行CB颁发的证书来表示自己是合法的银行，通过生成的签名密钥来签发电子现金，并在此之后可处于离线状态。用户U可以向地方银行LB
申请开户，开户成功后可以从此地方银行进行存取电子现金，取款时，地方银行LB对自己要发行的电子现金进行签名，并且在电子现金中绑定证书，地方银行LB通过Groth-Sahai非交互式零知识证明方法向用户证明该证书的合法有效性。在支付过程中，消费者C需要将已经得到电子现金支付给商家M，并同时发送现金的序列号与交易标识。根据Groth-Sahai非交互式零知识证明方法的特点，商家M并不需要与银行或用户任意一方进行交互，也不会知道用户的任何私人信息，便可验证此笔现金是否合法有效，若在现金流通过程中产生经济纠纷，或者有非法行为，用户可以向中央银行CB申请打开电子现金，从而追踪出非法用户的身份。除此之外，在某些特定情况下，若系统中需要确认某笔现金是否属于某名用户，可以向签发此笔现金的银行发起仲裁申请，银行能够在不揭示用户身份的情况下，输出判定结果，所有人都能通过此致来判定此笔电子现金是否是某用户生成的。
[0042] 在具体实现时，消费者持有本地设备客户端，电子现金存储在本地设备中。消费者给商家交易时，发送的是本地设备中存储的电子现金，但是发送之前需要对其进行
修改，使其满足有效性，可验证性。消费者拥有自己的客户端，在售款的时候，可以选择展示二维码，付款方通过扫描二维码或者输入地址等方式连接收款方进行付款。
[0043] 一、电子现金系统的初始化
[0044] 完成电子现金系统的初始化的具体流程如下：
[0045] S101-1，中央银行服务器CB选择系统参数。
[0046] S101-2，CB生产能够对电子现金进行验证的群公钥pk及私钥，私钥包括CB的主私钥msk以及开启密钥sk0。
[0047] S101-3，CB设立
数据库，数据库用于存储已花费的电子现金，且LBj拥有对数据库的
访问权限。
[0048] 例如，中央银行服务器选择系统参数，生产能够对电子现金进行验证的群公钥pk以及私钥(中央银行的主私钥msk以及开启密钥sk0)。中央银行服务器在中央银行本地设立一个数据库专
门用于存储已花费的电子现金Reg[C]，所有地方银行拥有对此数据库的访问权限。
[0049] 二、客户端的注册和地方银行服务器的注册
[0050] 地方银行或者用户在系统中进行注册，参与的实体是中央银行服务器和地方银行服务器/用户客户端，任何想加入此系统的实体必须和中央银行交互执行此步骤。可以看做群签名方案中群成员Me(用户或者地方银行)和群管理者(中央银行)之间进行的交互式协议，分别运行在用户或地方银行端和中央银行服务端群成员Me以(pk,sk1,sk2)为输入，中央银行以PK为输入，运行该协议。当该协议运行成功时，一方面中央银行在群成员注册表reg中为群成员建立一个条目，记为reg[e]，条目的内容条目的内容地方银行资格证书以及公钥；另一方面群成员Me(用户或者地方银行)获得中央银行颁发的地方银行资格证书certe，另外地方银行生成签名密钥以及验证密钥(sske,vke)，用户生成追踪密钥tk[e]。
[0051] 本步骤包括用户客户端的注册、商家客户端的注册和地方银行服务器的注册。
[0052] 1、地方银行服务器的注册
[0053] 如LBj在电子现金系统中注册流程如下：
[0054] S201-1，LBj根据PKI中的密钥对(lbsk[j],lbpk[j])计算并发送密钥的承诺值Y′j给CB。
[0055] S201-1具体包括：
[0056] S201-1-1，LBj调取PKI中的密钥对(lbsk[j],lbpk[j])。
[0057] S201-1-2，LBj随机选择y′j←Zp。
[0058] S201-1-3，LBj计算 将Y′j发送给CB。
[0059] S201-2，CB根据Y′j生成LBj的资格证书certj的前半部分，并发送给LBj。
[0060] S201-2具体包括：
[0061] S201-2-1，CB选择
[0062] S201-2-1，CB生成LBj的资格证书certj的前半部分(yj″,Aj,Xj,2)，并发送(yj″,Aj,Xj,2)给LBj。
[0063] 其中，
[0064] S201-3，LBj确定certj的前半部有效后，计算LBj的私钥sk[j]，并对sk[j]进行签名得到s[j]，将s[j]发送给CB。
[0065] S201-3具体包括：
[0066] S201-3-1，LBj校验 是否成立。
[0067] S201-3-2，若成立，则LBj计算sk[j]＝yj＝y′j+yj″，并得到等式[0068] S201-3-3，对 进行签名得到sj。
[0069] S201-3-4，将(j,lbpk[j],Aj,Xj,Sj)发送给CB。
[0070] 其中，sj为LBj对 进行签名得到的签名值。
[0071] lbpk[j]是LBj的公钥；Aj)和Xj,2是LBj和中央银行在之前交互过程中得到的证书的一部分。
[0072] S201-4，CB根据lbpk[j]验证s[j]正确后，将LBj的信息添加到注册表RegLB[j]中。
[0073] 具体的，CB根据lbpk[j]验证s[j]正确后，将(j,lbpk[j],Aj,Xj,Sj)添加到注册表RegLB[j]中。
[0074] S201-5，CB发送certj的前后部分Xj,1给LBj。
[0075] 具体的，CB发送certj的前后部分 给LBj。
[0076] S201-6，LBj验证Xj,1正确后，将certj的前半部分和Xj,1合并为certj。
[0077] S201-6具体包括：
[0078] S201-6-1，LBj验证 是否成立；
[0079] S201-6-2，如果成立，则LBj验证Xj,1正确；
[0080] S201-6-3，将certj的前半部分和Xj,1合并为certj。
[0081] S201-7，LBj生成sskj以及电子现金验证密钥vk，并公布vk。
[0082] S201-7具体包括：
[0083] S201-7-1，LBj选取随机数z←Zp；
[0084] S201-7-2，LBj生成sskj＝kz以及vk＝gz，并公布vk。
[0085] 2、用户客户端的注册、商家客户端的注册
[0086] 其中，用户客户端的注册和商家客户端的注册流程相同，本实施例仅以用户客户端的注册为例进行说明。
[0087] 如Ui在电子现金系统中注册流程如下：
[0088] S202-1，Ui根据PKI中的密钥对(lbsk[i],lbpk[i])计算并发送密钥的承诺值Y′i给CB。
[0089] S202-2，CB根据Y′i生成Ui的资格证书certi的前半部分，并发送给Ui。
[0090] S202-3，Ui确定certi的前半部有效后，计算Ui的私钥yi，并对yi进行签名得到si，将si发送给CB。
[0091] S202-4，CB根据lbpk[i]验证si正确后，将Ui的信息添加到注册表Regu[i]中。
[0092] S202-5，CB发送certi的前后部分Xi,1给Ui。
[0093] S202-6，Ui验证Xi,1正确后，将certi的前半部分和Xi,1合并为certi。
[0094] S202-7，Ui根据yi生成追踪密钥tk[i]，加密tk[i]得到用户追踪密钥密文ei。
[0095] S202-8，Ui将ei，Ai，Xi,2， 签名后发送至CB。
[0096] 其中，Ai，Xi,2分别是Ui的证书的一部分，是在用户注册过程中和银行交互时得到的。
[0097] yi是Ui的私钥，也是在注册过程中用户生成的。 可以看做Ui的公钥信息。
[0098] CB将元组(i,lbpk[i],Ai,Xi,ei,si)添加到Regu[i]中。
[0099] 其中，Xi是Ui证书信息的一部分，是在用户注册过程中和银行交互时得到的。
[0100] Si为用户对其私钥yi进行签名得到的签名值。
[0101] 下面再以图5所示的流程，对客户端的注册和地方银行服务器的注册再次说明。
[0102] 1.1，地方银行服务器LBj进行注册，LBj拥有在PKI中的密钥对(lbsk[j],lbpk[j])，计算并发送密钥的承诺值Y′j给中央银行服务器CB。
[0103] 具体的，LBj管理人员点击地方银行LBj客户端中的注册按钮，客户端调取地方银行拥有的在PKI中的密钥对(lbsk[j],lbpk[j])，随机选择y′j←Zp，计算并发送 给中央银行服务器。
[0104] 本发明提供的电子现金系统中，每个银行都需要进行注册，才能获得权力来获得用户开户并接受用户存取电子现金等功能，若不注册，则无法使用。
[0105] 1.2，CB生成地方银行资格证书certj的前半部分并发送给LBj。
[0106] 具体的，CB收到地方银行的注册响应，管理人员接收地方银行发来的响应，则CB选择 生成地方银行资格证书certj的前半部分(yj″,Aj,Xj,2)其中并发送(yj″,Aj,Xj,2)给地方银行LBj。
[0107] 1.3，LBj验证前半部分证书的有效性，若有效，则计算自己的私钥sk[j]，并对私钥进行签名得到s[j]，将签名发送给CB。
[0108] 具体的，地方银行LBj客户端收到元组序列后，校验等式是否成立，若成立，计算私钥sk[j]＝yj＝y′j+yj″，得到等式
对 进行签名得到s[j]，最后，将(j,lbpk[j],Aj,Xj,Sj)发送给CB。
[0109] 1.4，CB收到s[j]后，利用lbpk[j]验证签名s[j]的正确性，然后将地方银行的信息添加到注册表RegLB[j]中。然后发送成员资格证书的最后一部分Xj,1给LBj。
[0110] 具体的，CB收到s[j]后，用lbpk[j]验证签名s[j]的正确性，然后将元组(j,lbpk[j],Aj,Xj,Sj)添加到注册表RegLB[j]中。然后发送成员资格证书的最后一部分 给LBj。
[0111] 1.5，LBj验证收到的值Xj,1的正确性，如验证成功，则得到一个有效的证书certj。随后，LBj生成电子现金签名私钥sskj，以及电子现金验证密钥vk，随后公布验证密钥。
[0112] 具体的，LBj验证收到的值Xj,1是否确实为 (是否与 满足
配对等式如验证成功，则得到一个有效的证书随后，LBj选择随机数z←Zp，生成电子现金签名私钥sskj＝kz，以及电子现金验证密钥vk＝gz，随后公布验证密钥。同时地方银行客户端提示管理人员注册成功。
[0113] 至此地方银行注册结束。
[0114] 用户注册，与银行注册(步骤2.1到步骤2.5)大体相同，但是用户客户端Ui收到证书certi后，无需计算电子现金签名私钥与验证密钥，但是需要利用私钥yi生成其追踪密钥tk[i]并加密tk[i]得到ei。最后，需要在ei连同Ai，Xi,2， 上进行签名并发送给中央银行服务器。中央银行服务器将元组(i,lbpk[i],Ai,Xi,ei,si)添加到注册表Regu[i]中。
[0115] 具体的，用户注册时首先进行步骤2.1到步骤2.5，与银行注册协议大体相同。注册功能是通过用户客户端和中央银行服务器之间进行通信来完成。用户首先点击用户客户端注册标识符，输入PKI中存有的公私钥对，用户客户端发送用户密钥承诺值(用户客户端对其公钥进行签名，将签名作为请求发送给服务器；)发送给中央银行服务器。首先中央银行服务器验证签名的有效性，若有效，则颁发资格证书发送给用户客户端；用户客户端对服务器的响应进行处理，得到成员资格证书，用户客户端在本地存储证书，并提示用户注册成功。同时，用户客户端生成其追踪密钥：利用私钥yi生成其追踪密钥tk[i]，并加密tk[i]得到ei。最后，需要在ei连同Ai，Xi,2， 上进行签名并发送给中央银行服务器。中央银行服务器将元组(i,lbpk[i],Ai,Xi,ei,si)添加到注册表Regu[i]中。
[0116] 注册动作对于用户本身来说就是点击注册，输入PKI的公私钥即可、其余与服务器之间的交互均由用户客户端进行，无需用户处理。
[0117] 商家客户端的注册是通过商家客户端和中央银行服务器之间进行通信来完成。用户首先商家点击商家客户端注册标识符，商家客户端从本地调出用户公私钥，发送用户密钥承诺值(商家客户端对其公钥进行签名，将签名作为请求发送给中央银行服务器)发送给中央银行服务器。首先中央银行服务器验证签名的有效性，若有效，则颁发资格证书发送给商家客户端；商家客户端对中央银行服务器的响应进行处理，得到成员资格证书，商家客户端在本地存储证书，并提示用户注册成功。同时，商家客户端生成其追踪密钥，最后，需要在声称的所有参数上进行签名并发送给中央银行服务器。中央银行将用户添加到注册表中。
[0118] 三、用户通过用户客户端在地方银行服务器开户
[0119] 用户在地方银行进行开户，运行于用户和地方银行之间。用户打开本地用户客户端Ui，选择开户，界面显示已经合法注册的地方银行列表，点击地方银行。同时，Ui利用用户已保存的资格证书，通过生成证书承诺值证明值以及追踪密文密钥来证明其身份的合法性，发送给地方银行服务器LBj，地方银行服务器验证请求通过后，则为此用户在本银行开户。地方银行服务器生成响应数据并返回给用户客户端，随后发送追踪密钥密文到中央银行服务器来请求用户追踪密钥，中央银行服务器利用开启密钥对发送的密文进行解密，并生成响应数据返回给地方银行客户端，地方银行客户端对响应进行处理，将追踪密钥密文对存储在用户表中。
[0120] 此过程中央银行无需知道用户选择哪个地方银行，这也是安全的电子现金一个性质。中央银行服务器在执行响应之前，首先对接收到的信息进行身份验证，主要验证银行证书的合法性。合法性通过之后将响应数据(追踪密钥)返回给地方银行服务器。地方银行服务器随即对响应进行处理，将追踪密钥密文对存储在用户表中。
[0121] S301，Ui对Ui的证书certi进行承诺，得到承诺值 并生产证明值Πi。
[0122] 其中，certi为
[0123] S301具体包括：
[0124] S301-1，Ui随机选择 其中b＝1,…,5。
[0125] S301-2，Ui计算
[0126] 其中，
[0127] 其中，表示承诺值的向量表示形式。对于c()表示对括号内的元素进行承诺生成的值的一部分，共同组成大写向量 是系统生成基于DLin假设下的非交互式证明系统通用参考串CRS(即初始化时系统已经生成好的公共参数)。σi是用户Ui证书的第i部分。 是中央银行选择的开启密钥，在产生纠纷需要追踪客户时使用，
[0128] S301-3，Ui根据 计算：
[0129]
[0130]
[0131]
[0132] S302，Ui将 Πi，以及ei发送至LBj。
[0133] 具体的，Ui将 发送至LBj。
[0134] S303，LBj确认Ui身份及certi合法后，为Ui开户。
[0135] S303具体包括：
[0136] S303-1，LBj验证如下等式是否成立：
[0137]
[0138]
[0139]
[0140] 其中τT(u)表示一个3×3矩阵，(3,3)
位置为u∈GT其余位置为单位元1,即[0141] 所以这里表示一个3×3矩阵，其中(3,3)位置为e(g,u)其余位置为单位元1。
[0142] S303-2，若等式成立，则LBj确认Ui身份及certi合法，向Ui返回确认信息并为Ui开户。
[0143] S303-2，若等式不成立，则LBj确认Ui身份及certi不合法，向Ui返回失败信息。
[0144] S304，LBj将ei发送至CB。
[0145] S305，CB根据sk0计算追踪密钥值tk[i]，将ei及tk[i]发送至LBj。
[0146] 具体的，CB根据sk0(α1,α2)计算 将ei及tk[i]发送至LBj。
[0147] S306，LBj将(ei,tk[i])添加到用户开户列表中。
[0148] 下面再以图6所示的流程，对用户通过用户客户端在地方银行服务器开户再次说明。
[0149] 2.1，用户客户端Ui需要对持有的证书certi进行承诺计算承诺值
[0150] 因为从用户隐私想考虑，用户不想泄露自己的证书信息给地方银行，仅仅想象地方银行证明自己是合法用户，所以需要对用户客户端存储的证书进行处理。处理过程为，用户打开用户客户端，选择开户，界面显示已经合法注册的地方银行列表，点击地方银行，随即用户客户端计算用户证书的承诺值，承诺值不泄露证书信息，但是能使地方银行验证证书的有效性。
[0151] 具体的，Ui需要对持有的证书 进行承诺，客户端随机选择 其中b＝1,…,5，计算承诺值 其中，
[0152]
[0153] 2.2，用户并生成证明值Πi。
[0154] 本步骤仅仅是用户在用户客户端中申请在某地方银行开户后，用户客户端在本地计算的证明值。
[0155] 具体的，客户端计算关于满足如下等式的证明值Πi：
[0156]
[0157] 每个等式的证明值要包含9个群元素。
[0158] 证明值 计算如下：
[0159]
[0160] 证明值 计算如下：
[0161]
[0162] 证明值 计算如下：
[0163]
[0164] 2.3，Ui将承诺，证明值连同追踪密钥的密文 一起发送给LBj。
[0165] 具体的，Ui将承诺，证明值连同追踪密钥的密文 一起发送给LBj。
[0166] 2.4，LBj验证用户的身份即证书的真实合法性，如果验证通过，则向Ui返回确认信息1，表示用户可以在此存取电子现金，为用户开户，否则向Ui返回失败信息0。
[0167] 具体的，LBj收到用户开户响应，要验证用户的身份，即证书的真实合法性，即验证下列等式是否成立：
[0168]
[0169]
[0170]
[0171] 如果验证通过，则向Ui返回确认信息1，表示用户可以在此存取电子现金，为用户开户，否则向Ui返回失败信息0。用户客户端收到银行客户端返回的信息后，向用户显示确认开户成功或者失败。
[0172] 2.5，地方银行为了获得对此用户的仲裁权利，需要与要向中央银行申请得到此开户用户的追踪密钥tk[i]，中央银行将对于用户的仲裁权利能力赋予地方银行。
[0173] 此步骤中的地方银行并非中央银行选择的，而是用户自己选择的在某地方银行开户，这个地方银行为了获得对此用户的仲裁权利，需要与要向中央银行申请得到此开户用户的追踪密钥，中央银行将对于用户的仲裁权利能力赋予地方银行。
[0174] 具体的，LBj为了获得对Ui的仲裁权利，需要向中央银行申请得到此开户用户的追踪密钥
[0175] 2.6，LBj在Ui发送的信息中提取到关于追踪密钥的密文ei，发送给中央银行服务器。
[0176] 具体的，用户开户成功后，LBj将Ui发送的信息中提取到关于追踪密钥的密文ei，发送给中央银行服务器。
[0177] 2.7，中央银行服务器利用开启密钥sk0，计算tk[i]，提取出用户的追踪密钥tk[i]，并发送给地方银行LBj。
[0178] 具体的，中央银行服务端收到地方银行客户端的信息后，管理人员确认信息来源可靠后，同意中央银行服务端执行响应。中央银行服务器利用sk0(α1,α2)计算提取出用户的追踪密钥tk[i]，并发送至LBj。
[0179] 2.8，LBj将二元组(ei,tk[i])添加到用户开户列表regu[i]中。
[0180] 具体的，LBj收到中央银行服务器信息后将二元组(ei,tk[i])添加到用户开户列表regu[i]中。
[0181] 四、用户通过用户客户端从地方银行服务器中提取电子现金
[0182] 用户在其开户的银行取走一笔电子现金，用户得到银行签名的电子现金M，银行则在用户的账户中扣除相应的金额。用户客户端发送取款请求，地方银行服务器利用电子现金签名密钥生成电子现金值作为响应数据发送给用户客户端，并更新用户账户表。用户客户端处理响应并验证电子现金的有效性，若有效则导出并保存电子现金，若无效则重新发送请求。
[0183] S401，用户客户端Ui向地方银行服务器LBj发送取款请求，LBj为Ui的开户银行服务器。
[0184] S402，LBj根据取款请求生成电子现金M发送给Ui。
[0185] 除此之外，LBj还会更新Ui的用户账户表。
[0186] 由于取款请求中包括取款金额，因此S402具体包括：
[0187] S402-0，LBj确认取款金额不大于Ui用户账户表中的存款金额。
[0188] S402-1，根据取款请求确定电子现金M。
[0189] S402-2，LBj利用电子现金签名密钥sskj对M进行签名，生成签名值σ(M)。
[0190] S402-2具体包括：
[0191] S402-2-1，LBj选取随机数s←Zp。
[0192] 其中，Zp指的是循环群，s是在0到p整数之间选择的一个随机整数。
[0193] S402-2-2，LBj通过如下公式计算σ(M)：
[0194] σ(M)＝(sskjF(M)s,gs)＝(kZF(m)s,gs)。
[0195] gs为g的s次幂，gs为LBj将M进行签名时的一部分，k为M的长度，k
m＝(m1,…,mk)∈{0,1}。
[0196] 其中u0到uk为电子现金系统在初始化时发布的随机向量，ui为随机向量的第i个值u:(u0,u1,…,uk)←Gk+1这里电子现金长度也为k，所以对于电子现金M，计算其签名函数为σ(M)＝(sskjF(M)s,gs)＝(kZF(m)s,gs)。
[0197] S402-3，LBj对LBj的证书certj进行承诺并生产证明值
[0198] 其中，certj＝(Aj,Xj,jj)， σj4＝(uz,gz)，σj5＝kZF(M)s，σj6＝gs；
[0199] 且满足如下等式：
[0200]
[0201] 其中Xj，yj，Aj分别是地方银行的证书信息的一部分，证书应为certj＝(Aj,Xj,jj)，这三个值是在注册时地方银行和中央银行交互式时两方生成的。
[0202] e()是双线性配对运算符号，Ω＝gγ是中央银行公开的参数，γ是中央银行主密钥；
[0203] S402-4，LBj将σj， 和σ(M)发送给Ui。
[0204] S403，Ui验证M的有效性。
[0205] S403具体包括：
[0206] S403-1，Ui根据σj， 验证LBj的身份。
[0207] S403-2，Ui验证σ(M)。
[0208] 具体的，验证如下等式是否满足：
[0209]
[0210] σj,5，σj,4,2，σj,6，σj,4,1，σj,4,2为LBj发给Ui的M中包含的元素。
[0211] S403-3，若S403-1的验证结果为验证通过，且，S403-2的验证结果也为验证通过，则确定验证结果为有效。
[0212] S403-4，若S403-1的验证结果为验证不通过，或者，若403-2的验证结果为验证不通过，则确定验证结果为无效。
[0213] S404，当验证结果为有效时，导出并保存M。
[0214] S405，当验证结果为无效时，重复执行步骤S401至S403。
[0215] 下面再以图7所示的流程，对用户通过用户客户端从地方银行服务器中提取电子现金再次说明。
[0216] 3.1，LBj利用电子现金签名私钥sskj对电子现金M进行签名生成签名值σ(M)。
[0217] 具体的，用户在用户客户端中点击取款功能，选择地方银行。Ui显示用户在地方银行的余额，用户点击取款功能，Ui显示输入框，用户输入取款金额(小于余额)。Ui将取款请求发送给LBj。
[0218] LBj收到用户取款请求，验证取款金额小于存款金额，成功则继续执行，否则返回拒绝请求服务。
[0219] LBj客户端利用电子现金签名私钥sskj对电子现金M进行签名：选取随机值s←Zp设电子现金M的长度表示为k，那么对于M的签名值可被计算为σ(M)＝(sskjF(M)s,gs)＝(kZFs s k(m) ,g)，其中 (m＝(m1,…,mk)∈{0,1})。
[0220] 3.2，LBj同样需要对自己的证书进行承诺及证明，生成 所以LBj最后生成σj，并生成证明值
[0221] 具体的，LBj同样需要对自己的证书进行承诺及证明，生成 所以LBj最后生成 并生成证明值
[0222] 其中， σj4＝(u2,g2)，σj5＝kZF(M)s，σj6＝gs。
[0223] 且满足如下等式：
[0224]
[0225] 3.3，LBj将 以及证明值 一起作为电子现金M发送给Ui。
[0226] 3.4，Ui对得到的电子现金值要进行正确性验证，首先要用对LBj的身份进行验证，其次要对这笔现金的签名进行判定；若两次均通过验证，则证明该客户得到的电子现金是真实有效的，并且此电子现金可用于以后的支付协议。
[0227] 具体的，Ui得到的电子现金值要进行正确性验证，首先要用对LBj身份进行验证，即验证证明值与同构的等式成立。其次要对这笔现金的签名进行判定，即验证签名值是否满足以下两个等式：
[0228]
[0229] 若两次均通过验证，则证明该客户得到的电子现金是真实有效的，并且此电子现金可用于以后的支付协议。则Ui向用户显示取款成功，并在本地存储此笔电子现金。
[0230] 五、用户通过用户客户端向商家客户端支付购物费用
[0231] 用户想要在商家进行购物需要支付一笔电子现金，商家输出为1表示接受，输出为0表示拒绝。设此次交易的交易标识为R，并且交易中的电子现金为消费者花费的第F笔电子现金。用户客户端首先生成证书承诺值以及证明值，随后一同将现金序列号以及防双重支付值绑定进即将支付的电子现金中并发送给商家客户端，商家客户端接受响应后验证电子现金有效性，若有效则导出并存储电子现金，并且向消费者客户端返回响应结果。
[0232] 其中，用户客户端的支付过程如下：消费者在用户客户端中选择点击支付，扫描商家二维码或者输入上家客户端地址信息，成功后，用户客户端成证书承诺值和证明之，在用户客户端中选择在地方银行中取出的电子现金，用户客户端将现金序列号以及防双重支付值绑定进即将支付的电子现金中，用户客户端将上述生成的值发送给商家客户端。
[0233] 上述过程中，消费者呈现给商家的是3个东西：1)消费者的身份信息，即证书的承诺值和证明值。2)电子现金。3)证明电子现金有效的信息(序列号，防双重支付值)。
[0234] 在具体消费中，首先消费者利用本地用户客户端识别商家客户端地址(通过扫描二维码或者输入地址等途径)，识别成功后，则可以选择支付金额，进入选择电子现金界面，选择从银行取出的电子现金。选择成功后用户客户端进行一系列计算，完成后用户可以点击支付，将选择的电子现金发送给商家。商家客户端受到响应后，验证现金的有效性和来源的合法性，验证成功后提示商家提示收到现金一笔，金额XX。
[0235] S501，Ui计算花费电子现金时的序列号S以及防双重支付值
[0236] S502，Ui将M的 替换成Ui对自己身份的承诺
[0237] S503，Ui生成花费的电子现金的临时标识
[0238] S504，Ui生成证明值
[0239] S504具体包括：
[0240] Ui根据 计算：
[0241]
[0242]
[0243]
[0244]
[0245] S505，Ui生成花费的电子现金
[0246]
[0247] S506，Ui将M'支付给商家客户端。
[0248] S507，商家客户端对Ui的身份进行验证。
[0249] S507具体包括：
[0250] 商家客户端验证如下等式是否成立：
[0251]
[0252]
[0253]
[0254]
[0255] S508，商家客户端确认M'是否由LBj签名。
[0256] S508具体包括：
[0257] 商家客户端验证如下等式是否成立：
[0258]
[0259] S509，若S507验证通过，且，S508确认成功，则商家客户端接收M'。
[0260] S510，电子现金系统删除花费电子现金相关的交易标识，并执行交易。
[0261] 下面再以图8所示的流程，对用户通过用户客户端向商家客户端支付购物费用再次说明。
[0262] 4.1，为了防止重花费问题，消费者(也即特殊用户)需要首先计算在花费此笔电子现金时的序列号S以及防双重支付值T。
[0263] 具体的，用户想要在商家进行购物需要支付一笔电子现金，首先打开消费者用户客户端Ui，选择支付功能。Ui向消费者显示客户端中电子现金的余额以及个数，消费者选择需要支付的相应电子现金。Ui计算花费电子现金时的序列号S以及防双重支付值[0264] 4.2，Ui将从银行中取出的电子现金进行修改，将电子现金内与银行身份有关的信息 替换成Ui对自己身份的承诺
[0265] 4.3，Ui生成与此电子现金有关的临时ID，记为σ0，生成证明值
[0266] 具体的，Ui生成与此电子现金有关的临时ID： 记为σ0。同时给出下列公式相应证明：
[0267]
[0268] 前三个等式是关于σ'1,1,σ'1,2,σ'2,2,σ'3的二次配对等式，因此每个等式的证明与步骤2.2的证明方法相同。根据Groth-Sahai证明系统，对于第四个等式的证明 计算如下：
[0269]
[0270] 4.4，Ui将序列号S，防双重支付值T以及临时ID添加进电子现金M'中，则电子现金[0271]
[0272] 4.5，Ui将电子现金M'支付给商家客户端。
[0273] 具体的，消费者需要协助Ui绑定商家地址。Ui需要通过扫描二维码或者输入商家地址信息等方式识别商家地址。实现将电子现金支付给商家Mj。
[0274] 4.6，商家客户端收到电子现金后，首先要用对用户的身份进行验证。
[0275] 具体的，商家客户端收到电子现金后，首先要用对用户的身份进行验证，即验证证明值是否满足等式：
[0276]
[0277]
[0278]
[0279]
[0280] 4.7，商家客户端对这笔现金的签名进行判定，即验证下列等式是否成立，来确定现是否金是由银行签名的。
[0281]
[0282] 4.8，如果上2个步骤均验证成功，则接受该电子现金，电子现金系统自动删除交易标识并执行买卖交易，否则拒绝。
[0283] 具体的，如果上2个步骤均验证成功，则接受该电子现金，商家客户端提示商家收款成功，否则拒绝。
[0284] 六、商家通过商家客户端在地方银行服务器中存入电子现金
[0285] 商家在其开户的银行存入一笔电子现金，银行则在用户的账户中增添相应的金额。商家客户端首先生成证书承诺值以及证明值，随后连同收到的现金一起发送给地方银行服务器，地方银行服务器接受响应后验证电子现金有效性，若有效则继续验证电子现金是否被重复花费，若两者均验证通过，则更新用户账户表，最后向商家客户端返回响应。
[0286] S601，商家客户端将M'的 替换成商家客户端对自己身份的承诺 并生产证明值
[0287] S 6 0 2 ，商 家 客 户 端 将 S 6 0 1 替 换 后 的 代 存 电 子 现 金发送给地方银行服务器LBc。
[0288] S603，LBc验证商家客户端身份。
[0289] S604，LBc确定M”是否有效。
[0290] S605，若S603验证通过，且，S604确认成功，则LBc检查数据库中是否有与S相同的值。
[0291] S606，若无与S相同的值，则LBc将M”存入商家客户端的账户，并在数据库中记录M”的交易信息，交易信息至少包括S和T。
[0292] S607，若有与S相同的值，则LBc获取数据库中S值对应的 计算将g1/S+i+1带入T＝gZ·(g1/S+i+1)R
求得 根据 识别重复花费用户身份信息。
[0293] 下面再以图9所示的流程，对商家通过商家客户端在地方银行服务器中存入电子现金再次说明。
[0294] 5.1，商家将从消费者处得到的电子现金存入银行，首先需要将电子现金进行处理，将电子现金内与消费者身份有关的信息替换成客户对自己身份的承诺，并给出相应证明值，同步骤4.2。
[0295] 具体的，商家客户端电子现金M'存入银行LBc，首先在商家客户端中选择存款功能，商家客户端显示用户已开户的地方银行列表，用户选择银行LBc。商家客户端显示用户本地收到的电子现金，用户选择想要存入银行的现金M'。商家客户端首先需要将电子现金进行处理，将电子现金内与消费者身份有关的信息 替换成商家客户端对自己身份的承诺 并给出相应证明值，同步骤4.2。
[0296] 5.2，商家客户端将处理后的现金发送给LBc。
[0297] 具体的，商家客户端将处理后的现金 发送给LBc。
[0298] 5.3，LBc首先要确定商家的身份即承诺及证明的真实合法性，验证方法同步骤2.4。
[0299] 5.4，LBc要对电子现金进行判定，即验证M”中的签名值能否使配对等式是否成立。
[0300] 5.5，若步骤5.3和5.4的验证同时成立，则证明LBc得到的电子现金是真实有效的，并将其存入商家账户。
[0301] 5.6，LBc需要在电子现金存入电子现金数据库Reg[C]中检查是否有值与S相等，若有相等的情况，则此笔电子现金被重复花费过，则银行提取出两笔S值相等的现金中的中T，1/S+i+1
T'进行如下计算： 随后银行可以将g 的值带入T求得 从而重
复花费用户身份信息被识别出。若没有被重复花费过，则将此笔现金存入商家账户。并在已花费电子现金数据库中记录此笔现金。
[0302] 具体的，LBc在电子现金存入电子现金数据库Reg[C]中检查是否有值与S相等若有相等的情况，则此笔电子现金被重复花费过，则银行提取出两笔S值相等的现金中的中进行如下计算： 随后LBc将g1/S+i+1的值带入T＝gZ·(g1/S+i+1)R便可求得 从而重复花费客户身份信息被识别出。若没有被重复花费过，则将此笔现金存入商家账户。并在已花费电子现金数据库中记录此笔现金。
[0303] 七、中央银行服务器监控非法交易
[0304] 若存在非法交易，合法用户或者地方银行有权通报中央银行。中央银行需要通过此步骤来追踪出交易方用户的身份。中央银行输入用户资格证书CID与开启密钥sk0，输出用户身份ID。
[0305] S701，CB从电子现金M″′中提取C(σ3)，通过sk0打开C(σ3)，计算[0306] S702，CB在RegLB[i]中查找是否有表项
[0307] S702，若有表项 则CB根据d追踪M″′涉及的客户端身份，客户端为用户客户端，或者，客户端为商家客户端。
[0308] 例如，
[0309] 6.1，中央银行服务器首先从电子现金中提取出得到客户的证书承诺值C(σ3)，利用开启密钥sk0＝(α1,α2)，在签名中打开C(σ3)，计算出
[0310] 具体的，首先合法用户或者地方银行通过本地客户端，将非法电子现金发送至中央银行服务器。中央银行服务器验证信息有效性，若有效，则首先从电子现金中提取出得到用户的证书承诺值C(σ3)，利用开启密钥sk0＝(α1,α2)，在签名中打开C(σ3)，计算出[0311] 6.2，中央银行服务器在注册列表RegLB[i]中查找是否有表项 若存在则返回对应的标志符d，追踪到客户的身份。
[0312] 八、两客户端的电子现金仲裁
[0313] 其中，客户端可以为用户客户端，也可以为商家客户端，即可以仲裁2个用户客户端间的电子交易纠纷，也可以仲裁2个商家客户端间的电子交易纠纷，还可以仲裁1个用户客户端和1个商家客户端间的电子交易纠纷。
[0314] 特定情况下，若用户双方产生纠纷，用户意图通过签发电子现金的某地方银行，来判定某笔电子现金是否是由用户生成的这一判定进行仲裁，输入某笔电子现金与追踪密钥密钥tk[d]，输出判定向量τ，所有人都能通过此致来判定此电子现金是否是拥有追踪密钥tk[d]的用户生成的。
[0315] 下面以用户1和用户2发生纠纷为例，进行说明。
[0316] S801，用户1通过用户客户端1根据电子现金Md中的vk确定签发Md的地方银行服务器LBd，并向LBd发送Md的仲裁申请。
[0317] S802，LBd提取Md的用户追踪密钥密文ed，确定对应的追踪密钥值tk[d]，根据tk[d]确认Md的生成客户端。
[0318] S803，LBd输出盲化值 以及生成客户端，以使客户端2能够验证 的有效性，并
跟踪仲裁过程。
[0319] S803具体包括：
[0320] S803-1，LBd选取β←Zp。
[0321] S803-2，LBd输出 以及生成客户端。
[0322] S804，用户2的用户客户端2通过基于 和e(σ4,2,c3)＝e(c2,g)验证 的有效性，并通过 跟踪仲裁过程。
[0323] 例如，
[0324] 7.1，用户从电子现金中提取出验证公钥vk，来找到签发此笔电子现金的地方银行，并向其服务器LBd发送目标电子现金值Md来申请执行仲裁。
[0325] 具体的，用户1和用户2发生纠纷，则用户1在用户客户端1中选择仲裁功能，从用户1处收到的电子现金中提取出验证公钥vk，来识别出到签发此笔电子现金的地方银行。用户客户端1向LBd发送目标电子现金值Md来申请执行仲裁。
[0326] 7.2，LBd从电Md中提取出用户追踪密钥密文ed，从用户表中找到与其对应的追踪密钥值tk[d]，来确认此笔现金确实是由此用户生成的。
[0327] 具体的，LBd管理员确认后，LBd从Md中提取出用户追踪密钥密文ed。从用户表中找到与其对应的追踪密钥值tk[d]，来确认此笔现金确实是由此用户生成的。
[0328] 7.3，LBd输出一个盲化值 以及生成客户端。任何人能够验证这一盲化值的有效性，并确定追踪过程的结果。
[0329] 具体的，LBd选取β←Zp，输出一个盲化三元组 以及生成客户端给用户客户端2。
[0330] 用户客户端2通过等式 和e(σ4,2,c3)＝e(c2,g)来验证这一三元组的有效性，并通过验证等式 是否成立来确定追踪过程的结果，最终将
结果通过用户客户端2界面发布给用户2。
[0331] 本实施例提供的系统，用户客户端Ui向地方银行服务器LBj发送取款请求，LBj为Ui的开户银行服务器；LBj根据取款请求生成电子现金M发送给Ui；Ui验证M的有效性；当验证结果为有效时，导出并保存M，解决可交易中传统纸币带来的各种限制因素，同时有效保护用户的匿名性。
[0332] 需要明确的是，本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。
[0333] 还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。
[0334] 最后应说明的是：以上所述的各实施例仅用于说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。
