（2）支付宝卡通方式支付，只要用户以合法身份成功登录到支付宝，并且拥有支付密码，
则可立刻完成整个支付流程。
攻击模式：客户在申请支付宝卡通业务时，若主机上已经挂马，如各种带键盘监听的
rootkit（在键盘驱动上恶意附着一层过滤驱动，使所有键盘消息都被过滤驱动拦截，设置
回调例程函数，待键盘底层驱动解析出键码值后，直接返回给了过滤驱动，从而实现键盘按
键消息截获），可准确无误地获取到用户输入的支付密码、客户登录ID、密码，并启动主机
上的后门通信服务，可实时地向远端主机发送这些重要信息。
（3）黑客 Evil 可通过第三方支付平台捏造虚假交易，实施信用卡套现、甚至洗钱等不
法行为。Evil 可在 C2C 模式的网站上分别注册一个卖家账号、一个卖家账号，使用信用卡
方式进行支付套现，实际上整个商品的交易并没有发生。

支付平台建设安全性设想
 
  从前面的分析可知，支付网关可能存在的攻击主要表现在：（1）客户、商户、支付网关
之间未实施三方认证；（2）支付过程中客户的支付密码、卡密码、网银登录ID 可能被泄露； 
为了解决上面提出的问题，设计了如下一个支付流程：
（1）客户、商户向第三方支付平台注册时，三方相互交换数字证书公钥；
（2）客户在购买商品时用自己的私钥Kc对订单OIM加密处理后，向商户M发送Req_Buy
(OIM | Ekc
（3）M收到Req_Buy，使用C的公钥K
(OIM))消息；
pc解密Ekc(OIM)以验证OIM是否被篡改；通过后则构
造一个支付响应消息Res _Pay_Infor (OIM | Ekm
（4）C收到Res _Pay_Infor消息后，使用M的公钥K
(OIM | Date | LifeTime))返回给C；
pm解密Ekm(OIM | Date | LifeTime)，
验证是否为合法商户，订单是否被篡改；通过验证后，则向第三方支付平台G发起支付请求
Req_Pay_Infor ( Ekg (CERTc
（5）G收到Req_Pay_Infor后，用G的私钥解密E
 | OIM | Date | LifeTime))；
kg (CERTc | OIM | Date | LifeTime)，
验证CERTc是否来自C的客户证书，验证通过后构造报文Req_Pay_Auth (Ekc (RAND | Ekg (OIM
| Date | LifeTime )))、Req_Pay_Auth (Ekm (RAND | Ekg (OIM | Date | LifeTime )))，
分别发送给C和M，其中RAND为G生成的一个挑战数；

（6）C和M收到Req_Pay_Auth后，使用各自的私钥和G的公钥解密报文，判断OIM是否正
确及LifeTime是否在生命周期内；验证通过后，会分别构造一个响应报文，请求支付，报文
分别如下：Res_Auth (Epg
E
(RAND | OIM | Date | LifeTime | PayerAcNo | 
pc(PayerAcNo)))、Res_Auth (Epg (RAND | Ekm
（7）G收到来自C和M的支付授权后，G用私钥K
(PayeeAcNo | OIM | Date | LifeTime)))；
g
全部通过后，G直接向 C所在开户行提交支付报文Pay_Infor (E
解密授权密文，判断RAND是否一致，再
用各自的公钥解密订单信息，判断订单是否一致且是否在有效期内；因为C和M上送的支付授
权可能会在不同时间到达G端，故G需要比对两个支付授权是否都已经返回给G；验证
k(PayerAcNo |
Epc(PayerAcNo)))；其中密钥K为G与C所在开户行建立支付连接时生成的证书私钥；公钥

在银行方保存；银行解密后账户是否一致，比对成功则直接扣款，完成支付。
 
小结
 
通过分析当前各种支付模式，给出了每种模式可能存在的风险性，并提出了一种新型的
支付模型，笔者并没有对支付模型进行有效性、可行性验证，在实际支付上可能会因支付流
程过于复杂导致支付效率底下。但对于大金额支付而言，建议还是实施三方认证并尽可能省
略掉客户登录网银支付的流程。
网关支付建议：在使用银行网关进行中支付时，尽可能地使用 UsbKey 证书方式完成支
付，在输入密码、动态口令域页面尽可能查看域名URL 是否与银行的相符，防止钓鱼攻击；
虽然支付宝卡通方式的简化了支付流程同时又很好地规避了客户登录网银系统的风险性；但
无证书版的整个支付安全性偏低，即便控制了每日交易额及单笔交易额，若客户没有在开户