CN1877627A

CN1877627A - 在线交易的电子支付系统和方法

Info

Publication number: CN1877627A
Application number: CNA2005100751730A
Authority: CN
Inventors: 冯登国; 周永彬; 张振峰
Original assignee: Institute of Software of CAS
Current assignee: Institute of Software of CAS
Priority date: 2005-06-10
Filing date: 2005-06-10
Publication date: 2006-12-13

Abstract

本发明涉及一种由买方、卖方、银行和可信第三方(TTP)在计算机网络上共同实现的在线公平、安全的在线交易电子支付系统和方法。所述的系统包括至少一买方、一卖方和一银行，其特征在于，还包括可信第三方和基于RSA的公平交换模块；TTP不参与交易的过程，仅在交易的任一方抵赖的时候执行仲裁，而买方、卖方和银行可以通过公平交换模块利用基于标准RSA的密码算法实现承诺签名；所述的在线交易电子支付方法，参与交易的至少包括一买方、一卖方和一银行，其特征在于，在任意两个互不信任的交易方之间进行的交易步骤可调用基于RSA的公平交换模块，一可信第三方在任一交易方抵赖时执行仲裁。

Description

在线交易的电子支付系统和方法

技术领域

本发明主要涉及电子商务领域内的公平支付，更确切地是涉及一种用于在线交易的基于优化公平交换的电子支付系统和方法。

背景技术

电子商务、移动商务已成为基于Internet的现代经济活动的主要形式之一，它们的发展对于交易安全性提出了更高的要求。电子商务对交易安全的要求反映在两个方面：第一、交易的有效性：在电子商务活动中，要使其具有法律效力，除了制定必要的交易政策法规外，在技术手段上必须要反映交易者的身份、提供有效的手段保证数据的完整性，使数据具备法律的约束力，即发送者不能抵赖由自己所签发的数字化交易；同时数据的发送方要有签名的能力。第二、交易信息的安全性：由于因特网本身的开放性，使网上交易面临种种危险，因此，概括起来，电子商务具有如下最基本的安全需求：

1、身份鉴别(Authentication)：在双方进行交易前，首先要能确认对方的身份，要求交易双方的身份不能被假冒或伪装；

2、数据的机密性(Confidentiality)：对敏感信息进行加密，即使别人截获数据也无法得到其内容；

3、数据的完整性(Integrity)：要求收方能够验证收到的信息是否完整，是否被人篡改，保障交易的严肃和公正；

4、不可抵赖性(Non-Repudiation)：交易一旦达成，发送方不能否认他发送的信息，接收方则不能否认他所收到的信息。

在设计公平交换协议时，通常有三种基本的方法：逐步秘密交换方法、使用在线可信第三方(TTP，trusted third party)的方法、使用离线TTP的方法。逐步秘密交换方法反映了网络异步交换的特点，但是总存在至少“一比特的不公平性”。因此，目前国际上已经很少有基于这种方法的公平交换协议。使用在线可信第三方的交换方法是在协议中使用一个在线的可信第三方作为公平交换的基础，由于在交换的过程中必须使用一个在线的TTP作为公平交换的基础，所以无论从计算上还是在通信上讲TTP都会成为一个瓶颈，这就注定这类交换方法的效率不会很高。因此，如何通过有效的手段在保证电子交易的安全性的前提下，实现效率较高的使用离线TTP的公平交换协议，就成为研究的重点。

在传统的在线交易电子支付方案中，参与实体通常有三方：银行、买方和卖方，其中买方和卖方互不信任，但共同信任银行。这样的缺点在于卖方和银行之间必须达成协议，买方购物也必须到指定银行支付，这样的交易模式会给买方和卖方增添许多不必要的麻烦。随着电子商务理论的改进和实践应用的飞速发展，这种简单的信任模型已不再能够满足新的应用需求。

发明内容

针对上述问题，本发明的一个目的在于提供一种在线交易的电子支付系统，包括至少一买方、一卖方、一银行、一可信第三方(TTP)和基于RSA的公平交换模块。其中，TTP不参与正常的交易过程，仅在交易的任一方抵赖的时候参与执行仲裁。在传统的买方和卖方互不信任但共同信任银行的交易模式下，所述的参与交易的三方在交易的过程中需调用一次基于RSA的公平交换模块，即，买方和卖方之间的数据交换通过基于RSA的公平交换模块实现。

在上述系统中，也可以是买方和银行或卖方和银行之间互不信任，还可以是参与交易的三方互相都不信任，但无论交易方之间的信任关系如何改变，参与交易的任一方总是信任TTP；并且，在所述的系统中包含的交易方进行在线交易的时候，互不信任的双方之间的信息交换都可以通过调用基于RSA的公平交换模块来实现。

本发明的另一个目的还在于提供一种基于上述系统的在线交易的电子支付方法，在交易的所有步骤中采用杂凑值和数字签名技术来保证通信信息的完整性和真实性，并采用公平的交换协议和离线的第三方来保证交易的公平性。

根据上述的目的，实现本发明的一个具体的方案可以是：参与在线交易的实体包括一个买方、一个提供在线服务的卖方、一个提供电子支付业务的银行，所述的三个交易方和一个提供认证与仲裁的TTP以及一个提供公平交换协议的基于RSA的公平交换模块共同组成了一个在线交易的电子支付系统。其中，买方、卖方和银行可以各自独立，即在交易之前，买方、卖方和银行之间不需要达成任何协议；换言之，买方、卖方和银行三者之间互不信任，但共同信任TTP是保证在线交易能顺利和公平地进行的基础。也可以简化三方的信任关系，即买方和卖方仍然互不信任、但共同信任银行，则在这个最简化模式下，正常的交易过程包括如下步骤：

1)服务请求步骤，买方向卖方提出经过数字签名的服务请求，其中：

买方发给卖方的服务请求消息由服务请求信息、买方对服务请求信息的签名、服务请求信息和买方对服务请求信息签名的杂凑值组成，而在买方的服务请求信息中则包含有买方的ID、买方的证书、卖方的ID、买方的服务请求内容、买方发出服务请求的时间信息，买方将服务请求信息和买方对服务请求信息签名的杂凑值作为此次服务请求的ID(即交易步骤ID，不同于买方和卖方的ID)；

2)服务响应步骤，卖方验证所述的服务请求有效后，向买方发送经过数字签名的服务承诺，其中：

卖方发给买方的服务承诺消息由服务承诺信息、卖方对服务承诺信息的签名以及服务承诺信息和卖方对服务承诺信息签名的杂凑值组成，而在卖方的服务承诺信息中则包含有卖方的证书、卖方的承诺的服务信息、卖方提供服务承诺的时间、卖方的ID、买方的ID、卖方的服务承诺。卖方将服务承诺信息和卖方对服务承诺信息签名的杂凑值作为此次服务响应的ID；

3)取款请求步骤，买方验证卖方的服务承诺有效后，向银行提出经过数字签名的取款请求，其中：

买方发给银行的取款请求消息由取款请求信息、买方对取款请求信息的签名以及取款请求信息和买方对取款请求信息签名的杂凑值组成，而在买方的取款请求信息中则包含有买方的ID、买方的证书、银行的ID、买方的具体的取款内容、买方发出取款请求的时间信息，买方将取款请求信息和买方对取款请求信息签名的杂凑值作为此次取款请求的ID；

4)取款响应步骤，银行验证买方的取款请求有效后，向买方发送经过数字签名的取款响应，其中：

银行发给买方的取款响应消息由取款响应信息、银行对取款响应信息的签名以及取款响应信息和银行对取款响应信息签名的杂凑值组成，而在银行的取款响应信息中则包含有银行的证书、银行ID、买方的ID、买方的具体的取款信息、银行响应买方的取款请求的时间、银行响应消息所对应的买方的取款请求消息的ID，银行将取款响应信息和银行对取款响应信息签名的杂凑值作为取款响应消息的ID；

5)在线支付步骤，买方验证银行的取款响应有效后，向卖方发送经过数字签名的支付承诺，其中：

买方发给卖方的在线支付消息由在线支付信息、买方对在线支付信息的签名以及在线支付信息和买方对在线支付信息签名的杂凑值组成。而在线支付信息中则包含有买方的ID、买方的证书、银行的ID、买方在线支付的具体内容、买方在线支付的时间信息、买方的在线支付所对应的卖方的服务承诺消息的ID、支付秘密随机数r_payment以及对应的支付承诺y_payment，买方将在线支付信息和买方对在线支付信息签名的杂凑值作为此次在线支付消息的ID；

6)转帐请求步骤，卖方验证买方的支付承诺有效后，向银行发送经过数字签名的转帐请求，其中：

卖方发给银行的转账请求消息由转账请求信息、卖方对转账请求信息的签名以及转账请求信息和卖方对转账请求信息签名的杂凑值组成，而在卖方的转账请求信息中包含有买方的卖方的证书、卖方的ID、银行的ID、买方的在线支付信息、卖方的转账请求信息、卖方提出转账请求的时间、卖方的服务请求所对应的买方在线支付请求消息的ID，卖方将转账请求信息和卖方对转账请求信息签名的杂凑值作为此次转账请求的ID；

7)转帐响应步骤，银行验证卖方的转帐请求有效后，向卖方发送经过数字签名的转帐响应，其中：

银行发给卖方的转账响应消息由转账响应信息、银行对转账响应信息的签名以及转账响应信息和银行对转账响应信息签名的杂凑值组成，而在银行的转账响应信息中则包含有银行的证书、银行的ID、卖方的ID、转账信息、银行的转帐响应时间、银行的转账响应消息所对应的卖方的转账请求消息的ID，银行将转账响应信息和银行对转账响应信息签名的杂凑值作为此次转帐响应的ID；

8)服务承诺步骤，卖方验证银行的转帐响应有效后，向买方发送经过数字签名的服务提供消息，其中：

卖方发给买方的服务提供消息由在交易步骤二中生成的服务提供秘密随机数r_service、此服务提供消息所对应的买方的在线支付消息的ID以及服务提供秘密随机数r_service和在线支付消息的ID的杂凑值组成，卖方将秘密随机数r和在线支付消息的ID的杂凑值作为此次服务提供消息的ID。

在上述的整个交易过程中，每个步骤均采用杂凑链技术来保证整个交易所有步骤的顺序完成，防止买方的重放攻击(特别是重复支付)；并且任意交易的任意步骤的ID由此交易步骤的交易信息的杂凑值唯一标识，通过交易步骤的ID，所有的交易步骤被顺序链接在一起形成一个完整的交易过程；而且，参与交易的任一方或TTP都可以通过验证所收到的消息签名的杂凑值来检查消息的完整性，还可以通过验证对消息的签名检查消息的真实性。

在上述的步骤1)至4)和6)至8)，所述的签名为普通的RSA签名；在上述的步骤2)和步骤5)中，所述的数字签名是通过基于RSA的承诺签名技术实现的，具体的承诺签名算法定义为Sig(sk，m，r)，其中sk为签名者的私钥，m为签名消息，r为签名时产生的秘密随机数。实现承诺签名σ＝Sig(sk，m，r)时，设计了一个基于可信第三方公钥N的单向带陷门函数：

y＝f_e(r)＝r^e mod N＝r^{H(ID‖pk)‖0x01} mod N

签名者签名时产生随机数r，通过ID，公钥pk计算出e，H为杂凑值函数(如SHA1)，最终计算出单向陷门函数的结果y。然后计算y＝f_e(r)用于产生承诺签名，用私钥sk对消息m和y进行普通的RSA签名σ＝RSASig_sk(m‖y)，σ就是最终的RSA承诺签名结果，即σ＝Sig(sk，m，r)。

而承诺签名的验证过程和签名过程相同。仅仅是比较签名方承诺的y和验证方计算出的y’是否相同。

进一步地，在上述的交易过程中，当其中的任意一个步骤发生异常情况时，都可以交由离线的TTP来仲裁。具体地，当交易中的1、2、3、4、6、7这六个交易过程中出现异常时，TTP首先检查这6步所对应的信息中的杂凑值来确认消息的完整性，然后检查对应的信息中的签名来检查消息的真实性，从而确认是谁的责任，帮助解决交易争端。当交易的第5步出现异常时，TTP恢复出买方的支付承诺所对应的秘密随机数，然后和客户交给卖方的秘密随机数相比较后确认是谁的责任。当交易的第8步出现异常时，TTP恢复出卖方的服务承诺所对应的秘密随机数，并和卖方交给客户的秘密随机数相比较后确认是谁的责任。

在上述的在线交易电子支付系统和方法中，当任一交易方抵赖或交易的任一步骤出现异常情况时，与该交易方交换消息的另一交易方或是该步骤中的另一交易方可以向TTP提出仲裁请求，由TTP执行仲裁程序。此时，TTP将利用一个陷门函数恢复出参与交易的签名者用于生成承诺签名的秘密随机数，具体过程如下：

(1)请求仲裁者向TTP提供仲裁信息‖m，ID，y，d‖，其中m为待签名消息，ID为签名者标识，y为签名者的签名承诺，δ为签名

(2)TTP检查0＜y＜N是否成立，其中N为TTP公钥。如果该条件不成立，则中止签名恢复，返回“无效签名”；

(3)TTP检查H(m‖y)是否等于d^e mod n(其中e，n是签名者的公钥)。如果该条件不成立，则中止签名恢复，返回“无效签名”；

(4)TTP计算中间变量λ＝H(ID‖PK)‖0x01。设(N)＝(p-1)(q-1)，该值仅有TTP知道。TTP利用扩展的欧几里德算法计算θ，满足λθ＝1 mod(N)；

(5)TTP计算r＝f_d(y，q)＝yq mod N，这里的r即用来生成承诺签名的秘密随机数

本发明的优点在于，采用离线的可信第三方来保证交易的公平性。基于信息技术的商务活动的主要问题之一就是在任意的两个互不信任的主体之间以一种高效、公平的方式来交换电子数据；公平性和高效性成为这类电子商务协议的基本要求。公平交换协议可以使得参与交换的双方以公平的方式交换信息；这样，要么任何一方都可以得到对方的信息，要么双方都得不到对方的信息。公平性是大多数电子商务协议安全所必须解决的关键问题。本交易方案使用一个离线可信第三方(TTP)作为公平交换的基础：即TTP不需要在线参与正常的交换过程，而只需参与双方发生了纠纷的交换，帮助解决交易争端，以便保证交换的公平性。

附图说明

图1为最简化模式下在线交易的电子支付系统的结构示意图；

图2为最简化模式下在线交易的电子支付方法的流程图。

具体实施方式

如图1所示，为最简化模式下的一种在线交易的电子支付系统，其中，买方、卖方和银行是参与在线交易的实体，买方和卖方之间互不信任，但共同信任银行，买方和银行、卖方和银行之间的信息交换采用普通的RSA签名，而买方和卖方之间的信息交换则需要通过基于RSA的公平交换模块进行。该系统还包括一可信第三方(TTP)，所述的TTP不参与买方、卖方和银行之间正常的交易过程，但无论交易中的任一方有抵赖行为时，与抵赖交易方进行信息交换的另一交易方都可以向TTP提出仲裁申请，由TTP执行仲裁程序。

在具体的实现方案中，买方所在的系统为客户端系统，卖方和银行所在的系统为服务器系统，TTP所在的系统为仲裁系统。

所述的客户端系统的具体实现手段是用ATL开发的COM组件，COM组件打包后，嵌入服务器Web页面，买方访问Web服务器，通过从服务器上下载客户端系统，从而与服务器交互。客户端模块的特点是模块结构、接口必须清晰明确，模块代码必须满足重用，力求精简，执行代码小。

客户端系统为了满足买方交易所需的签名，数据保存，验证等操作，通过了签名、验证等一系列操作接口，对交易信息进行签名、验证、保存等操作。客户端用到交易消息流，具体实现时，采用XML消息格式，对XML消息进行Base64编码传输。

所述的服务器系统既包括买方服务器，也包括银行服务器。尽管两方在业务数据、交易流程中的作用等方面截然不同，但是从安全交易的角度来看，两者功能上又是相同的，都是要实现身份识别、数据认证、完整性校验、数据请求应答。服务器模块的特点在于数据的处理，交易的数据必须经过验证，核实，保存。具体实现时，服务器系统基于.NET平台Web技术实现，服务器程序使用C#实现。

服务器由数据签名验证、Web站点、数据比较和保存、数据库操作等部分构成。每一部分操作的数据，则是根据客户端发送的XML消息进行重新构造，生成相应的应答消息。

所述的仲裁系统的实现是通过网上仲裁的方式。当交易中出现异常，如签名数据验证失败，数据被恶意串改，消息审核失败等情况，买方可以向可信第三方要求仲裁。仲裁部分可分为两个模块：交易流程验证，交易秘密随机数的恢复。交易流程认证实现的交易中具体某一步的数据认证，交易秘密随机数实现的是卖方抵赖时，卖方秘密随机数由可信任中心恢复。仲裁模块也是基于.NET平台开发。

仲裁系统使用到的数据源是客户端保存的交易信息文件。买方在仲裁服务器上的操作流程：首先买方登录可信任中心的仲裁Web站点，上传交易数据(也就是每次交易客户端所保存的XML数据)。仲裁服务器解析客户上传的交易数据，首先进行数据的审核，认证，这一部分主要是验证杂凑值和签名；接着数据分析(如交易一些列的ID、时间、金额等的核实)；如果这些都无误就用TTP的私钥恢复卖方的秘密随机数。

如图2所示，为最简化模式下的在线交易的电子支付方法的流程图，包括如下步骤：

第1步：

买方向卖方提出经过数字签名的服务请求，服务请求消息格式如下：

<ServiceRequestMsg>------------------------------------------------------服务请求消息节点

<ServiceRequest>-----------------------------------------------------------服务请求节点

<ServiceRequestInfo>-------------------------------------------------服务请求信息节点

<CustomCert/>-------------------------------------------------------买方证书

<CustomID/>---------------------------------------------------------买方ID

<MerchantID/>-------------------------------------------------------卖方ID

<OrderBill>--------------------------------------------------------订单信息节点

<SerialNumber/>------------------------------------------------订单序列号

<OrderItems>---------------------------------------------------订单项节点

<Item>-----------------------------------------------------订单小项节点

<ItemName/>-------------------------------------------商品名称

<Number/>---------------------------------------------商品数量

<Price/>----------------------------------------------商品价格

</Item>

</OrderItems>

<Sum/>---------------------------------------------------------商品总金额

<PaymentMethod/>-----------------------------------------------支付方式

<OrderTime/>---------------------------------------------------下订单的时间

<Status/>------------------------------------------------------购物状态

</OrderBill>

<RequestTime/>---------------------------------------------------买方签名时间

</ServiceRequestInfo>

<ServiceRequestSig/>-------------------------------------------------买方对订单的签名

</ServiceRequest>

<ServiceRequestHash/>-----------------------------------------------------请求信息的Hash

</ServieeRequestMsg>

第2步：

卖方验证所述的服务请求有效后，向买方发送经过数字签名的服务响应，服务响应消息格式如下：

<ServiceProvideMsg>----------------------------------------------------------服务应答消息节点

<ServiceProvide>---------------------------------------------------------服务应答节点

<ServiceCommitent/>------------------------------------------------卖方服务承诺秘密随机数

<OnlinePaymentID/>---------------------------------------------------------在线支付ID

</ServiceProvide>

<ServiceProvideHash>/>-------------------------------------------------服务应答消息Hash

</ServiceProvideMsg>

第3步：

买方验证卖方的服务承诺有效后，向银行提出经过数字签名的取款请求，取款请求消息格式如下：

<WithdrawRequestMsg>---------------------------------------------------------------提款请求消息节点

<WithdrawRequest>----------------------------------------------------------------提款请求节点

<WithdrawRequestInfo>------------------------------------------------------提款请求信息节点

<CustomCert/>------------------------------------------------------------客户证书

<CustomID>--------------------------------------------------------客户ID

<BankID/>---------------------------------------------------------银行ID

<WithdrawBillInfo>------------------------------------------------取款信息节点

<WithdrawBillSerial/>----------------------------------------取款单序列号

<Account/>---------------------------------------------------取款帐户

<Sum/>-------------------------------------------------------取款总金额

<WithdrawTime/>----------------------------------------------取款时间

<WithdrawBillStatus/>----------------------------------------取款单状态

</WithdrawBillInfo>

<WithdrawRequestTime/>--------------------------------------------取款单签名时间

</WithdrawRequestInfo>

<WithdrawRequestInfoSig/>----------------------------------------------取款单签名

</WithdrawRequest>

<WithdrawRequestHash/>------------------------------------------------------取款消息的Hash

</WithdrawRequestMsg>

第4步：

银行验证买方的取款请求有效后，向买方发送经过数字签名的取款响应，取款响应消息的格式如下：

</TransferConfirmationInfo>

</TransferConfirmation>

</TransferConfirmationMsg>

第5步：

买方验证银行的取款响应有效后，向卖方发送经过数字签名的支付承诺，在线支付消息格式如下：

<OnlinePaymentMsg>---------------------------------------------------------线支付消息根节点

<OnlinePaymentMsgInfo>---------------------------------------------------在线支付消息节点

<OnlinePayment>-------------------------------------------------在线支付节点

<OnlinePaymentInfo>------------------------------------------在线支付信息节点

<CustomCert/>-----------------------------------------------客户证书

<CustomID/>-------------------------------------------------客户ID

<MerchantID/>-----------------------------------------------卖方ID

<PaymentMsg>------------------------------------------------支付消息节点

<PaymentInfo>-----------------------------------------------支付信息节点

<BankID/>-----------------------------------------------银行ID

<CustomID/>---------------------------------------------买方ID

<Sum/>--------------------------------------------------支付总金额

<PaymemSerial/>-----------------------------------------支付序列号

<PaymentTime/>------------------------------------------支付时间

</PaymentInfo>

<PaymentInfoSig/>-------------------------------------------支付信息签名

</PaymentMsg>

<OnlinePaymentTime/>----------------------------------------支付签名时间

<ServiceCommitentID/>---------------------------------------服务承诺ID

</OnlinePaymentInfo>

<ProbabilitySigInfo>--------------------------------------------承诺签名信息节点

<Random/>---------------------------------------------------客户秘密随机数

<PCVY/>-----------------------------------------------------客户承诺值

</ProbabilitySigInfo>

</OnlinePayment>

<OnlinePaymentSig/>-------------------------------------------------在线支付签名

</OnlinePaymentMsgInfo>

<OnlinePaymentHash/>----------------------------------------------------在线支付消息Hash

</OnlinePaymentMsg>

第6步：

卖方验证买方的支付承诺有效后，向银行发送经过数字签名的转帐请求，转帐请求消息格式如下：

</PaymentInfo>

</TransferRequestInfo>

</TransferRequest>

</TransferRequestMsg>

第7步：

银行验证卖方的转帐请求有效后，向卖方发送经过数字签名的转帐响应，转帐响应消息格式如下：

<WithdrawConfirmationMsg>------------------------------------------------取款应答消息节点

<WithdrawConfirmation>------------------------------------------------取款应答节点

<WithdrawConfirimationhnfo>--------------------------------------取款应答信息节点

<BankCert/>------------------------------------------------------银行证书

<BankID/>--------------------------------------------------------银行ID

<CustomID/>------------------------------------------------------买方ID

<WithdrawBillInfo>-----------------------------------------------取款单信息

<WithdrawBillSerial/>----------------------------------------取款单序列号

<Account/>---------------------------------------------------取款帐户

<Sum/>-------------------------------------------------------取款总金额

<WithdrawTime/>----------------------------------------------取款时间

<WithdrawBillStatus/>----------------------------------------取款单状态

</WithdrawBillInfo>

<WithdrawConfirmationTime/>----------------------------------取款应答签名时间

<WithdrawRequestID/>-----------------------------------------提款请求ID

</WithdrawConfirmationInfo>

<WithdrawConfirmationInfoSig/>-----------------------------------取款应答签名

</WithdrawConfirmation>

<WithdrawConfirmationHash/>------------------------------------------取款应答消息Hash

</WithdrawConfirmationMsg>

第8步：

卖方验证银行的转帐响应有效后，向买方发送经过数字签名的服务承诺消息，服务承诺消息格式如下：

<ServiceCommitentMsg>----------------------------------------------------------服务承诺消息节点

<ServiceCommitent>---------------------------------------------------------服务承诺节点

<ServiceCommitentInfo>-------------------------------------------------服务承诺信息节点

<MerchantCert/>------------------------------------------------------卖方证书

<OrderBillInfo>------------------------------------------------------订单信息

<SerialNumber/>------------------------------------------------订单序列号

<OrderItems>---------------------------------------------------订单项节点

<Item>-----------------------------------------------------订单小项节点

<ItemName/>--------------------------------------------商品名称

<Number/>----------------------------------------------商品数量

<Price/>-----------------------------------------------商品价格

</Item>

</OrderItems>

<Sum/>---------------------------------------------------------商品总金额

<PaymentMethod/>-----------------------------------------------支付方式

<OrderTime/>---------------------------------------------------下订单时间

<Status/>------------------------------------------------------购物状态

</OrderBillInfo>

<ServiceCommitentTime/>--------------------------------------------卖方签名时间

<ServiceRequestID>-------------------------------------------------服务请求ID

<MerchantID/>------------------------------------------------------卖方ID

<CustomID/>--------------------------------------------------------客户ID

<MerchantCommitent>----------------------------------------------卖方的服务承诺

</ServiceCommitentInfo>

<ServiceCommitentInfoSig/>-------------------------------------------卖方签名

</ServiceCommitent>

<ServiceCommitentHash/>--------------------------------------------------承诺消息的Hash

</ServiceCommitentMsg>

当其中任一步骤出现异常，以及上述的在线交易电子支付系统中参与交易的任一方抵赖时，则需要TTP执行仲裁程序，TTP执行仲裁概率签名的程序伪代码如下：

TTP_Mediation(m，Cert，ID，y，δ，r)

{

其中各个参数说明如下：m为待签名消息，Cert为签名者的证书，ID为签名者标识，y为签名者的签名承诺，δ为签名，r用来返回TTP恢复的随机数，

1)验证签名者的RSA签名：RSAVerify(Cert，m‖y，δ)，如果签名验证不通过，退出并返回false；

2)计算H(m‖y)和d^e mod n，并比较H(m‖y)和d^e mod n是否相等，退出并返回false；

3)计算λ＝H(ID‖PK)‖0x01；

4)计算(N)＝(p-1)(q-1)；

5)计算θ：θ＝g(λ，θ＝g(λ，(N))，满足λθ＝1 mod(N)

6)计算r：r＝y^q mod N

7)退出返回true

}

以上通过优选的实施例描述了本发明提供的在线交易的电子支付系统和方案，本领域的技术人员应该理解，在不超出本发明实质和范围的情况下，可以进行修改。

Claims

1、一种在线交易的电子支付系统，包括至少一买方、一卖方和一银行，其特征在于，还包括可信第三方和基于RSA的公平交换模块，所述的可信第三方不参与交易的过程，仅在交易的任一方抵赖的时候执行仲裁，所述的买方、卖方和银行可以通过公平交换模块利用基于标准RSA的密码算法实现承诺签名。

2、如权利要求1所述的在线交易的电子支付系统，其特征在于，所述的公平交换模块利用一个基于可信第三方公钥的单向陷门函数实现承诺签名。

3、如权利要求1所述的在线交易的电子支付系统，其特征在于，所述的可信第三方执行仲裁是通过利用一个公开的陷门函数恢复出参与交易的签名者用于生成承诺签名的秘密随机数实现的。

4、一种在线交易的电子支付方法，参与交易的至少包括一买方、一卖方和一银行，其特征在于，在任意两个互不信任的交易方之间进行的交易步骤可调用基于RSA的公平交换模块，一可信第三方在任一交易方抵赖时执行仲裁。

5、如权利要求4所述的在线交易的电子支付方法，其特征在于，所述的基于RSA的公平交换模块通过一个基于可信第三方公钥的单向陷门函数实现承诺签名，包括如下步骤：

交易方A向交易方B发送概率签名承诺；

交易方B验证交易方A的概率签名承诺有效后，向交易方A发送概率签名和用于生成概率签名承诺的秘密随机数；

交易方A验证交易方B的概率签名承诺有效后，向交易方B发送用于生成概率签名承诺的秘密随机数。

6、如权利要求4所述的一种在线交易的电子支付方法，其特征在于，所述的可信第三方通过利用陷门函数恢复交易方用于生成承诺签名的秘密随机数的方法来执行仲裁。

7、如权利要求6所述的在线交易的电子支付方法，其特征在于，所述的可信第三方恢复交易方用于生成承诺签名的秘密随机数的具体实现方法包括如下步骤：

提出仲裁请求的交易方向可信第三方提交仲裁信息；

可信第三方验证仲裁信息的合法性和有效性，如果验证失败，则仲裁终止；

可信第三方使用自己的陷门信息恢复出被提出仲裁请求的交易方的概率签名和用来生成概率签名的秘密随机数；

可信第三方将恢复出的概率签名和秘密随机数发送给提出仲裁请求的交易方。

8、如权利要求4所述的在线交易的电子支付方法，其特征在于，在交易过程的所有步骤中采用杂凑链技术。

9、如权利要求4所述的在线交易的电子支付方法，其特征在于，至少包括如下步骤：

服务请求步骤，买方向卖方提出经过数字签名的服务请求；

服务响应步骤，卖方验证所述的服务请求有效后，向买方发送经过数字签名的服务承诺；

取款请求步骤，买方验证卖方的服务承诺有效后，向银行提出经过数字签名的取款请求；

取款响应步骤，银行验证买方的取款请求有效后，向买方发送经过数字签名的取款响应；

在线支付步骤，买方验证银行的取款响应有效后，向卖方发送经过数字签名的支付承诺；

转帐请求步骤，卖方验证买方的支付承诺有效后，向银行发送经过数字签名的转帐请求；

转帐响应步骤，银行验证卖方的转帐请求有效后，向卖方发送经过数字签名的转帐响应；

服务承诺步骤，卖方验证银行的转帐响应有效后，向买方发送经过数字签名的服务承诺消息。

10、如权利要求9所述的在线交易的电子支付方案，其特征在于，在所述的服务响应和在线支付步骤中，所述的数字签名通过基于RSA的承诺签名技术实现。