先看结论与判断条件

  • 工程判断:只计算模型文件哈希不会覆盖独立存放的 tokenizer、归一化参数或标签文件;具体资产路径需从项目清单确认。
  • 工程判断:词表变化可能改变 token 与 ID 的映射;本文来源未证明一定生成完全相反的意图,也未证明日志必然没有异常。
  • 工程判断:归一化参数变化可能改变视觉模型输入分布;是否造成定向误判或绕过检测,需要用目标模型与样本验证。
  • 工程判断:标签映射变化会改变类别 ID 的业务解释;本文没有项目证据证明存在攻击者重命名高风险类别的场景。
  • 工程判断:后处理阈值变化可能影响检测框数量或置信度;对具体业务的影响应由目标数据集回归确认,不外推到自动驾驶。
  • 工程判断:LiteRT、ONNX Runtime Mobile 与 Core ML 的所引资料未承诺自动校验应用独立分发的配套资产;具体行为需按集成方式核对。
  • 成组摘要、签名版本和运行回归可共同发现资产混搭与回滚;这是一套工程方案,不是防止所有替换行为的唯一手段。
  • 工程判断:独立分发的配置文件应由应用更新链维护一致性;本文来源未直接证明平台模型加密对所有配置文件的覆盖范围。

1. 保护边界为何必须延伸到预处理资产

在移动端 AI 部署架构中,模型文件仅仅是推理系统的一个组成部分,而非全部。Google AI Edge LiteRT 文档明确指出,模型元数据可携带输入输出描述、归一化参数、标签及关联文件。如果安全策略仅对主模型二进制文件进行哈希校验,攻击者完全可以通过替换与之搭配的词表或预处理配置文件来操纵整个推理流水线,而不会触发任何针对模型文件的完整性告警。这种攻击面往往被传统安全扫描所忽略。

攻击者可以利用应用更新机制、文件热加载功能或本地资源目录的写权限来篡改这些轻量级资产。例如,一个文本生成应用可能从外部存储加载词表文件,若该文件未经签名或校验,便极易被替换。The Update Framework 规范要求更新客户端验证签名、版本和快照以防止回滚与混搭,但它主要管理分发渠道的安全;一旦文件落入本地存储且应用在加载时不加校验,篡改便有机可乘,导致运行时加载了恶意配置。

业务后果可能极为严重且难以追溯:金融情感分析模型若使用被篡改的词表,可能将负面报道映射为正面评价,从而错误驱动交易决策;客服系统输出的回复语义若发生反转,将直接造成品牌合规风险。这些风险的根源在于防护范围仅覆盖了模型权重,却未将同等重要性赋予其配套资产。因此,完整性边界必须外扩至所有影响推理语义的静态配置,才能构建有效的防御体系。

许多开发团队误以为只要模型文件本身未被修改,推理结果就是可信的。然而,预处理阶段的任何参数变化都会直接改变输入数据的分布特征,进而影响模型内部的激活模式。即使模型权重完好无损,错误的输入表示也会导致输出结果偏离预期。这种依赖关系的断裂使得单独保护模型文件变得毫无意义,必须将预处理环节纳入统一的安全视图中进行管控。

在实际工程中,预处理资产往往以明文形式存储在应用沙箱或共享存储中,缺乏访问控制。攻击者无需获取 root 权限,仅需利用应用自身的文件读写漏洞或社会工程学手段即可替换这些文件。由于这些文件通常较小且结构简单,修改过程极快且不留痕迹。若不建立严格的加载前校验机制,应用将在不知情的情况下执行被污染的推理任务,导致业务逻辑被暗中操控。

此外,随着模型迭代频率的增加,配套资产的版本管理变得愈发复杂。不同版本的模型可能需要特定版本的词表或归一化参数,若发生版本混搭,即便文件未被恶意篡改,也可能导致推理性能下降或结果异常。因此,保护边界不仅要防恶意替换,还要防版本错配。这要求安全策略必须具备版本感知能力,确保模型与其配套资产在版本上严格匹配,避免因配置不一致引发的隐性故障。

表 1 预处理与配套资产被篡改的业务影响
资产类型典型内容替换方式示例业务后果
词表/分词器配置vocab.txt, tokenizer.json, 合并规则替换为包含恶意映射的词表文本输出语义错误,安全过滤绕过,用户接收有害内容
归一化参数mean/std 值,scale/offset轻微修改均值和标准差图像识别精度下降,安全检测模型漏判,误分类造成自动化决策错误
标签映射文件labels.txt, class_map将高风险标签映射到无害标签监控系统将危险行为标记为安全,安防漏报,合规失效
后处理参数NMS 阈值、anchor 配置、解码参数修改阈值使检测框消失自动驾驶目标丢失、安防区域漏报,业务依赖的输出失效
  • 是否已识别所有影响推理语义的外部配置文件?
  • 是否建立了模型与配套资产的版本绑定关系?
  • 是否在加载前对所有资产执行了完整性校验?
  • 校验失败时是否有明确的阻断和报警机制?

2. 词表被替换如何重塑文本推理结果

Tokenizer 负责将输入文本拆分为 token 并映射为 ID,模型推理后在解码阶段再将 ID 序列还原为文本。如果攻击者替换了词表文件,相同的 ID 将被映射到截然不同的词条或子词。例如,将 ID 为 123 的词从“同意”改为“拒绝”,模型自身权重不变,生成的句子却传递相反意图。由于模型输出 logits 没有异常,传统模型校验手段完全失效,难以通过常规监控发现异常。

在自然语言处理任务中,词表替换的影响难以被自动化监控发现。对话系统可能不断输出语法正确但内容危险的文本;情感分类结果经后处理显示为高置信度,实际却是错误极性。这类攻击不需要高深技术,只需读写本地文件系统权限,安全团队很容易忽略这种低级别篡改。攻击者甚至可以利用开源词表中的相似结构进行微调,使异常更加隐蔽,长期潜伏在系统中而不被发现。

保护词表的最低要求是在模型加载前计算其哈希并与预期值比对,并且将词表文件与模型一同纳入签名机制。若应用允许动态更新词表,必须采用类似 TUF 的版本化分发,确保不会因回滚到旧词表面导致安全漏洞。任何未经验证的词表加载都应视为风险入口,必须坚决阻断。只有将词表视为核心资产的一部分,才能有效防止此类语义层面的劫持攻击。

词表的结构复杂性也增加了保护难度。现代分词器不仅包含词汇映射,还可能包含合并规则、特殊 token 定义等复杂逻辑。攻击者只需修改其中一条规则,即可改变分词粒度,进而影响模型对长句的理解能力。例如,将常用短语强行拆分,可能导致模型无法识别上下文关联,产生断章取义的回复。这种细粒度的篡改更难被哈希校验发现,需要更细致的结构化校验策略。

在某些场景下,词表文件可能非常大,全量哈希计算会带来一定的启动延迟。为了平衡安全与性能,可以采用分层校验策略:首先校验词表文件的整体哈希,若通过再抽样校验关键片段。但需注意,抽样校验不能替代全量校验,只能作为辅助手段。对于高安全需求的场景,必须坚持全量哈希校验,确保每一个字节都未被篡改,宁可牺牲少量性能也要保证推理链路的纯净。

此外,词表的更新频率通常高于模型权重,频繁的更新增加了校验逻辑的复杂度。每次更新词表时,都必须同步更新对应的哈希值和签名,并确保分发渠道的安全。若更新过程中出现网络中断或文件损坏,可能导致新词表无法通过校验,进而引发服务不可用。因此,需要设计完善的回滚机制,在校验失败时自动切换到上一版本的合法词表,保障业务的连续性。

表 2 词表篡改的典型场景与检测难点
篡改类型具体操作对推理的影响检测难点
词汇映射替换修改特定 ID 对应的单词生成文本语义反转,情感极性错误模型输出流畅,无异常报错
合并规则修改调整子词合并逻辑分词粒度变化,上下文理解偏差需深入分析分词结果才能发现
特殊 Token 增删添加或删除控制符模型指令遵循能力受损,输出失控特殊 Token 不可见,难以直观排查
编码格式篡改更改字符编码映射生成了乱码或不可读字符易被误认为模型崩溃或兼容性问题
  • 词表文件是否已纳入版本控制系统?
  • 是否对词表文件进行了数字签名?
  • 加载前是否验证了词表文件的哈希值?
  • 是否有机制防止词表版本回滚?

3. 归一化参数篡改对视觉模型的影响

图像输入模型前通常需经过预处理,包括缩放和归一化。归一化参数(如均值和标准差)保存在模型元数据或独立的配置文件中。LiteRT model metadata 规范允许携带这些值,但并未强制要求运行时在推理前对它们做完整性校验。攻击者可以微调这些参数,使图像整体偏色或对比度变化,从而导致模型误判。这种攻击方式极其隐蔽,因为图像在人眼看来可能并无明显异常。

例如,安防摄像头的人脸识别模型若被篡改归一化参数,可能将特定光照下的合法人员拒绝识别,但系统日志中模型推理置信度仍显示正常,管理员无法从面板上发现异常。在工业缺陷检测中,此类篡改可导致大量漏检,造成产品质量危机。这种攻击不会修改模型文件,绕过所有基于模型哈希的安全措施,使得传统的文件完整性监控形同虚设,无法发挥应有的防护作用。

解决方案要求任一归一化参数均与模型版本绑定,并在模型实例化时强制校验。即使参数嵌入模型元数据,也需要核对元数据块的完整性,而不是仅依赖元数据本身的读取。如果由应用层以配置文件形式提供,则应将文件哈希纳入资产清单。Apple Core ML 的加密仅保护模型文件本身,若归一化参数以单独 plist 文件存在,则不在加密范围内,必须由应用层额外保护。

归一化参数的敏感性在于其对数值精度的极高要求。浮点数的微小差异可能在深层网络中被逐级放大,最终导致输出结果的巨大偏差。攻击者无需大幅修改参数,只需在最后一位小数上做手脚,即可达到预期效果。这种细微的改动很难被人眼察觉,甚至难以通过简单的统计测试发现。因此,必须采用高精度的哈希算法进行校验,确保参数值的每一位都准确无误。

在多模型协同工作的场景中,不同模型可能依赖不同的归一化标准。若全局配置文件被篡改,可能导致所有依赖该配置的模型同时失效,引发系统性风险。因此,建议采用模型专用的配置文件,避免共享配置带来的连锁反应。同时,应对配置文件进行访问控制,限制只有授权进程才能读取和修改,减少被恶意篡改的可能性。

此外,归一化参数的校验应与图像预处理流程紧密结合。在读取参数后,应立即进行合法性检查,如范围验证、类型检查等,防止非法参数导致程序崩溃或未定义行为。若发现参数异常,应立即终止推理流程,并记录详细的错误日志,以便后续审计和追踪。通过多层次的校验机制,可以最大程度地降低归一化参数被篡改的风险。

表 3 归一化参数保护策略对比
保护方式实施位置防御能力局限性
嵌入模型元数据模型文件内部随模型加密一起保护需校验元数据块完整性,否则无效
独立配置文件哈希应用层加载前可检测文件替换无法防御内存中参数篡改
硬编码在代码中编译进二进制难以被外部修改更新参数需重新发布应用
远程动态下发服务端控制灵活更新,可实时撤销依赖网络,存在中间人攻击风险
  • 归一化参数是否已绑定模型版本?
  • 是否在实例化前校验了参数完整性?
  • 是否对参数值进行了范围合法性检查?
  • 是否有备用参数以防主参数损坏?

4. 标签映射劫持导致业务误判

分类模型输出是一组概率分布,最终通过标签映射文件转换为人类可读的类别名称。该映射文件通常是一个简单的文本文件,每行对应一个类别。攻击者可轻松替换此文件,例如将索引 0 从“正常”改为“攻击”,或将索引 1 从“恶意”改为“安全”。结果,模型的实际分类结果被曲解,后端业务逻辑依据错误标签执行动作,导致决策完全背离初衷。

在金融反欺诈场景中,若标签映射被篡改,系统可能将高风险交易标记为正常,直接跳过人工审核。由于模型本身的推理性能未受影响,监控系统无法检测到这种语义层面的劫持。攻击者甚至可采用渐进式修改,先替换少部分标签,逐步使业务偏离正确方向,隐蔽性极高。这种攻击利用了业务逻辑对标签名称的信任,绕过了模型本身的防御机制。

ONNX Runtime Mobile 等运行时没有提供任何机制来验证外部标签文件的完整性;Core ML 若使用编译后的 mlmodelc,标签可能已包含在内,但未编译加工的文件依然存在被替换风险。为此,开发者必须自行实施标签文件的哈希校验,并将其视为关键资产或同等重要的完整性保护对象。对标签的任何改动都应触发模型拒绝服务,防止错误标签流入业务系统。

标签文件的结构简单使其极易被编辑和替换。攻击者只需使用文本编辑器即可修改内容,无需复杂的工具或专业知识。因此,必须对标签文件施加严格的访问控制和完整性校验。建议将标签文件与模型文件打包在一起,并进行统一签名,确保两者的一致性。任何单独的标签文件更新都应被视为高风险操作,需经过严格的审批和验证流程。

在多语言支持的应用中,标签文件可能有多个版本,分别对应不同的语言环境。攻击者可能只篡改其中一种语言的标签文件,导致特定用户群体受到误导。这种针对性的攻击更难被发现,因为其他语言的用户不受影响。因此,必须对所有语言的标签文件进行同等强度的保护,确保无论用户使用何种语言,都能获得准确的分类结果。

此外,标签文件的更新应与模型更新同步进行。若模型结构发生变化,标签顺序或内容可能随之调整。若只更新模型而未更新标签文件,可能导致标签错位,产生严重的业务错误。因此,应建立模型与标签文件的强绑定关系,确保两者版本严格匹配。在加载时,应同时校验两者的版本号和哈希值,防止版本不匹配引发的隐性故障。

表 4 标签文件安全风险与应对措施
风险点攻击手法潜在后果应对措施
文件未签名直接替换文本内容类别名称错误,业务逻辑误判实施数字签名,加载前验签
版本不匹配混用新旧版本标签索引错位,分类结果混乱绑定模型版本,强制一致性检查
多语言遗漏仅篡改部分语言文件特定用户群受误导全语言覆盖校验,无死角防护
动态加载漏洞通过网络注入恶意标签远程操控分类结果限制加载源,仅允许本地可信路径
  • 标签文件是否已纳入完整性校验范围?
  • 是否验证了标签文件与模型的版本一致性?
  • 是否对所有语言版本的标签文件进行了保护?
  • 是否限制了标签文件的加载来源?

5. 后处理配置被篡改的连锁效应

目标检测模型和语音识别模型常依赖后处理参数,如非极大值抑制(NMS)的 IOU 阈值、锚框尺寸、解码器超参数等。这些参数决定了最终输出结果的形状和过滤方式。攻击者一旦篡改 NMS 阈值,可导致检测框数量骤变:例如,将阈值从 0.5 改为 0.99,几乎抑制所有重叠框,使安防系统看不到入侵者。这种篡改直接影响了模型的可用性,使其失去实际价值。

自动驾驶路况感知中,若后处理参数被恶意调整,行人检测召回率可能暴跌,直接危及交通安全。与归一化参数类似,这些配置通常以 JSON 或 YAML 方式存储,独立于模型主体,因而不在模型加密或签名的覆盖范围内。仅有应用层校验才能防止此风险。攻击者利用这一盲区,可轻易使高精度的模型变得毫无用处,甚至产生危险的误导信息。

后处理配置的校验应与模型验证成组进行,构建一个综合清单,包括所有影响推理输出的外部文件。在流水线中,任何后处理参数的变动都必须触发版本变更与重新签名。运行时在加载模型之前,需完成全量核对,如违规则禁止启动并上报异常。这种严格的校验机制虽然增加了开发成本,但对于保障业务安全至关重要,是不可省略的关键环节。

后处理参数的种类繁多,且不同模型所需的参数各异,这增加了统一管理的难度。建议采用标准化的配置文件格式,明确定义每个参数的含义、类型和取值范围。在加载时,不仅要校验文件的完整性,还要校验参数的合法性。例如,阈值必须在 0 到 1 之间,锚框尺寸必须为正数等。通过多重校验,可以有效防止因参数错误导致的推理异常。

在某些高级攻击场景中,攻击者可能动态调整后处理参数,以适应不同的输入数据。例如,针对特定类型的图像自动调整 NMS 阈值,以最大化漏检率。这种自适应攻击更难防御,需要引入行为分析机制,监测后处理参数的变化趋势。若发现参数频繁变动或偏离正常范围,应及时报警并采取措施,防止攻击者得逞。

此外,后处理参数的校验结果应记录在案,便于后续审计和追溯。若发生安全事故,可通过日志快速定位是否为后处理参数被篡改所致。同时,应定期对后处理配置进行审查,确保其符合最新的安全标准和业务需求。通过持续的监控和优化,不断提升后处理环节的安全性,筑牢推理链路的最后一道防线。

表 5 后处理参数篡改影响分析
参数类型篡改效果业务影响检测建议
NMS 阈值抑制过多或过少检测框目标漏检或误检增多监控检测框数量分布异常
置信度阈值过滤掉低分目标或保留噪声召回率下降或误报率上升统计置信度分布直方图
锚框尺寸改变默认检测尺度特定大小目标检测失效对比不同尺度目标的检出率
解码器参数坐标转换错误检测框位置偏移或变形可视化检测框与真实物体对齐情况
  • 是否将所有后处理参数纳入校验清单?
  • 是否对参数值进行了合法性范围检查?
  • 是否监控了后处理参数的动态变化?
  • 是否记录了参数校验的详细日志?

6. 主流移动端推理框架的保护缺口

LiteRT 具备完善的模型元数据机制,支持在模型中嵌入归一化参数与标签关联,但并未提供自动的完整性验证钩子,开发者需自行实现签名校验。Google AI Edge LiteRT 明确,运行时加载模型后通过 delegate 执行推断,但磁盘加密不能消除内存中的可用表示,因此模型保护不能止步于文件加密。开发者必须意识到,框架提供的功能仅是基础,完整的安全策略需由应用层补充。

ONNX Runtime Mobile 面向 Android 和 iOS 提供模型装载和执行提供程序,但在其文档中指出,支持受限于算子集与包体大小,并未内建模型签名或授权功能,更遑论对配套资产的管理。开发者若仅依赖运行时,则对模型及预处理文件毫无保护能力。这意味着在使用 ONNX Runtime Mobile 时,必须自行构建一套完整的资产校验体系,不能有任何侥幸心理。

Apple Core ML 可对模型进行编译并可选加密,但其文档只涉及模型集成、装载和预测,框架本身不承诺运行时不可提取,更不会保护独立于模型文件存在的预处理资产。综合来看,所有主流框架都将安全责任推给了应用开发者,这意味着完备的校验策略必须脱离框架原生机制,由业务自行实现。依赖框架自带的安全功能是远远不够的,必须主动出击。

框架的设计初衷往往是追求性能和兼容性,安全性常被置于次要位置。例如,为了加快加载速度,框架可能跳过某些校验步骤;为了支持更多硬件,框架可能开放过多的接口。这些设计选择在提升性能的同时,也引入了潜在的安全风险。开发者在使用这些框架时,必须充分了解其安全边界,针对性地补充防护措施,填补框架留下的安全空白。

不同框架对配套资产的处理方式各异,增加了统一保护的难度。有的框架将参数嵌入模型文件,有的则要求外部配置文件。开发者需要根据所用框架的特点,制定相应的保护策略。对于嵌入式的参数,需校验模型文件的整体完整性;对于外部文件,则需单独校验其哈希值和签名。无论哪种方式,都不能遗漏任何一个可能影响推理结果的资产。

此外,框架的更新也可能带来新的安全挑战。新版本可能引入新的文件格式或配置项,若未及时更新校验逻辑,可能导致新资产未被保护。因此,开发者应密切关注框架的更新动态,及时调整安全策略。同时,建议在应用中预留扩展接口,以便快速适配新的资产类型,确保持续的保护能力。通过动态调整和持续优化,应对不断变化的安全威胁。

表 6 移动端 AI 运行时对配套资产保护的支持界限
运行时模型元数据承载Tokenizer 保护归一化参数保护标签保护后处理参数保护
LiteRT支持嵌入归一化参数和标签(模型元数据)不提供单独词表文件校验机制仅可存入元数据,应用需自己验证元数据完整性同左,无自动校验无支持,需应用外部管理
ONNX Runtime Mobile通过模型 Proto 可携带输入归一化信息无内建保护无内建保护无内建保护无内建保护
Core ML部分参数编译进 mlmodelc无词表概念,但可带标签,文件可独立编译后融入模型,但未编译文件无保护同左无内置保护
自定义 C++/Rust 引擎取决于实现完全由应用负责完全由应用负责完全由应用负责完全由应用负责
  • 是否了解所用框架的安全边界?
  • 是否针对框架缺口制定了补充策略?
  • 是否对所有外部资产实施了独立校验?
  • 是否跟进了框架更新带来的安全变化?

7. 成组一致性校验的工程实施

要实现完备的配套资产保护,必须建立一份包含所有推理所需静态文件的清单(Manifest),清单中分别记录模型文件、词表、归一化配置、标签文件、后处理参数文件的加密哈希值及版本号。每次启动或模型热加载时,应用根据清单逐项校验实际文件的哈希,任何不匹配均应立即终止加载并进入安全模式。这种集中式的校验机制能有效防止资产被替换或混搭。

清单本身需要防止被篡改,最佳实践是用设备内置的信任锚(如应用签名或专用密钥)对其进行数字签名,并在运行时验签。更新流程可借鉴 The Update Framework,对资产包整体签名,防止攻击者混搭不同版本的资产。若发现版本回退或过期,应拒绝启用旧配置。通过签名和版本控制的双重保障,确保清单的真实性和时效性,为校验提供可靠依据。

实际代码实现中,校验逻辑应完全脱离于推理框架,在模型实例化之前执行。如果设备支持硬件安全模块,可将公钥或预期哈希值存储在安全区域。以下代码示例展示了一个基本的校验脚本:它读取 JSON 格式清单,计算每个指定资产的 SHA-256 哈希并与预期值比对,任何失败都将以非零状态退出。这种独立的校验模块能确保在推理开始前就拦截住潜在的威胁。

清单的格式设计应简洁明了,便于解析和维护。建议使用 JSON 或 YAML 格式,清晰列出每个资产的路径、算法、预期哈希值和版本号。同时,应预留扩展字段,以便未来添加新的校验属性。在生成清单时,应自动遍历所有相关目录,确保无遗漏。任何手动修改清单的行为都应被禁止,防止人为失误导致校验失效。

校验过程的效率也是需要考虑的因素。对于大型资产文件,全量哈希计算可能耗时较长。可采用增量校验策略,仅校验发生变化的文件部分。但需注意,增量校验的实现复杂度较高,且可能存在安全隐患。因此,在资源允许的情况下,仍推荐全量校验,以确保万无一失。对于性能敏感的场景,可考虑在后台线程异步执行校验,减少对主线程的阻塞。

此外,校验结果的处理也需谨慎。若校验失败,应立即停止加载,并清除已加载的部分数据,防止污染内存。同时,应记录详细的错误信息,包括失败的文件名、预期哈希、实际哈希等,便于后续排查。对于频繁校验失败的情况,应触发高级别报警,提示可能存在持续的攻击行为。通过严谨的错误处理机制,最大化校验的价值。

表 7 配套资产校验策略比较
策略覆盖范围实施复杂度防范混搭攻击限制
仅对模型权重校验只覆盖主模型,遗漏所有配套资产低(可用平台现有功能)无法防范攻击者可任意替换资产
分别校验每个资产可覆盖所有文件,但各校验逻辑分散中等若未联动版本,可混搭不同版本资产维护成本高,易遗漏新资产
签名清单集中校验覆盖所有资产,统一入口较高,需设计清单格式与签名可结合版本号防止混搭需额外安全存储签名公钥
结合 TUF 委派的端到端校验覆盖分发和本地加载全链路高,需部署更新服务器与客户端彻底防范分发环节替换与回滚无法防御加载后的内存攻击
  • 所有外部资产文件是否已纳入清单?
  • 清单文件是否经过数字签名且公钥受保护?
  • 验证逻辑是否在模型加载前执行?
  • 校验失败后是否有安全的降级或拒绝策略?
  • 更新分发是否使用版本化快照防止混搭?
校验清单和资产一致性的诊断脚本
#!/usr/bin/env python3
"""Diagnose integrity of model companion assets via hash manifest."""
import hashlib
import json
import os
import sys

MANIFEST = "assets-integrity.json"

def file_digest(path, algo="sha256"):
    h = hashlib.new(algo)
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(65536), b""):
            h.update(chunk)
    return h.hexdigest()

def verify(manifest_path):
    if not os.path.exists(manifest_path):
        print(f"Manifest not found: {manifest_path}", file=sys.stderr)
        sys.exit(2)
    
    with open(manifest_path, "r", encoding="utf-8") as fh:
        plan = json.load(fh)
    
    errors = []
    base_dir = plan.get("base_dir", ".")
    
    for entry in plan.get("assets", []):
        rel = entry.get("path")
        expected = entry.get("expected_hash")
        algo = entry.get("algo", "sha256")
        
        if not rel or not expected:
            errors.append(f"Missing path/hash in entry: {entry}")
            continue
        
        full = os.path.join(base_dir, rel)
        if not os.path.exists(full):
            errors.append(f"Missing asset: {full}")
            continue
        
        actual = file_digest(full, algo)
        if actual != expected:
            errors.append(f"Hash mismatch: {full} expected={expected} actual={actual}")
    
    if errors:
        for e in errors:
            print(f"[FAIL] {e}", file=sys.stderr)
        sys.exit(1)
    
    print("[PASS] All companion assets match integrity manifest.")
    sys.exit(0)

if __name__ == "__main__":
    verify(MANIFEST)

8. 持续防护与集成建议

将资产清单生成与校验集成到 CI/CD 流水线中,确保每次模型或配套设施变更都会自动更新并重新签名。开发团队应建立资产清单维护规范,任何新加入的预处理资源都必须立即纳入,否则发布流水线应被阻断。基于 in-toto 证明的思路,可以将清单签名过程作为供应链证明的一部分,将产物摘要与声明负载绑定。这种处理流程能减少人为疏忽,确保持续的安全合规。

在运行时,除了启动时校验,还应考虑定期复核关键资产,或在接收到可疑行为报告时触发主动校验。移动设备上的文件系统可能因沙箱逃逸或恶意应用而被篡改,周期性的哈希巡检能及时发现异常并上报。然而,这些措施无法防御内存级的模型提取或运行时篡改,因此仍需结合代码保护与完整性监控。多层防御策略是应对复杂威胁环境的必要选择。

安全团队必须认识到,模型有效性的前提是推理链路未被污染。预处理资产保护不应被视为附加项,而是基本的部署安全要求。结合现有分发框架(如 TUF 确保无误分发)和应用层强校验,可以构建纵深防御,防止因低等级资产被篡改而引发业务风险。只有将安全意识融入到开发的每一个环节,才能真正建立起坚不可摧的防御体系。

定期审计应直接检查资产 manifest:验证签名链是否来自预期发布者,逐项重算 tokenizer、归一化、标签和后处理文件摘要,并把构建记录中的版本组合与设备实际加载组合对照。回滚测试要确认旧清单会被拒绝或进入明确的兼容分支。

资产清单的修改权限应落实到代码所有者,清单生成与签名密钥使用分开授权。CI 在缺少签名、引用文件不存在或摘要不匹配时阻断制品;测试人员只消费已签名清单,不手工改写期望值来让失败用例通过。

上线前的最后检查是:CI 已生成并签名成组清单,客户端加载前重新计算各资产摘要,设备回归覆盖正常组合、缺失文件、旧版本和摘要错误。日志只记录资产标识、版本与错误类别,不保存模型内容或业务输入。

表 8 持续防护与集成关键点
环节关键动作目标注意事项
CI/CD 集成自动生成并签名清单确保发布资产完整性阻断未签名资产的发布
运行时监控定期哈希巡检及时发现本地篡改避免影响正常业务性能
供应链管理引入 in-toto 证明绑定产物与声明确保签名者可信
应急响应建立快速恢复机制最小化事故损失定期演练预案
  • 是否将校验集成到了 CI/CD 流程?
  • 是否建立了定期巡检机制?
  • 是否引入了供应链证明技术?
  • 是否制定了详细的应急预案?

事实依据与适用边界

以下内容区分官方事实、本文工程判断和不能外推的范围,避免把设计建议写成未经验证的产品结论。

本文判断事实或工程依据适用限制
模型元数据可携带输入输出描述、归一化参数、标签和关联文件。LiteRT model metadata只校验主模型摘要会遗漏 tokenizer、标签与预处理配置。
LiteRT 在端侧加载模型并通过不同 delegate 执行推理。Google AI Edge LiteRT运行时会使用模型内容,磁盘加密不能消除内存中可用表示。
ONNX Runtime Mobile 在 Android/iOS 装载模型,并受算子、包体和执行提供程序约束。ONNX Runtime Mobile运行时支持不提供模型签名、授权或防回滚能力。
Core ML 负责模型集成、编译、装载、预测与可选模型加密。Apple Core ML框架能力不等于业务模型在运行时不可提取。
更新客户端应验证签名、版本、过期时间和一致快照,以识别回滚、冻结和混搭风险。The Update Framework specificationTUF 是更新框架,不直接规定移动端模型或 APK 的业务授权策略。
供应链证明应把产物摘要与有类型的声明负载绑定,避免报告与候选包错配。in-toto Attestation Statement v1声明格式不保证声明内容真实,仍需可信签名者和门禁核验。
对推理配套资产执行成组摘要校验可发现任意文件的替换与版本混搭,但不防御内存转储或运行时提取。工程判断摘要校验无法阻止在模型加载后从进程内存中读取权重或配置。
将模型与 tokenizer 等资产共同纳入 TUF 元数据哈希绑定,可防止分发环节的资产替换,但不能替代应用层对加载阶段的校验。The Update Framework specificationTUF 确保下载一致,但应用启动后仍可能被本地篡改或中间人注入。

工程常见问题

为什么只使用平台提供的模型加密还不够?

模型加密例如 Core ML 的加密只针对 .mlmodelc 文件本身,而词表、归一化参数等常作为独立文件存在,不在加密范围内。磁盘加密也只能防御静态读取,一旦应用加载模型到内存,攻击者仍可提取。因此需要应用层对配套资产进行独立的完整性校验。

如果所有资产都打包在 App 内,还需要额外校验吗?

即使打包在 APK 或 IPA 内,启动后文件仍可能被越狱或 root 环境篡改,或者通过热更新替换。因此,在加载前进行哈希校验仍是必要的。基于 TUF 机制可确保分发时未经炮制,但本地加载前校验是最后防线。

归一化参数影响看似很小,真的会被利用吗?

归一化参数的微小变化可能不会让模型崩溃,但可导致特征分布偏移,使模型对特定输入产生定向误判,被用于逃避安全检测或制造选择性错误。这种攻击几乎无法被常规监控发现,危害持久而隐蔽。

Core ML 的加密模型功能可以保护预处理配置吗?

Core ML 的模型加密只保护编译后的模型包,预处理配置如果通过文件单独提供,则不受加密保护。若归一化参数嵌入 mlmodel 配置编译进包内,则随模型加密保护;但仍需应用确保编译后的模型哈希校验。

TUF 能否直接管理移动端所有模型资产的版本?

TUF 可以管理任意文件的更新元数据和签名,移动端客户端可实现 TUF 协议来校验下载的模型及配套资产的完整性和版本。但 TUF 本身不负责应用运行时加载阶段的再次验证,因此还需要应用内再校验。

校验失败后如何安全降级?

校验失败应立即停止加载受影响模块,并回退到内置的安全基线模型(如有),或提示用户使用受限功能并上传异常报告。绝不可因为避免中断而跳过校验,那样会导致被篡改资产持续生效。

想用自己的 App 验证?

提交候选包、目标系统和关键业务路径,申请御盾 PoC 与兼容性评估。

继续阅读: 移动 AI 应用的运行时安全边界