apple pay 支付 java 流程图 apple pay for

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

问题1：ApplePay是什么，包含哪些必备组件？

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

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

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

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

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

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

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

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

问题2：SecureEnclave是否就是ARMTrustZone？

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

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

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

问题3：ApplePay如何保证SecureEnclave和TouchID之间的通信安全？

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

问题4：ApplePay如何保证SecureEnclave和SecureElement之间的通信安全？

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

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

问题5：ApplePay如何保证SecureElement和POS之间的通信安全？

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

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

问题6：ApplePay如何避免对支付交易回放攻击？

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

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

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

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

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

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

问题7：ApplePay如何控制支付功能的激活？

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

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

问题8：SecureEnclave中运行何种操作系统？

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

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

问题9：SecureEnclave中是否运行一个GPTEE？

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

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

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

问题10：何为ApplePay的有卡和无卡模式？

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

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

问题11：SecureElement中的支付Applet是如何个人化的？

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

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

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

问题12：ApplePay是否兼容EMVCoTokenisation规范？

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

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

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

问题13：Apple如何利用ApplePay盈利？

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

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

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

问题14：ApplePay是否足够安全？

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

问题15：“AndroidPay”是否可以做到同ApplePay一样安全？

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