手机盾设计相关安全问题

本示意图为简化版本。

我们知道手机盾的两大作用是：证书管理和转账。

证书管理是指证书的下载、更新、删除。转账是指银行应用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进行安全保证。