果粉必须知道：有关ApplePay的15个问题

　　Apple Pay自推出以来，由于其极佳的用户体验，很多人对其前景非常看好，但是同时也有很多人对其安全性如何非常关心，毕竟此事涉及到大家的钱包和银行账户。而 且，对于那些不使用iOS设备的用户来说，Apple Pay是否能在Android或Windows Phone系统上实现也是非常现实的问题。本文就这些大家关心的问题对Apple Pay的实现机制以及安全策略做了一个简单的分析，希望能给用户以及行业相关者提供一些参考。

　　问题1：Apple Pay是什么，包含哪些必备组件?

　　Apple Pay是Apple公司的移动支付和数字钱包产品，结合了令牌化和NFC技术，使得用户可以完成应用内(in-app)和非接(contactless) 移动支付。目前只有Apple最新一代产品(iPhone 6/6 等)对该功能有支持。不同于Apple公司更早时推出的iBeacon产品，Apple Pay不需要专用的线下非接POS终端，在现有的POS终端上就可以完成支付。Apple Pay在2014年9月份正式宣布，10月发布支持该服务的系统更新，目前仅在美国推广使用。

　　Apple Pay是一个整合了各种技术以及资源的产品，其构成比较复杂，核心组件包括：

　　Secure Element：简称SE，就是我们常说的安全元件，是防物理攻击的电子元件，其内部包含微处理器、存储以及加解密 硬件等，可独立使用(例如：芯片卡)或嵌入到其他设备中(例如：Apple Pay和Google Wallet)提供高安全服务。一般来说，SE是普通人所能接触到的最高安全保证级别的硬件/软件设备了，Apple Pay使用的即是eSE这种形式，具体来说就是Apple Pay使用的是经过工业标准认证的、运行Java卡平台(JCP，Java Card Platform)的、兼容金融行业电子交易要求的安全元件。SE是Apple Pay安全保障的核心，本质上来说，所有和Apple Pay相关的支付处理和安全保障都是由SE负责的，其他组件只是起到辅助作用。

　　NFC controller：NFC控制器，在Apple Pay的场景中，NFC控制器相当于一个路由器，它同三个不同外部实体连接：外部近场设备(例如：销售终端POS，Point-Of-Sale)、应用处 理器(AP，Application Processor)以及Secure Element，进而形成两个通信通道：应用处理器到Secure Element的通信通道，以及POS到Secure Element之间的通信通道。

　　Passbook：Passbook是在Apple Pay产品推出之前就已经存在的服务，Apple Pay推出之后，Apple对其功能进行了扩充，使得其可以为Apple Pay添加和管理信用卡以及借记卡，当然还可以查看已添加的卡的信息、银行的隐私策略以及最近交易明细等等。对Apple Pay来说，Passbook相当于Secure Element的管理客户端，Secure Element中添加和删除信用卡或借记卡信息都可以经由Passbook服务进行。

　　Touch ID：也就是iPhone的指纹识别服务，其目的在于利用指纹识别使得访问设备更安全、更快速和更容易。Touch ID不是对设备安全密码的替换，而是让用户可以使用复杂的设备密码，同时不损失便利性。换句话说，用户可以使用复杂的密码来保护设备，同时还可以 使用Touch ID来方便的访问设备。

　　Secure Enclave：Secure Enclave是iOS设备内部的安全执行环境，可以用来进行一些敏感信息的处理，例如：Touch ID的指纹成像传感器获取的数据需要传递到Secure Enclave来进行实际的指纹识别过程。对于Apple Pay来说，Secure Element负责管理认证过程和使得支付交易可以进行。

　　Apple Pay Servers：Apple Pay服务器，其用来管理Passbook中的信用卡和借记卡的状态，以及存储在Secure Element中特定于设备的账户信息。Apple Pay服务器同时同设备以及支付网络(Payment Network)中的服务器进行通信，对于应用内支付来说，Apple Pay服务器还负责使用特定于商户的密钥，对Apple Pay产生的支付凭据(Payment Credentials)进行加密，然后将其发送到实际的商户服务器进行支付处理。

　　问题2：Secure Enclave是否就是ARM TrustZone?

　　Secure Enclave是Apple A7以及后续系列的应用处理器封装在一起的协处理器，它有自己的安全引导过程和个性化的软件更新过程，并且同iOS系统所在的应用处理器分离。 Secure Enclave使用加密(使用临时产生的密钥加密)的物理内存(和应用处理器共享的物理内存的一部分空间)进行业务处理，并且有自己的硬件随机数产生器。 Secure Enclave同应用处理器之间通过中断驱动的mailbox以及共享内存来进行通信，对外提供数据保护密钥管理相关的所有密码学服务。

　　ARM TrustZone技术本质上是一种虚拟化技术，通过将处理器状态分为安全和非安全状态，并且配合其他总线以及外设上的安全属性来实现遍布整个硬件系统的 安全。同Secure Enclave一样，ARM TrustZone也有自己的安全引导过程以及个性化的软件更新过程，也有自己的硬件随机数产生器(以及其他类似的安全外设)，并且同应用处理器之间也是 通过中断驱动的Monitor模式以及共享内存来进行通信。可以看出，Secure Enclave所提供的安全特性并没有超出ARM TrustZone技术的范围。

　　不过就Apple的官方信息来说，Apple从未提过Secure Enclave就是ARM TrustZone安全扩展技术的实现(虽然根据Apple官方文档中关于几个安全通信通道的描述来看，Secure Enclave很可能是ARM TrustZone技术的一种实现)，因此我们还是无法断定Secure Enclave究竟是独立的协处理器还是应用处理器的一种运行状态(两种架构都可以提供Secure Enclave必须的安全特性)，这个有待于Apple公布更多的Secure Enclave的实现细节，就目前而言，可以得出的结论是：Secure Enclave所提供的安全特性，使用ARM TrustZone技术同样可以实现。

　　问题3：Apple Pay如何保证Secure Enclave和Touch ID之间的通信安全?

　　我们知道Touch ID成像阵列获取的指纹数据需要交由Secure Enclave进行实际的匹配处理，而在Apple Pay的实现中，Touch ID传感器通过串行外设接口总线(Serial Peripheral Interface Bus)同应用处理器进行连接，然后再连接到Secure Enclave，换句话说，指纹传感器获取的指纹成像数据需要经由应用处理器中转，这就带来了安全隐患：恶意程序可以截获Touch ID传感器产生的数据。Apple Pay通过简单的方式实现了指纹数据的安全传输，首先Touch ID传感器和Secure Enclave会预置一个共享密钥，然后利用该共享密钥协商一个会话密钥，再用协商获得的会话密钥使用AES-CCM算法对传输的数据进行加密，这样可以 确保应用处理器无法读取指纹数据，保证了整个指纹识别过程的安全。

　　问题4：Apple Pay如何保证Secure Enclave和Secure Element之间的通信安全?

　　前面介绍NFC控制器的时候已经提到，Secure Enclave和Secure Element之间的物理通信通道需要经过NFC控制器中转，而两者之间是没有直接的物理连接的，具体就是Secure Element同NFC控制器连接，然后NFC控制器同应用处理器连接，而没有提到NFC控制器如何同Secure Enclave连接(Apple的官方文档如此说，这里可以看出Secure Enclave很有可能不是一个独立的协处理器)，那么既然Secure Element和Secure Enclave之间需要经由应用处理器中转，那么也就必须要考虑到通信安全问题。

　　实现方式同Touch ID和Secure Enclave通信的过程类似，也是通过共享配对密钥的方式来对通信内容加密，不过因为涉及到了Secure Element，所以共享配对密钥的预置比较复杂一些，具体就是：共享配对密钥是在生产阶段预置的，而且该密钥由Secure Enclave利用自己的UID密钥和Secure Element的唯一标识作为输入产生，然后在工厂内安全的传输到外部硬件安全模块(HSM，Hardware Security Module)，再注入到Secure Element中。实际使用过程中，Secure Element和Secure Enclave之间的通信使用基于AES的密码学算法进行加密，而且还使用了密码学机制防止重放攻击(replay attacks)。

　　问题5：Apple Pay如何保证Secure Element和POS之间的通信安全?

　　严格来说，传统意义上Secure Element和POS终端之间的通信是不需要保证安全的，因为两者必须靠近才能发生通信，实际上相当于认证了人和卡的存在。而对于Apple Pay来说，由于应用处理器也会参与其中的某些步骤，因此情况稍微有些复杂，Apple Pay需要有3个附加的保障机制来确保非接触式交易的安全。

　　首先，Apple Pay确保只有经过用户的授权，例如：通过了指纹识别或输入了设备密码，非接触式交易才可能发生，否则装备了Apple Pay的设备只要处于RF通信场中，就可能在用户无意识的情况下发生交易。其次，Apple Pay必须确保只有来自外部非接触式POS终端的支付请求才能被标识为非接触式交易，这主要和交易费率相关(后面会对其进行说明)，通过外部非接通信方式 进行的Apple Pay交易同应用内的Apple Pay交易费率是不同的。最后，如前面所说，非接触式支付的通信是不加密的，因此Apple Pay通过NFC控制器的卡模拟模式确保非接通信通道交互的数据无论如何不会暴露给应用处理器。

　　问题6：Apple Pay如何避免对支付交易回放攻击?

　　Apple Pay避免支付交易回放攻击的方法是特定于交易的动态安全码(Dynamic Security Code)。所有自Secure Element中的支付applet发起的交易都包含一个附带有特定于交易的动态安全码的设备帐号(Device Account Number)信息。动态安全码是一次性的，并且使用Secure Element中的支付Applet在个人化时预置的密钥(该支付Applet和发卡行共享)以及其他信息进行计算所得，这些信息包括：

　　-- 每次交易都会增加的单向计数器的值;

　　-- 支付Applet产生的随机数;

　　-- POS终端产生的随机数——NFC交易时适用;

　　-- Apple Pay服务器产生的随机数——应用内交易时适用。

　　动态安全码在交易时被提供给支付网络(Payment Network)和发卡行，可用来对交易进行校验。根据交易类型的不同，动态安全码的长度是可变的。不过，虽然使用了动态安全码进行保护，Apple Pay在正式推出后的确发生了重复交易的问题，目前还不能判断是因为何种原因导致了重复交易的问题。

　　问题7：Apple Pay如何控制支付功能的激活?

　　Secure Element只在收到来自Secure Enclave的授权信息后才会允许支付交易进行。Apple Pay的Secure Element内有一个特别设计的、专门用来管理Apple Pay的Applet，支付交易是否可以进行即是由该Applet进行控制。

　　当用户授权一个交易后，Secure Enclave签发一个有关认证方式和交易类型(非接触式交易或应用内交易)的数据，然后绑定授权随机数(AR，Authorization Random)给Secure Element。授权随机数AR是用户第一次部署信用卡的时候在Secure Enclave内部产生、并且使用Secure Enclave的加密和防回滚攻击(Anti-rollback)存储机制保存。当AR产生后，Secure Element利用同Secure Element之间共享的配对密钥将其安全的分发给Secure Element。授权随机数还有其他用处，一旦接收到新的AR值，Secure Element就将所有已添加的卡删除，这个机制可以用来擦除预置的卡信息。

　　问题8：Secure Enclave中运行何种操作系统?

　　Apple Pay的Secure Enclave需要能处理Touch ID产生的指纹识别数据，安全存储敏感信息、还需要具备对称、非对称等密码学计算等能力，其功能已经比较复杂，我们都知道越精简的系统越容易保证其安全， 而越庞大的系统越不容易。Secure Enclave系统已经比较复杂，因此其上运行的操作系统是何种类型是我们要关注的。从Apple 的官方文档可知，Secure Enclave运行的是一个L4家族的微内核操作系统，当然Apple对其进行了一些定制。

　　L4微内核操作系统是一个操作系统家族，微内核操作系统是一种操作系统的设计风格，目的在于将操作系统内核尽可能的小，使系统架构简单，为了保证 系统资源的安全性，微内核操作系统特别强调对内核资源的访问控制，通过诸如能力集管理等机制，控制系统内所有资源的访问，因此很适合安全领域应 用。

　　问题9：Secure Enclave中是否运行一个GP TEE?

　　GlobalPlatform(简称GP) TEE(Trusted Execution Environment)，是国际标准组织GP，在分析了移动安全需求场景以及现有硬件安全技术的基础上，制定的可信执行环境标准。TEE在移动设备的安 全执行环境(例如ARM TrustZone)中执行，是与设备上的Rich OS(例如Android等)隔离的运行环境，并且可以给Rich OS提供安全服务。GP TEE是一系列规范的总称，目前正式发布的主要有：Client API规范：用于Rich OS访问TEE、Internal Core规范：TEE的内部接口以及可信应用(Trusted Application)模型定义、可信用户界面规范(TUI，Trusted User Interface)：用于安全的给用户呈现用户界面，防止钓鱼等形式的攻击。由于其符合市场需求，因此GP TEE是目前热门安全技术标准。

　　通过上述GP TEE的介绍可以看出，Secure Enclave所对外提供的功能同GP TEE很相似，但是目前没有任何信息表明Secure Element中运行的是GP TEE兼容的实现。不过，随着Apple作为GP组织的Full member加入到该组织中，以及要求Secure Enclave给iOS开放更多的安全功能的呼声越来越高，可以预想，Apple实现完整的GP TEE规范是指日可待的事情。

　　值得一提的是，GP TEE标准一经推出，就获得了国内相关金融安全组织和机构的重视。目前国内对该标准的研究已经经过多年的发展，对GP TEE不利于本地化和行业合作的缺点已经进行了充分的分析，并启动了国内标准(例如：中国银联的TEEI和N3TEE规范)的制定工作，目前相关标准已经 基本成熟，预计2015年就会面向全行业公布。

　　问题10：何为Apple Pay的有卡和无卡模式?

　　有卡模式(Card-present)和无卡模式(Card-not-present)是支付卡交易的两种模式，其中无卡模式是指在进行支付交易 时，持卡人没有或不能通过物理的方式出示卡片给商户，因而商户无法通过可视的方式检查持卡人的交易方式，一般来说通过电子邮件、电话、传真或互联 网等方式进行交易的场景就属于无卡模式。有卡模式与此相反，即持卡人必须物理的将卡片呈现给商户进行交易的方式。无卡模式由于持卡人不直接出现， 很容易通过卡片复制(特别是磁条卡)的方式进行欺诈交易，风险要高于有卡模式，因而两种的交易费率是不同的。

　　对于Apple Pay来说，通过NFC和POS之间非接通信通道进行的交易被视作有卡模式，而同Apple早前推出的iBeacon支付类似，Apple Pay的应用内支付被视作无卡模式。不过，就我们的分析而言，无论是Apple Pay的NFC非接触式交易还是应用内支付，交易都是从Secure Element中发起，且用户都需要使用Touch ID或密码的方式进行授权才能进行交易，而且，由于Apple使用的是EMVCo的令牌化方案，因此整个交易过程中都不会有真正的PAN(Primary Account Number)出现，因此将Apple Pay的应用内支付视为无卡模式是很难理解的，或许未来所有的Apple Pay交易都被视为有卡模式也是可能的。

　　问题11：Secure Element中的支付Applet是如何个人化的?

　　向Apple Pay中添加信用卡或借记卡的过程其实就是支付Applet个人化的过程，Apple Pay主要使用两个服务器端调用(同银行或卡发行商)来进行个人化的处理：卡片信息检查(Check Card)、连接&预置(Link and Provision)来验证、承认将要添加到Apple Pay的卡信息，并且预置卡信息到Apple Pay设备中。目前用户有两种实施该流程的方法：通过Passbook和通过iTunes。通过iTunes的方式因为有些支付卡或借记卡的信息输入和用 户身份校验可以自动进行，因此较为简单，不过，无论哪一种方式都涉及到卡片信息录入、用户身份校验、Apple Pay许可条款承认以及将卡片信息同Secure Element绑定的过程。

　　Apple Pay的核心组件Secure Element是GP卡规范兼容的Java卡，其中可包含多个对应不同发卡行或支付网络实体的安全域(Security Domain)，这些安全域同对应的管理方共享用于验证管理方身份和安全通信的密钥。来自发卡行或支付网络的个人化数据，使用这些共享密钥进行加密，可以 安全的被分发到对应的安全域中，由此即可完成支付Applet的个人化过程，这和传统支付卡的个人化过程比较类似。

　　对于那些在Secure Element中还不存在的支付Applet是如何进行部署的，目前还没有较为详细的介绍资料，Apple官方文档中对其有过简单的描述，但是由于信息太 少目前还无法进行更进一步的分析，目前只能判断新安装的支付Applet是通过OTA方式部署的。

　　问题12：Apple Pay是否兼容EMVCo Tokenisation规范?

　　我们得承认，虽然几乎所有的国外或国内的分析文章都在有意无意的提到Apple Pay实现了EMVCo的规范，但是到目前为止，没有任何Apple或EMVCo的官方资料提到Apple Pay实现了EMVCo的Tokenisation规范，那么这种论断是否令人信服呢?

　　EMVCo的Tokenisation规范是2014年3月推出的(该技术框架起初由Visa、MasterCard和AmEx推出，后考虑到行 业合作的问题遂移交给EMVCo负责)，其特点是：以令牌(令牌的格式基本同现有PAN格式相同，可以在传递PAN的地方使用令牌)来替代 PAN、同现有支付行业的报文格式以及业务流程基本兼容、并引入了新的角色：令牌服务提供商(TSP，Token Service Provider)和令牌请求者(Token Requester)，其中令牌请求者是那些发起请求将用户的PAN映射为令牌的实体，而TSP则是提供此项映射服务的实体。另外，在一些应用场景，例 如：通过NFC设备在POS上支付(类似于Apple Pay的非接触式支付)，移动钱包/电子钱包的电子商务支付(类似于Apple Pay的应用内支付)两种场景，EMVCo的规范要求提供Token Cryptogram来保证交易的安全。不难看出，EMVCo的规范目的在于减少欺诈行为、以及降低新技术对现有支付行业生态圈的影响。

　　而添加卡到Apple Pay的过程非常类似于EMVCo的请求令牌的过程，此时Apple扮演了“令牌请求者”的角色(EMVCo的规范明确提到，使得移动支付可以进行的设备 制造商是令牌请求者的主要类别之一)，银行或支付网络扮演了令牌服务提供商的角色。另外，为Apple Pay交易提供基础安全保障的动态安全码，同EMVCo规范的Token Cryptogram产生方法以及使用方式也是非常相似的。再联想到Visa和MasterCard在Apple Pay推出后纷纷公开自己的令牌化服务，我们有理由相信，Apple Pay实际上是实现了EMVCo的Tokenisation规范，只是什么时候会公布具体细节，目前还不得而知。

　　问题13：Apple如何利用Apple Pay盈利?

　　我们知道，传统的卡片支付采用的是6-3-1或7-2-1的分成模式，其中发卡行获得最多的份额，结算机构收取最小的份额，而收单行获取中间大小 的份额。Apple Pay为移动支付提供了一个新的通道，因此里所应当，Apple会从整个蛋糕中分得一小块。从目前公开的信息来看，Apple Pay分得的份额是来自发卡行的那块蛋糕，具体就是对于信用卡交易，Apple每次收取交易金额的0.15%，而对于借记卡交易，Apple收取固定收 益，即每次交易收取0.5美分。

　　可以看到，发卡方将自己的收益的小部分让给了Apple，不过没人愿意将自己的蛋糕轻易分给别人，有消息显示，令牌服务提供商 (TSP，Token Service Provider)发行令牌时，发卡行需要给Visa和MasterCard这样的TSP支付费用，例如：每发行一个令牌，MasterCard收取50 美分，而Visa收取7美分。最近有消息显示，Visa为了促进令牌交易模式的发展，已经准备免除发行令牌的费用了。

　　虽然看起来Apple Pay分得的份额很少，不过移动支付是非常庞大的市场，而且还在快速发展中。根据央行消息，2014年第三季度国内支付业务统计数据显示，第三季度移动支 付业务12.84亿笔，金额6.16万亿元，同比分别增长157.81%和112.70%，发展势头非常好。如果将Apple Pay的分成模式放在国内市场，可以看到整个智能设备行业将会因此额外获得巨额收益，这会极大的促进移动支付技术的发展。

　　问题14：Apple Pay是否足够安全?

　　Apple Pay主要的支付流程处理是在Secure Element中进行，其安全程度基本等同于现有的基于芯片卡的支付，而用于激活Apple Pay交易的用户身份认证过程是在Secure Enclave中进行，一般来说，Secure Enclave虽然没有Secure Element安全，但是对于认证手机用户的身份来说已经足够了，毕竟传统的有卡交易也只是对持卡人进行简单认证(例如检查签名)。如果交易金额较 大，Apple Pay也需要用户在商户的专用设备输入PIN(Personal Identification Number)进行认证(这和传统芯片卡交易完全一致)，显然，我们可以很容易得出结论：Apple Pay是非常安全的，否则也不会有这么多金融机构和支付机构为其摇旗呐喊了。

　　问题15：“Android Pay”是否可以做到同Apple Pay一样安全?

　　现在终于到了很多人都关心的问题了： “Android Pay”是否可以做到同Apple Pay一样安全?基于我们先前的分析，这个问题是不难回答的：在整个Apple Pay的支付过程中，主要的支付数据处理全部在Secure Element内进行，而激活支付流程的处理是在Secure Enclave中进行，iOS手机操作系统仅在某些数据传输过程中才参与其中，而且由于经由其传输的数据(指纹数据和认证结果数据)都经过加密，手机操作 系统对传输数据内容一无所知，因此，手机操作系统本身的安全性对整个Apple Pay的安全性很难构成威胁，无论对iOS系统还是Android系统，或是其他系统来说都是如此。因此我们可以得出结论：只要手机操作系统控制范围以外 的硬件和软件系统遵循必要的安全原则设计，“Android Pay”可以做到同Apple Pay一样安全。