钱庄

最近研究了小米安全开放服务客户端 SDK 的实现，意外发现小米实际上实现了一套简化版的密钥验证，囊括了从 Trust Application、AIDL HAL、客户端 API 到应用 SDK 的全流程。下面以红米 Note 12 为例，逐项拆解一下：

1）系统启动：由 init 执行 /odm/bin/mrmd，启动名为 vendor.xiaomi.hardware.mrm 的 AIDL 服务，并注册三个名为 IMrm、IMiCertificate、IMrmRemoteAuth 的接口，供客户端使用。服务的具体逻辑在 /vendor/lib64/libmiriskmanager.so。服务启动时会调用高通 QSEECOM API 接口，请求内核向 TEE 加载名为 miriskm 的 TEE 应用。

2）应用发送验证请求：应用调用 sdk 的 init 方法，应用绑定至小米手机管家的 com.xiaomi.security.xsof.SAFETY_DETECT_SERVICE，并传入 APP_ID 和 APP_KEY（应用注册时由小米分配）及挑战码。小米手机管家再次绑定至 MiTrustService 的 com.xiaomi.trustservice.IMiTrustService，IMiTrustService 调用上述 AIDL 服务的 MiRiskManager::getStatusByAuth 接口，开始验证流程。

3）验证：分为两部分，一部分为用户空间的验证，逻辑很简单，无非 prop、selinux、su 文件（注意，验证在 mrmd 进程中完成，这是个原生进程，denylist 只针对 app 进程，因此需要手动对 mrmd umount su）；另一部分为 TEE 中验证，这里调用 QSEECOM API 与 TEE 通信，关键代码在 TEE 应用中。我没有仔细梳理逻辑，但可以看出将用户侧数据送进了 TEE，并在 TEE 中获取解锁状态、生成包含验签信息在内的 JSON 后，返回至客户端。

4）验签：可以本地对比 hash，也支持将数据上传至小米服务器远程验签。

整体来看，若证书生成及验签流程正确，这就是个精简版的密钥验证。目前小米仍未强制此项验证，因此可以通过改机型、关闭 framework 端服务等方式绕过此项检测，而真正破解则需要小米颁发的私钥。（像不像 PIF？）目前，第三方应用中仅发现 Hunter 搭载了该 SDK。

题外话：研究时顺便看了下内核中的 TEE 接口，发现 libmiriskmanager 有三种与内核通信的实现：高通机型使用高通提供的 QSEECOM，MTK机型一部分使用 MTK 与豆荚科技联合开发的 TEEi，还有少数机器使用小米自研 MiTEE（从驱动代码看，实际上基于 Linaro 提供的开源实现 OP-TEE 二次开发）。

www.tgoop.com/qianqianzhuang/76

7.0K views钱钱, edited  Sep 8 at 09:23

最近研究了小米安全开放服务客户端 SDK 的实现，意外发现小米实际上实现了一套简化版的密钥验证，囊括了从 Trust Application、AIDL HAL、客户端 API 到应用 SDK 的全流程。下面以红米 Note 12 为例，逐项拆解一下：

1）系统启动：由 init 执行 /odm/bin/mrmd，启动名为 vendor.xiaomi.hardware.mrm 的 AIDL 服务，并注册三个名为 IMrm、IMiCertificate、IMrmRemoteAuth 的接口，供客户端使用。服务的具体逻辑在 /vendor/lib64/libmiriskmanager.so。服务启动时会调用高通 QSEECOM API 接口，请求内核向 TEE 加载名为 miriskm 的 TEE 应用。

2）应用发送验证请求：应用调用 sdk 的 init 方法，应用绑定至小米手机管家的 com.xiaomi.security.xsof.SAFETY_DETECT_SERVICE，并传入 APP_ID 和 APP_KEY（应用注册时由小米分配）及挑战码。小米手机管家再次绑定至 MiTrustService 的 com.xiaomi.trustservice.IMiTrustService，IMiTrustService 调用上述 AIDL 服务的 MiRiskManager::getStatusByAuth 接口，开始验证流程。

3）验证：分为两部分，一部分为用户空间的验证，逻辑很简单，无非 prop、selinux、su 文件（注意，验证在 mrmd 进程中完成，这是个原生进程，denylist 只针对 app 进程，因此需要手动对 mrmd umount su）；另一部分为 TEE 中验证，这里调用 QSEECOM API 与 TEE 通信，关键代码在 TEE 应用中。我没有仔细梳理逻辑，但可以看出将用户侧数据送进了 TEE，并在 TEE 中获取解锁状态、生成包含验签信息在内的 JSON 后，返回至客户端。

4）验签：可以本地对比 hash，也支持将数据上传至小米服务器远程验签。

整体来看，若证书生成及验签流程正确，这就是个精简版的密钥验证。目前小米仍未强制此项验证，因此可以通过改机型、关闭 framework 端服务等方式绕过此项检测，而真正破解则需要小米颁发的私钥。（像不像 PIF？）目前，第三方应用中仅发现 Hunter 搭载了该 SDK。

题外话：研究时顺便看了下内核中的 TEE 接口，发现 libmiriskmanager 有三种与内核通信的实现：高通机型使用高通提供的 QSEECOM，MTK机型一部分使用 MTK 与豆荚科技联合开发的 TEEi，还有少数机器使用小米自研 MiTEE（从驱动代码看，实际上基于 Linaro 提供的开源实现 OP-TEE 二次开发）。

BY 钱庄