重写手机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不同，端侧部署让攻击者更容易接触模型和预处理细节。 第二类是后门攻击。 攻击者希望让模型在正常输入下表现良好，但在特定触发器出现时输出攻击者指定结果