在线支付系统可信通道建立（OP-TEE侧实现）

整理下网上的在线支付其中一种实现方式。通过学习、消化，可借鉴到自己项目重要数据的交互使用。

1 在线支付的模式

在线支付分三块：支付终端、支付服务商服务器（支付宝、微信）、银行。

支付终端：如手机、pos机，这些设备通过密码、指纹、面部识别等获取验证，我们得op-tee就是在终端使用；

支付服务商：如支付宝，你通过终端使用支付宝进行交易。这里可以理解为我们公司内部得服务器。

银行：这些最终还需要通过银行进行交易。如何确保支付凭据安全且可信的发送到服务器端并被服务器验证通过就尤为重要。本文将简要介绍在线支付系统中，终端设备中的TEE是如何确保数据安全且可信地被支付系统的服务器端使用。

2 在线支付的框架

在线支付系统的支付凭据是由终端产生，该支付凭据包含了产生支付操作所需要的所有信息，支付凭据的组包和加密都是由TEE内核或者运行于TEE中的TA来完成的，至于采取何种方式则需要支付厂商与终端设备厂商协商解决。

公司内部的通信、加密采取什么加密协议，肯定是公司内部协商。可根据该框架进行修改，学习的这个加密框架是可以用的，或者改进的。

一个简单的在线支付系统的大致框架如下图所示

在整篇文章中我们不考虑银行端的问题。从终端的角度出发。

终端和服务器之间的重要数据交互问题，首先要搭建一个交互框架、数据的组包和加密都在tee中进行与ree操作进行隔离开来。根据是否在终端设备中预置了密钥，在TEE中完成终端设备与支付系统服务器端之间交互数据的组包和加密可大致分为预置密钥的组包方式和未预置密钥的组包方式。

在线支付系统的服务器端与银行之间的数据交互协议是由支付厂商与银行之间制定的，而支付系统的服务器端与终端设备之间的数据交互协议则是由支付服务提供商自行定义。一般情况下支付系统提供商会为终端设备提供从应用层到系统层面的支付应用程序、库文件和可执行文件，这些软件能够搭建一个完整的支付请求交互通道。终端设备普遍支持TEE，支付厂商可将数据的组包操作和加密操作都放到TEE中来完成，这样可将交互数据的组包和加密部分与REE侧的系统相互隔离。

3 可信通道

可信通信通道是指设备终端与支付服务器之间的通信链路是安全可信的，即设备终端发出去的支付相关数据只有支付服务器才能正确地解析。

在确定可信通信通道之前，设备终端与服务器端需要经过三次握手来协商通信时使用的加密密钥。设备终端向服务器第一次发送握手请求时会生成一个随机数A，服务器端会认证该请求的可信性，如果认证通过，服务器会生成一个随机数B，然后将该随机数发送给设备终端。设备终端获取到来自服务器的返回数据之后会进行一系列的可信认证，待认证通过之后会生成一个随机数C，并将该随机数发送给服务器完成整个握手操作。然后客户端和服务器端使用相同的算法结合上述三个随机数生成两者之间进行数据通信的加密密钥。

为防止中间人攻击，在终端设备和服务器建立可信通信通道时，终端设备和服务器需要具有数据的唯一性和可信鉴定机制。这一点可通过在设备生产时提前将认证密钥预置到设备中或在应用程序安装或注册时分发密钥到设备来实现。为确保终端设备与服务器之间的相互隐私，这组密钥一般使用的是非堆成算法密钥，其中私钥保存在终端设备中，而公钥则由服务器来保存。在线支付程序安装或者注册时，支付服务器可给设备下发一对RSA密钥的公钥，该公钥最终会被保存到OP-TEE中。在建立可信通信信道时，终端设备可用该公钥加密握手数据请求。

4 数据交互协议

数据交互协议是指终端设备与支付服务器之间进行数据交互时双方发送的数据需按照一定的格式进行组合。组合的数据需要包含数据的用途、内容、发送方、数字签名，且以密文的形式进行传输。

示例中，数据交互协议的内容包括数据头部区域、数据区域、电子签名区域。数据头部区域和数据区域的内容在发送之前需要使用密码学算法进行处理，以便数据在传输过程中都是以密文的形式存在。

5 交互示例

终端与服务器需通过三次握手确认，建立可信通信通道。设备端和服务器分别把自己存的私钥对应的公钥发送给对方，用于加密数据。每次握手操作的握手数据包中都会包含一个随机数，待握手操作完成后，支付服务器和终端设备会使用握手过程中的三个随机数使用PBKDF2算法生成后期设备终端与支付服务器之间进行数据交互时使用的AES加密密钥。

在第一次握手时会使用到RSA的公钥对数据包进行加密。该密钥可通过在线下发的方式，在安装或注册支付应用程序时下发给终端设备。

第二次握手时使用的RSA公钥即可在第一次握手请求时告知服务器端，亦可在终端设备生产时提前将该RSA私钥预置到设备中，同时将RSA公钥告知服务器。关于设备终端的RSA密钥对可在使用时调用OP-TEE的接口产生亦可提前生成好然后预置到设备中。

5.1 第一次握手请求

在支付应用程序安装到终端设备或者用户登录时（经常用pos机刷信用卡的同志可能会注意到，开机的时候他会下载一个密钥，猜测这个密钥就是加密的公钥），服务器会向终端设备下发一把RSA公钥。为方便后续说明，将该RSA公钥称为RSA_PUBLIC_SERVER。终端设备发起第一次握手请求时，在TA中就会使用该公钥加密握手请求数据，按照通信协议规定，第一次握手请求的明文数据内容如图所示。

5.2 第二次握手数据的解析

第一次握手请求时，设备终端会将一把RSA的公钥RSA_PUBLIC_CLIENT打包到握手请求数据包中，服务器接收到数据包后使用对应的RSA私钥解密开数据包，然后解析获取到设备终端的RSA公钥，该公钥会被用于加密第二次握手数据。第二次握手数据是由服务器端组包完成的。该数据的明文内容如图所示

第二次握手数据明文组包完成后会使用RSA_PUBLIC_CLIENT进行加密，最后使用服务器的RSA私钥对密文数据进行RSA电子签名操作，第二组数据包中的数据区域中会包含第二个随机数B。终端设备接收到该数据后会调用CA接口，将数据包发送给TA，然后TA按照协议内容对数据包进行电子签名验证、数据解析、数据验证，最终获取到第二个随机数B，并将该随机数保存到OP-TEE中。

5.3 第三次握手请求

第三次握手请求会将第三个随机数C发送给服务器端，按照协议内容组包的第三次明文数据内容如图所示。

第三次握手请求使用设备终端的RSA私钥进行签名，其中会包含第三个随机数C。明文数据会使用RSA_PUBLIC_SERVER进行加密。

待数据组包完成之后，TA会使用获取和生成的三个随机数A、B、C使用PBKDF2算法生成数据交互使用的AES密钥，并将最终生成的AES密钥保存在OP-TEE中。待此操作完成后，TA会将第三次握手请求数据包返回给CA, CA以网络通信的方式将数据发送给服务器端。待服务器端接收到第三次握手请求后，服务器同样也会使用PBKDF2算法节后三个随机数生成AES密钥并保存起来，用于后续数据交互时明文数据的加密操作。到此终端设备与服务器端之间可信通信信道已经建立。

5.4 支付请求

支付请求命令会生成一个通知支付服务器与银行产生清算操作的支付凭据的数据包。该数据包使用握手时生成的AES密钥进行加密，然后使用设备终端的RSA私钥进行电子签名，以确保数据包的完整性和唯一性。支付请求的数据包内容示意图如图所示。

支付请求时设备终端发送给支付服务器的支付凭据，在组包之前需要被发起支付请求的操作者进行相关的身份验证，例如支付密码、指纹验证、短信验证等方式。待身份验证通过后，CA会向OP-TEE发送该命令，让TA生成合法的支付请求数据包。明文支付请求数据会使用握手时生成的AES密钥进行加密，服务器接收到该数据包后会对数据包进行电子签名验证、解密、解析、支付请求合法性验证等操作。

5.5 支付反馈

支付请求完成之后，服务器端会向设备终端发送支付反馈数据包，该数据包包含直接结果和其他相关的信息，用于将最终的支付结果反馈给用户。该数据包的内容示意图如图所示。

设备终端接收到支付反馈数据包后会通过调用CA将该数据发送给TA, TA接收到数据后会对数据包进行电子签名验证、AES解密、合法性验证，然后解析出支付结果，并将最终的支付结果信息返回给CA。支付应用可从CA的返回数据中获取支付结果并显示给用户。

6 项目借鉴

这套支付系统的设备终端与支付服务商服务器的通信非常值得借鉴。可移植到项目设备与公司内服务器间的可信通信。通过RSA对通信数据防偷窥进行加密（传递信息的安全性），通过RSA对传递信息进行签名和验签（传递信息的完整性）。使用三次握手的随机数，通过PBKDF2算法产生密钥，通过AES-CBC对支付信息（或者项目中需传递的信息）进行加密。