浅谈手机支付的架构、安全与合规

type

status

date

slug

summary

一、手机支付和电子钱包等概述

电子钱包（Digital Wallets）

电子钱包是电子商务购物活动中常用的支付工具。在电子钱包内存放的电子货币，如电子现金、电子零钱、电子信用卡等。

来源于百度百科

手机钱包（Mobile Wallets）

基于手机的钱包，市场上常见的目前有Apple Pay，Android Pay，Samsung Pay，Huawei Pay以及Mi Pay等等。这些Pay有一个共性，就是基于软件与硬件的组合，目的是使用替代传统的借记卡/信用卡/以及其他卡（如交通卡）。

数字货币钱包（Digital Currency Wallets）

从英文角度讲，和Digital Wallets似乎很像，但是这个数字货币钱包是基于区块链技术应用而产生的。以下引用简书上的解释。

比特币、以太坊等数字货币钱包就属于虚拟的电子钱包。虚拟货币的钱包其实并不是装钱的，而是装密钥（私钥和公钥）的工具，有了密钥就可以拥有相应地址上的数字货币的支配权。

无线支付传输技术

目前基于设备（或者说手机）的支付，都是通过将支付需要的信息通过设备无线传输给销售终端（POS机）。

常见的无线传输机制有：

MST：三星的一种技术，详见

https://www.samsung.com/us/support/answer/ANS00043865/

NFC：近场通信。使用了NFC技术的设备（比如手机）可以在彼此靠近的情况下进行数据交换，是由非接触式射频识别(RFID)及互连互通技术整合演变而来，通过在单一芯片上集成感应式读卡器、感应式卡片和点对点通信的功能，利用移动终端实现移动支付、电子票务、门禁、移动身份识别、防伪等应用。（来源于百度百科）

QR Code：二维码。二维条码/二维码（2-dimensional bar code）是用某种特定的几何图形按一定规律在平面（二维方向上）分布的黑白相间的图形记录数据符号信息的；在代码编制上巧妙地利用构成计算机内部逻辑基础的“0”、“1”比特流的概念，使用若干个与二进制相对应的几何形体来表示文字数值信息，通过图象输入设备或光电扫描设备自动识读以实现信息自动处理：它具有条码技术的一些共性：每种码制有其特定的字符集；每个字符占有一定的宽度；具有一定的校验功能等。同时还具有对不同行的信息自动识别功能、及处理图形旋转变化点。（来源百度百科）

蓝牙/短信。根据Internet上的资料介绍，这些也算在无线传输技术内，但是目前我没有见到基于此类技术的手机支付。

手机支付交易原理

本文说述的手机支付，适用于前面所说的电子钱包和手机钱包，尤其重点在手机钱包。简单来说手机支付是传统信用卡/借记卡支付的一种延伸，本质上并没有改变传统的卡支付的系统设计。

传统上，客户在POS机上刷卡（非芯片卡）或者拍卡（支持闪付的卡），商户通过此动作获取交易卡号，并将相关卡号（英文往往成为PAN-Primary Account Number）以及交易金额加密后通过支付网络，从收单行传输至卡的发卡行进行授权。

手机支付，原理上类似，客户在手机靠近POS（支持闪付的pos）进行NFC交易，或者通过POS扫描二维码进行二维码支付。然后商户将Token（令牌）协同其他支付信息如金额等通过支付网络，从收单行传输至卡的发卡行进行授权。

其中的令牌（Token）就是替代了物理卡的卡号和有效期等信息。Token所对应的实际物理卡号以及有效期等信息，只安全的存储于卡组织或者发卡行。所以发卡行在最后授权该笔交易的时候，会先查询该Token对应的卡号和有效期，进行转换然后进行扣款或者授权。

安全单元（Secure Element）

安全单元是一个抗干扰的/安全的硬件平台，用于安全的放置相关程序和加密数据。在金融领域（如前文提到的各种Pay），SE主要用户存放和运行卡组织相关的小程序以及用于信用卡/借记卡交易的密钥。在某些领域，生物相关数据也存在SE中。

在人民银行发布的《移动终端支付可信环境技术规范》上，也对SE进行了相关描述，引用如下，具体详见JR/T 0156-2017。

移动终端上的高安全运行环境，可在硬件与软件层面上防御各种恶意攻击，运行在其上的应用具备高安全性需求，如eSE、inSE。其组成主要包括:
——应用软件层:包括安全应用，如金融、公交、社保、电信等，应用采用预置或在 TSM 控制下安全获取与部署；
——系统软件层:运行一种可验证的卡片操作系统，主要供安全加解密、密钥存储等功能。

可信执行环境（Trusted Execution Environment）

直接引用人民银行发布的《移动终端支付可信环境技术规范》，如下：

与REE相隔离的安全区域，通过一组硬件和软件的组合，保证各种敏感数据在其中被安全传输、存储、处理，保证TA执行的机密性、完整性和数据访问权限端到端的安全。TEE的实现可以基于不同的技术，其组成主要包括:
——应用软件层:包括各种安全相关的可信应用，一般与对应 REE 应用相结合，为用户供既便捷又安全的用户体验，可信应用以机构部署为主，如指纹、支付、身份认证等应用;
——系统软件层:充分利用硬件资源(如 CPU、RAM、FLASH、SPI 总线等)的可信性，实现受硬件隔离的系统执行环境，具备安全计算及其所属各种安全设备运行的资源调用能力，可供下述功能:
安全加解密、安全存储、可信用户接口、可信身份认证等各种系统服务;
系统和应用安全的密钥体系;
与 REE、SE、外部设备的安全通信机制，并供相应的访问控制;
供可信虚拟化层，可支撑多个可信 OS 并存与运行。

安全单元与可执行环境的区别

一张图来说明Rich OS（也就是我们的手机操作系统）与TEE/SE三者的关系。

（图1）

二、手机支付平台以及安全概述

基于安全单元（SE）的手机支付加载卡片流程

Apple Pay，Samsung Pay之类的加载卡片流程，大致为以下的流程图。

（图2）

1. 用户通过在手机APP中输入现有的借记卡/信用卡信息。

2. 手机终端将这些信息发送至手机后台服务器（可能还有设备号等其他信息，以便检测风控情况）。一般涉及到2层加密，其一为字段级加密，会对用户输入后的卡号，有效期分别加密。其二是在发送到服务器时候的网络层加密（TLS v1.2之类）。

3. 服务器一般会对收集到的信息进行转发或者转加密（取决于不同手机公司做法）后发给支付网络，在国内的话，目前就是银联。有些手机商在第2步直接使用银联控件进行加密的话，一般直接转发给银联。有些手机商则会在通过加密机进行转加密后发给银联。

4&5. 支付网络（银联）会协同发卡行对收到的信息解密，并且判断是否是合法且可以加载到手机的卡片。如果是，则发卡行生成令牌，并且通过网络将令牌下发到设备。发卡行这边存一般存有令牌与物理卡号的映射关系表。

6. 设备SE收到令牌信息，将这些信息存入SE中，且只有SE中的银联小程序可以读取和发送这个令牌。其他SE中的小程序或者操作系统层面的APP都无法直接读取这个令牌。

基于安全单元（SE）的手机支付闪付流程

Apple Pay，Samsung Pay之类的线下POS机支付时候的流程，大致为以下的流程图。

（图3）

1. 一般以用户将手机靠近支持闪付的POS时，触发支付流程。手机会要求用户进行生物认证（指纹/面部）或者输入设备密码进行身份确认。确认后，且用户选择了对应的卡片后，该卡的令牌通过SE里的银联小程序将令牌反馈至POS机商户。

2. 商户通过POS机将令牌发送给收单行。

3. 收单行收到含有令牌的支付报文，但收单行无法识别令牌对应的卡号，因此需要通过银联发送给该令牌实际对应的发卡行。

4.发卡行收到后，转换成令牌对应的物理卡号。

5.银行根据物理卡号进行扣款。

6.扣款成功结果通过银联->收单行->POS机的顺序反馈至POS机，完成整个交易。

令牌的安全意义

使用令牌，极大的防止了物理卡号被泄漏的可能性。在手机支付中，令牌本身会与“唯一值”一同发送至银联和发卡行。而发卡行和银联可以同样计算出这个“唯一值”来进行验证，该笔基于令牌的交易是否是来自授权的设备（也就是当初加载该卡片的手机）。这样，我们可以发现，即使令牌泄漏，单纯的令牌（即使他类似卡号，长度和卡号的BIN都类似物理卡）也无法在在线网站或者其他途径进行扣款。

在Apple的《iOS 安全保护 - iOS 11》这个白皮书34页，对我提到的“唯一值”进行了描述。请注意，在Apple的白皮书上，设备帐号也就是我说的令牌，交易专用动态码则就是我说的“唯一值”。

源自支付小程序的所有支付交易均包括交易专用动态安全码和“设备帐号”。这个一次性代码使用计数器和密钥计算，计数器值随每次新交易的产生而递增，密钥则在个性化过程中预置在支付小程序中，为支付网络和/或发卡机构所知。根据支付方案的不同，计算这些代码的过程中还可能使用其他数据，包括：
支付小程序生成的随机码。
终端生成的另一个随机码（NFC 交易）。
或服务器生成的另一个随机码（应用内交易)。
这些安全码会提供给支付网络和发卡机构，允许其验证每笔交易。完成交易的类型不同，这些安全码的长度也可能有所不同。

至于Samsung Pay，没有找到更详细的资料进行佐证。但笔者认为应该也是一样的。

手机支付中涉及的数据保护

1. 物理卡号和CVV，有效期等，均只有在第一次加载卡片的时候使用，且不会被服务器或者设备储存。如《iOS 安全保护 - iOS 11》这个白皮书32页中，明确有此声明。

完整的付款卡号码不会储存在设备或 Apple 服务器上。而是会创建唯一的“设备帐号”、进行加密，然后储存在安全元件中。

2. NFC交易时，直接通过NFC控制器将SE中的银联小程序所反馈的令牌，反馈给NFC场，因此操作系统层面的APP是根本没办法获取到令牌。

3. NFC交易时，物理卡号，有效期，CVV等这些信息不会被使用到。物理卡号与令牌的转换只有在发卡行自己内部进行转换，极大的保护了持卡人信息。

安全单元（SE）详解和加载卡片

从上面加载卡片或者闪付消费的描述中，我们注意到所有的信息最后都在SE中。这也就是我们之前说的安全的存储。

SE，简单来说，就是一个安全芯片，用于安置小程序（Applet）和机密且加密后的数据。SE是手机支付最核心的内容。

一个典型的基于SE的手机支付。在设备端主要涉及以下3个组件。也可以见下图4。

1. SE，也就是我们说了好几次的硬件本身

2. 在SE上运行的OS（软件）以及安全域（Security Domain)

3. 在OS上运行的Applet

安全域又可以细分为ISD、CASD，Device Domain以及SSD四大块安全域。

（图4）

监管机构安全域：是SE元件的生产商所拥有的区域，包含了一些与手机商共同确认的安全策略，用于控制整个SE。CASD拥有SE 厂商提供的私钥，手机商不可用。在添加卡片过程中，CASD主要用于验证SE的合法性。

发行方安全域：手机厂商所拥有的区域，包含了手机商所定义的安全策略，并可以管理辅助安全域。ISD拥有手机商的私钥。

手机厂商安全域：一般包含用于管理SSD里的Applet的安全政策略。

辅助安全域：一般是用于安置银行卡的小程序。

以用户添加一张卡为例，也就是之前（图2）中的第6步为例。当终端被告知可以添加这个卡对应的令牌进入到SE中时，以下步骤将会发生。

使用主安全域密钥（Key-ISD）建立安全通道。这个密钥只有手机商拥有。

创建后，为辅助安全域设置新的密钥（Key-SSD）

使用银行或者银联的密钥（Key-bank）替换Key-SSD

安装银行或者银联的小程序

下载APDU脚本并在小程序内执行（包含了令牌信息），手机商无法解密其中的信息，因为APDU脚本由步骤3重的Key-bank密钥保护。

划重点：

以上1-4步骤，所有的通讯即使在SE中发生，也都是加密且在安全通道内发生。

一旦使用银行或者银联的密钥（Key-bank）之后，即使是手机商也无法进行解密了。

发行者安全域密钥（Key-ISD）很重要，他是用于建立安全通道的。所以一旦Key-ISD泄漏的话，那么相应的防护就会弱了很多。当然，就像我前面所说，本身数据也是加密后在安全通道内传递。因此Key-ISD泄漏不代表一定会出事。

安全单元（SE）详解和闪付交易

闪付交易通过NFC Radio触发，在经过生物认证或者密码输入后，大致的流程是：

NFC Controller通知SE选择适合的Applet进行支付，在国内，就是银联的Applet将会被调用

EMVCo指令通过NFC Controller在银联的Applet与POS机之间传递，以完成闪付。

注：NFC Controller与银联Applet之间传递交易指令，是通过专用的硬件总线实现的，因此避免了设备上其他应用程序监听和拦截指令的可能性。参考下图5。

（图5）

三、手机支付的安全与合规问题

先谈下安全。

基于SE的手机支付，在之前的阐述中，已经可以感觉到大体上是很安全的。在现有的这种架构下，数据泄漏的可能性是很低的。举几个常见的场景，其实在上文中也已经多处提及。

1. 物理卡号以及其他相关信息的泄漏：物理卡号只有在用户添加卡片到手机时候需要输入，仅此一次。一旦卡片加载在手机后，物理卡号不会被使用到。这种情况下，物理卡号的泄漏只有可能在通信协议TLS1.2以及字段级加密都失效的情况下发生。

通讯协议会随着技术的迭代，使用新的版本去替换老的版本，以规避老协议的漏洞。SSL1->SSL2->SSL3->TLS1.0->TLS1.1->TLS1.2就是一个迭代的过程。

字段级加密则有很多实现的方式。比如使用键盘控件，防止键盘钩子以及实现字段在发送前就加密的功能。有效防止了数据被窃听和泄漏的可能。

2. 令牌信息泄漏：令牌信息在多个地方有涉及。逐一来看看。

2.1 加载卡片最后确认可以的情况下，银行会通过支付网络发送令牌信息到手机SE上。这种情况下，令牌信息泄漏只有可能在安全通道以及支付网络私钥被泄漏的情况下发生。

安全通道使用Key-ISD建立安全通道（SCP02或SCP03）。

令牌在发送给设备时，是包含在APDU脚本里的，并且使用支付网络的公钥加密，到了SE里，由支付网络的Applet的私钥（Key-bank）解密，并保存在SE的Applet里。

因此，只有在支付网络的私钥被泄漏的情况下，且安全通道漏洞发生的情况下，令牌有机会被泄漏。但是使用泄漏的令牌无法进行除手机支付以外的在线支付，见最一开始“令牌的安全意义”段落的描述。

2.2 存储在SE的Applet情况下，令牌信息也是受保护的。首先按照SE中Applet按照安全策略的话，是无法被操作系统层面的第三方应用访问或者通讯的。其次，令牌是由支付网络的Applet进行密钥加密存储。

2.3 支付时的令牌信息泄漏。这个可能性很小，如以上“安全单元（SE）详解和闪付交易”处的解释，令牌信息是通过硬件总线直接传递出去的。保证了一定的安全性。

从手机NFC发送给POS机的过程，类似物理银行卡闪付交易了。这段通讯过程中，信息是被加密的。但是不排除可以被窃听的可能，有研究指出信息在链路层没有被加密，增加了泄漏的风险。不过好在NFC的特性，导致监听的设备要求在非常相近的距离，减小了对应的风险。

3. 丢失手机的情况下，如何保护信息和防止金额丢失

现在偷盗和丢失手机是很频繁的事情，所以基于SE的手机支付都有相应的考量来保证用户的信息和资金。

3.1 首先，对于启用手机支付的情况下啊，手机会被强制要求输入密码或者指纹。他人在没有密码或者生物识别特征的情况下，是无法进入手机查看任何信息的，也无法触发手机交易。

3.2 其次，在手机丢失且联网状态下，为了万无一失。手机商往往提供了在线的网站提供移除卡片或者启用丢失模式，用户只需要登录网站，按提示操作，手机终端的卡片即会被移除或者进入丢失模式。当然，通过拨打银行客服热线，也可以实现一样的目的。

3.3 最后，在手机被切断网络的情况下。只要通过手机商网站或者银行这边进行了挂失或者移除卡片操作，即使手机没有联网，在支付网络和银行端已经将该卡的令牌进行了标记。因此，卡片也是安全的，资金不可能意外损失。

在谈下合规

目前，看到有三大主体出具了针对手机支付的一些认证和合规要求。

1. FIPS，（Federal Information Processing Standards）即（美国）联邦信息处理标准。他针对SE层面的算法、密钥、随机数发生器等有制定相应的认证要求和标准。

2. PCI，Payment Card Industry也对移动支付建立了相应的标准，着重于一些终端层面的安全指导政策。

3. 移动金融技术服务认证，这是根据国内人民银行出具的移动金融的标准而建立的一套检测和认证体系。包含了SE，SE的OS，SE上Applet，客户端，TSM等要求。

目前个人感觉，移动金融技术服务认证所引用的标准，还是很齐全的，包含了从硬件到软件的全方面审阅。以下将每个认证对应的金融标准也罗列了下，有兴趣的可以去看看具体的文档。已经公开的文档是2012年的，但是其实新的要求（讨论稿）在2017/2018年都已经出来了，预计正式的新版本也会很快发布的吧。

可信服务管理系统（TSM系统）认证依据：

JR/T 0097-2012 中国金融移动支付可信服务管理技术规范

安全单元（SE）载体认证依据：

（1）JR/T 0089.1-2012 中国金融移动支付安全单元第1部分：通用技术要求

（2）JR/T 0089.2-2012 中国金融移动支付安全单元第2部分：多应用管理规范

嵌入式应用软件认证依据：

JR/T 0095-2012 中国金融移动支付应用安全规范

安全芯片认证依据：

（1）JR/T 0089.1-2012 中国金融移动支付安全单元第1部分：通用技术要求

（2）JR/T 0089.2-2012 中国金融移动支付安全单元第2部分：多应用管理规范

（3）JR/T 0098.2-2012 中国金融移动支付检测规范第2部分：安全芯片

客户端软件认证依据：

（1）JR/T0092-2012 中国金融移动支付客户端技术要求

🤗 总结归纳

我个人使用手机支付已经有将尽3年，非常喜欢这种快速和安全的体验。可惜在国内市场上，由于用户习惯问题，以及商户的员工培训问题，经常在支持闪付的商户遇到收银员不知道如何接受闪付和云闪付（也就是手机支付）交易，从而导致手机支付的失败。更有甚者，经常是闪付/云闪付的POS机就一直没开过。

当然，除了基于SE的手机支付，别的类型支付的百花齐放，对于市场上的用户而言，始终是个好事。但由于基于SE的手机支付所知者甚少，希望这边科普性文章可以给没有使用过此类手机支付的用户一个较好的理解。大家如能够明白其中的安全意义以及便利意义，那就是极好的了。