到了我最喜歡的環(huán)節(jié)了，我其實(shí)學(xué)習(xí)的過程中，對這些應(yīng)用場景概念是十分的感興趣的。

下面一起看看老師這本書的最后的一個部分應(yīng)用篇—在線支付系統(tǒng)

內(nèi)容來自《手機(jī)安全和可信應(yīng)用開發(fā)指南》

1、簡介

基于安全考慮，支付系統(tǒng)的最終結(jié)算由支付服務(wù)提供商與銀行完成支付結(jié)算，而終端設(shè)備只為支付系統(tǒng)的服務(wù)器提供支付憑據(jù)，讓支付系統(tǒng)的服務(wù)器端觸發(fā)支付操作完成與銀行間的賬務(wù)清算。

而終端設(shè)備的支付憑據(jù)就在整個在線支付過程中起到了至關(guān)重要的作用。如何確保支付憑據(jù)安全且可信的發(fā)送到服務(wù)器端并被服務(wù)器驗(yàn)證通過就尤為重要。

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

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

2、在線支付系統(tǒng)的基本框架

在線支付系統(tǒng)的支付憑據(jù)是由終端產(chǎn)生，該支付憑據(jù)包含了產(chǎn)生支付操作所需要的所有信息，支付憑據(jù)的組包和加密都是由TEE內(nèi)核或者運(yùn)行于TEE中的TA來完成的，至于采取何種方式則需要支付廠商與終端設(shè)備廠商協(xié)商解決。

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

在線支付系統(tǒng)的服務(wù)器端與銀行之間的數(shù)據(jù)交互協(xié)議是由支付廠商與銀行之間制定的，而支付系統(tǒng)的服務(wù)器端與終端設(shè)備之間的數(shù)據(jù)交互協(xié)議則是由支付服務(wù)提供商自行定義。

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

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

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

3、可信通信通道

可信通信通道是指設(shè)備終端與支付服務(wù)器之間的通信鏈路是安全可信的，即設(shè)備終端發(fā)出去的支付相關(guān)數(shù)據(jù)只有支付服務(wù)器才能正確地解析。

可信通信通道的建立可以仿照SSL協(xié)議來進(jìn)行建立，SSL協(xié)議主要用于網(wǎng)絡(luò)通信，通過設(shè)備終端與支付服務(wù)器之間的握手通信來建立兩者之間進(jìn)行密文通信使用的加密密鑰。圖24-2所示為SLL通信協(xié)議的簡圖。

在確定可信通信通道之前，設(shè)備終端與服務(wù)器端需要經(jīng)過三次握手來協(xié)商通信時使用的加密密鑰。

設(shè)備終端向服務(wù)器第一次發(fā)送握手請求時會生成一個隨機(jī)數(shù)A，服務(wù)器端會認(rèn)證該請求的可信性，如果認(rèn)證通過，服務(wù)器會生成一個隨機(jī)數(shù)B，然后將該隨機(jī)數(shù)發(fā)送給設(shè)備終端。

設(shè)備終端獲取到來自服務(wù)器的返回?cái)?shù)據(jù)之后會進(jìn)行一系列的可信認(rèn)證，待認(rèn)證通過之后會生成一個隨機(jī)數(shù)C，并將該隨機(jī)數(shù)發(fā)送給服務(wù)器完成整個握手操作。然后客戶端和服務(wù)器端使用相同的算法結(jié)合上述三個隨機(jī)數(shù)生成兩者之間進(jìn)行數(shù)據(jù)通信的加密密鑰。

為防止中間人攻擊，在終端設(shè)備和服務(wù)器建立可信通信通道時，終端設(shè)備和服務(wù)器需要具有數(shù)據(jù)的唯一性和可信鑒定機(jī)制。這一點(diǎn)可通過在設(shè)備生產(chǎn)時提前將認(rèn)證密鑰預(yù)置到設(shè)備中或在應(yīng)用程序安裝或注冊時分發(fā)密鑰到設(shè)備來實(shí)現(xiàn)。

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

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

4、數(shù)據(jù)交互協(xié)議

數(shù)據(jù)交互協(xié)議是指終端設(shè)備與支付服務(wù)器之間進(jìn)行數(shù)據(jù)交互時雙方發(fā)送的數(shù)據(jù)需按照一定的格式進(jìn)行組合。

組合的數(shù)據(jù)需要包含數(shù)據(jù)的用途、內(nèi)容、發(fā)送方、數(shù)字簽名，且以密文的形式進(jìn)行傳輸。

在本章節(jié)提供的示例中，數(shù)據(jù)交互協(xié)議的內(nèi)容包括數(shù)據(jù)頭部區(qū)域、數(shù)據(jù)區(qū)域電子簽名區(qū)域。

數(shù)據(jù)頭部區(qū)域和數(shù)據(jù)區(qū)域的內(nèi)容在發(fā)送之前需要使用密碼學(xué)算法進(jìn)行處理，以便數(shù)據(jù)在傳輸過程中都是以密文的形式存在。

4.1 數(shù)據(jù)頭部區(qū)域

數(shù)據(jù)頭部區(qū)域包含通信協(xié)議的版本信息、數(shù)據(jù)發(fā)送方、數(shù)據(jù)接收方以及預(yù)留區(qū)域，以便后續(xù)擴(kuò)展使用。

數(shù)據(jù)頭部區(qū)域包含的版本信息可以進(jìn)行擴(kuò)展使用，其可用于規(guī)定通信時使用的電子簽名算法類型。

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

4.2 數(shù)據(jù)區(qū)域

數(shù)據(jù)區(qū)域中包含的內(nèi)容是設(shè)備終端與服務(wù)器之間進(jìn)行交互式傳輸?shù)臄?shù)據(jù)內(nèi)容，關(guān)于數(shù)據(jù)區(qū)域中包含了哪些數(shù)據(jù)內(nèi)容則由支付服務(wù)提供商自行決定。

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

數(shù)據(jù)區(qū)域中的數(shù)據(jù)是設(shè)備終端與服務(wù)器端需要進(jìn)行相關(guān)操作的依據(jù)，用于產(chǎn)生支付憑據(jù)、合法的支付請求以及支付結(jié)果的反饋等。支付廠商可以根據(jù)自身的實(shí)際需求定義該部分的內(nèi)容。

4.3 電子簽名區(qū)域

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

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

4.4 交互數(shù)據(jù)包的格式

一個完整數(shù)據(jù)包需要包含數(shù)據(jù)包頭、數(shù)據(jù)區(qū)域、電子簽名區(qū)域。

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

由于在數(shù)據(jù)通信過程中并不會在設(shè)備終端中固定加密密鑰。

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

5、在線支付系統(tǒng)示例的實(shí)現(xiàn)

在線支付系統(tǒng)示例仿照SSL協(xié)議，終端設(shè)備與支付服務(wù)器采取三次握手的方式完成可信通信信道的建立。

在握手過程中終端設(shè)備和支付服務(wù)器會將一把RSA公鑰發(fā)送給彼此，RSA公鑰用于加密握手?jǐn)?shù)據(jù)。每次握手操作的握手?jǐn)?shù)據(jù)包中都會包含一個隨機(jī)數(shù)，待握手操作完成后，支付服務(wù)器和終端設(shè)備會使用握手過程中的三個隨機(jī)數(shù)使用PBKDF2算法生成后期設(shè)備終端與支付服務(wù)器之間進(jìn)行數(shù)據(jù)交互時使用的AES加密密鑰。本節(jié)將詳細(xì)介紹示例中各操作的實(shí)現(xiàn)。

（本來不想學(xué)的，頂不住了，但是發(fā)現(xiàn)這個部分竟然有TA與CA的交互，我必須得瞅瞅了）

5.1、第一次握手請求

在支付應(yīng)用程序安裝到終端設(shè)備或者用戶登錄時，支付服務(wù)器會向終端設(shè)備下發(fā)一把RSA公鑰。

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

終端設(shè)備發(fā)起第一次握手請求時，在TA中就會使用該公鑰加密握手請求數(shù)據(jù)，按照通信協(xié)議規(guī)定，第一次握手請求的明文數(shù)據(jù)內(nèi)容如圖24-4所示。

整個數(shù)據(jù)包按照256個字節(jié)進(jìn)行對齊，組包后的明文數(shù)據(jù)會使用RSA_PUBLIC_SERVER公鑰進(jìn)行加密，并將密文數(shù)據(jù)返回給CA，然后將密文數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送支付服務(wù)器。

**數(shù)據(jù)的組包、RSA加密模式、填充數(shù)據(jù)都在TA中完成，**讀者可根據(jù)實(shí)際需求自行修改協(xié)議中的內(nèi)容，可添加時間戳信息、魔術(shù)數(shù)等身份標(biāo)識數(shù)據(jù)，這些信息可被服務(wù)器用于對數(shù)據(jù)合法性的驗(yàn)證。

5.2、第二次握手?jǐn)?shù)據(jù)的解析

第一次握手請求時，設(shè)備終端會將一把RSA的公鑰RSA_PUBLIC_CLIENT打包到握手請求數(shù)據(jù)包中，服務(wù)器接收到數(shù)據(jù)包后使用對應(yīng)的RSA私鑰解密開數(shù)據(jù)包，然后解析獲取到設(shè)備終端的RSA公鑰，該公鑰會被用于加密第二次握手?jǐn)?shù)據(jù)。

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

第二次握手?jǐn)?shù)據(jù)是由服務(wù)器端組包完成的。該數(shù)據(jù)的明文內(nèi)容如圖24-5所示。

第二次握手?jǐn)?shù)據(jù)明文組包完成后會使用RSA_PUBLIC_CLIENT進(jìn)行加密，最后使用服務(wù)器的RSA私鑰對密文數(shù)據(jù)進(jìn)行RSA電子簽名操作，第二組數(shù)據(jù)包中的數(shù)據(jù)區(qū)域中會包含第二個隨機(jī)數(shù)B。終端設(shè)備接收到該數(shù)據(jù)后會調(diào)用CA接口，將數(shù)據(jù)包發(fā)送給TA，**然后TA按照協(xié)議內(nèi)容對數(shù)據(jù)包進(jìn)行電子簽名驗(yàn)證、數(shù)據(jù)解析、數(shù)據(jù)驗(yàn)證，**最終獲取到第二個隨機(jī)數(shù)B，并將該隨機(jī)數(shù)保存到OP-TEE中。

5.3 第三次握手請求

第三次握手請求會將第三個隨機(jī)數(shù)C發(fā)送給服務(wù)器端，按照協(xié)議內(nèi)容組包的第三次明文數(shù)據(jù)內(nèi)容如圖24-6所示。

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

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

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

（搞了半天就是為了安全，傳遞這三個參數(shù)，去實(shí)現(xiàn)AES秘鑰的生成）

5.4 支付請求

支付請求命令會生成一個通知支付服務(wù)器與銀行產(chǎn)生清算操作的支付憑據(jù)的數(shù)據(jù)包。

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

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

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

5.5 支付反饋

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

設(shè)備終端接收到支付反饋數(shù)據(jù)包后會通過調(diào)用CA將該數(shù)據(jù)發(fā)送給TA, TA接收到數(shù)據(jù)后會對數(shù)據(jù)包進(jìn)行電子簽名驗(yàn)證、AES解密、合法性驗(yàn)證，然后解析出支付結(jié)果，并將最終的支付結(jié)果信息返回給CA。

支付應(yīng)用可從CA的返回?cái)?shù)據(jù)中獲取支付結(jié)果并顯示給用戶。

（CA就是對外的，TA就是實(shí)際干活的）

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

7、組包操作嵌入內(nèi)核

若支付廠商想提高支付系統(tǒng)與終端設(shè)備的強(qiáng)制綁定，則可將打包操作完全嵌入到OP-TEE的內(nèi)核中，在TA調(diào)用系統(tǒng)調(diào)用接口的方式來完成數(shù)據(jù)包的打包和解析操作，也即是芯片廠商需按照支付系統(tǒng)的通信協(xié)議將相關(guān)操作嵌入到內(nèi)容中，該種實(shí)現(xiàn)方式的支付系統(tǒng)在OP-TEE中的框架圖如圖24-11所示。

（就是硬件邏輯實(shí)現(xiàn)相應(yīng)TEE側(cè)的功能）

采取該種方式完成數(shù)據(jù)打包時就需要讀者將打包操作移植到OP-TEE中，可以在OP-TEE的內(nèi)容中建立一個虛擬的服務(wù)，然后通過服務(wù)的方式將操作接口暴露到系統(tǒng)調(diào)用中，而最終打包操作時可看作是一**個虛擬的安全驅(qū)動，**將操作接口暴露給虛擬服務(wù)就可實(shí)現(xiàn)將操作嵌入到OP-TEE內(nèi)容的開發(fā)。關(guān)于具體的實(shí)現(xiàn)，讀者可參考第22章中關(guān)于安全驅(qū)動的開發(fā)部分。

8、支付系統(tǒng)與生物特征的結(jié)合

生物特征數(shù)據(jù)一般都會用于終端設(shè)備使用者身份合法性的鑒定，如果在執(zhí)行支付操作時嵌入使用者生物特征的匹配檢查就能實(shí)現(xiàn)支付系統(tǒng)與使用者生物特征數(shù)據(jù)的結(jié)合。

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

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

9、為什么操作都放在TEE側(cè)

建議將密碼學(xué)操作、組包操作、鑒權(quán)操作、數(shù)據(jù)保存等操作都放在OP-TEE中完成，只將處理之后的數(shù)據(jù)返回給REE側(cè)的應(yīng)用程序。這樣可實(shí)現(xiàn)支付數(shù)據(jù)全程都與REE側(cè)相互隔離，即使REE側(cè)的系統(tǒng)被破壞也不會造成關(guān)鍵數(shù)據(jù)的泄密。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。