手機盾設計相關安全問題

本示意圖為簡化版本。

我們知道手機盾的兩大作用是：證書管理和轉賬。

證書管理是指證書的下載、更新、刪除。轉賬是指銀行應用APP進行轉賬匯款操作。我們的安全設計必須圍繞著這兩部分來進行。我們今天來著重聊聊這兩個步驟。

1，證書如何從CA中心安全地下載到SE中？

這裡流程會與IFAA有所不同。

我們來回顧一下在IFAA體系中，手機終端產線階段預置了一對公私鑰，保存在RPMB中，公鑰安全地方式上傳到IFAA伺服器中，同時IFAA TA預置了IFAA伺服器的公鑰。因此雙方的身份認證就變得十分簡單，簡單的說在註冊發起時手機終端用自己的私鑰簽名數據向IFAA服務證明這是一台真實的手機，用IFAA的公鑰加密數據確保只能是IFAA伺服器才能解密數據。

手機盾中雖然已經在產線階段預置了applet和密鑰對，但是沒有建立綁定關係。也就是說SE中的公鑰事先並未上傳到伺服器中。所以銀行APP首先會從SE中申請公鑰，並上傳到伺服器。在這個過程中，有3個問題需要探討。

APP與銀行伺服器之間的安全信任機制問題。

銀行APP與伺服器之間的安全問題，目前可以通過多因子協助手段進行輔助安全保證，比如簡訊驗證碼，比如人臉識別。舉個例子來說招行的閃電貸申請，就採用了簡訊驗證碼和人臉識別雙因子認證來保證APP的真實性以及操作APP的人就是你。

APP與TA之間的安全信任機制問題。

同時還有惡意APP對TA的訪問通道的佔用風險。理論上可信執行環境中的TA是被動調用的，在《移動終端支付可信環境技術規範》中有關訪問控制的明確要求，可信環境需維護一組訪問規則判斷本次訪問是否被允許，本次介面調用是否被允許，TA維護一組規則判斷本次被其他TA訪問是否被允許。從理論上說假冒APP是可以獲取SE中的公鑰數據，一種極端情況攻擊者可以將預置的公鑰全部「使用完」導致正常的業務註冊流程無公鑰可用。

FIDO規範在這方面有許多措施可以參考。

TA與SE之間的信任機制問題。

本質上這兩種之間的信任是TEE和SE之間的信任關係。TA已經有簽名機制，只有合法的TA才能在TEE中運行。SE和TEE之間是安全的SPI硬體介面，因此其安全性由TEE系統保證。TEE鑒定是否是非法SE，可以在SE中預製一個私鑰進簽名，在TEE中進行驗簽是否合法SE。

2，如何保證轉賬安全？

使用TUI來進行流程安全保證，使用SE中的簽名來保證交易信息安全。具體來說，TUI的安全具體體現在發起轉賬流程後，進行可信界面，在可信界面中完成PIN碼的輸入，在SE中進行PIN校驗，如果校驗成功，則返回交易信息。此時在TUI中點擊確認按鈕，則在SE中進行簽名，並將簽名數據返回。整個過程中APP發起，並回傳消息到服務中，全程由TEE+SE進行安全保證。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！