从诺基亚 X6 聊人脸解锁：安全基础是TEE

前不久，诺基亚发布了其全新X系列智能手机诺基亚X6，官网上也打出了：AI面部识别，基于TEE移动安全解决方案指纹解锁之外，更享安全便捷的宣传。由于其采用的是高通芯片，因此TEE技术方案是QSEE/QTEE。

原题目：从诺基亚 X6 聊人脸解锁：你以为有结构光就叫安全吗？

来源周三科技，以及作者欧阳洋葱

周三科技的一大主义是（正考虑改叫周三电子），从理论上分享一些知识点，如果一定要谈目标，那大概就是开阔爱好者们的视野吧。因为我翻译和撰写的文章，一般既不像很多“评测”文章那样具有导购的作用，也不是专业技术文——对生产也不会有任何帮助。所以这里的资讯，本质上也就是起到增加谈资的作用，作为茶余饭后的笑料去和好友分享可能是最合适的。

文题略标题党，这次我想聊一个相对偏门，甚至很难作为营销卖点去说的手机人脸识别某一个层级的安全性问题——恰巧之前写过一篇类似的文章，这篇则意图以更便于理解的方式来谈这一问题（虽然在写完之后，感觉又有点自 high 了）。

没想到的是，我前两个月撰写的《听说 Android 手机已经和 iPhone 一样安全了，真的是这样吗？》点赞和评论都还算活跃，毕竟这个话题关注的人其实挺少的。不过实际上，Android 和 iOS 的安全性问题范畴远大于文中提到的“系统漏洞”，至少 Android 最严重的安全威胁就目前看来其实是恶意程序，其中的绝大部分是不涉及漏洞的。如果我们再进一步对这两个系统做安全性的探讨，那么无论苹果还是谷歌，在系统安全性方面做的文章都还是极为多样和工程庞大的，本文就再尝试探讨其中的一个层面。

本文面向的阅读群体是手机爱好者，一般消费用户也可以阅读；若要理解全文，可能需要对计算机科学有最基本的认识。不过文章内容整体还是比较浅的，阅读时可以忽略一些细节；略过文中标注“选读”部分，也完全不影响全文意思的理解。有意向对技术做进一步了解的，欢迎点阅文末参考的链接，里面有更具体的技术分析。

前两周参加诺基亚 X6 的发布会，会上的其中一屏 PPT 提到了这款手机的人脸识别解锁采用了 TEE 方案。TEE 的全称叫 Trust Execution Enviroment，说句人话，TEE 在 ARM 架构的处理器中就叫 TrustZone。TEE 最早是由 GlobalPlatform 提出的一种标准，其基本理念是在 CPU 内部构建一块独立的“安全世界”，把敏感信息（如某些密钥、PIN 码）的存储和操作都放在这里进行，以确保安全性。而我们所知的 TrustZone 就是 TEE 的一种具体实现。

所以诺基亚的意思也就是 X6 这款手机的人脸识别是和 TrustZone 挂钩的，这是我们要谈的重点。

人脸解锁的安全性是什么意思？

“安全”是个比较宽泛和涉及到多层级的词汇，一般媒体日常都很喜欢说 Face ID 的安全性好。不过这里的“安全性”好，说的是众多传感器（包括摄像头）识别人脸这一过程比较安全——而生物特征（biometric）做身份认证的安全性实际上不光这一个环节，它还涉及到生物特征数据（如人脸、指纹数据）的存储、传输等操作是否安全。

如果说传感器识别人脸的过程很安全（比如 2D 照片、3D 脸模都无法欺骗人脸识别传感器），但人脸数据在存储后却可以被轻易窃取，则其安全性也是存在问题的。当然 Face ID 这方面做得也不错，其生物特征（人脸数据）就是在 A11 芯片的 TEE 安全世界中执行操作的。当然在苹果的宣传中，这个 TEE 叫做 Secure Enclave，这也可以认为是苹果版的 TrustZone 了（虽然可能微架构存在很大差别）。

再举个例子，在 Touch ID 时代，人们普遍更关注生命特征的存储问题。实际上也正是从 iPhone 5s 的指纹识别传感器开始，很多消费用户和爱好者知道了有个叫 TrustZone 的东西的存在。因为在指纹识别作为主流身份认证的年代，识别过程的安全性往往没有那么重要（即便依然有黑客通过指纹取样、建模来欺骗指纹识别传感器，但这个层面的攻击难度会大很多），指纹数据的传输和存储在一般人看来才是最重要的。

这里小结一下，至少就本地生物特征身份认证（如手机的人脸解锁）的安全性需要分两个阶段来谈，第一阶段即传感器识别生物特征的过程，第二阶段则是生物特征数据传输和存储的安全性问题。针对其中任一阶段的攻击和破解，都可以达到窃取数据或其他破坏性目的。比如理想情况下，针对指纹识别的第一阶段，可以通过采集指纹和建模来欺骗指纹识别传感器，也可以针对第二阶段来拦截传输中的或获取已存储的指纹数据——完成其中任何一个阶段，都能欺骗身份认证过程，并最终窃取手机中的资料。

在人脸识别时代，其实大部分消费电子科技媒体谈的所谓安全性都是第一阶段的安全性，这的确也是人脸识别解锁乃至支付最大的挑战。iPhone X 可能是目前在民用移动设备领域，人脸识别第一阶段安全性做得最好的手机产品：Face ID 用上了现在被很多人所熟知的结构光。而许多 Android 手机人脸识别的第一阶段，很大程度上还受制于 2D 照片的欺骗——而用户的 2D 照片实际上是很容易从社交网络上获取的。

早年，相对复杂的 3D 脸部识别技术对于硬件的处理性能会有较高的要求，而且体验也并不好。比如东芝脸部识别工具（Toshiba Face Recognition Utility）要求用户根据提示把头转向几个不同的方向，整个认证过程还需要大约 30 秒——这在民用设备上是个不能忍的。另一方面，其实 2D 维度的人脸识别也并非全靠用户录入的一张照片。2014 年的一篇题为《Sensor-assisted facial recognition: An enhanced biometric authentication system for smartphones》的 paper 就提到了，利用手机中的加速计来推测前置摄像头的位置和方向[1]。

所以苹果在收购 PrimeSense 之后能有此番建树也实属不易了（尤其是体验和安全的双重提升）。不过这不是本文要谈的重点，我想从较浅的层面聊聊这里的第二阶段，即生物特征数据的存储和操作的安全性——也是诺基亚 X6 所说的安全性所在，毕竟 TrustZone 的博大精深远不是我这样的二道贩子能完全理清的（而且大部分消费电子科技媒体似乎也都没提过 TrustZone 在人脸识别这件事情上扮演何种角色）。

而 TrustZone 相关的安全问题，也绝不仅仅是下面讨论的这些。典型如苹果的 Secure Enclave 参与 iOS 的安全启动过程，而且每一代 SoC 的迭代也伴随 Secure Enclave 的加强，如最新的 A11 中，会有个 integrity tree 阻止 Secure Enclave 的存储部分被 replay 攻击，存储空间还会借由片上 SRAM 内的临时密钥（ephemeral key）和随机数做加密...这些就不在我们的讨论范围内了。

Android 4 时代的人脸解锁

不知很多同学是否还记得，早在 Android 4.0 冰淇淋三明治时代，Android 系统内部就集成了人脸解锁功能——当年的 Galaxy Nexus 和 Nexus 4 还用这项功能做过一波广告（还记得是一个小孩儿做出各种鬼脸企图解锁父亲的手机，父亲把手机拿到跟前看了一眼就完成了解锁）。那个时代的人脸解锁体验当然比现在差远了，尤其识别率和对场景的要求，都和现在的人脸解锁解决方案相去甚远。

但这是次要的，在人脸解锁功能推出初期，谷歌似乎没怎么考量过这项功能的安全性，所以用照片来欺骗 Android 4.0 的人脸识别解锁是完全可行的（即第一阶段的安全性差）。那么第二阶段安全性又如何呢？悲剧的是，我作为一个从未参与过生产的人，也没有条件去对当年的 Android 4.0 搞逆向；我也没有找到相关资料。不过我恶意揣测，这个阶段的人脸数据和 TrustZone 还没什么关系（或者说没有专有硬件的证书存储和加密操作），人脸数据可能只是简单地放在某个文件夹里，有关依据会在下文提到。

这其中当然还关乎很多细节，比如人脸数据是如何转为数字形式存储的，是否加密等。但其存储方式就决定了其安全等级与当代诺基亚 X6 这类手机在生物特征数据存储安全性方面存在差距。所以后来谷歌把这项功能移到了设置菜单的 Smart Lock 中，而不将其作为解锁手机的属性单独列项。

现在各 OEM 手机制造商所用的人脸解锁方案大部分也都不是谷歌集成在 Android 系统内的功能了。即便它们始终也没能迈过人脸识别第一阶段安全性的门槛，第二阶段的安全性却都清一色做了升级——这是一种进步，但这也注定 Android 手机当前比较普遍的人脸解锁方案是很难应用于支付的。毕竟支付关乎金钱，它对于安全性的要求可比解个锁高多了（至少对普通人而言是如此），唯有第一阶段也做到苹果的程度，才有将其作为全局身份认证方案的基础。

那么如果我们只讨论第二阶段的安全性，iPhone 和 Android 手机谁又做得更好呢？如果不做具体工程，大概也很难比对 QSEE（高通的 TrustZone 方案）和苹果 Secure Enclave 谁更安全，所以就第二阶段，Android 手机和 iPhone 的安全性比较也很难讲清楚。但至少，它们的大体思路是一样的，就是把生物特征数据在 CPU 的这个“黑匣子”里进行操作，包括加密、存储等，别说其它 App 撬不开，连系统自己也拿不到里面的数据——这就是一种进步。

实际上我们之所以说 Android 4.0 时代的人脸解锁在安全性方面还很原始，有一则依据是直到 2013 年下半年 Android 4.3 果冻豆的推出，谷歌才在 API 文档中首次提及硬件级别的证书存储（Hardware credential storage）[2]，说句人话就是 KeyChain 证书可以存储在专有的硬件中了（好像也不是人话...），极为敏感的身份凭证，比如密钥这种东西就会更安全。谷歌也是那时才第一次在开发者文档中提到了 TrustZone，“即便是操作系统内核也无法访问（存储在其中的）密钥资料”。

从这个版本的系统开始，Android Key Store 密钥存储，对于存储和使用 app 私钥才有了公共 API——早前的系统其实也可以实现，只不过并没有得到谷歌的正式支持。系统甚至在设置项中还支持检查证书存储是否受到专有硬件支持，比如当时的 Nexus 4 就已经开始宣传高通内部的 TrustZone 了，而更早一代的 Galaxy Nexus 在证书存储的问题上仍然只支持从软件上来实现（德州仪器的 SoC？）[3]。其实我们把这里的“证书”译作“身份凭证”可能更便于理解，人脸或指纹解锁中的人脸和指纹数据，就是一种身份凭证（即便可能和实质上的 credential 还是不一样，或成为独立的子系统），它们放在哪个位置显然是很重要的。

(注：但我也不能下结论说，Android 4.3 之前的解锁凭证没有受到硬件级别的保护；另外可能还需要对 Android 系统后来的全盘加密做更进一步研究。这里简单聊一聊，Android 系统的全盘加密是从 5.0 时代开始受到支持的，这其中涉及到的各类密钥和加密过程比较复杂。设备解锁启用的 PIN 码、密码、解锁图案都属于全盘加密（以及文件级别加密）的组成部分，而不仅是很多人以为的某个简单的通行证而已。详情可以参见 Android 安全文档[4]。

我们说“证书存储”，究竟存什么证书？实际上 Android 4.3 正式引入的证书存储 API 主要用于存储例如 Wi-Fi 和 V** 连接之类的证书（比如密钥），另外当然就是针对第三方 App 的证书。这个 API 支持生成和访问 App 私钥，为非系统 App 安全存储密钥提供了便利，开发者不需要再自己取实施密钥保护措施。就硬件支持的证书存储（TrustZone），即便有 root 权限也很难拿到其中的证书。

不过据此，我们至少可以认为，Android 4.3 之前的系统还罕有专门硬件支持的凭证存储。TrustZone 在此之前还没有被普遍认知，更不用谈生物特征数据是否在这里操作。）

选读：有关 Android 系统证书的存储（可略过）

《Android 安全剖析：Android 安全架构深度指导（Android Security Internals: An In-Depth Guide to Android's Security Architecture）》[5]（这本书貌似还挺贵的，电子书售价 874 美元）一书中有特别提到我们上面在谈的这个证书存储。这里与大家分享一些节选。

“系统证书存储是个系统服务，在将导入的证书存入磁盘之前，可对其进行加密。加密密钥源自用户提供的密码，包括在 Android 4.0 系统之前专门的证书存储防护密码，或者设备解锁图案，PIN，或者是 4.0 系统之后支持的密码。此外，证书存储系统服务会对证书而访问做出规范，确保仅有明确授权的 App 才可以访问密钥。”

“最初的证书存储特性，是在 Android 1.6 系统中引入的，当时仅限于 V** 和 Wi-Fi EAP 证书。那个时候只有系统可以访问存储的密钥和凭证，第三方 App 是不可以的...证书存储管理是没有公共 API 的...”

图片来源：Android Security Internals: An In-Depth Guide to Androids Security Architecture

“访问系统存储证书 API 的最早引入是在 Android 4.0。系统证书存储后来扩展到了硬件级别，不仅支持共享的系统密钥，而且还支持 App 私钥。上表展示了每个 Android 版本证书存储相关的重大升级...”

“原本守护进程的实施方案包括在一个库中的密钥块管理和加密，但后来 Android 4.1 引入了全新的 keymaster 硬件抽象层（HAL）系统模块，支持在无需输出密钥的情况下，就可以生成非对称密钥，以及签署和确认数据。keymaster 模块会将 keystore 密钥存储服务，从非对称密钥操作实施方案中剥离出来，支持特定设备、硬件级别更方便的整合。实施方案可采用供应商提供的专有库，与加密硬件进行通讯，并提供 HAL 库...”

“Android 另外支持 softkeymaster 模块，可以纯软件的形式执行所有密钥操作（使用系统的 OpenSSL 库）。该模块使用基于模拟器（emulator），用于那些不包含专用加密硬件的设备...”

“所有非对称密钥操作，对 keystore 服务可见，通过调用系统 keymaster 模块来实现。因此，如果 keymaster HAL 模块有硬件级别的支持，那么所有更上层的命令，以及使用 keystore 服务接口的 API，都会自动去使用硬件加密。除了非对称密钥操作，所有其他证书存储操作，都通过 keysotre 系统服务实现，不依赖于 HAL 模块......和大部分 Android 服务有所不同的是，keystore 服务以 C++ 实施，位于 system/security/keystore 中。”

不过需要指出的是，这本书写的时间比较早，可能其中的资讯是滞后的；后续 Android 系统或已经对这部分内容做了更新。跟进这部分内容的高人欢迎留言补充。

用指纹或人脸解锁设备时，系统究竟在做什么？

其实我不知道诺基亚 X6 的人脸解锁用的是哪家的方案（诺基亚当前全系支持人脸解锁设备的手机应该都是同一套方案），可能并不是时下国内厂商普遍流行的 Face++（旷视）。而且我在网上找 Face++ 的方案细节也一无所获（哭，不会做逆向的悲哀）。但 Face++ 的方案基于 TrustZone 也是可以确认的。

这里我们只能借用 iOS 系统的 Touch ID 和 Face ID 来简单地管中窥豹了[6]（Android 的安全文档实际上也有指纹识别方面的内容），iOS 的安全白皮书相对简要地谈到人脸解锁识别和支付的过程。人脸解锁和支付的过程，其实并不像很多人想象得那么简单，就是把两份数据简单比对一下，看看是否匹配，匹配就解锁或支付——因为如果真的这么做，安全性会成为一个巨大的问题。

先聊聊 Touch ID，毕竟就生物特征数据的存储和操作，总体上它和 Face ID 应该是差不多的。这部分有点绕：就 iPhone 而言，Touch ID 是几乎直接和处理器的 Secure Enclave 进行通讯的。苹果的处理器与 Touch ID 指纹识别传感器的通讯是通过串行外围接口（SPI）总线进行的，处理器随后把 Touch ID 获得的数据转给 Secure Enclave，处理器自己的“普通世界”是无法阅读这部分数据的。每台 iPhone 设备的 Touch ID 传感器都会与对应的处理器 Secure Enclave 最初都会有个共享密钥（出厂时就有的，且每台设备都不一样），两者会利用这个共享密钥再协商一个会话密钥——这个会话密钥对刚才获取的指纹数据进行加密和认证。

另外，两者的会话密钥的交换过程也是加密的，而这里用于加密交换过程的 AES 密钥还会有一重外衣，这层外衣由 Touch ID 传感器和 Secure Enclave 分别提供的随机密钥构建起来，传输再采用 AES-CCM 传输加密。

说得这么绕，讲句人话其实也就是 Touch ID 的指纹数据的传输、存储等操作经过了层层加密、各种加密，才在 Secure Enclave 中落地，即便或许在你的使用过程中，只是一瞬间的事情。

当然有一点还是需要提一下，即所谓的“指纹数据”存储，最终还是要落地为数字化内容的，不会是真的给 Secure Enclave 呈现个指纹图片。实际上 Touch ID 传感器的光栅扫描结果首先会临时存储在 Secure Enclave 的专用存储区间内。然后分析过程中会对指纹纹路进行一个映射，这个过程会丢弃一些细节数据，随后映射产生的数据再以加密的方式存起来，仅有 Secure Enclave 可以读取。这个所谓的“映射过程”算是个有损的数据存储过程（因为丢弃了某些细节数据）。按照苹果的说法，这么说是为了防止有机会可利用这些数据重新构建用户真正的指纹长什么样。

Face ID 的这一过程则会相对更复杂，很多媒体都提过传感器识别人脸数据的过程——这套系统在苹果那儿叫 TrueDepth。Face ID 在首先检测到人脸之后就会开始后续的操作，iPhone X 刘海的那一排传感器会投射出超过 30000 个红外点，构成脸部的深度图（depth map），另外当然也会录入 2D 红外图像。最后转往 Secure Enclave 的数据实际上是一系列的脸部 2D 和深度图。诸多 2D 图像和深度图的顺序是随机化的。处理器 Secure Enclave 随后会把这些图像转成某种数据形式，随后的人脸识别匹配过程自然也是在 Secure Enclave 中进行的。这个识别过程当然又关乎到神经网络了，但此处的匹配只关乎深度学习的 inference，而 training 阶段仍然是苹果那边在做的事情——这和麒麟 970 的 NPU 是异曲同工的。

不好意思，一激动又装了个逼。上面这两段都是次要的，也不是我们这篇文章要讨论的问题，毕竟它们更偏向于前文提到的“第一阶段”的安全性。不过在 Face ID 的阐述中，苹果并未言明相关脸部数据的“传输”通道是如何保证安全性的，对应于 Touch ID 的传输（传感器和处理器之间的通讯）经过了层层加密；毕竟后续“脸部数据”的数字化表达（mathematical representation）和加密都是在 Secure Enclave 内部进行的，前期的传输过程如何是未知的（以及除了前置摄像头意外，其他传感器是如何与处理器进行通讯的）。我们猜测，2D 图像和深度图顺序的随机化，或许可以抵御针对传输过程的攻击。

实际上，和前文 Android 证书存储部分所述的一样，利用 Touch ID 和 Face ID 进行手机“解锁”，它们并不只是单纯充当通行证的角色，匹配正确了就让你完成解锁，进入系统。生物特征数据，或者我们设置的解锁密码、PIN 之类，本质上都会参与设备上的各种加密操作，比如 Android 5.0 之后的全盘加密，以及 iOS 设备上的数据防护。有关这部分内容，还可以参见我早前写的另一篇文章《内置加密芯片的金立M6，真的是“最安全”的手机吗？咱来聊聊TrustZone》（这篇文章可能在 TrustZone 架构的理解上存在一些错误）。

iOS 的数据防护（Data Protection，包括文件加密）当然也有最高级别的密钥，这些密钥存在于 Secure Enclave 中。如果我们开启人脸或指纹识别，在我们关闭屏幕之后，设备不会丢弃这些密钥。这些密钥会再用另一个密钥进行加密操作，然后把它们交给 Touch ID 或 Face ID 子系统。当我们去解锁设备，并且成功匹配，则 Touch ID 或 Face ID 就会交还一个密钥，用于解密数据防护的密钥。如果设备重启，上面提到的这些密钥会丢失，Secure Enclave 也丢弃了这些密钥（也包括 48 小时我们都没有去使用设备的情况下），所以我们需要重新输入解锁密码。

（顺带吐槽一下魅族，无论何时，包括重启等各类操作，你都可以用指纹去解锁手机——这其实算得上对安全的一种漠视。大部分 Android 手机即便启用指纹解锁，某些情况下，如重启设备，依然会要求用户数据密码。）

所以简单的一个解锁设备的操作，其后系统忙里忙外做的事情可是相当多样的。我虽然没有仔细阅读 Android 在这部分的设定，加密解密的细节可能会存在较大差异，但整体思路差不多也会是这样——但 Android 的人脸解锁估计并不参与这部分操作，因为 Android 安全文档的身份验证章节中并没有提到人脸解锁。所以有可能 Android 当前的人脸解锁还真的主要停留在进入系统的“通行证”功能的层级上（欢迎反驳）。

有关支付的巧妙操作

最后咱来聊聊生物特征识别，在支付行为中扮演什么角色。某一类生物特征识别的支付，或者关乎金融操作（比如取款）的方案其实是很不安全的，比如很多银行为了方便用户进行金融方面的操作，要用户到银行去录入指纹，以后取钱不用密码，用指纹就可以。这种模型是一个“中心化”的模型，即指纹数据是集中存储在一个中央机构的，如果说有黑客用各种手段攻破了服务器防线，获取到了这些数据，那么就意味着上亿用户的生物特征数据被窃取（即便或许其他攻击方式可能会更经济）。

大部分消费类媒体都不止一次地提到，生物特征数据的一次破解，就意味着终生破解，毕竟生物特征（包括指纹、掌纹、声纹、心跳等）具有稳定、不可更改、不可抛弃的特点。这和设置字符密码是不同的，毕竟如果密码被暴力破解了，我们大不了改一个。所以中心化的生物特征识别支付操作是非常不安全的。

FIDO 联盟（Fast Identity Online）2015 年就提出过一个参考标准[7]，而且是与 TrustZone 打配合的。其中 UAF（Universal Authentication Framework）标准的扩展提到过这么一套方案：比如利用指纹或人脸来支付的场景，设备生成公钥和私钥（两者自然是配对的关系）——针对用户、设备及卖家（也就是购物网站）。卖家那边仅持有公钥，买家持有私钥——这个私钥当然也是加密存储的。买东西的时候，如果私钥能够与公钥匹配，则完成支付操作。

可能很多人以为私钥就是指纹或人脸了，但实际情况是私钥是加密存储的，指纹、人脸这样的生物特征只不过是用来解密私钥的一个因素（也就是说指纹、人脸只是获得私钥的一个必要途径）。这样一来，生物特征数据只参与解密私钥，而且不可或缺，还不会在网络上传输，安全性自然就和前面提到的那些银行的操作不同了。

现如今用指纹进行支付的场景已经随处可见了，包括 Android 手机也能用指纹完成支付。但就像文章第一部分说的，Android 手机至今都没能很好地解决人脸识别关乎的第一阶段的安全性，所以用人脸来支付在 Android 设备上依旧任重而道远。

选读：TrustZone 究竟是个啥？（可略过）

ARM 很早就提出了 TrustZone 的设计。就像我们前面说的，TrustZone 的设计理念是把 SoC 硬件和软件资源分隔成两部分：安全子系统的“安全世界”，和常规使用的“普通世界”（比如 Android 系统整体都可以算是普通世界）。安全世界有自己专门的操作系统（比如高通的 QSEOS，这个系统直接以系统调用的形式提供少量服务），内部还运行一些“微应用”，比如密钥管理、加密、完整性检查等。这些微应用（Trustlet）为普通世界提供安全服务。一般来说，两个世界之间的通讯是经过操作系统内核进行的。

图片来源：Android Security Internals: An In-Depth Guide to Androids Security Architecture

常见的微应用比如 Keymaster，这是 Android 系统 keystore 守护进程提供的密钥管理 API 的具体实现，它负责生成存储加密密钥，以及让用户使用这些密钥。微应用再比如 Widevine，负责在设备上进行媒体的“安全播放”等。

TrustZone 的实现就 ARM 的官方方案来看，并不只是单纯在 CPU 内部划个逻辑区块出来。它的实现关乎很多物理层面的设计，比如说其 AMBA3 AXI 系统总线需要针对每个读写通道增加额外的控制信号，用这个信号比特位来确认处理操作究竟是 Secure 还是 Non-secure。处理器的 Cache 也需要重新设计，需要多一个标记比特位。另外，处理具体工作的时候，如何在两个“世界”间切换也是需要考虑的。

每家芯片制造商对于 TEE 的具体实施方案可能会存在很大差别，甚至不按照 ARM 的方案去做。具体到 Nexus 4 当年的高通骁龙 S4 Pro APQ8064，系统与安全世界微应用通讯的唯一途径就是 /dev/qseecom 提供的控制接口。Android 应用如果想要与 QSEE 通讯，则加载专门的 libQSEEComAPI.so 库，利用其函数给 QSEE 发出命令。如 QSEE keystore 应用会使用专门的加密密钥块，某些形式的主 KEK（master key-encryption key）会得到保护，用户生成的密钥则会以 KEK 进行加密。

敬畏信息技术的每一次改进

无论 ARM 的 TrustZone，还是苹果版本的 Secure Enclave 都不是绝对安全的。前两年的 GeekPwn 2016 黑客大赛上，美国的 Shellphish 团队攻破华为 P9 Lite 的加密功能，也就是海思 Kirin 内部的 TrustZone，最终实现了用任意指纹来解锁手机。高通的 QSEE 也被数度曝出漏洞。本质上都是抓住“安全世界”和“普通世界”通讯的切入点，一击毙命。对此感兴趣的可以参考先前某些大神分享的系列文章：《Exploring Qualcomm's Secure Execution Environment》

但 ARM 在 TrustZone 安全白皮书中提过的安全理念很正确[8]，我在过去的文章中提过无数次：

• 任何一种设计出来的安全方案都不应该用“不可能被绕过”来形容，而应该这样描述：“A 针对 B 资产的攻击，至少需要耗费 Y 天，Z 美元的成本。”因为所有的安全措施，只要有足够的时间和金钱都能被攻破。如果花费的时间和金钱成本太长太多，这样的防御就是成功的。
• 不仅攻击复杂度高，而且攻击方案无法简单复制到其他同类设备之上，也就是说攻击一台设备成功后，如果还想攻击其他同类设备，则还需要付出同样程度的劳动，这样的防护也可以认为是成功的。

电子科技行业的任何一点进步，哪怕是体验方面用户无法察觉的一点小提升，其背后所需付出的努力都是海量的。如同现如今我们可以在诺基亚 X6 这样的千元机上用上人脸解锁的功能，即便它可能还需要在安全性上做提升。从 Android 4.0 到现如今人脸解锁的变迁，其提升自然不光是体验上的，即便第一阶段的安全性依旧没有解决得很好，第二阶段的安全性改进却是一步步可以看得到的。

当我们谈“安全”这个话题的时候，即便每篇近万字的笼统概括，也只能揪出其中的一个点来大致聊聊。这篇文章其实也就是随意谈了谈 Android 和 iOS 系统在生物识别身份认证方面的一小部分投入，就已经值得我们花大量的时间去研究和深入了。如果你是个技术爱好者，请记得在探究哪怕是某些媒体所谓“痒点创新”的时候，都怀有一颗敬畏之心。

参考来源

[1]TrustFA: TrustZone-Assisted Facial Authentication on Smartphone

[2]Android 4.3 APIs - Google

[3]Credential storage enhancements in Android 4.3

[4]Full-Disk Encryption - Google

[5]Android Security Internals: An In-Depth Guide to Android's Security Architecture

[6]iOS Security - Apple

[7]Securing the Future of Authentication with ARM TrustZone-based Trusted Execution Environment and Fast Identity Online (FIDO)

[8]ARM Security Technology - Building a Secure System using TrustZone® Technology