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 之间的通信安全？
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年就会面向全行业公布。
对于 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 规范，只是什么时候会公布具体细节，目前还不得而知。
可以看到，发卡方将自己的收益的小部分让给了 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 一样安全。