MTK安全启动链全解析：从芯片到avb系统级验证
结合具体厂商，MTK的安全启动分为MTK芯片级安全启动链和Android AVB系统级验证链两大类。
一、整体信任链总览
MT8766采用两级嵌套链式信任，信任根锚定硬件eFuse，每一级验签通过后才会获得信任，进而验证下一级：
硬件eFuse（根公钥哈希）→ BROM验签 → Preloader → Preloader验签 → LK → LK执行AVB验签 → vbmeta.img → 链式验签 → vbmeta_system.img / vbmeta_vendor.img → 校验各业务分区
二、芯片级安全启动链（MTK私有签名体系）
这一级是MTK平台原生的硬件级安全启动，使用私有镜像格式，不遵循AVB规范，信任根为芯片eFuse中一次性烧录的根公钥哈希。
1. Boot ROM（BROM，片上固化固件）
- 镜像内公钥/哈希：不存储完整公钥，仅在芯片eFuse/OTP区烧录根公钥的SHA-256哈希（硬件信任根RoT Hash），不可篡改。
- 自身签名：无，代码固化在芯片硅片内，是整个系统的信任起点，不接受任何软件验证。
- 签名产生方：无。
- 验签执行者：自身，为平台第一级验签主体。
- 被验签对象：Preloader镜像。MT8766 平台的 Boot ROM（BROM）对 Preloader 的验签，核心分为「公钥哈希锚定」和「镜像签名校验」两步：先提取 Preloader 镜像中携带的完整公钥，计算其 SHA-256 哈希值，与芯片 eFuse（OTP 一次性可编程区）中预先烧录的根公钥哈希做比对；比对通过后，再用这把经过可信锚定的公钥，验证 Preloader 镜像主体的数字签名，最终确认镜像合法。
- 信任关系：作为硬件信任根，主动校验下一级Preloader的合法性，是整条信任链的起点。
2. Preloader 镜像
- 镜像内公钥/哈希：镜像头部携带完整的根公钥，用于自身签名校验。
- 自身签名：镜像头部附带MTK私有格式数字签名，签名覆盖Preloader全部有效代码与数据段。
- 签名产生方：设备厂商/方案商持有的根私钥（与eFuse中的根公钥哈希一一对应），量产阶段完成签名。
- 验签执行者：BROM。
- 验签逻辑：BROM先计算镜像中根公钥的哈希，与eFuse中的预置哈希比对；匹配后，再用该公钥验证Preloader的数字签名。
- 被验签对象：LK（Little Kernel）镜像。
- 信任关系：自身被BROM验证通过后获得信任，继续向下验证LK镜像，传递信任链。
3. LK（Little Kernel / Bootloader）镜像
- 镜像内公钥/哈希：
- 镜像头部携带芯片级签名公钥（可与根公钥为同一对，或为派生的子公钥，由厂商配置）；
- 代码内部预置AVB可信公钥哈希，用于后续系统级AVB验签。
- 自身签名：镜像头部附带MTK私有格式数字签名，覆盖LK核心代码与数据区。
- 签名产生方：设备厂商持有的芯片级签名私钥。
- 验签执行者：Preloader。
- 验签逻辑：Preloader使用已被信任的公钥，校验LK镜像的签名完整性。
- 被验签对象：vbmeta.img（AVB顶级元数据镜像）。
- 信任关系：承接芯片级信任链，自身验证通过后，成为Android AVB验证的执行主体，完成从芯片级到系统级的信任传递。
三、Android AVB 系统级验证链（标准AVB 2.0规范）
这一级遵循Google AVB 2.0标准，所有vbmeta镜像采用统一格式，信任锚点为LK中预置的AVB可信公钥哈希。
4. vbmeta.img（顶级主元数据镜像）
- 镜像内公钥/哈希：
- 镜像自身携带AVB根公钥（完整公钥），用于验证自身签名；
- 描述符区包含：boot、dtbo、recovery等分区的全量哈希（Hash描述符）；vbmeta_system、vbmeta_vendor的授权公钥哈希+镜像预期哈希（Chain链式描述符）；全局回滚版本号。
- 自身签名：镜像尾部的签名块（AVB Footer），签名覆盖「镜像头部 + 所有描述符数据」，算法为RSA 2048/4096 + SHA-256。
- 签名产生方：设备厂商持有的AVB根私钥，系统编译/OTA打包时完成签名。
- 验签执行者：LK中的libavb库。
- 验签逻辑：
- LK提取vbmeta中的AVB根公钥，计算其哈希，与LK内置的可信公钥哈希比对；
- 哈希匹配后，用该公钥验证vbmeta自身的数字签名；
- 校验回滚版本号，防止降级攻击。
- 被验签对象：
- boot、dtbo、recovery等小分区（全量哈希校验）；
- vbmeta_system.img、vbmeta_vendor.img（链式授权校验）。
- 信任关系：承接芯片级信任链，是系统分区验证的根节点，自身合法性由LK担保。
5. vbmeta_system.img（System分区元数据镜像）
- 镜像内公钥/哈希：
- 镜像自身携带System专属签名公钥；
- 描述符区包含system、system_ext分区的dm-verity哈希树根哈希（Hashtree描述符）、哈希树参数、数据块大小。
- 自身签名：镜像尾部签名块，签名覆盖自身头部+全部描述符数据。
- 签名产生方：设备厂商System团队持有的System签名私钥（独立于AVB根私钥）。
- 验签执行者：LK中的libavb库（基于主vbmeta的授权）。
- 验签逻辑（两步校验）：
- 完整性校验：计算vbmeta_system镜像的全量哈希，与主vbmeta.img中Chain描述符记录的预期哈希比对；
- 授权校验：提取vbmeta_system的签名公钥，计算哈希，与主vbmeta的Chain描述符中预置的授权公钥哈希比对；匹配后用该公钥验证自身签名。
- 被验签对象：system、system_ext分区（通过哈希树根哈希做运行时完整性校验）。
- 信任关系：由主vbmeta.img授权信任，独立负责System分区的验证，支持System分区单独OTA更新，无需修改主vbmeta。
6. vbmeta_vendor.img（Vendor分区元数据镜像）
- 镜像内公钥/哈希：
- 镜像自身携带Vendor专属签名公钥；
- 描述符区包含vendor、odm分区的dm-verity哈希树根哈希、哈希树参数。
- 自身签名：镜像尾部签名块，签名覆盖自身头部+全部描述符数据。
- 签名产生方：芯片厂商（MTK）或设备厂商Vendor团队持有的Vendor签名私钥。
- 验签执行者：LK中的libavb库（基于主vbmeta的授权）。
- 验签逻辑：与vbmeta_system完全一致，基于主vbmeta的Chain描述符完成授权与签名校验。
- 被验签对象：vendor、odm分区。
- 信任关系：由主vbmeta.img授权信任，独立负责Vendor分区验证，适配Project Treble的分区解耦更新。
补充：业务分区（boot.img / system.img / vendor.img）
- 自身不携带独立公钥与数字签名；
- boot等小分区的完整性由vbmeta.img中的Hash描述符担保；
- system/vendor等大分区的完整性由对应子vbmeta中的Hashtree描述符（根哈希）担保，运行时由内核dm-verity模块按需校验。
四、签名-验签关系汇总表
镜像名称 | 签名由谁签发（私钥持有方） | 由谁执行验签 | 验签的信任依据 | 验签通过后验证谁 |
Preloader | 设备厂商根私钥 | BROM | eFuse根公钥哈希 | LK镜像 |
LK | 设备厂商芯片级签名私钥 | Preloader | 芯片级根公钥 | vbmeta.img |
vbmeta.img | 设备厂商AVB根私钥 | LK | LK内置AVB公钥哈希 | boot等小分区 + 子vbmeta镜像 |
vbmeta_system.img | 设备厂商System签名私钥 | LK（libavb） | 主vbmeta的Chain授权 | system/system_ext分区 |
vbmeta_vendor.img | MTK/厂商Vendor签名私钥 | LK（libavb） | 主vbmeta的Chain授权 | vendor/odm分区 |
五、关键设计说明
- 硬件只存哈希，不存完整公钥：eFuse中仅烧录公钥哈希，避免攻击者直接替换镜像中的公钥绕过验证，确保信任根不可篡改。
- 公私钥分层隔离：芯片级密钥、AVB根密钥、System/Vendor子密钥分层管理，不同团队持有不同密钥，降低密钥泄露风险。
- 链式解耦适配OTA：子vbmeta独立签名的设计，让System、Vendor分区可以单独更新、单独签名，完美匹配Project Treble的分区解耦架构，也是MT8766这类入门平台支持独立厂商定制的核心基础。