移动支付情境下网络安全问题分析与解决方案
**
安徽师范大学数学计算机科学学院 2012级物联网工程专业 韩文锴
**1 **引言****
**
早在2010年，中国移动通信集团就将移动支付定为其重点发展战略之一[1]
。随着移动互联网和物联网的迅猛发展，QR-Code、RFID、NFC支付都成为物联网移动支付的新载体。支付宝扫码支付、Apple Pay等业务也遍布全球。在苹果于2015年3月10日举办的特别产品发布会上，其CEO库克宣布：目前在美国有超过2500家银行已支持Apple Pay，接受Apple Pay的网店多达70余万处，包括4万余台可口可乐贩卖机的众多自动贩售机也纷纷支持Apple Pay，而且每天都有更多的商户和应用在加入这个行列。[2]
但支付问题涉及个人财产及隐私问题，因此其安全问题显得更加敏感。其挑战是多方面的[3-4]
，不仅来自于传统互联网的账号密码管理、木马病毒窃取、社会诈骗手段，更有数据传输反监听、动态Token和用户隐私保护等多方面新挑战。
本文就移动支付情境下网络安全问题进行分析，并针对以上不同技术和应用情景，提供在数据传输反监听、用户隐私保护等新兴挑战方面可能的解决方案和建议。
**2 **移动支付安全分析****
**
移动支付的过程主要由用户端、服务端和商户端三个部分组成。用户端由每一个支付工具的用户组成，服务端包括如银联、支付宝、Paypal、Apple Pay这些提供支付服务的运营商，而商户端则由线下商铺、自动贩售机等实体经营商户组成。其三者关系主要可以从下图1中看到。其中服务端则是整个体系中在技术与安全上最重要的一环，它不仅要保证用户和交易信息在三者间准确、高效地传输，更需要保证交易信息和过程的安全性。
图1
支付过程与关系
一般情况下的支付流程用伪代码可以表示其过程如下：
Step 1：用户在商户选购商品，若成功选中商品，进入Step 2，否则结束；
Step 2：用户使用相应服务端应用通过QR-Code, NFC等技术获取商品和商户信息，并发起支付请求且进行下一步，若请求失败则重复此步；
Step 3：服务端接收到用户、商品和商户信息后，认证用户信息和账号余额，若余额充足且账户合法，则进行支付操作，将成功支付信息发送给商户且进行下一步，并定期将付款转账给商户，否则结束；
Step 4：商户端接收支付信息并将货品交送给用户，结束流程。
在此过程中，安全问题主要出现在Step 2-4中。
在Step 2中，要保证用户在面对伪造商户端时信息和财产不受损，且信息发送的过程中不被截取；在Step 3-4中，要保证账户信息不泄露、对商户不可见。
而经过查阅文献资料和现实实例分析，解决上述个问题可以使用动态握手协议和数据传输加密技术保证商户信息可靠性和发送信息不被截取、用动态Token技术保证用户信息的保密性。
**3 **安全支付技术分析****
**
3.1 TLS****协议
**
TLS握手协议提供的连接安全具有三个基本属性：
1.可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。
2.共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。
3.协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。
TLS协议允许C/S模型的应用程序跨网络通讯，旨在防止窃听和篡改的方式进行沟通。TLS协议的优势在于它是与应用层协议独立无关的。高层的应用层协议（例如：HTTP、FTP、Telnet等等）能透明的创建于TLS协议之上。TLS协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。
TLS协议是可选的，所以如果需要使用就必须配置客户端和服务器，有两种主要方式实现这一目标：一个是使用统一的TLS协议端口号（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：邮件、新闻协议和STARTTLS)。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于创建安全连接：
l 当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。
l 服务器从该列表中决定加密和散列函数，并通知客户端。
l 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。
l 客户端确认其颁发的证书的有效性。
l 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
l 利用随机数，双方生成用于加密和解密的对称密钥。
这就是TLS 协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS 握手过程就会失败，并且断开所有的连接。
3.2 ****动态Token**技术****
**
Token技术在Apple Pay等支付系统中广泛应用[5]，Token SP根据Token Requestor提供的PAN(主帐号)生成Token后，将Token作为PAN的替代值流转在支付的各个环节，使得在支付流程中，独一无二的PAN只在Token SP、转接方、发卡方间传递，由于三者专线连接且彼此互信，且当Token被检测到风险或到期时，将再次生成新Token替代，从而大幅降低支付过程中PAN泄漏的可能性，极大地提高了PAN的安全性。
3.2.1 Token****申请流程
**
NFC终端传递PAN至Token Requestor;
Token Requestor向Token SP发起Token申请，发送PAN;
Token SP根据PAN，生成对应的Token并返回至Token Requestor，同时建立PAN至Token的映射并存储在Token库中，与发卡方共享此Token库;
Token Requestor将返回的Token传递至NFC终端。
图2 Token申请流程
**
**
3.2.2 Token****应用流程
**
图3 Token应用流程
- Token从NFC终端开始，依次传递至POS、收单方、转接方;
2．转接方通过与Token SP的接口，发送Token至Token SP;
Token SP对Token执行去令牌化操作，并将PAN传递至转接方;
转接方将Token&PAN传递至发卡方，发卡方用Token库进行验证，验证通过后，再将PAN传递至转接方;
验证后的Token从转接方开始，依次传递至收单方和POS，之后Token作为PAN的替代值继续后续的交易流程。
以上是Token的技术实现方案，可以看到，在交易过程中，PAN传递且仅传递在Token SP、发卡方和转接方三者之间，且Token的动态性保证了交易信息的保密性。
参考文献
**
[1] http://www.edu.cn/tgyy_7952/20100714/t20100714_496025.shtml
[2]http://finance.ifeng.com/a/20150310/13542799_0.shtml
[3] http://www.cebnet.com.cn/2014/0717/270517.shtml
[4]王学刚.NFC移动支付及其安全管理[J].中国管理信息化,2012,15(21):79-80.
