到了我最喜歡的環節了，我其實學習的過程中，對這些應用場景概念是十分的感興趣的。

下面一起看看老師這本書的最后的一個部分應用篇—在線支付系統

內容來自《手機安全和可信應用開發指南》

1、簡介

基于安全考慮，支付系統的最終結算由支付服務提供商與銀行完成支付結算，而終端設備只為支付系統的服務器提供支付憑據，讓支付系統的服務器端觸發支付操作完成與銀行間的賬務清算。

而終端設備的支付憑據就在整個在線支付過程中起到了至關重要的作用。如何確保支付憑據安全且可信的發送到服務器端并被服務器驗證通過就尤為重要。

本章將簡要介紹在線支付系統中，終端設備中的TEE是如何確保數據安全且可信地被支付系統的服務器端使用。

（原來支付的結算不是終端，而是服務提供商與銀行，那支付寶、微信都是服務提供商，難怪要收利息）

2、在線支付系統的基本框架

在線支付系統的支付憑據是由終端產生，該支付憑據包含了產生支付操作所需要的所有信息，支付憑據的組包和加密都是由TEE內核或者運行于TEE中的TA來完成的，至于采取何種方式則需要支付廠商與終端設備廠商協商解決。

一個簡單的在線支付系統的大致框架如圖24-1所示。（銀行端太多了，微信支付寶把銀行端統一了，要是有天銀行統一推出支付手段，現在的云閃付，那支付寶有點危險啊，不過習慣這個玩意很難去改。微信也難以割舍。所以說前期的推廣，后期習慣了以后就進入了收割期）

在線支付系統的服務器端與銀行之間的數據交互協議是由支付廠商與銀行之間制定的，而支付系統的服務器端與終端設備之間的數據交互協議則是由支付服務提供商自行定義。

一般情況下支付系統提供商會為終端設備提供從應用層到系統層面的支付應用程序、庫文件和可執行文件，這些軟件能夠搭建一個完整的支付請求交互通道。

終端設備普遍支持TEE，**支付廠商可將數據的組包操作和加密操作都放到TEE中來完成，**這樣可將交互數據的組包和加密部分與REE側的系統相互隔離。

根據是否在終端設備中預置了密鑰在TEE中完成終端設備與支付系統服務器端之間交互數據的組包和加密可大致分為預置密鑰的組包方式和未預置密鑰的組包方式。

3、可信通信通道

可信通信通道是指設備終端與支付服務器之間的通信鏈路是安全可信的，即設備終端發出去的支付相關數據只有支付服務器才能正確地解析。

可信通信通道的建立可以仿照SSL協議來進行建立，SSL協議主要用于網絡通信，通過設備終端與支付服務器之間的握手通信來建立兩者之間進行密文通信使用的加密密鑰。圖24-2所示為SLL通信協議的簡圖。

在確定可信通信通道之前，設備終端與服務器端需要經過三次握手來協商通信時使用的加密密鑰。

設備終端向服務器第一次發送握手請求時會生成一個隨機數A，服務器端會認證該請求的可信性，如果認證通過，服務器會生成一個隨機數B，然后將該隨機數發送給設備終端。

設備終端獲取到來自服務器的返回數據之后會進行一系列的可信認證，待認證通過之后會生成一個隨機數C，并將該隨機數發送給服務器完成整個握手操作。然后客戶端和服務器端使用相同的算法結合上述三個隨機數生成兩者之間進行數據通信的加密密鑰。

為防止中間人攻擊，在終端設備和服務器建立可信通信通道時，終端設備和服務器需要具有數據的唯一性和可信鑒定機制。這一點可通過在設備生產時提前將認證密鑰預置到設備中或在應用程序安裝或注冊時分發密鑰到設備來實現。

為確保終端設備與服務器之間的相互隱私，這組密鑰一般使用的是非對成算法密鑰，其中私鑰保存在終端設備中，而公鑰則由服務器來保存。

在線支付程序安裝或者注冊時，支付服務器可給設備下發一對RSA密鑰的公鑰，該公鑰最終會被保存到OP-TEE中。在建立可信通信信道時，終端設備可用該公鑰加密握手數據請求。

4、數據交互協議

數據交互協議是指終端設備與支付服務器之間進行數據交互時雙方發送的數據需按照一定的格式進行組合。

組合的數據需要包含數據的用途、內容、發送方、數字簽名，且以密文的形式進行傳輸。

在本章節提供的示例中，數據交互協議的內容包括數據頭部區域、數據區域電子簽名區域。

數據頭部區域和數據區域的內容在發送之前需要使用密碼學算法進行處理，以便數據在傳輸過程中都是以密文的形式存在。

4.1 數據頭部區域

數據頭部區域包含通信協議的版本信息、數據發送方、數據接收方以及預留區域，以便后續擴展使用。

數據頭部區域包含的版本信息可以進行擴展使用，其可用于規定通信時使用的電子簽名算法類型。

解析數據是獲取到版本信息后就可以確定認證數據唯一性時使用的算法配置信息。

4.2 數據區域

數據區域中包含的內容是設備終端與服務器之間進行交互式傳輸的數據內容，關于數據區域中包含了哪些數據內容則由支付服務提供商自行決定。

但該區域中一般都會包含該份數據的用途、數據長度等信息。數據區域的數據格式定義如表24-2所示。

數據區域中的數據是設備終端與服務器端需要進行相關操作的依據，用于產生支付憑據、合法的支付請求以及支付結果的反饋等。支付廠商可以根據自身的實際需求定義該部分的內容。

4.3 電子簽名區域

電子簽名區域用于驗證接收到的數據的完整性和唯一性，一般使用RSA算法來實現，當然支付廠商也可以根據實際的需求使用電子證書加RSA簽名的方式來實現。本章提供的示例代碼中直接使用RSA2048算法來實現，其內容定義如表24-3所示。

在建立可信通信通道過程中，第一次握手時不會帶電子簽名，如果設備終端沒有在生產時將RSA公鑰發布給支付廠商，則在第一次握手時會將設備終端的一把RSA公鑰發送給服務器端。

4.4 交互數據包的格式

一個完整數據包需要包含數據包頭、數據區域、電子簽名區域。

一般在完成通信握手操作之后使用對稱加密算法對數據包頭和數據區域進行加密。一份完整的數據包的組合方式如圖24-3所示。

由于在數據通信過程中并不會在設備終端中固定加密密鑰。

故在仿照SSL通信協議協商加密密鑰的過程中傳輸的數據一般使用非對稱加密的方式對握手操作時的數據進行加密處理。這樣可以確保終端設備與服務器端握手操作時數據的安全性。

5、在線支付系統示例的實現

在線支付系統示例仿照SSL協議，終端設備與支付服務器采取三次握手的方式完成可信通信信道的建立。

在握手過程中終端設備和支付服務器會將一把RSA公鑰發送給彼此，RSA公鑰用于加密握手數據。每次握手操作的握手數據包中都會包含一個隨機數，待握手操作完成后，支付服務器和終端設備會使用握手過程中的三個隨機數使用PBKDF2算法生成后期設備終端與支付服務器之間進行數據交互時使用的AES加密密鑰。本節將詳細介紹示例中各操作的實現。

（本來不想學的，頂不住了，但是發現這個部分竟然有TA與CA的交互，我必須得瞅瞅了）

5.1、第一次握手請求

在支付應用程序安裝到終端設備或者用戶登錄時，支付服務器會向終端設備下發一把RSA公鑰。

為方便后續說明，將該RSA公鑰稱為RSA_PUBLIC_SERVER。

終端設備發起第一次握手請求時，在TA中就會使用該公鑰加密握手請求數據，按照通信協議規定，第一次握手請求的明文數據內容如圖24-4所示。

整個數據包按照256個字節進行對齊，組包后的明文數據會使用RSA_PUBLIC_SERVER公鑰進行加密，并將密文數據返回給CA，然后將密文數據通過網絡發送支付服務器。

**數據的組包、RSA加密模式、填充數據都在TA中完成，**讀者可根據實際需求自行修改協議中的內容，可添加時間戳信息、魔術數等身份標識數據，這些信息可被服務器用于對數據合法性的驗證。

5.2、第二次握手數據的解析

第一次握手請求時，設備終端會將一把RSA的公鑰RSA_PUBLIC_CLIENT打包到握手請求數據包中，服務器接收到數據包后使用對應的RSA私鑰解密開數據包，然后解析獲取到設備終端的RSA公鑰，該公鑰會被用于加密第二次握手數據。

（都是使用公鑰外發，你發來的東西都用這個公鑰加密，我有私鑰好解密）

第二次握手數據是由服務器端組包完成的。該數據的明文內容如圖24-5所示。

第二次握手數據明文組包完成后會使用RSA_PUBLIC_CLIENT進行加密，最后使用服務器的RSA私鑰對密文數據進行RSA電子簽名操作，第二組數據包中的數據區域中會包含第二個隨機數B。終端設備接收到該數據后會調用CA接口，將數據包發送給TA，**然后TA按照協議內容對數據包進行電子簽名驗證、數據解析、數據驗證，**最終獲取到第二個隨機數B，并將該隨機數保存到OP-TEE中。

5.3 第三次握手請求

第三次握手請求會將第三個隨機數C發送給服務器端，按照協議內容組包的第三次明文數據內容如圖24-6所示。

第三次握手請求使用設備終端的RSA私鑰進行簽名，其中會包含第三個隨機數C。明文數據會使用RSA_PUBLIC_SERVER進行加密。

待數據組包完成之后，TA會使用獲取和生成的三個隨機數A、B、C使用PBKDF2算法生成數據交互使用的AES密鑰，并將最終生成的AES密鑰保存在OP-TEE中。

待此操作完成后，TA會將第三次握手請求數據包返回給CA, CA以網絡通信的方式將數據發送給服務器端。待服務器端接收到第三次握手請求后，服務器同樣也會使用PBKDF2算法節后三個隨機數生成AES密鑰并保存起來，用于后續數據交互時明文數據的加密操作。到此終端設備與服務器端之間可信通信信道已經建立。

（搞了半天就是為了安全，傳遞這三個參數，去實現AES秘鑰的生成）

5.4 支付請求

支付請求命令會生成一個通知支付服務器與銀行產生清算操作的支付憑據的數據包。

該數據包使用握手時生成的AES密鑰進行加密， 然后使用設備終端的RSA私鑰進行電子簽名，以確保數據包的完整性和唯一性。支付請求的數據包內容示意圖如圖24-7所示。

支付請求時設備終端發送給支付服務器的支付憑據，在組包之前需要被發起支付請求的操作者進行相關的身份驗證，例如支付密碼、指紋驗證、短信驗證等方式。(這些驗證也是安全的環境中執行)

待身份驗證通過后，CA會向OP-TEE發送該命令，讓TA生成合法的支付請求數據包。明文支付請求數據會使用握手時生成的AES密鑰進行加密，服務器接收到該數據包后會對數據包進行電子簽名驗證、解密、解析、支付請求合法性驗證等操作。

5.5 支付反饋

支付請求完成之后，服務器端會向設備終端發送支付反饋數據包，該數據包包含直接結果和其他相關的信息，用于將最終的支付結果反饋給用戶。該數據包的內容示意圖如圖24-8所示。

設備終端接收到支付反饋數據包后會通過調用CA將該數據發送給TA, TA接收到數據后會對數據包進行電子簽名驗證、AES解密、合法性驗證，然后解析出支付結果，并將最終的支付結果信息返回給CA。

支付應用可從CA的返回數據中獲取支付結果并顯示給用戶。

（CA就是對外的，TA就是實際干活的）

6、具體源碼實例–書里面（不展開）

7、組包操作嵌入內核

若支付廠商想提高支付系統與終端設備的強制綁定，則可將打包操作完全嵌入到OP-TEE的內核中，在TA調用系統調用接口的方式來完成數據包的打包和解析操作，也即是芯片廠商需按照支付系統的通信協議將相關操作嵌入到內容中，該種實現方式的支付系統在OP-TEE中的框架圖如圖24-11所示。

（就是硬件邏輯實現相應TEE側的功能）

采取該種方式完成數據打包時就需要讀者將打包操作移植到OP-TEE中，可以在OP-TEE的內容中建立一個虛擬的服務，然后通過服務的方式將操作接口暴露到系統調用中，而最終打包操作時可看作是一**個虛擬的安全驅動，**將操作接口暴露給虛擬服務就可實現將操作嵌入到OP-TEE內容的開發。關于具體的實現，讀者可參考第22章中關于安全驅動的開發部分。

8、支付系統與生物特征的結合

生物特征數據一般都會用于終端設備使用者身份合法性的鑒定，如果在執行支付操作時嵌入使用者生物特征的匹配檢查就能實現支付系統與使用者生物特征數據的結合。

即在觸發支付操作之前需要使用者提供生物特征數據，例如指紋、虹膜、人臉掃描等。只有當生物特征數據驗證通過之后才能觸發支付操作，如果生物特征數據匹配失敗則取消支付操作。

如要實現生物特征數據與支付系統的強制綁定，可在開通支付系統之前要求用戶錄入生物特征數據，并將該數據傳遞到服務器端，由服務器端來完成使用者身份的論證，但該方式往往會牽扯到侵犯用戶隱私的問題，故當前一般將生物特征數據的鑒定放在終端設備中來完成。（現在還真的不好說這個咱們的信息存放在哪里的，一般安裝這些軟件一大堆用戶須知，一般都是同意）

9、為什么操作都放在TEE側

建議將密碼學操作、組包操作、鑒權操作、數據保存等操作都放在OP-TEE中完成，只將處理之后的數據返回給REE側的應用程序。這樣可實現支付數據全程都與REE側相互隔離，即使REE側的系統被破壞也不會造成關鍵數據的泄密。

總結

以上是生活随笔為你收集整理的TEEOS的实例-在线支付系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。