LiteRT 与 ONNX 模型资产完整性治理：覆盖模型、元数据、算子库、预处理与版本耦合的清单生成与摘要校验

模型资产的表面完整性与实际缺口

移动端应用可以用 APK 签名验证包内文件，但动态下载到应用数据目录的模型和元数据需要额外的来源与摘要校验。评审时先列出每个资产的交付位置和信任根，再确认加载代码是否逐项核对；不能只看主模型文件存在就假定整套推理输入完整。

更深一层的问题是，即使设备对模型文件做了哈希校验，也只覆盖了主文件。LiteRT 模型内嵌的 metadata 包含输入归一化参数、标签文件引用等关键信息，它们可能在模型分发后被独立替换。ONNX 模型则依赖外部算子实现库，如果运行时包体中的共享库被篡改，模型文件自身依旧干净，校验也不会失败，攻击者可以制造看似合法、实则异常的推理环境。

模型、预处理代码、算子库和运行时可能分别更新。若兼容关系只靠人工记忆，某次发布就可能遗漏联动检查，出现组件各自完整、组合行为却变化的情况。清单应记录经过验证的版本组合，并由回归样本确认输出，而不是把摘要校验当成兼容性证明。

• 确认模型加载路径覆盖 APK 内置、Asset、文件系统和网络下载所有来源
• 对每个来源的模型文件单独计算摘要，并与可信渠道提供的预期值比对
• 检查是否仅校验了主模型文件而放过元数据和关联外部文件
• 记录模型所依赖的运行环境版本号，并在清单中声明版本耦合要求

应纳入治理的五类资产

完整的模型资产清单应包含五类实体。首先是模型主文件，比如.tflite 或.onnx 序列化文件，这是推理的直接载体。第二类是元数据块及关联文件，LiteRT metadata 内可引用词汇表、标签文件，它们对正确解析输入输出至关重要。第三类是算子实现库，如 LiteRT delegate 共享库或 ONNX Runtime 的 Execution Provider 动态库。第四类是预处理与后处理配置，例如归一化均值、标准差、tokenize 规则或后处理阈值，即便它们存放在 JSON 或代码常量中，一旦被篡改也会破坏推理语义。

第五类是版本耦合元信息，它描述模型依赖的运行时、算子库、配置文件的最低版本范围。缺少这类元信息，设备无法判断升级后的模型是否能与现有算子集协同工作。反之，如果只校验前四类资产但不记录它们之间的版本关联，清单校验仍会被混搭攻击绕过：攻击者可组合旧版模型、新版预处理和旧版算子库，所有文件摘要都有效，但组合起来却产生错误结果。

治理起点是生成一份涵盖这五类的结构化清单，并对其签名或附加可信摘要。清单格式应可机读，支持自动化校验。构建流水线或安全运营平台应能根据清单自动提取每个资产的预期哈希值，并写入分发元数据。任何一类资产的缺失或摘要不一致都应导致完整性验证失败，不能区别对待，必须建立统一的阻断或降级机制来响应此类异常。

LiteRT 中的元数据解析与关联文件校验

根据 LiteRT 官方文档，模型元数据可携带输入输出张量描述、归一化参数、标签文件等信息，并以 FlatBuffer 结构内嵌或引用外部文件。这一设计原本是为了让推理管道能自动适配输入格式，但在安全视角下它引入了依赖关系：模型文件字节本身并不包含 label.txt 或 vocab.txt 的完整内容，校验模型 SHA‑256 无法察觉这些外部文件的变化。

如果攻击者或错误的分发流程替换了 labels.txt，而模型文件完好，分类器可能在特定类别上持续输出错误标签，而所有常规监控只关注模型文件摘要，这就形成一个持久且隐蔽的攻击面。类似风险也存在于归一化参数：若均值和标准差被微小幅度修改，在量化推理中可能造成较大输出偏差，但同样不会触发模型文件校验。

工程判断：可通过 TensorFlow Lite Support Library 或 flatc 工具在构建阶段解析 metadata，列出所有关联的外部文件路径和预期大小，并将其加入资产清单。设备侧不仅要核对模型文件摘要，还应依据清单逐一验证这些关联文件的哈希值。如果 metadata 自身包含内嵌参数，也需明确其预期哈希或纳入 collateral 文件进行整体签名，防止 metadata 被局部重写。

• 使用 flatc 或 TFLite 支持库提取 metadata 中的 associated files 列表
• 对每个关联文件计算 SHA‑256，并与清单中记录值比对
• 验证 metadata 自身字节段的哈希，确保内嵌参数未被修改
• 加载模型前执行以上检查，失败则阻止推理管道启动

ONNX Runtime Mobile 的算子依赖与包体约束

ONNX Runtime Mobile 在设备端装载 ONNX 模型，其执行能力直接受编译时包含的算子 kernel 和可选的 Execution Provider 限制。资料明确指出，运行时支持不提供内置的模型签名、授权或防回滚能力。因此，攻击者可以替换整个 onnxruntime 动态库，裁剪某些算子，使模型回退到参考实现甚至直接失败，而检查模型文件本身并不会发现该风险。

治理这类风险需要将算子实现库视为完整性保护对象。在构建阶段，应记录模型所需的算子集合以及对应的最低 ORT 版本和 Provider 要求，写入清单。设备端在初始化推理引擎前，不仅要核对.onnx 文件摘要，还应验证 libonnxruntime.so 或相应 delegate 库的摘要，并对比清单中的算子要求与运行时实际支持的算子集合。

只校验模型文件时，无法得知当前运行时是否仍包含模型需要的算子，也无法确认是否进入了回退路径。ONNX 移动端部署应把算子集合或运行时包版本写入资产清单，加载后再记录执行提供程序与输出回归结果；摘要正确只说明文件未变，不说明组合性能和精度符合预期。

更新分发时的回滚、冻结与混搭风险

TUF（The Update Framework）规范要求更新客户端验证目标文件的签名、版本、过期时间，并执行一致快照检查。这一框架可直接用于模型 OTA 分发：若只用普通 HTTPS 下发模型但未实施版本验证，攻击者可拦截更新并回滚到含有已知漏洞或后门的旧模型，而客户端却认为是合法更新，导致安全风险长期潜伏。

在 AI 模型场景中，回滚攻击可能更具欺骗性。旧模型可能与当前预处理逻辑、后处理阈值不兼容，其结果在业务上不可接受，但如果没有版本耦合校验，App 无法分辨这种不兼容。同样，混搭攻击中攻击者可组合新版模型、旧版预处理配置和旧算子库，所有单独文件的签名都可验证通过，但三者组合却构成一个错误推理管道。

应用 TUF 时，需要针对模型资产设计角色和元数据层次，将模型文件、关联配置、算子库和兼容性信息分别定义为独立目标或 unified bundle。一致快照可防止客户端同时看到新旧元数据，但前提是服务端严格遵循规范生成和分发这些元数据。工程判断：必须为每个目标分配单调递增的版本号，并将该版本号与 App 侧的兼容性矩阵绑定。

构建证明与供应链签名的适用边界

SLSA Provenance v1.1 和 in‑toto Attestation Statement v1 提供了将模型产物的构建过程与产物摘要绑定的标准方式。构建证明可记录源码仓库、构建环境参数、依赖材料以及最终产物的 SHA‑256，为发布管道的准入控制提供可验证的来源追溯。这有助于阻断构建流水线内部的投毒或误打包，但不能替代设备运行时的完整性检查。

依据 in-toto 资料，证明声明将产物摘要与带类型的声明载荷绑定，防止声明与实际包不匹配，但声明格式本身不保证声明内容的真实性，仍需可信签名者和门禁核验。同理，SLSA provenance 只证明记录的构建过程，不能单独证明当前设备上加载的模型就是构建证明中所描述的那个文件，因为设备侧文件可能在传输后或安装后被替换。

实际工程中，构建证明应作为资产清单生成的一部分，将预期摘要集成到 TUF 或自有分发元数据中。设备侧使用存储在安全区域（如 Android Keystore）的公钥，验证资产清单的签名，然后依据清单中的摘要逐项核对文件。若设备不支持硬件信任根，签名验证的可靠性会降低，但仍优于完全忽略构建证明的做法，需结合多层防御策略。

清单生成与摘要验证的自动诊断代码

下面的 Bash 脚本读取 manifest 中的 SHA-256 和相对文件名，逐项核对资产目录。文件缺失或摘要不符时返回非零状态并打印具体条目，可直接用于 CI 的产物检查。

清单采用两列文本：第一列是 SHA-256，第二列是相对文件名；空行和以 # 开头的注释会被跳过。它只回答“文件内容是否与清单一致”，版本兼容、算子依赖和运行输出仍由兼容矩阵与设备回归检查。

在移动端生产环境中，应进一步对 manifest 文件本身做签名保护。如果 manifest 可以被改写，校验将失去意义。工程判断：可将 manifest 存放在可信位置（如 APK 内部资源，已被 APK 签名涵盖），或通过 TUF 取得可信的 manifest。脚本本身不应包含敏感逻辑，仅作为执行校验的工具存在。

#!/usr/bin/env bash
set -euo pipefail
# 验证模型资产完整性的安全诊断脚本，不执行任何破坏性操作

MODEL_DIR="${1:?请提供模型资产目录作为第一个参数}"
MANIFEST="$MODEL_DIR/manifest.txt"

if [ ! -f "$MANIFEST" ]; then
  echo "错误：找不到清单文件 $MANIFEST" >&2
  exit 1
fi

# 初始化错误数组
errors=()

# 逐行读取清单，跳过注释和空行
while IFS= read -r line; do
  [[ "$line" =~ ^# ]] && continue
  [[ -z "$line" ]] && continue
  expected_sha=$(echo "$line" | awk '{print $1}')
  file_path=$(echo "$line" | awk '{print $2}')
  
  if [ ! -f "$MODEL_DIR/$file_path" ]; then
    errors+=("缺失文件：$file_path")
    continue
  fi

  # 计算实际哈希值，仅保留十六进制部分
  actual_sha=$(sha256sum "$MODEL_DIR/$file_path" | cut -d' ' -f1)
  if [ "$expected_sha" != "$actual_sha" ]; then
    errors+=("哈希不匹配：$file_path")
  fi
done < "$MANIFEST"

# 汇总错误并输出
if [ ${#errors[@]} -gt 0 ]; then
  for err in "${errors[@]}"; do
    echo "错误：$err" >&2
  done
  exit 1
fi

echo "所有模型资产验证通过。"

工程实施建议与失败处理策略

清单分发通道的签名和防回滚容易被忽略。清单随 APK 发布时可由 APK 签名覆盖；动态模型使用的清单则需要独立验证签名、版本与过期时间。工程判断：可借鉴 TUF 的签名元数据设计，并保留一个随应用发布的最低可信基线；具体信任根仍由项目更新架构决定。

校验失败的响应策略不能一概而论。对于运行在安全敏感场景的模型，任何资产不匹配都应立即阻止推理，并通知监控系统。对于内容推荐等容忍度稍高的场景，可回退到内置的、经过同等完整性校验的兜底模型，确保服务不中断。无论何种策略，严禁静默吞咽错误或仅打出日志警告，必须有明确的动作响应。

版本耦合治理建议在设备端维护一个轻量级兼容性矩阵，矩阵数据由 CI 在构建时填入资产清单。加载模型前，比较清单中声明的算子库、预处理配置和运行时版本与设备当前环境，若任何一项低于要求，则视为完整性失败或按预定义回退路径处理。矩阵应覆盖回滚场景：允许加载版本不低于已知安全基线的旧组合，但禁止任何未经验证的跨版本拼接。