重写手机AI安全边界！首个MoAI攻防SoK，系统梳理三大安全支柱

过去很长一段时间里，移动AI服务大多是一个「云端故事」：手机采集语音、图像、文本、位置和上下文，把请求传到服务器，等云端大模型完成推理，再把结果显示给用户。

这套模式简单、可扩展，也方便服务商集中管理模型。但在现实场景里，它天然有三重代价：敏感数据要离开设备，网络传输会带来延迟，没网或弱网时智能功能直接降级。

现在，硬件升级和模型优化给出了另一条路。

墨尔本大学、RMIT大学和南洋理工大学联合发布的最新研究论文指出，Google Tensor、Apple Neural Engine、Qualcomm Hexagon 等移动端AI硬件，以及面向本地部署的轻量化、多模态、生成式和推理模型，正在把越来越多AI能力推向终端设备。

于是，Mobile On-device AI（MoAI）正成为移动智能服务的重要范式：AI模型不再需要部署在云上，而是以LiteRT/TFLite、Core ML、ExecuTorch、ONNX等形式，真实地存储、加载、运行在用户手机里。

对用户来说，这意味着更低延迟、更强隐私保护，以及离线可用的AI功能。对开发者来说，这意味着模型离用户更近，体验更顺滑。但对安全研究者来说，这也意味着一个更复杂的问题：当模型部署在用户设备上，谁来保护模型本身？谁来保证输入可信？谁来约束运行环境？

当模型部署在手机里，各种安全风险也随之而来

在传统云端AI系统里，模型通常位于服务商可控的数据中心，用户设备更像一个「轻客户端」。攻击者很难直接接触模型参数、模型结构和运行时状态。

但MoAI改变了这条边界。为了实现本地推理，模型文件、推理框架、运行时中间状态、硬件加速路径都要出现在终端设备上。用户设备不再只是输入输出窗口，而是同时承载输入接口、模型工件、运行时执行和硬件隔离。

这带来一个核心矛盾：MoAI把数据留在本地，提升了隐私；但它也把模型放到本地，扩大了模型和推理过程被接触、分析、篡改的机会。

论文给出的威胁非常直观：攻击者可以通过反编译、设备端内存dump、运行时hook等方式，提取端侧模型和推理相关信息。一旦模型被取出，后续就可能出现对抗攻击、后门注入、参数级篡改、模型窃取，甚至专门让手机多耗电、多延迟的能耗攻击。

论文链接：https://arxiv.org/abs/2607.00362

项目资源：https://github.com/Jinxhy/Awesome-MoAI-Security

以一个真实世界场景为例，某交通驾驶助手 App 将识别模型部署在手机端。攻击者可以先通过逆向分析提取模型，随后向模型中植入后门并设计对应触发器，使其在真实道路环境中对特定交通标志产生错误识别，例如将停车标志误判为可继续通行或加速提示。此时，攻击带来的风险已不再局限于模型知识产权泄露，而是进一步影响用户安全和现实世界行为。

这篇SoK不是「单点攻击论文」

这篇论文的定位是 SoK，即 Systematization of Knowledge。它并不是提出一个新的单点攻击，也不是发布一个单一防御工具，而是试图回答一个更基础的问题：MoAI安全到底应该怎么被定义、拆解和研究？

作者指出，已有综述更多关注 Edge AI、TinyML，或MoAI中的模型窃取问题。但MoAI并不等同于「移动设备上跑模型」，也不只是「模型文件会被偷」。它是传统移动软件组件与本地神经网络组件的组合体，攻击面贯穿用户输入、模型工件、运行时和硬件环境。

因此，论文从移动系统整体视角出发，给出了一个统一框架：先把MoAI系统拆成四层，再定义三大安全支柱，随后分别梳理攻击图谱、防御图谱、跨支柱关系、开放问题与未来方向。

这也是这篇论文最像「地图」的地方：它不只是告诉你哪里已经有人打过仗，更重要的是告诉你哪些地方还没有被真正守住。

四层架构

论文首先把MoAI系统拆解为四个层次。

第一层是输入接口层（Input Interface Layer）。这里包括摄像头、麦克风、用户交互、App上下文、平台API、数据格式适配和预处理流程。模型最终看到的不是「现实世界」，而是这一层处理后的张量、token或结构化输入。

第二层是AI模型工件层（AI Model Artifact Layer）。这是MoAI的核心资产，包括模型结构、训练权重、算子、输入输出规格、标签、词表、tokenizer等。模型经过量化、剪枝、聚类或格式转换后，被打包为移动端可部署工件。

第三层是运行时执行层（Runtime Execution Layer）。这一层负责把模型工件真正跑起来：加载模型、准备输入输出张量、管理中间buffer、调度CPU/GPU/NPU/Neural Engine等后端，并根据内存、兼容性和算子支持作出执行决策。

第四层是硬件隔离层（Hardware Isolation Layer）。MoAI可以在普通移动OS环境中执行，也可能部分或全部进入TEE、TrustZone、pKVM等硬件支持的隔离环境。它决定了模型权重、中间张量和敏感推理状态是否会暴露给不可信组件。

这个四层拆解很关键。因为MoAI的安全问题并不只发生在「模型文件」上：输入可能被污染，预处理可能被篡改，模型可能被偷走，运行时可能泄露中间状态，硬件加速路径也可能成为侧信道或可用性攻击的入口。

三大安全支柱

在四层架构之上，论文进一步提出三大安全支柱。用更直白的话说，MoAI安全要回答三个问题：模型看到的输入可信吗？模型本身还可靠吗？模型运行的地方安全吗？

第一根支柱，是用户可控输入完整性（User-governed Input Integrity）。手机上的输入来自用户、传感器和App上下文。攻击者可能操控摄像头画面、注入恶意噪音、污染上下文，或篡改预处理逻辑。保护这一支柱，就是保护「模型看到什么」。

第二根支柱，是设备驻留模型安全性（Device-resident Model Security）。端侧模型被发布到用户设备后，已经离开开发者可控边界。模型结构、权重、参数、执行图都可能被定位、提取、修改或复用。保护这一支柱，就是保护「模型自己是谁」。

第三根支柱，是设备原生环境约束（Device-native Environment Confinement）。模型推理发生在移动OS、AI runtime、内存子系统和硬件加速器共同组成的环境里。如果隔离失败，解密后的模型buffer、中间张量、运行时状态都可能被观察或操控。保护这一支柱，就是保护「模型在哪里跑」。

这三根支柱让MoAI安全从「模型保护」升级为「端侧智能链路治理」。对开发者来说，它提醒我们：仅仅给模型文件加密并不够，输入、运行时和硬件隔离同样是安全边界的一部分。

五类攻击

攻击方面，论文按照攻击者能力和操控位置，把MoAI威胁模型分为输入级、模型级和执行级三类，并系统整理出五类典型攻击。

第一类是对抗攻击。攻击者利用端侧模型可被分析、相似模型可被复用、梯度可被重构或预处理可被操控等特征，构造让模型输出错误结果的输入。与云端黑盒API不同，端侧部署让攻击者更容易接触模型和预处理细节。

第二类是后门攻击。攻击者希望让模型在正常输入下表现良好，但在特定触发器出现时输出攻击者指定结果。端侧场景中的后门不来自训练阶段，而是通过payload注入、量化过程或图像隐写进入模型。

第三类是对抗权重攻击。这类攻击直接修改模型参数，让模型行为偏移，同时尽量保持普通输入上的正常性能。论文提到的TYPHON代表了这类新兴方向：攻击者不再只骗输入，而是直接改变模型理解。

第四类是模型窃取攻击。模型被存储在设备上，天然引发知识产权和下游滥用风险。攻击者可以通过静态分析查找 .tflite、.pb、.mlmodel 等文件，通过动态分析在模型加载或解密后从内存中提取模型，也可能利用功耗、缓存等侧信道推断模型结构。

第五类是能耗时延攻击。这类攻击不一定让模型预测变错，而是让端侧推理变慢、变耗电，破坏可用性。在资源受限的手机上，延迟、功耗和稳定性本身就是安全目标。

这五类攻击共同说明，MoAI的风险不是一个点，而是一条链：从输入到模型，从模型到运行时，从运行时到硬件。

四类防御

防御方面，论文把MoAI安全目标建立在传统 CIA 三元组之上：机密性、完整性、可用性。除此之外，作者还加入了一个很适合端侧场景的新目标：部署后问责性（Post-deployment Accountability）。

为什么需要「部署后问责」？因为MoAI模型一旦发布到用户设备上，模型可能被提取、复制、转换、再利用。即使事前防护失败，开发者也需要在事后证明模型所有权，追踪未经授权的复用。

论文总结的四类防御，可以粗略概括为四个字：挡、绑、隔、追责。

模型混淆，是「挡」。它通过重命名、参数封装、结构变换、算子耦合、原生代码生成或硬件结合等方法，提升模型被定位、理解和恢复的难度。

模型授权，是「绑」。它把模型的正确推理能力与特定App、签名、密钥或完整性验证绑定在一起。模型即便被偷走，没有正确授权上下文也无法正常使用；模型被篡改，也会在推理前被发现。

TEE，是「隔」。它把全部推理、部分关键层，或敏感模型组件放入硬件隔离环境中执行，试图让普通OS、恶意App和攻击者无法观察到模型权重与中间状态。

模型水印，是「追责」。它并不一定阻止模型被偷，而是在模型被复制或复用后，通过黑盒查询或特定触发行为证明模型归属。对于端侧模型IP保护来说，这是一种「事后证据」。

但论文也强调，防御不是免费的，因为各类机制都会带来一定的性能消耗。 MoAI安全的难点，正是在安全收益、性能开销和实际可部署性之间找到平衡。

9个开放问题

这篇SoK最值得关注的部分，是它没有把MoAI安全写成一个「已有答案」的领域。相反，作者把大量研究从论文实验拉回真实手机部署场景，指出了九个开放问题。

攻击侧的核心问题在于：很多攻击在实验室条件下成立，但要真正部署到用户设备上，需要强假设。比如你要操控用户输入、重新打包App、精准定位关键权重、绕过定制加密，或者让某种能耗攻击跨硬件栈稳定生效，这些都非常复杂并具有挑战。

防御侧的核心问题在于：很多防护看似保护了模型文件，却可能在授权推理、客户端执行、运行时恢复、TEE集成或模型再部署过程中暴露缺口。MoAI防御不只要「能防」，还要能在真实移动生态中部署、升级、兼容和验证。

未来方向

论文最后把未来安全研究方向聚焦在三个正在发生的变化上。

第一，是端侧训练（On-device Training）。现有MoAI安全研究大多关注只读、只推理的已部署模型。但未来，模型可能在用户设备上继续微调、个性化更新。这样一来，梯度、参数更新、训练样本和用户数据都会在运行时暴露，攻击面会从「推理安全」扩展到「训练安全」。

第二，是端侧生成式AI（On-device GenAI）。过去端侧AI安全研究大量集中在计算机视觉和图像分类任务上。随着手机端LLM和图像生成模型逐渐可用，安全问题将进入提示词注入、越狱、敏感信息泄露、幻觉输出和本地上下文滥用等新领域。

第三，是Agentic MoAI系统。这可能是最危险、也最值得研究的方向。未来手机里的AI不只是被动回答问题，而是可以读取App上下文、访问传感器、调用系统服务、跨App执行操作，甚至维护记忆和写计划。

一旦MoAI进入Agent形态，安全问题就不再只是「prompt能不能骗模型」，而是「上下文到行动」的整条链路能不能被保护。论文提出，未来需要建立移动上下文来源追踪，区分可信用户意图与不可信环境内容，把工具和API调用绑定到任务级权限，并为敏感操作加入确认、回滚、审计机制。换句话说，Agentic MoAI时代的安全，不是给模型多加几条规则，而是给手机里的AI执行能力建立一套操作系统级、应用级和用户级共同参与的治理机制。

结语

MoAI的出现，本质上是体验、隐私和计算能力共同推动的结果。它让AI不必永远依赖云端，也让手机从「智能服务入口」变成「智能服务发生地」。

但这也意味着，过去由云端数据中心承担的安全边界，被重新切分到用户设备、App、模型文件、AI runtime、移动OS、硬件加速器和用户上下文之间。边界越分散，默认信任就越危险。

这篇SoK的价值不在于宣布MoAI已经安全，也不在于制造对端侧AI的恐慌。它真正做的，是把这个新领域的战场画出来：哪里是核心资产，哪里是攻击入口，哪里已有防御，哪里仍是空白。

当AI从云端走向每一台手机，安全研究也必须从「保护一个远程模型服务」转向「治理一条端侧智能链路」。这可能正是下一代移动AI系统能否真正可信的起点。

参考资料：

https://arxiv.org/abs/2607.00362

编辑：LRST