为移动设备设计和证明一个符合EMV协议的支付协议一

原文链接：https://members.loria.fr/VCortier/files/Papers/euroSP17.pdf

首先说明了目前大多数支付协议存在的问题：它们通常假设主机是安全的。例如，将密钥存储在信用卡里是很难提取出来的，但是对于移动设备提取密钥却不是不可能的。因此，论文中提出了一个支付协议，保证了设备在处于低安全或安装了恶意软件的情况下的支付安全，能够抵抗篡改和克隆。本文所说的移动设备为智能手机、平板电脑甚至是最近的物联网设备(比如智能手表)，这些设备都可以承载SE。

随后，文章介绍了能够抵抗恶意应用支付协议的两大主流趋势。第一个趋势是SE（Secure Elements）的使用。SE是一个防篡改平台（如SIM卡），由软、硬件组成，能够存储可信数据，提供一个安全的应用执行环境。SE不能被单独使用，因为它不能控制设备屏幕，所以没有安全的用户输入接口。因此，需要一个可信的用户接口（TUI）为用户终端到SE提供可信路径。SE的激活通常是在用户对自己进行身份验证之后完成的(例如：通过一个TUI输入一个PIN或一个指纹)。SE的优势在于它的简单性，利用已有的完整的解决办法就可以实现。然而，SE存在成本高，以及内存大小限制等问题。

SE的相关连接：

另一个主流趋势是HCE（Host Card Emulation），它摒除了SE基于设备的特性，提供了一个完整的软件应用。目前两种主要选择可以在市场上观察到。一种HCE应用程序将敏感的操作放置(即: 由SE执行)在云上，这个方法的缺点就是，用户需要连接到云上。另一些基于HCE的应用依赖于白盒密码、混淆应用程序密钥和本身应用中的密码操作。这种方法的第一个问题是用户的设置(或注册):它是很难在手机与支付服务之间预先分享个人密钥。另一个主要的问题是使用白盒加密技术本身。所有白盒设计的加密原语的当前解决方案都被能够打破，因此是不安全的。

本文提出的移动平台的支付协议具有如下特点：

1.完全兼容EMV-静态数据验证(emv-sda)协议。

2.支持离线支付。

3.抵抗恶意应用。

4.基于SE特性。

5.短暂的主帐号。在与标准的EMV相比，其解决方案使用了短暂的PANs（Primary Account Numbers），也被称为令牌tokens。由于这些令牌，该协议对经典的emv-sda提供保护重放攻击从而提高了EMV的安全性，不需要修改核心协议。

协议描述：

术语：

 - CH: Cardholder （持卡人）

我们假设 CH是一个拥有身份值IDval的用户，他是唯一的一个知道或能够提供该值的人。这个值它可以是一个PIN码，一种生物特征指纹、一种方案或任何其他移动设备支持的身份识别方法。

- MA: Mobile Application （移动应用）：

智能手机、平板电脑甚至是最近的物联网设备(比如智能手表)。 MA主要持有用户的令牌请求者身份(TR_ID)，把CH注册到TSP，一个TSP 公钥(pk_TSP)——用于令牌请求过程的非对称密钥的公钥，还有一个签名验证(spkTSP)用于令牌接收和付款流程。

- NFC: Near Field Communicatio

- PIN: Personal Identification Num

- POS: Point of Sale

它可以是一个物理终端，也可以是一个互联网平台付款。

- SDA: Static Data Authentication

- SE: Secure Element

- TE: Trusted Enclave ：

所谓的Trusted Enclave(TE)实际上是在现实中目前两种安全工具的结合：信任的执行环境(TEE)和安全元素(SE)，嵌入在大部分智能手机中。用户标识IDval将经过受信任的用户接口（TEE）处理，因此IDval不能从主操作系统中偷出来。IDval只能让TE知道。SE正如前面所说它是基于设备的，这个设备可以是SIM卡，嵌入式SIM卡、安全sd卡或嵌入式安全元素。它存放了两个用于身份识别的对称密钥，一个用于令牌准备(K_ID) 另一个用于支付(K_Pay)，还有一个计数器(C_CH) 用于防止重放攻击。

- TEE: Trusted Execution Environ （可信执行环境）

- TSP: Token Service Provider （令牌服务提供者）

令牌服务提供者(TSP)负责令牌生成供应、支付验证和令牌的管理与存储。为了实现这些任务，TSP持有对称密匙(K_ID K_Pay)与持卡人的TR_ID以及三个相关计数器(CTSP，CTok和CPay)。TSP也拥有EMVCo所要求的用于签名和加密的私钥(sskTSP和 skTSP)，它的签名密钥是经认证机构认证的({spkTSP}sskCA)。

原EMV卡静态数据认证过程：

本文的协议对该过程并没有进行过多的改动，只是增加了令牌服务提供者Token Service Provider（TSP）的参与。下面对令牌服务提供者（TSP）进行详细的介绍。

TSP确保了一个暂时性令牌被正确地转换为用户的真正的PAN到发行商。本文不考虑用户注册部分，假设用户利用他的TRID(令牌请求者标识符，用于客户注册TSP)已经注册了TSP，并且他的移动设备已经持有正确对称密匙，在每个请求中设备从TSP接收到的令牌已经稳定了。

下图是令牌配置过程。

首先持卡者先利用IDval认证他自己，认证过后移动应用才授权访问SE来请求H_ID（计算方式见图）。然后移动应用利用pkTSP公钥加密发送令牌请求M_tok = aenc(< TRID, CCH, HID >, pkTSP)到TSP。

TSP解密后，核对计数器的值，核对HID值等。验证成功后，TSP生成k个令牌tokens ti并且计算k个令牌的EMV支付包：EMVi :={TRID, ti, Data}_sskTSP。这些数据表示一个厂商需要验证一个事务的额外数据。根据EMVCo规范的支付协议要求，这些支付包是由认证的TSP签名的。

每一个EMV包是可随时使用的支付值，并被存储到主操作系统。TSP会用对称加密密码加密它们。对于每一个令牌化的EMV包，TSP生成一个新鲜的nonce(si)，它将被用于支付由SE和TSP生成对称密钥。这个密钥将用于加密一个令牌包: ki = MAC(KPay si)。每一个生成的令牌支付包EMVi也与一个计数器ci相关，TSP然后将与TRID相关的集合< EMVi, si, ci >: TRID →(i=1至k)< EMVi, si, ci >存储起来，然后将令牌返回给移动应用：Tres={TRID, (i=1至k)<ciphTi, si > }_sskTSP ，每个加密的令牌(ciphTi)都是与其相应的特定nonce一起传输。