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)}KMG1Step6: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)}KMG2Step8: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。