15个有关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 A 7以及后续系列的应用处理器封装在一起的协处理器，它有自己的安全引导过程和个性化的软件更新过程，并且同 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 运行的是一个 L 4家族的微内核操作系统，当然 Apple 对其进行了一些定制。

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

问题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 和 N 3 TEE 规范）的制定工作，目前相关标准已经 基本成熟，预计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 一样安全。