基于主机的卡仿真：开发，安全和生态系统影响分析外文翻译资料

 2022-11-04 16:24:32

英语原文共 4 页，剩余内容已隐藏，支付完成后下载完整资料

基于主机的卡仿真：开发，安全和生态系统影响分析

摘要

为智能手机配备NFC（近场通信）能力，为其增加了新功能。这些功能之一就是非接触式卡仿真，其使得智能手机能够通过NFC销售点（POS）实现商业交易（例如支付，忠诚度和票务）。最初，卡仿真相关服务被唯一地托管在安全元件（如SIM）上，因此，确保了他们对安全威胁的防护。最近，Android提出了基于主机的卡仿真（HCE），使普通应用程序能够仿真非接触式卡。因此，降低了仿真非接触式卡的复杂性和费用。在本文中，我们澄明HCE的概念，并指出其历史和当前的使用。我们进一步比较HCE与基于SE的卡仿真在安全性和开发方面的问题。最后，我们讨论HCE对NFC服务生态系统的影响。

关键词：HCE，NFC，移动支付，安全

引言

近场通信（NFC）是用于非接触式短距离通信的规范[1]。主要的NFC规范在ISO / IEC 18092 [2]中定义。NFC标准化由NFC论坛（http://nfc-forum.org/）引领。NFC在未授权的13.56 MHz频率上工作，允许在长达20厘米的距离上传输数据，但通常在0-4厘米附近[3]。NFC基于射频识别（RFID），即它使用磁场感应来实现电子设备之间的通信[4]。启用NFC的设备处于开启状态; 即，其使用其功率或无源产生其射频（RF）场，即，其由有源器件供电并且使用电感耦合来传输数据。无源设备不能是NFC通信会话中的发起者。它只能响应来自接近的有源设备的请求，该设备将为其供电。 NFC比其他无线技术简便，通过碰触/接近两个NFC设备来自动启动交易。这种简易性促使将NFC集成到智能手机。NFC为智能手机的新应用和商业模式提供了机遇，例如电子票务[5]，智能海报，访问控制系统[6]，识别[7]，支付[8]。NFC应用遵循三种操作模式之一[9]：

点对点（P2P）模式：它允许在两个启用NFC的设备之间的数据传输，最高传输速率达424 Kbit/s。

读/写模式：它使NFC的设备用作标签和非接触式智能卡的读卡器/写卡器。这里，数据传输速率达到106 Kbit/s。

非接触式卡仿真：它允许支持NFC的设备仿真非接触式智能卡（或标签），该卡可以由NFC读取器读取/写入。

仿真非接触式智能卡使得支持NFC的智能手机能够进行支付，管理忠诚度和赠送程序，执行传输验证等。最初，仿真非接触式卡需要使用安全元件（SE）。 SE是诸如SIM卡的“芯片上系统”（SoC）[10]。最近，Android4.4操作系统支持基于主机的卡仿真（HCE），使普通应用程序模拟非接触式卡。据我们所知，没有分析HCE的学术工作。在本文中，我们重点描述HCE的历史，它如何工作，以及它的实际使用。 我们进一步比较基于HCE和SE的卡仿真服务在安全和开发方面的问题。这种比较有助于预测HCE对NFC服务生态系统的影响。 本文的余下部分安排如下。在第2节中，我们介绍HCE并提供有关其历史和当前利用率的详细信息。 在第3节中，我们详细介绍了HCE的开发和安全方面问题，并进一步将其与基于SE的服务进行比较。最后，我们总结了本文，并提供一些看法。

II．基于主机的卡模拟

概述

HCE允许具有NFC功能的智能手机模拟非接触式智能卡。 它包括在操作系统（OS）上实现的库和API。 这些库和API由在主机CPU上运行的普通应用程序使用（或重写）。 因此，该应用变得能够与NFC POS交换APDU（应用协议数据单元）（APDU是智能卡和智能卡读卡器之间的通信单元。 它在ISO / IEC 7816-4标准中定义。）[11]命令/响应。 HCE背后的基本思想是它独立于SE。最初，需要在SE（如SIM卡）内部安装处理APDU的应用，以使得智能手机能够安全地模拟非接触式卡。 来自NFC读取器的APDU由智能手机的NFC天线接收，然后经由NFC控制器传递到SE，反之亦然（图1）。 因此，APDU不经过智能手机的OS。 另一方面，HCE使得能够提供不使用SE的卡仿真服务。 在实践中，APDU命令经由天线，NFC控制器和OS分别被转发到在主机CPU上运行的应用（图2）。 此应用程序处理这些APDU并将响应（如果存在）发送回NFC读取器。 注意，NFC控制器负责与NFC读取器建立NFC连接[12]。

图1 基于HCE的卡仿真的NFC智能手机

图2 基于SE的卡仿真的NFC设备

HCE发展史

2012年初，SimplyTapp Inc.（https://www.simplytapp.com/）（一家美国创业公司）创建了HCE，目的是使移动支付生态系统免于依赖SE。 不是将私有信息存储在本地SE中，SimplyTapp将此数据存储在位于云中的远程安全元件中。 SimplyTapp将一个HCE补丁添加到一个定制版本的Android操作系统所谓的CyanogenMod（http://www.cyanogenmod.org/）。 黑莓是第一个公开支持HCE的智能手机。 2012年，Blackberry Blod 9900系列附带了Java SDK 7.1，其中包括能够模拟NFC卡的API。 最新版本的Android操作系统（版本4.4，也称为Kitkat）正式支持HCE。 Google还在Nexus 5的Google电子钱包实施中使用HCE。从2014年4月14日起，Google电子钱包只能在支持HCE的智能手机上使用[13]。在支付和交易服务行业的几个国际领导者（例如Actonite，Wirecard）（http://www.aconite.net ，http://www.wirecard.com）介绍和支持HCE。此外，HCE被Visa和MasterCard所接受。 2014年2月，Visa宣布扩展其“Ready Program”，以支持基于HCE的移动，支付服务，以便有关银行帐户的信息安全地存储在云中。为此，Visa致力于通过引入即所谓的“PayWave 指南，（i）用于基于HCE的支付的新标准;（ii）要求和项目批准过程;（iii）方案实施，来增强其非接触式支付应用。 在Visa公布后不久，MasterCard宣布将发布一个新规范，以利用HCE进行基于NFC的移动支付。 目标是使万事达卡的持有者能够使用其NFC支持的智能手机进行非接触式支付。 为此，万事达卡与两家银行合作：Capital One和Banco Sabadell分别负责初始和欧洲试点。

III．HCE与CE比较

在本节中，我们旨在比较非接触卡仿真的两种技术：HCE和SE。 在表1中提供了该比较的概要。

表1 基于HCE和基于SE的卡仿真之间的比较

发展问题

具有NFC功能的智能手机可以模拟几个非接触式卡， 支付，运输，忠诚度计划。 为了知道NFC读取器想要与之通信的仿真卡，NFC控制器依赖于从该读取器接收的应用标识符（AID）。 在实践中，可以处理APDU的每个应用具有AID。 NFC控制器维护将这些应用与其AID相关联的路由表。 当NFC读取器发送APDU命令时，NFC控制器将包括在该命令中的AID与路由表中的AID进行匹配。 如果存在匹配，则将该APDU发送到与匹配的AID相关联的应用。注意，此应用程序托管在SE或主机CPU上。 为了提供基于SE的卡仿真服务，服务提供商需要从SE的所有者（例如，用于SIM的移动网络运营商（MNO））获得对SE的访问。 简而言之，服务提供商在SE中购买安全域以安装服务的应用程序。 安装和内容管理操作由SE的所有者提供的加密密钥来保护[11]。这种方法的缺点是，获得安全域相对昂贵，复杂和时间长。使用HCE，卡仿真服务是在主机CPU上运行的普通应用程序。 这意味着消除了使用SE的复杂性和费用。 注意，基于HCE的服务和基于SE的服务的共存是可能的。 这种共存触发了两个重要的问题：

是否可以从外部识别基于HCE或基于SE的应用程序是否正在使用？通常，NFC读取器不能区分HCE应用和基于SE的应用。但是，可以通过发送空的SELECT命令来区分它们。 在这种情况下，基于SE的应用程序返回关于卡功能的描述，而基于HCE的应用程序返回错误。 区分它们的另一种方式是处理APDU命令的持续时间。使用基于SE的应用程序的持续时间比使用基于HCE的应用程序更长。这是由于HCE使用比SE的资源显着更重要的主机资源的事实。

是否可以直接将应用程序从SE移动到HCE？在实践中，这是不可能的，因为Android 4.4中的HCE的当前实现与全球平台（GP）（http://www.globalplatform.org/）规范不完全兼容：

当读取器发送包含不存在的AID的命令时，HCE返回错误，而对于具有GP兼容的SE，活动应用程序有机会回答此命令。

在HCE中使用SELECT命令是强制性的; 否则产生错误。

使用符合GP的SE，SELECT命令是可选的。GP兼容的SE支持多个逻辑信道（最多19个，而HCE只支持一个信道。

上述差异是与实现相关的。 因此，例如，可以通过改变SELECT命令行为并且在NFC栈中添加“默认应用”的概念来覆盖它们。 然而，仍然存在操作差异。 首先，即使智能手机处于非开启状态或没有电池电源，基于SE的应用程序也会工作。 使用基于HCE的应用程序，智能手机应该通电并处于开启状态。 其次，SE比HCE更安全，如下一节所述。

安全问题

基于SE的卡仿真服务比基于HCE的卡仿真服务更安全。 这是因为SE是基于硬件的防篡改。 因此，其内部安装的卡仿真应用程序可以防御安全威胁。 此外，SE为仿真卡的信息提供高度安全的存储位置，其是敏感的和私密的（例如，加密密钥）。 因此，保护该信息免受未经授权的访问或修改。 另一方面，基于HCE的应用程序在其他应用程序旁边的主机CPU上运行。 因此，它容易受到安全威胁，例如， 窃取敏感数据，完整性违规等。此外，可以修改来自Android操作系统域的NFC控制器的路由表。 这意味着恶意软件可能会通过恶意修改此表或甚至通过声明很多AID来使其恶化，从而导致拒绝服务（DoS）。许多与操作系统相关和基于编程的措施（如指纹，登陆密码等）可以用于保护HCE。在Android 4.4中，每个基于HCE的服务受系统权限保护，因此只有操作系统可以绑定和交换APDU与服务。但是，仍然存在篡改服务本身或提供来自恶意软件的伪造的数据的可能。为了将基于HCE的应用程序与其他应用程序隔离，应用程序Sandbox（http://developer.android.com/training/articles/security-tips.html）可用于防止未知来源提供的应用程序与其他应用程序交互或访问特定资源。但是，当智能手机root时，此安全功能会丢失。还建议将敏感数据和授权过程导出到云中的安全服务器（所谓的基于云的SE）。注意，在云中租用和管理资源比获得对SE的访问更便宜和更简单。然而，延迟或云的连接的中断导致服务的延迟或甚至中断。要覆盖此问题，标记化通常与Cloudbased一起使用。简而言之，令牌是在交易授权期间用于替换敏感数据（例如，银行卡的PAN）的交易ID或代理值。用户通常从由服务提供商控制的安全服务器下载令牌。值得一提的是，令牌存储在主机（可以将令牌存储在OS的密钥库中。 密钥库加密并由访问权限保护）上，因此它易受安全威胁的影响。然而，令牌的使用限于例如一个支付交易，特定商家和日期。因此，欺骗性使用令牌的风险是有限的。值得一提的是，基于SE和基于HCE的仿真卡服务都易受针对NFC读取器和NFC智能手机之间的NFC通信的攻击的攻击。更确切地说，攻击者可能窃听NFC通信，修改这些通信和/或破坏它们[14]。

HCE对NFC生态系统的影响

基于HCE的服务不需要修改部署的NFC POS。此外，HCE允许消除SE的依赖性。因此，HCE鼓励服务提供商在其产品中采用基于NFC的解决方案。然而，安全威胁仍然是HCE方式的重要障碍。为了更好地理解这一点，我们区分两种类型的服务：（i）接受降低的安全级别（例如忠诚度，赠与，票务）的服务，以及（ii）需要高级别安全性的服务（例如，移动支付）。对于第一种类型，开发基于SE的服务可能不是有吸引力的，因为它迫使服务提供商与SE的所有者一起工作。 HCE从这些约束中释放服务提供者。因此，将鼓励服务提供商对不需要高级别安全性的服务采用基于HCE的解决方案。关于需要高水平安全的服务，我们将考虑移动支付服务。使用纯HCE提供此类服务不被接受，因为它容易受到安全威胁。然而，使用与HCE的标记化允许提供HCE支付服务（没有SE元素NFC服务和基于云的SE NFC服务严格来说是不同的解决方案。 然而，它们有时被表示为相同的东西。）。重要的是要注意，支付服务提供商认为支付涉及欺诈和风险管理，而不是绝对的安全和身份验证。此外，提供商更喜欢在其控制下使用基于云的SE，而不是使用由另一方控制的SE。

IV．结论

HCE包括由智能手机的操作系统提供的服务和库。它允许支持NFC的智能手机通过在主机CPU上运行的应用程序来模拟非接触式智能卡。该应用与具有NFC功能的读取器交换APDU命令/答案以实现商业交易（例如，支付，票务）。智能手机可能包含几个基于HCE的应用程序。由于NFC控制器的路由，这些应用程序和基于SE的应用程序的共存是可实现的。 HCE是公开的在Android 4.4（Kitkat）操作系统。其他操作系统也将支持HCE。

预计HCE加速了支持NFC的产品/服务的引入，因为不需要使用基于HCE的服务的SE。因此，覆盖了通过获得对SE的访问而施加的复杂性和费用。然而，基于HCE的服务比基于SE的服务更容易受到安全威胁。为了保护基于HCE的服务，Android支持许多编程和实现相关的方法，例如沙盒隔离，用户和硬件验证，白

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[140463]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章