CN108449332A - 一种基于双网关的轻量级移动支付协议设计方法 - Google Patents

一种基于双网关的轻量级移动支付协议设计方法 Download PDF

Info

Publication number
CN108449332A
CN108449332A CN201810196540.XA CN201810196540A CN108449332A CN 108449332 A CN108449332 A CN 108449332A CN 201810196540 A CN201810196540 A CN 201810196540A CN 108449332 A CN108449332 A CN 108449332A
Authority
CN
China
Prior art keywords
user
tid
message
businessman
payment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201810196540.XA
Other languages
English (en)
Inventor
甘加升
龙冬阳
于跃
熊绘
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Yat Sen University
National Sun Yat Sen University
Original Assignee
National Sun Yat Sen University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National Sun Yat Sen University filed Critical National Sun Yat Sen University
Priority to CN201810196540.XA priority Critical patent/CN108449332A/zh
Publication of CN108449332A publication Critical patent/CN108449332A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明提供一种基于双网关的轻量级移动支付协议设计方法，该方法设计的基于双网关的安全支付协议，由用户发起支付请求，协议过程使用对称密钥体制。本文提出的安全协议满足支付协议的基本安全性要求，包括保密性、完整性、不可伪造性和不可否认性，同时，为了保证用户及商家的隐私，协议为用户和商家使用动态ID的方式，每次交易过程中使用随机的伪ID，实现用户对商家的匿名和商家对用户发卡银行的匿名。对称密钥体制减少加解密过程对移动终端的资源消耗，十分轻量级，适用于移动支付系统。总之，本发明提出的安全协议，提供了移动支付系统所需要的所有安全属性，同时有着较好的执行效率。

Description

一种基于双网关的轻量级移动支付协议设计方法
技术领域
本发明涉及互联网络安全和电子商务领域，更具体地，涉及一种基于双网关的轻量级移动支付协议设计方法。
背景技术
随着移动互联网的快速发展，移动智能终端设备得到大面积普及，电子商务用户数量急剧增大，但移动设备本身不可避免有着有限内存和低计算力等限制，为维持电子商务的稳步发展，急需轻量级移动支付协议应用于此。
近些年来，许多国内外学者对移动支付协议这一课题都提出了自己的想法，Farahnaz Zamanian等人(F.Zamanian and H.Mala,"A new anonymous unlinkablemobile payment protocol,"2016 6th International Conference on Computer andKnowledge Engineering(ICCKE),Mashhad,2016,pp.117-122)提出使用对称密钥体制，在保证移动支付协议基本安全特性的同时保证用户的匿名性和不可链接性。VenkatasamySureshkumar等人(Venkatasamy Sureshkumar,R.Anitha,N.Rajamanickam,Ruhul Amin.Alightweight two-gateway based payment protocol ensuring accountability andunlinkable anonymity with dynamic identity.Computers&Electrical Engineering,Volume 57,January 2017,Pages 223–240)提出使用双网关解决用户双卡支付的问题，该协议将交易分为两个子交易，由用户明确指定每个子交易需要支付的金额。
目前，针对单个网关完成单卡支付的协议已经十分成熟，但针对双卡支付的实际问题，国内外对该课题的研究很少，国内所有支付应用中都还没实现双卡支付的选项，因此为了移动支付更加普及，需要满足用户双卡支付的需求。
发明内容
本发明提供一种基于双网关的轻量级移动支付协议设计方法，该方法设计的协议在保证协议安全可靠的同时，减少安全操作的次数，保证协议执行的效率。
为了达到上述技术效果，本发明的技术方案如下：
一种基于双网关的轻量级移动支付协议设计方法，包括以下步骤：
S1：设计协议模型；
S2：对协议进行初始假设；
S3：设计协议过程。
进一步地，所述步骤S1的具体过程是：
针对双卡支付的场景，用户在一张卡余额不足的情况下选择双卡支付，在此场景下，使用双网关完成支付；第一个支付网关连接用户的第一个账号对应的发卡银行Issuer1和商家的发卡银行Acquirer，第二个支付网关连接用户的第二个账号对应的发卡银行Issuer2和商家的发卡银行Acquirer，商家通过支付网关请求付款和收款；保证在不安全网络下移动支付的安全，只考虑不安全网络下的协议过程，作为银行安全网络和不安全公网连接桥梁的支付网关，在此协议中视为银行系统的代理，代理完成账号的分发和验证工作，其实质的账号分发和验证仍然是由银行系统完成。
进一步地，所述步骤S2的具体过程是：
a)用户拥有两张以上的银行卡或者支付账号，并且每个账号对应的余额不足以完成支付，但两个账号的总额足够完成支付；
b)用户浏览商品，在了解具体商品价格后决定使用两个账号同时支付金额的方式完成付款；
c)协议的参与方完成了初始对称密钥的分发，包括用户与商家之间、用户与两个支付网关之间、商家和两个支付网关之间；
d)银行内部网络是安全可靠的，支付交易过程在银行内部网络中不会遭到第三方的攻击；
e)用户移动设备是安全可靠的，没有遭到木马病毒的挟持，用户发送的请求均是遵循自己的意愿。
进一步地，所述步骤S3的具体过程是：
阶段1-注册阶段：用户和商家在各自发卡银行进行注册并获得动态ID：
在交易之前，用户和商家都需要向自己的发卡银行进行注册；用户和对应的发卡银行之间产生会话密钥K1，双方的会话密钥可以通过Diffie-Hellman密钥协商协议生成；Diffie-Hellman密钥协商协议对设备的硬件要求和计算资源的要求不高，适合移动设备；
接下来，用户使用会话密钥K1加密注册信息，详细的注册信息可以包括账号信息、用户ID和电话号码：
Customer->Issuer:{AccountInfo,ID,number}K1
在注册过程中，用户需要设置密码识别号码PN和个人识别密码PIN才能访问用户的移动钱包应用程序，这个实现将使用两个因素认证，这是移动设备访问控制的一个重要原则；这两个因素认证意味着分两步验证用户访问移动钱包系统的权限；第一步是移动设备进入移动钱包应用程序，第二步是输入密码，该密码只有用户自己知道；然后用户的初始ID将通过哈希用户的PN和PIN来计算得到：
RIDC＝PNC+H(PNC+PINC)
然后用户的发卡银行系统将使用会话密钥K1解密注册信息，并将必要的信息存储在数据库中；如果注册过程成功，用户的发卡银行系统将发送确认信息通知用户，确认信息使用会话密钥K1进行加密传输；
Issuer->Customer:{success/failure}K1
商家同样需要按照以上步骤在Acquirer中完成注册并获得初始ID；
阶段2-初始化阶段：用户向商家提交订单详情并请求TID：
Step1:C->M
m1＝{OD,TIDreq,amount}
Step2:M->C
m2＝{TID}KMC
正式的交易从初始化阶段开始，初始化阶段的主要目的是用户向商家请求交易标识符TID，TID只能由商家生成，用户浏览所需要购买的商品或服务，并生成订单，用户向商家发送请求，该请求包括订单描述OD、商品的总额和请求交易标识符TIDreq，商家在收到用户的请求后，确认订单总额，生成交易标识符TID，并通过用户与商家之间的会话密钥KMC对TID进行加密，将密文返回给用户，用户使用密钥KMC解密密文，获得交易标识符TID；
阶段3-支付阶段：向付款方和收款方发出扣款和收款请求并得到回复：
Step3:C->M
m3＝{TID,amount,G1,G2,T1,debit_request1,debit_request2}KMC
其中debit_request1＝{TID,G1,RIDC1,amount,T1,H(TID,amount,KMC)}KCG1debit_request2＝{TID,G2,RIDC2,amount,T1,H(TID,amount,KMC)}KCG2
Step4:M->G1
m4＝{TID,G1,amount,RIDM,debit_request1}KMG1
Step5:G1->M
m5＝{TID,amt1,amt2,acp1,T2,H(TID,amount,KMC),H(TID,amt1,T2，KCG1)}KMG1
Step6:M->G2
m6＝{TID,G2,amount,amt2,RIDM,debit_request2}KMG2
Step7:G2->M
m7＝{TID,amt2,acp2,T3,H(TID,amount,KMC),H(TID,amt2,T3，KCG2)}KMG2
Step8:M->C
m8＝{TID,amt1,amt2,acp,T3,H(TID,amount,KMC),H(TID,amt1,T2,KCG1),H(TID,amt2,T3,KCG2)}KMC
支付阶段是该安全协议的核心部分，用户发送付款请求，分别通过支付网关1和支付网关2进行双卡支付，用户的主账号扣完全部余额后剩下的金额有第二个账号扣除；
此阶段由用户C发起，用户构造扣款请求debit_request1和debit_request2，扣款请求debit_request1是请求支付网关Gateway1完成对主账号的扣款，debit_request1使用用户C与支付网关Gateway1之间的会话密钥KCG1进行加密，该请求只能被用户和支付网关Gateway1获知，debit_request1包括的信息有交易标识符TID、支付网关G1、用户主账号随机RIDC1、交易总额amount、时间戳T1和用户和商家的交易消息验证码H(TID,amount,KMC)，同样的，用户构造debit_request2请求支付网关Gateway2对第二张卡进行扣款，具体的消息内容与debit_request1相似，携带支付网关G2和用户第二个账号随机RIDC2，并使用用户与支付网关Gateway2之间的会话密钥KCG2进行加密，保证只有用户和支付网关Gateway2可以获知，用户发送给商家的消息m3包括debit_request1和debit_request2，m3中还包含G1和G2，以通知商家用户使用双卡支付的方式完成付款操作，m3使用用户与商家之间的对称会话密钥KMC进行加密；
商家在收到消息m3之后，使用KMC解密消息，获得扣款请求debit_request1和debit_request2，商家核对用户发送过来的商品总额，确认无误后构造消息m4并发送给支付网关G1，消息m4包括的信息有交易标识符TID、G1、商品总额amount和商家的随机RIDM，并附加从用户接收到的debit_request1，使用商家和支付网关G1之间的对称会话密钥KMG1加密消息；
支付网关G1收到消息m4后，使用KMG1解密消息，获得商家随机RIDM和用户的扣款请求debit_request1，使用密钥KCG1解密debit_request1，获得用户主账号随机RIDC1，比较m4中的商品总额amount和debit_request1中的商品总额amount，确保两者相同，若不同则交易取消，返回商家acp1＝false；在两者相同的情况下，支付网关G1连接银行内部网络系统，请求Issuer1验证RIDC1，并获得RIDC1对应的实际账户的余额amt1，返回给支付网关G1，同时请求Acquirer验证RIDM，在验证操作均正确的情况下设置acp1＝true，否则acp1＝false；另外，支付网关G1使用时间戳T2，计算△t＝T2-T1，如果△t超过限定的时限，则置acp1＝false，交易取消，支付网关G1构造回复消息，并使用密钥KMG1加密消息生成消息m5，将m5返回给商家，消息包括TID、主账号需要支付的金额amt1、第二个账号需要支付的金额amt2＝amount–amt1、验证结果acp1、时间戳T2、支付网关G1返回给用户的扣款回复消息认证码H(TID,amt1,T2,KCG1)，并携带H(TID,amount,KMC)；
商家收到支付网关G1的回复消息m5后，使用KMG1解密m5，获得用户第二个账号需要支付的金额amt2，商家构造消息，并用与支付网关G2共享的会话密钥KMG2加密消息生成m6，将m6发送给支付网关G2，消息m6包括交易标识符TID、G2、商品总额amount、第二个账号需要支付的金额amt2、商家随机RIDM以及扣款请求debit_request2；
支付网关G2获得加密消息m6后使用KMG2解密消息，获得扣款请求debit_request2并解密，基本操作与支付网关G1收到商家的消息后的操作相似，支付网关G2构造回复消息，并使用KMG2加密消息生成消息m7，回复消息包括的内容有TID、第二个账号需支付的金额amt2、验证结果acp2、时间戳T3、支付网关G2返回给用户的扣款回复H(TID,amt2,T3,KCG2)，并携带H(TID,amount,KMC)；
商家在收到消息m7后，解密消息，综合从支付网关G1收到的消息m5，计算综合验证结果acp＝acp1&acp2，构造将要返回给用户的消息，并用KMC加密回复消息生成密文m8，消息内容包括TID、主账号需要支付的金额amt1、第二个账号需要支付的金额amt2、综合验证结果acp、时间戳T3、从支付网关G1获得的扣款回复H(TID,amt1,T2,KCG1)、从支付网关G2获得的扣款回复的消息验证码H(TID,amt2,T3,KCG2)，并携带H(TID,amount,KMC)；
用户收到消息m8后使用KMC解密，获得明文消息，根据综合验证结果acp判断是否需要继续执行交易，若acp＝true，则继续后续的提交阶段，否则终止交易；
阶段4-提交阶段：向付款方和收款方提交扣款和收款确认：
Step9:C->M
m9＝{TID,T4,continue,H(TID,amt1,amt2,T4)}KMC
Step10:M->G1
m10＝{TID,commit,T5,H(TID,amt1,T2,KCG1),H(debit_request1,TID,T5,KMG1)}
Step11:G1->M
m11＝{TID,committed,H(TID,amt1,T2,KCG1),H(debit_request1,TID,KMG1)}
Step12:M->G2
m12＝{TID,commit,T5,H(TID,amt2,T3,KCG2),H(debit_request2,TID,T5,KMG2)}
Step13:G2->M
m13＝{TID,committed,H(TID,amt2,T3,KCG2),H(debit_request2,TID,KMG2)}
Step14:M->C
m14＝{transaction_success,payment_receipt}
支付阶段完成后，用户判断综合验证标识acp是否为true，若acp＝false，则终止交易，进入阶段五动态ID更新阶段，否则，继续提交阶段完成交易；
在支付阶段确认无误后用户提交扣款请求，请求支付网关完成转账操作，提交阶段仍然由用户发起，用户构造加密消息m9，使用与商家之间的共享密钥KMC加密消息，将加密消息发送给商家；消息内容包括交易标识符TID、时间戳T4、请求继续提价的标识符continue，以及对TID、amount和时间戳T4的消息摘要，确保消息的完整性；
商家在接收到用户继续提交的消息m9后，解密消息m9获知交易的continue标识符，得知用户继续提交付款；商家构造消息m10，并将消息m10发送给支付网关G1；消息内容包括交易标识符TID、提交标识符commit、时间戳T5、支付阶段支付网关G1返回的扣款回复H(TID,amt1,T2,KCG1)以及商家发送给支付网关的消息验证码H(debit_request1,TID,T5,KMG1)，该消息验证码包含了用户对支付网关的扣款请求debit_request1，debit_request1是商家在支付阶段缓存下来的，但商家并不能解析该扣款请求，在这一步中附加debit_request1会对支付网关的验证有帮助；
支付网关G1收到商家发送过来的消息m10，获取消息中的提交标识符commit，验证扣款请求debit_request1和扣款回复H(TID,amt1,T2,KCG1)，验证无误后连接银行内部网络系统，请求发行方Issuer1和收款方Acquirer之间完成金额为amt1的转账，转账操作完成后支付网关G1回复商家消息m11，消息内容包括交易标识符TID、已完成提交标识符committed以及与商家之间的消息验证码H(debit_request1,TID,KMG1)；
商家收到消息m11，获取消息内容中的已提交标识符committed，得知支付网关G1完成转账操作，商家发送消息m12至支付网关G2，操作和消息内容类似于对支付网关G1的操作；
支付网关G2收到商家发送的提交请求，连接银行内部网络系统，完成发行方Issuer2与收款方Acquirer之间金额为amt2的转账操作，并回复商家已提交committed；
商家收到支付网关G1的committed和支付网关G2的committed，得知通过两个支付网关的转账操作都已经完成，商家回复用户交易成功标识符transaction_success和支付已接收标识符payment_receipt；同时，商家进入动态ID更新阶段；
用户收到商家返回的成功消息，接下来继续动态ID更新阶段；
阶段5-动态ID更新阶段：更新用户和商家的随机ID：
Step15:
C->G1:m15＝{updateID,success/failure}
C->G2:m16＝{updateID,success/failure}
M->G1:m17＝{updateID,success/failure}
Step16:G1->C,G2->C,G1->M
m18＝{result}
用户和商家的动态ID更新方式可以为：
RIDC1(new)＝H(RIDC1(old),(T2-T1))
RIDC2(new)＝H(RIDC2(old),(T3-T1))
RIDM(new)＝H(RIDM(old),(T2-T1))
不管交易是否完成，动态ID更新阶段都要执行，用户或商家的ID更新都发生在于支付网关之间，支付网关将更新ID的请求转发到对应的发卡银行系统，由对应的发卡银行系统完成ID的更新并存储在数据库中；动态ID的更新仍然由用户发起，用2户根据协议的计算方法计算新的ID，并发送更新ID的消息至支付网关，支付网关将请求交给对应发卡银行系统，银行系统也根据协商的计算方式计算新的ID并更新数据库，之后的交易都使用最新的随机ID。
与现有技术相比，本发明技术方案的有益效果是：
本发明设计的基于双网关的安全支付协议，由用户发起支付请求，协议过程使用对称密钥体制。本文提出的安全协议满足支付协议的基本安全性要求，包括保密性、完整性、不可伪造性和不可否认性，同时，为了保证用户及商家的隐私，协议为用户和商家使用动态ID的方式，每次交易过程中使用随机的伪ID，实现用户对商家的匿名和商家对用户发卡银行的匿名。对称密钥体制减少加解密过程对移动终端的资源消耗，十分轻量级，适用于移动支付系统。总之，本发明提出的安全协议，提供了移动支付系统所需要的所有安全属性，同时有着较好的执行效率。
附图说明
图1移动支付协议中双网关支付模型；
图2本发明协议模型的基本流程图；
图3本发明协议模型的数据流向图。
具体实施方式
附图仅用于示例性说明，不能理解为对本专利的限制；
为了更好说明本实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；
对于本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。
下面结合附图和实施例对本发明的技术方案做进一步的说明。
实施例1
一种基于双网关的轻量级移动支付协议设计方法，本发明的详细设计如下：
(1)协议模型
移动支付系统中，用户向商家提交订单请求，商家向用户的开户银行和商家本身的开户银行请求扣款和收款，商家需要通过一个接口才能连接到银行的内部系统，这个接口就称为支付网关。支付网关作为银行内部的安全网络和不安全的互联网之间的连接桥梁。所以对于常见的支付协议，一般会有五个参与者：付款方(Issuer)、收款方(Acquirer)、支付网关(Gateway)、用户(Customer)、商家(Merchant)。付款方是用户的发卡银行，其功能是为用户提供账号和验证账号的正确性。收款方是商家的发卡银行，其功能是为商家提供账号和验证账号正确性。这类支付协议是针对单一账号的场景，使用单一账号支付只需要一个支付网关即可完成支付。
本发明的安全协议是针对双卡支付的场景，用户在一张卡余额不足的情况下选择双卡支付，在此场景下，使用双网关完成支付。双网关支付模型如图1所示。第一个支付网关连接用户的第一个账号对应的发卡银行Issuer1和商家的发卡银行Acquirer，第二个支付网关连接用户的第二个账号对应的发卡银行Issuer2和商家的发卡银行Acquirer，商家通过支付网关请求付款和收款。本发明提出的安全协议目的是保证在不安全网络下移动支付的安全，所以只考虑不安全网络下的协议过程，作为银行安全网络和不安全公网连接桥梁的支付网关，在此协议中视为银行系统的代理，代理完成账号的分发和验证工作，其实质的账号分发和验证仍然是由银行系统完成。
(2)初始假设
在正式介绍安全支付协议之前，为满足实际的支付场景，我们对协议的执行作出如下初始假设：
a)用户拥有两张以上的银行卡或者支付账号，并且每个账号对应的余额不足以完成支付，但两个账号的总额足够完成支付
b)用户浏览商品，在了解具体商品价格后决定使用两个账号同时支付金额的方式完成付款
c)协议的参与方完成了初始对称密钥的分发，包括用户与商家之间、用户与两个支付网关之间、商家和两个支付网关之间
d)银行内部网络是安全可靠的，支付交易过程在银行内部网络中不会遭到第三方的攻击
e)用户移动设备是安全可靠的，没有遭到木马病毒的挟持，用户发送的请求均是遵循自己的意愿
(3)符号说明
本文提出的协议所使用的相关符号描述如表1所示。
表1协议符号描述
(4)协议过程
本文提出的安全协议主要分为注册阶段和交易阶段，用户在交易之前需要向发卡银行进行注册，注册阶段只执行一次。交易阶段主要分为初始化阶段、支付阶段、提交阶段和动态ID更新阶段。
交易阶段协议的执行过程如图2所示。
交易阶段消息传递如图3所示，图中消息的传递没有包括注册阶段和动态ID更新阶段。
协议模型详细说明及安全性分析如下：
阶段1-注册阶段：用户和商家在各自发卡银行进行注册并获得动态ID
在交易之前，用户和商家都需要向自己的发卡银行进行注册。用户和对应的发卡银行之间产生会话密钥K1，双方的会话密钥可以通过Diffie-Hellman密钥协商协议生成。Diffie-Hellman密钥协商协议对设备的硬件要求和计算资源的要求不高，适合移动设备。
接下来，用户使用会话密钥K1加密注册信息，详细的注册信息可以包括账号信息、用户ID和电话号码等。
Customer->Issuer:{AccountInfo,ID,number}K1
在注册过程中，用户需要设置密码识别号码PN和个人识别密码PIN才能访问用户的移动钱包应用程序，这个实现将使用两个因素认证，这是移动设备访问控制的一个重要原则。这两个因素认证意味着分两步验证用户访问移动钱包系统的权限。第一步是移动设备进入移动钱包应用程序，第二步是输入密码，该密码只有用户自己知道。然后用户的初始ID将通过哈希用户的PN和PIN来计算得到。
RIDC＝PNC+H(PNC+PINC)
然后用户的发卡银行系统将使用会话密钥K1解密注册信息，并将必要的信息存储在数据库中。如果注册过程成功，用户的发卡银行系统将发送确认信息通知用户，确认信息使用会话密钥K1进行加密传输。
Issuer->Customer:{success/failure}K1
商家同样需要按照以上步骤在Acquirer中完成注册并获得初始ID。
[安全性分析]：
注册阶段用户从发卡银行系统中获取初始的随机ID，用户在注册之前与发卡银行系统采用Diffie-Hellman算法协议会话密钥，Diffie-Hellman算法本身的安全性保证了用户与发卡银行系统之间会话密钥的机密性，从而保证注册信息的机密性。
阶段2-初始化阶段：用户向商家提交订单详情并请求TID
Step1:C->M
m1＝{OD,TIDreq,amount}
Step2:M->C
m2＝{TID}KMC
正式的交易从初始化阶段开始。初始化阶段的主要目的是用户向商家请求交易标识符TID(TID只能由商家生成)。初始化阶段分为步骤1和步骤2，用户浏览所需要购买的商品或服务，并生成订单。用户向商家发送请求，该请求包括订单描述OD、商品的总额和请求交易标识符TIDreq。商家在收到用户的请求后，确认订单总额，生成交易标识符TID，并通过用户与商家之间的会话密钥KMC对TID进行加密，将密文返回给用户。用户使用密钥KMC解密密文，获得交易标识符TID。
[安全性分析]：
消息m1是用户发送的请求，没有包含隐私信息，不必对消息进行加密，消息m2是商家返回的交易标识符TID，使用用户和商家的会话密钥KMC进行加密，前已假设参与方之间的会话密钥是安全可靠的，商家生成的TID使用KMC加密，因此只有用户和商家能够解密，攻击者无法获知TID，保证用户购物的隐私性。另外，前已假设，用户移动设备是安全的，用户发送的请求均来自用户的真实需求，不存在伪造用户身份的问题。使用对称会话密钥加密信息，如果发生商家伪造的攻击方式，伪造的商家无法知道KMC，只用使用KMC加密的信息用户才接收，所以也能够检测出伪造商家的攻击。
阶段3-支付阶段：向付款方和收款方发出扣款和收款请求并得到回复
Step3:C->M
m3＝{TID,amount,G1,G2,T1,debit_request1,debit_request2}KMC
其中
debit_request1＝{TID,G1,RIDC1,amount,T1,H(TID,amount,KMC)}KCG1
debit_request2＝{TID,G2,RIDC2,amount,T1,H(TID,amount,KMC)}KCG2
Step4:M->G1
m4＝{TID,G1,amount,RIDM,debit_request1}KMG1
Step5:G1->M
m5＝{TID,amt1,amt2,acp1,T2,H(TID,amount,KMC),H(TID,amt1,T2，KCG1)}KMG1
Step6:M->G2
m6＝{TID,G2,amount,amt2,RIDM,debit_request2}KMG2
Step7:G2->M
m7＝{TID,amt2,acp2,T3,H(TID,amount,KMC),H(TID,amt2,T3，KCG2)}KMG2
Step8:M->C
m8＝{TID,amt1,amt2,acp,T3,H(TID,amount,KMC),H(TID,amt1,T2,KCG1),H(TID,amt2,T3,KCG2)}KMC
支付阶段是该安全协议的核心部分。支付阶段包括步骤3至步骤8，用户发送付款请求，分别通过支付网关1和支付网关2进行双卡支付，用户的主账号扣完全部余额后剩下的金额有第二个账号扣除。
此阶段由用户C发起，用户构造扣款请求debit_request1和debit_request2，扣款请求debit_request1是请求支付网关Gateway1完成对主账号的扣款，debit_request1使用用户C与支付网关Gateway1之间的会话密钥KCG1进行加密，该请求只能被用户和支付网关Gateway1获知，debit_request1包括的信息有交易标识符TID、支付网关G1、用户主账号随机RIDC1、交易总额amount、时间戳T1和用户和商家的交易消息验证码H(TID,amount,KMC)。同样的，用户构造debit_request2请求支付网关Gateway2对第二张卡进行扣款，具体的消息内容与debit_request1相似，携带支付网关G2和用户第二个账号随机RIDC2，并使用用户与支付网关Gateway2之间的会话密钥KCG2进行加密，保证只有用户和支付网关Gateway2可以获知。用户发送给商家的消息m3包括debit_request1和debit_request2，m3中还包含G1和G2，以通知商家用户使用双卡支付的方式完成付款操作，m3使用用户与商家之间的对称会话密钥KMC进行加密。
商家在收到消息m3之后，使用KMC解密消息，获得扣款请求debit_request1和debit_request2，商家核对用户发送过来的商品总额，确认无误后构造消息m4并发送给支付网关G1，消息m4包括的信息有交易标识符TID、G1、商品总额amount和商家的随机RIDM，并附加从用户接收到的debit_request1，使用商家和支付网关G1之间的对称会话密钥KMG1加密消息。
支付网关G1收到消息m4后，使用KMG1解密消息，获得商家随机RIDM和用户的扣款请求debit_request1，使用密钥KCG1解密debit_request1，获得用户主账号随机RIDC1，比较m4中的商品总额amount和debit_request1中的商品总额amount，确保两者相同，若不同则交易取消，返回商家acp1＝false；在两者相同的情况下，支付网关G1连接银行内部网络系统，请求Issuer1验证RIDC1，并获得RIDC1对应的实际账户的余额amt1，返回给支付网关G1，同时请求Acquirer验证RIDM，在验证操作均正确的情况下设置acp1＝true，否则acp1＝false。另外，支付网关G1使用时间戳T2，计算△t＝T2-T1，如果△t超过限定的时限，则置acp1＝false，交易取消。支付网关G1构造回复消息，并使用密钥KMG1加密消息生成消息m5，将m5返回给商家，消息包括TID、主账号需要支付的金额amt1、第二个账号需要支付的金额amt2＝amount–amt1、验证结果acp1、时间戳T2、支付网关G1返回给用户的扣款回复消息认证码H(TID,amt1,T2,KCG1)，并携带H(TID,amount,KMC)。
商家收到支付网关G1的回复消息m5后，使用KMG1解密m5，获得用户第二个账号需要支付的金额amt2，商家构造消息，并用与支付网关G2共享的会话密钥KMG2加密消息生成m6，将m6发送给支付网关G2。消息m6包括交易标识符TID、G2、商品总额amount、第二个账号需要支付的金额amt2、商家随机RIDM以及扣款请求debit_request2。
支付网关G2获得加密消息m6后使用KMG2解密消息，获得扣款请求debit_request2并解密，基本操作与支付网关G1收到商家的消息后的操作相似，支付网关G2构造回复消息，并使用KMG2加密消息生成消息m7，回复消息包括的内容有TID、第二个账号需支付的金额amt2、验证结果acp2、时间戳T3、支付网关G2返回给用户的扣款回复H(TID,amt2,T3,KCG2)，并携带H(TID,amount,KMC)。
商家在收到消息m7后，解密消息，综合从支付网关G1收到的消息m5，计算综合验证结果acp＝acp1&acp2，构造将要返回给用户的消息，并用KMC加密回复消息生成密文m8，消息内容包括TID、主账号需要支付的金额amt1、第二个账号需要支付的金额amt2、综合验证结果acp、时间戳T3、从支付网关G1获得的扣款回复H(TID,amt1,T2,KCG1)、从支付网关G2获得的扣款回复的消息验证码H(TID,amt2,T3,KCG2)，并携带H(TID,amount,KMC)。
用户收到消息m8后使用KMC解密，获得明文消息，根据综合验证结果acp判断是否需要继续执行交易，若acp＝true，则继续后续的提交阶段，否则终止交易。
[安全性分析]：
支付阶段的参与者有客户C、商家M、支付网关G1、支付网关G2，各参与方之间都是通过对称的会话密钥进行数据加密传输，前已假设参与者之间的会话密钥是安全可靠的，所以数据传输是安全的，保证了协议的机密性。
同时协议也考虑了恶意商家的问题，在协议过程中，用户发出的请求都是通过商家传递到支付网关，恶意商家可能会在协议的过程中修改支付金额，意图使用户的发卡银行系统扣除更多的金额。本文设计的协议为防止恶意商家的攻击，在消息传递的过程中，使用消息摘要技术，对发送的关键信息进行消息摘要，在支付网关中对商家传递的金额以及其他信息做哈希操作，计算的哈希值与从用户发送过来的哈希值对比，保证关键金额信息未被篡改，保证了协议的完整性。
同样是恶意商家的安全问题，商家在完成支付交易后，缓存用户的支付请求，意图向支付网关再次提交已失效的支付扣款请求，使支付网关完成扣款和收款的操作，这类攻击称为重放攻击。安全协议使用时间戳技术，用户发送的扣款请求debit_request携带时间戳T1，支付网关G在收到扣款请求后记录时间戳T2，计算之间的差值并与限定的时限进行比较，超过时限则取消交易。若最初的交易完成后商家缓存扣款请求，其扣款请求仍然包含原来的时间戳T1，继续提交到支付网关G中必定会超过时限而取消交易，所以协议中使用时间戳技术能够有效避免重放攻击。
在步骤3中借鉴密码学中的双向签名技术，用户信息需要对商家隐藏的就使用用户与支付网关之间的共享会话密钥加密，给商家传递的消息使用与商家之间的会话密钥进行加密，有效保证了用户的隐私。其实，即使商家获得了用户的随机RIDC，也无法准确获得用户的实际账户信息。另外，商家同样使用随机RIDM，用户的发卡银行系统也无法准确知悉商家的具体账户信息，有效保证了商家的隐私。支付阶段在理论上是安全可靠的。
阶段4-提交阶段：向付款方和收款方提交扣款和收款确认
Step9:C->M
m9＝{TID,T4,continue,H(TID,amt1,amt2,T4)}KMC
Step10:M->G1
m10＝{TID,commit,T5,H(TID,amt1,T2,KCG1),H(debit_request1,TID,T5,KMG1)}
Step11:G1->M
m11＝{TID,committed,H(TID,amt1,T2,KCG1),H(debit_request1,TID,KMG1)}
Step12:M->G2
m12＝{TID,commit,T5,H(TID,amt2,T3,KCG2),H(debit_request2,TID,T5,KMG2)}
Step13:G2->M
m13＝{TID,committed,H(TID,amt2,T3,KCG2),H(debit_request2,TID,KMG2)}
Step14:M->C
m14＝{transaction_success,payment_receipt}
支付阶段完成后，用户判断综合验证标识acp是否为true，若acp＝false，则终止交易，进入阶段五动态ID更新阶段。否则，继续提交阶段完成交易。
提交阶段由步骤9至步骤14组成，在支付阶段确认无误后用户提交扣款请求，请求支付网关完成转账操作。提交阶段仍然由用户发起，用户构造加密消息m9，使用与商家之间的共享密钥KMC加密消息，将加密消息发送给商家。消息内容包括交易标识符TID、时间戳T4、请求继续提价的标识符continue，以及对TID、amount和时间戳T4的消息摘要，确保消息的完整性。
商家在接收到用户继续提交的消息m9后，解密消息m9获知交易的continue标识符，得知用户继续提交付款。商家构造消息m10，并将消息m10发送给支付网关G1。消息内容包括交易标识符TID、提交标识符commit、时间戳T5、支付阶段支付网关G1返回的扣款回复H(TID,amt1,T2,KCG1)以及商家发送给支付网关的消息验证码H(debit_request1,TID,T5,KMG1)，该消息验证码包含了用户对支付网关的扣款请求debit_request1，debit_request1是商家在支付阶段缓存下来的，但商家并不能解析该扣款请求，在这一步中附加debit_request1会对支付网关的验证有帮助。
支付网关G1收到商家发送过来的消息m10，获取消息中的提交标识符commit，验证扣款请求debit_request1和扣款回复H(TID,amt1,T2,KCG1)，验证无误后连接银行内部网络系统，请求发行方Issuer1和收款方Acquirer之间完成金额为amt1的转账。转账操作完成后支付网关G1回复商家消息m11，消息内容包括交易标识符TID、已完成提交标识符committed以及与商家之间的消息验证码H(debit_request1,TID,KMG1)。
商家收到消息m11，获取消息内容中的已提交标识符committed，得知支付网关G1完成转账操作，商家发送消息m12至支付网关G2，操作和消息内容类似于对支付网关G1的操作。
支付网关G2收到商家发送的提交请求，连接银行内部网络系统，完成发行方Issuer2与收款方Acquirer之间金额为amt2的转账操作，并回复商家已提交committed。
商家收到支付网关G1的committed和支付网关G2的committed，得知通过两个支付网关的转账操作都已经完成，商家回复用户交易成功标识符transaction_success和支付已接收标识符payment_receipt。同时，商家进入动态ID更新阶段。
用户收到商家返回的成功消息，接下来继续动态ID更新阶段。
[安全性分析]：
支付网关G1和支付网关G2在支付阶段构造转账事务但未提交，提交阶段用户通知支付网关完成转账事务的提交。总体来说，提交阶段存在的安全隐患并不是很大，主要安全问题在支付阶段都已经得到了预防。支付网关只需要判断发送过来的提交请求中的交易标识符TID与之前支付阶段的TID相同并且扣款请求debit_request1和debit_request2是有效的，就可以完成转账操作。
交易标识符TID可以通过消息摘要技术得到验证，而扣款请求debit_request1和debit_request2由用户和支付网关之间的共享密钥加密，消息只能由用户和支付网关解密获取，并且通过对比消息中的时间戳就能够判断消息的有效性。
提交阶段理论上是安全可靠的。
阶段5-动态ID更新阶段：更新用户和商家的随机ID
Step15:
C->G1:m15＝{updateID,success/failure}
C->G2:m16＝{updateID,success/failure}
M->G1:m17＝{updateID,success/failure}
Step16:G1->C,G2->C,G1->M
m18＝{result}
用户和商家的动态ID更新方式可以为：
RIDC1(new)＝H(RIDC1(old),(T2-T1))
RIDC2(new)＝H(RIDC2(old),(T3-T1))
RIDM(new)＝H(RIDM(old),(T2-T1))
不管交易是否完成，动态ID更新阶段都要执行。用户(或商家)的ID更新都发生在于支付网关之间，支付网关将更新ID的请求转发到对应的发卡银行系统，由对应的发卡银行系统完成ID的更新并存储在数据库中。动态ID的更新仍然由用户发起，用2户根据协议的计算方法计算新的ID，并发送更新ID的消息至支付网关，支付网关将请求交给对应发卡银行系统，银行系统也根据协商的计算方式计算新的ID并更新数据库。之后的交易都使用最新的随机ID。
[安全性分析]：
用户和对应发卡银行事先协商好新ID的计算方法，新ID的生成在双方内部完成，不附加在消息中，所以不必要加密请求消息。计算内容中包括双方都已知的时间戳，时间戳不断变化性以及复杂性也同时也使攻击者无法轻易计算出新ID。在每次交易后更新随机ID，不但能够解决伪造攻击的问题，还能保证匿名性，保护用户的隐私。
相同或相似的标号对应相同或相似的部件；
附图中描述位置关系的用于仅用于示例性说明，不能理解为对本专利的限制；
显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。

Claims (4)

1.一种基于双网关的轻量级移动支付协议设计方法，其特征在于，包括以下步骤：
S1：设计协议模型；
S2：对协议进行初始假设；
S3：设计协议过程。
2.根据权利要求1所述的基于双网关的轻量级移动支付协议设计方法，其特征在于，所述步骤S1的具体过程是：
针对双卡支付的场景，用户在一张卡余额不足的情况下选择双卡支付，在此场景下，使用双网关完成支付；第一个支付网关连接用户的第一个账号对应的发卡银行Issuer1和商家的发卡银行Acquirer，第二个支付网关连接用户的第二个账号对应的发卡银行Issuer2和商家的发卡银行Acquirer，商家通过支付网关请求付款和收款；保证在不安全网络下移动支付的安全，只考虑不安全网络下的协议过程，作为银行安全网络和不安全公网连接桥梁的支付网关，在此协议中视为银行系统的代理，代理完成账号的分发和验证工作，其实质的账号分发和验证仍然是由银行系统完成。
3.根据权利要求2所述的基于双网关的轻量级移动支付协议设计方法，其特征在于，所述步骤S2的具体过程是：
a)用户拥有两张以上的银行卡或者支付账号，并且每个账号对应的余额不足以完成支付，但两个账号的总额足够完成支付；
b)用户浏览商品，在了解具体商品价格后决定使用两个账号同时支付金额的方式完成付款；
c)协议的参与方完成了初始对称密钥的分发，包括用户与商家之间、用户与两个支付网关之间、商家和两个支付网关之间；
d)银行内部网络是安全可靠的，支付交易过程在银行内部网络中不会遭到第三方的攻击；
e)用户移动设备是安全可靠的，没有遭到木马病毒的挟持，用户发送的请求均是遵循自己的意愿。
4.根据权利要求3所述的基于双网关的轻量级移动支付协议设计方法，其特征在于，所述步骤S3的具体过程是：
阶段1-注册阶段：用户和商家在各自发卡银行进行注册并获得动态ID：
在交易之前，用户和商家都需要向自己的发卡银行进行注册；用户和对应的发卡银行之间产生会话密钥K1，双方的会话密钥可以通过Diffie-Hellman密钥协商协议生成；Diffie-Hellman密钥协商协议对设备的硬件要求和计算资源的要求不高，适合移动设备；
接下来，用户使用会话密钥K1加密注册信息，详细的注册信息可以包括账号信息、用户ID和电话号码：
Customer->Issuer:{AccountInfo,ID,number}K1
在注册过程中，用户需要设置密码识别号码PN和个人识别密码PIN才能访问用户的移动钱包应用程序，这个实现将使用两个因素认证，这是移动设备访问控制的一个重要原则；这两个因素认证意味着分两步验证用户访问移动钱包系统的权限；第一步是移动设备进入移动钱包应用程序，第二步是输入密码，该密码只有用户自己知道；然后用户的初始ID将通过哈希用户的PN和PIN来计算得到：
RIDC＝PNC+H(PNC+PINC)
然后用户的发卡银行系统将使用会话密钥K1解密注册信息，并将必要的信息存储在数据库中；如果注册过程成功，用户的发卡银行系统将发送确认信息通知用户，确认信息使用会话密钥K1进行加密传输；
Issuer->Customer:{success/failure}K1
商家同样需要按照以上步骤在Acquirer中完成注册并获得初始ID；
阶段2-初始化阶段：用户向商家提交订单详情并请求TID：
Step1:C->M
m1＝{OD,TIDreq,amount}
Step2:M->C
m2＝{TID}KMC
正式的交易从初始化阶段开始，初始化阶段的主要目的是用户向商家请求交易标识符TID，TID只能由商家生成，用户浏览所需要购买的商品或服务，并生成订单，用户向商家发送请求，该请求包括订单描述OD、商品的总额和请求交易标识符TIDreq，商家在收到用户的请求后，确认订单总额，生成交易标识符TID，并通过用户与商家之间的会话密钥KMC对TID进行加密，将密文返回给用户，用户使用密钥KMC解密密文，获得交易标识符TID；
阶段3-支付阶段：向付款方和收款方发出扣款和收款请求并得到回复：
Step3:C->M
m3＝{TID,amount,G1,G2,T1,debit_request1,debit_request2}KMC
其中debit_request1＝{TID,G1,RIDC1,amount,T1,H(TID,amount,KMC)}KCG1debit_request2＝{TID,G2,RIDC2,amount,T1,H(TID,amount,KMC)}KCG2
Step4:M->G1
m4＝{TID,G1,amount,RIDM,debit_request1}KMG1
Step5:G1->M
m5＝{TID,amt1,amt2,acp1,T2,H(TID,amount,KMC),H(TID,amt1,T2，KCG1)}KMG1
Step6:M->G2
m6＝{TID,G2,amount,amt2,RIDM,debit_request2}KMG2
Step7:G2->M
m7＝{TID,amt2,acp2,T3,H(TID,amount,KMC),H(TID,amt2,T3，KCG2)}KMG2
Step8:M->C
m8＝{TID,amt1,amt2,acp,T3,H(TID,amount,KMC),H(TID,amt1,T2,KCG1),H(TID,amt2,T3,KCG2)}KMC
支付阶段是该安全协议的核心部分，用户发送付款请求，分别通过支付网关1和支付网关2进行双卡支付，用户的主账号扣完全部余额后剩下的金额有第二个账号扣除；
此阶段由用户C发起，用户构造扣款请求debit_request1和debit_request2，扣款请求debit_request1是请求支付网关Gateway1完成对主账号的扣款，debit_request1使用用户C与支付网关Gateway1之间的会话密钥KCG1进行加密，该请求只能被用户和支付网关Gateway1获知，debit_request1包括的信息有交易标识符TID、支付网关G1、用户主账号随机RIDC1、交易总额amount、时间戳T1和用户和商家的交易消息验证码H(TID,amount,KMC)，同样的，用户构造debit_request2请求支付网关Gateway2对第二张卡进行扣款，具体的消息内容与debit_request1相似，携带支付网关G2和用户第二个账号随机RIDC2，并使用用户与支付网关Gateway2之间的会话密钥KCG2进行加密，保证只有用户和支付网关Gateway2可以获知，用户发送给商家的消息m3包括debit_request1和debit_request2，m3中还包含G1和G2，以通知商家用户使用双卡支付的方式完成付款操作，m3使用用户与商家之间的对称会话密钥KMC进行加密；
商家在收到消息m3之后，使用KMC解密消息，获得扣款请求debit_request1和debit_request2，商家核对用户发送过来的商品总额，确认无误后构造消息m4并发送给支付网关G1，消息m4包括的信息有交易标识符TID、G1、商品总额amount和商家的随机RIDM，并附加从用户接收到的debit_request1，使用商家和支付网关G1之间的对称会话密钥KMG1加密消息；
支付网关G1收到消息m4后，使用KMG1解密消息，获得商家随机RIDM和用户的扣款请求debit_request1，使用密钥KCG1解密debit_request1，获得用户主账号随机RIDC1，比较m4中的商品总额amount和debit_request1中的商品总额amount，确保两者相同，若不同则交易取消，返回商家acp1＝false；在两者相同的情况下，支付网关G1连接银行内部网络系统，请求Issuer1验证RIDC1，并获得RIDC1对应的实际账户的余额amt1，返回给支付网关G1，同时请求Acquirer验证RIDM，在验证操作均正确的情况下设置acp1＝true，否则acp1＝false；另外，支付网关G1使用时间戳T2，计算△t＝T2-T1，如果△t超过限定的时限，则置acp1＝false，交易取消，支付网关G1构造回复消息，并使用密钥KMG1加密消息生成消息m5，将m5返回给商家，消息包括TID、主账号需要支付的金额amt1、第二个账号需要支付的金额amt2＝amount–amt1、验证结果acp1、时间戳T2、支付网关G1返回给用户的扣款回复消息认证码H(TID,amt1,T2,KCG1)，并携带H(TID,amount,KMC)；
商家收到支付网关G1的回复消息m5后，使用KMG1解密m5，获得用户第二个账号需要支付的金额amt2，商家构造消息，并用与支付网关G2共享的会话密钥KMG2加密消息生成m6，将m6发送给支付网关G2，消息m6包括交易标识符TID、G2、商品总额amount、第二个账号需要支付的金额amt2、商家随机RIDM以及扣款请求debit_request2；
支付网关G2获得加密消息m6后使用KMG2解密消息，获得扣款请求debit_request2并解密，基本操作与支付网关G1收到商家的消息后的操作相似，支付网关G2构造回复消息，并使用KMG2加密消息生成消息m7，回复消息包括的内容有TID、第二个账号需支付的金额amt2、验证结果acp2、时间戳T3、支付网关G2返回给用户的扣款回复H(TID,amt2,T3,KCG2)，并携带H(TID,amount,KMC)；
商家在收到消息m7后，解密消息，综合从支付网关G1收到的消息m5，计算综合验证结果acp＝acp1&acp2，构造将要返回给用户的消息，并用KMC加密回复消息生成密文m8，消息内容包括TID、主账号需要支付的金额amt1、第二个账号需要支付的金额amt2、综合验证结果acp、时间戳T3、从支付网关G1获得的扣款回复H(TID,amt1,T2,KCG1)、从支付网关G2获得的扣款回复的消息验证码H(TID,amt2,T3,KCG2)，并携带H(TID,amount,KMC)；
用户收到消息m8后使用KMC解密，获得明文消息，根据综合验证结果acp判断是否需要继续执行交易，若acp＝true，则继续后续的提交阶段，否则终止交易；
阶段4-提交阶段：向付款方和收款方提交扣款和收款确认：
Step9:C->M
m9＝{TID,T4,continue,H(TID,amt1,amt2,T4)}KMC
Step10:M->G1
m10＝{TID,commit,T5,H(TID,amt1,T2,KCG1),H(debit_request1,TID,T5,KMG1)}
Step11:G1->M
m11＝{TID,committed,H(TID,amt1,T2,KCG1),H(debit_request1,TID,KMG1)}
Step12:M->G2
m12＝{TID,commit,T5,H(TID,amt2,T3,KCG2),H(debit_request2,TID,T5,KMG2)}
Step13:G2->M
m13＝{TID,committed,H(TID,amt2,T3,KCG2),H(debit_request2,TID,KMG2)}
Step14:M->C
m14＝{transaction_success,payment_receipt}
支付阶段完成后，用户判断综合验证标识acp是否为true，若acp＝false，则终止交易，进入阶段五动态ID更新阶段，否则，继续提交阶段完成交易；
在支付阶段确认无误后用户提交扣款请求，请求支付网关完成转账操作，提交阶段仍然由用户发起，用户构造加密消息m9，使用与商家之间的共享密钥KMC加密消息，将加密消息发送给商家；消息内容包括交易标识符TID、时间戳T4、请求继续提价的标识符continue，以及对TID、amount和时间戳T4的消息摘要，确保消息的完整性；
商家在接收到用户继续提交的消息m9后，解密消息m9获知交易的continue标识符，得知用户继续提交付款；商家构造消息m10，并将消息m10发送给支付网关G1；消息内容包括交易标识符TID、提交标识符commit、时间戳T5、支付阶段支付网关G1返回的扣款回复H(TID,amt1,T2,KCG1)以及商家发送给支付网关的消息验证码H(debit_request1,TID,T5,KMG1)，该消息验证码包含了用户对支付网关的扣款请求debit_request1，debit_request1是商家在支付阶段缓存下来的，但商家并不能解析该扣款请求，在这一步中附加debit_request1会对支付网关的验证有帮助；
支付网关G1收到商家发送过来的消息m10，获取消息中的提交标识符commit，验证扣款请求debit_request1和扣款回复H(TID,amt1,T2,KCG1)，验证无误后连接银行内部网络系统，请求发行方Issuer1和收款方Acquirer之间完成金额为amt1的转账，转账操作完成后支付网关G1回复商家消息m11，消息内容包括交易标识符TID、已完成提交标识符committed以及与商家之间的消息验证码H(debit_request1,TID,KMG1)；
商家收到消息m11，获取消息内容中的已提交标识符committed，得知支付网关G1完成转账操作，商家发送消息m12至支付网关G2，操作和消息内容类似于对支付网关G1的操作；
支付网关G2收到商家发送的提交请求，连接银行内部网络系统，完成发行方Issuer2与收款方Acquirer之间金额为amt2的转账操作，并回复商家已提交committed；
商家收到支付网关G1的committed和支付网关G2的committed，得知通过两个支付网关的转账操作都已经完成，商家回复用户交易成功标识符transaction_success和支付已接收标识符payment_receipt；同时，商家进入动态ID更新阶段；
用户收到商家返回的成功消息，接下来继续动态ID更新阶段；
阶段5-动态ID更新阶段：更新用户和商家的随机ID：
Step15:
C->G1:m15＝{updateID,success/failure}
C->G2:m16＝{updateID,success/failure}
M->G1:m17＝{updateID,success/failure}
Step16:G1->C,G2->C,G1->M
m18＝{result}
用户和商家的动态ID更新方式可以为：
RIDC1(new)＝H(RIDC1(old),(T2-T1))
RIDC2(new)＝H(RIDC2(old),(T3-T1))
RIDM(new)＝H(RIDM(old),(T2-T1))
不管交易是否完成，动态ID更新阶段都要执行，用户或商家的ID更新都发生在于支付网关之间，支付网关将更新ID的请求转发到对应的发卡银行系统，由对应的发卡银行系统完成ID的更新并存储在数据库中；动态ID的更新仍然由用户发起，用2户根据协议的计算方法计算新的ID，并发送更新ID的消息至支付网关，支付网关将请求交给对应发卡银行系统，银行系统也根据协商的计算方式计算新的ID并更新数据库，之后的交易都使用最新的随机ID。
CN201810196540.XA 2018-03-09 2018-03-09 一种基于双网关的轻量级移动支付协议设计方法 Pending CN108449332A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810196540.XA CN108449332A (zh) 2018-03-09 2018-03-09 一种基于双网关的轻量级移动支付协议设计方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810196540.XA CN108449332A (zh) 2018-03-09 2018-03-09 一种基于双网关的轻量级移动支付协议设计方法

Publications (1)

Publication Number Publication Date
CN108449332A true CN108449332A (zh) 2018-08-24

Family

ID=63194415

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810196540.XA Pending CN108449332A (zh) 2018-03-09 2018-03-09 一种基于双网关的轻量级移动支付协议设计方法

Country Status (1)

Country Link
CN (1) CN108449332A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110766397A (zh) * 2019-10-21 2020-02-07 深圳市丰鑫科技服务有限公司 基于数据识别模型的近场支付方法
CN111814909A (zh) * 2020-08-06 2020-10-23 蔡淦祺 基于网络直播和在线电商带货的信息处理方法及云服务器
CN112100653A (zh) * 2020-08-21 2020-12-18 北京思特奇信息技术股份有限公司 一种前端敏感信息处理的方法和系统
CN113139805A (zh) * 2021-05-13 2021-07-20 中国工商银行股份有限公司 支付作业的处理方法、装置及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101968907A (zh) * 2010-09-17 2011-02-09 宇龙计算机通信科技(深圳)有限公司 一种基于双卡移动终端的支付方法、系统及移动终端
CN104376459A (zh) * 2013-08-12 2015-02-25 黄金富知识产权咨询(深圳)有限公司 一种双卡双待无线pos机和相应支付系统
CN106408184A (zh) * 2016-09-12 2017-02-15 中山大学 一种基于多源异构数据的用户信用评估模型

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101968907A (zh) * 2010-09-17 2011-02-09 宇龙计算机通信科技(深圳)有限公司 一种基于双卡移动终端的支付方法、系统及移动终端
CN104376459A (zh) * 2013-08-12 2015-02-25 黄金富知识产权咨询(深圳)有限公司 一种双卡双待无线pos机和相应支付系统
CN106408184A (zh) * 2016-09-12 2017-02-15 中山大学 一种基于多源异构数据的用户信用评估模型

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
VENKATASAMY SURESHKUMAR等: "《Computers and Electrical Engineering》", 《A LIGHTWEIGHT TWO-GATEWAY BASED PAYMENT PROTOCOL ENSURING ACCOUNTABILITY AND UNLINKABLE ANONYMITY WITH DYNAMIC IDENTITY》 *
李海飞: "《移动支付中的安全协议研究》", 《中国优秀硕士学位论文全文数据库信息科技辑》 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110766397A (zh) * 2019-10-21 2020-02-07 深圳市丰鑫科技服务有限公司 基于数据识别模型的近场支付方法
CN111814909A (zh) * 2020-08-06 2020-10-23 蔡淦祺 基于网络直播和在线电商带货的信息处理方法及云服务器
CN111814909B (zh) * 2020-08-06 2021-07-06 广州蜜妆信息科技有限公司 基于网络直播和在线电商带货的信息处理方法及云服务器
CN112100653A (zh) * 2020-08-21 2020-12-18 北京思特奇信息技术股份有限公司 一种前端敏感信息处理的方法和系统
CN112100653B (zh) * 2020-08-21 2024-02-20 北京思特奇信息技术股份有限公司 一种前端敏感信息处理的方法和系统
CN113139805A (zh) * 2021-05-13 2021-07-20 中国工商银行股份有限公司 支付作业的处理方法、装置及系统

Similar Documents

Publication Publication Date Title
US11687924B2 (en) Cryptocurrency infrastructure system
KR102111368B1 (ko) 가상화폐 거래 시스템 및 방법
RU2648944C2 (ru) Способы, устройства и системы для безопасного получения, передачи и аутентификации платежных данных
US8725638B2 (en) Method and system for payment authorization and card presentation using pre-issued identities
US9213992B2 (en) Secure online transactions using a trusted digital identity
US20210344672A1 (en) Techniques for token proximity transactions
US8516560B2 (en) Secure remote authentication through an untrusted network
CN107358440B (zh) 数字货币定制追踪的方法和系统
CN108476227A (zh) 用于设备推送供应的系统和方法
Liu et al. State of the art: Secure mobile payment
CN108449332A (zh) 一种基于双网关的轻量级移动支付协议设计方法
JP2003524268A (ja) ネットワーク上で取引を実施する方法
US20080133419A1 (en) Secure financial transaction system and method
WO2022154789A1 (en) Token-based off-chain interaction authorization
US20230298009A1 (en) Rapid cryptocurrency transaction processing
US11574310B2 (en) Secure authentication system and method
US20210377039A1 (en) Checkout with mac
EP4379631A1 (en) Digital wallet device and dual offline transaction method thereof
US20240078522A1 (en) Interaction channel balancing
CN114462988A (zh) 一种发款方匿名的数字货币双离线交易方法及系统
WO2023064086A1 (en) Efficient and protected data transfer system and method
AU2008254851B2 (en) Method and system for payment authorization and card presentation using pre-issued identities
WO2015110039A1 (zh) 一种使用卡公开数据输入付款账户的方法和系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20180824