最近因为一直在调研独立secure element集成的工作，不巧的是目前使用的高通平台只有NFC-eSE的方案。高通目前也并不支持独立的eSE集成，codebase中并无相对应的代码。举个例子，目前使用的STM的一款eSE，但是这款eSE的开发STM还没有完成（搞不清楚，为什么就可以被选来用于项目），STM需要将code release给到高通进行validation的操作，高通集成进codebase之后，才能使可用状态，我理解这个也是进Qualcomm PVL的基本方法。
说一下Keymaster，之前的项目上是有过Keymaster相关经验的。Qualcomm SDM660的平台(至少是Android6 launch）基于这个平台，我们在Android N上launch了一个产品，产品为Gpc60，当时对应的keymaster1.0。通过观察，ota包解压后，里面有个两个镜像文件，keymaster.img
这里插一个Google version binding的项目：https://source.android.com/docs/security/features/keystore/version-binding?hl=zh-cn
通过绑定的系统版本和安全补丁信息，阻止针对攻击的系统回滚！详细的后面继续深度研究一下 。
将OTA包解压后，内容如下：
这里最大的内容是，payload.bin文件，其它部分后面再看。通过，payload_dumper工具能够将payload.bin 的内容导出：
可以看到里面的keymaster.img，update engine能够通过分区表中的分区名称查找镜像文件，并用来更新分区。分区表的内容通常和Emergency download的tool中对应的xml分区表是一致的。通常，分区表中内容是由Qualcomm进行定义的，codebase中自带。
那好，这里留一个疑问，keymaster.img和androd.hardware.keymaster@1.0-service的关系是什么？
为弄清楚上面这个问题，继续理解Qualcomm Android Security中的keymaster相关的技术。有幸经历了三个高通平台和Android6~Android14的8个Android的OS的开发过程。就先从Android6的keymaster1开始。在Android6（M）中，我们可以看到，要支持keymaster，
首先要物理分区表进行配置，早期都是使用的emmc作为存储。配置如下：
<partition label="keymaster" size_in_kb="256" type="4F772165-0F3C-4BA3- BBCB-A829E9C969F9" bootable="false" readonly="false" filename="keymaster.mbn" />这里还涉及tz和metadata的内容，tz的具体内容暂时先不看，主要看下metadata。分区表中，有单独的metadata的分区配置，但是目前也不是很清楚具体的作用，暂时按下不表。但是，可以了解一下vbmeta。
vbmeta 是Android 8.0 以后引入的一个机制，用于保证系统启动过程的完整性和安全性。 vbmeta 是一个包含数字签名的元数据文件，其中记录了系统启动过程中需要校验的boot、recovery、system 和vendor 分区的完整性信息，以及用于校验这些分区完整性的公钥。在分区表中通常由如下的分区设定：
<partition label="**vbmeta_a**" size_in_kb="64" type="4b7a15d6-322c-42ac-8110-88b7da0c5d77" bootable="false" readonly="true" filename="vbmeta.img"/><partition label="**vbmeta_b**" size_in_kb="64" type="77036CD4-03D5-42BB-8ED1-37E5A88BAA34" bootable="false" readonly="true" filename=""/> //没有文件名称？
<partition label="**vbmeta_system_a**" size_in_kb="64" type="1344859D-3A6A-4C14-A316-9E696B3A5400" bootable="false" readonly="true" filename="vbmeta_system.img"/><partition label="**vbmeta_system_b**" size_in_kb="64" type="FE3AB853-5B66-4D4A-BF85-8D90AF1C2C4A" bootable="false" readonly="true" filename=""/> //没有文件名称？
看下verify boot是什么概念：先看看Google的相关概念，简单的流程图如下：
简单的说就是签名和验签的过程， 确保用本公司自己的签名工具签过的image来启动机器。签名的过程就是获取分区的摘要（摘要通常就是一个数据块的hash值），使用私钥对摘要进行加密，并将加密文件和分区文件打包并刷到机器的磁盘中，例如mmc或者ufs中。
这里涉及到一个问题，这里的signature是存储在哪个位置？通过相关文档，发现是存在了vbmeta.img中了；
验证（verify）的过程就比较简单了，同样对分区取摘要为摘要A，对签名进行解密得到之前签名时的分区镜像文件的摘要为摘要B，对A/B进行比较，如果摘要一直，那么验签成功。针对Android的Verified boot后面要重点讲一下。
这里继续keymaster的故事，看一下一些名称需要理解和记忆：
AndroidKeystore 是供应用访问 Keystore 功能的 Android Framework API 和组件。它是作为标准 Java Cryptography Architecture API 的扩展程序实现的，包含在应用自己的进程空间中运行的 Java 代码。
AndroidKeystore
通过将与密钥库行为有关的应用请求转发到密钥库守护程序执行这些请求。//最好自己写一下测试app进行调试看看；
密钥库守护程序是 Android 系统中的一个守护程序，该程序通过 Binder API 提供对所有密钥库功能的访问权限（java的后端，AIDL）。密钥库守护程序负责存储“密钥 blob”。密钥 blob 中包含已加密的实际密钥材料，因此密钥库可以存储这些材料，但无法使用或显示这些材料。(比如说？)
keymasterd 是一个 HIDL 服务器，可提供对 Keymaster TA 的访问权限。（此名称未进行标准化，仅用于说明概念。）（keymaster@1.0-service.rc/ keymaster@4.0-service.rc/keymaster@3.0-service). e.g :keymaster@3.0-service, 这个便是keymasterd的一个实例。
Keymaster TA（可信应用）是在安全环境（大多数情况为 ARM SoC 上的 TrustZone）中运行的软件。它可提供所有安全的密钥库操作，能够访问原始密钥材料，在密钥上验证所有访问权限控制条件，等等。（ps操作命令可以能访问到吗？肯定是不能够的，因为运行在TEE中）；
LockSettingsService 是负责用户身份验证（包括密码和指纹）的 Android 系统组件。它不是密钥库的一部分却与其相关，因为很多密钥库密钥操作都需要对用户进行身份验证。
LockSettingsService
与 Gatekeeper TA 和 Fingerprint TA 进行交互以获取身份验证令牌，并将其提供给密钥库守护程序，这些令牌最终将由 Keymaster TA 应用使用。
Gatekeeper TA（可信应用）是在安全环境中运行的另一个组件，它负责验证用户密码并生成身份验证令牌（用于向 Keymaster TA 证明已在特定时间点完成对特定用户的身份验证）。
Fingerprint TA（可信应用）是在安全环境中运行的另一个组件，它负责验证用户指纹并生成身份验证令牌（用于向 Keymaster TA 证明已在特定时间点完成对特定用户的身份验证）
继续回到上面的问题：keymaster.img和androd.hardware.keymaster@1.0-service的关系是什么？手边刚好有Android12 的代码作为O设备的launch的设备MR。 对应的service是android.hardware.keymaster@3.0-service。对应的partition.xml内容如下：
那就要看看keymaster64.mbn的编译脚本，就可以知道keymaster64.mbn的内容。但开始可以确认的是，android.hardware.keymaster@3.0-service 是属于vendor分区的一部分，会被打包到vendor.img中。有点意思，keymaster64.mdn的内容到底是啥？（引导加载密钥?）
从高通得知，这个是高通平台封装的TA，是通过编译脚本打包进ROM包中。有一个问题是，那么TEE的整个运行环境是如何更新的？
版权归原作者 书笙拓荒 所有， 如有侵权，请联系我们删除。