车载端侧 AI 模型安全与 IAM 方案深度调研
报告时间：2026 年 6 月 聚焦领域：在车端（Edge / On-Device）运行的 AI 模型，包括端到端自动驾驶、VLM/VLA 大模型、智能座舱 LLM Agent 等 核心问题：当 AI 模型从云端搬到车端，威胁面、IAM 模型、安全栈架构会发生什么根本性变化？ 与上篇报告的关系：本报告聚焦车载场景的独特约束（实时性 / 资源受限 / 物理安全 / 安全关键），不重复通用 Agent 安全与 IAM 的内容
0. 一句话总结
车载端侧 AI 模型是把"安全关键 + 资源受限 + 物理可接触 + 实时性硬约束"这四个最难条件叠在一起。 通用云的 Agent 安全方案（L1–L6 防护栈）只能借用一半，另一半必须靠"芯片级信任根（HSM）+ 车规级标准（ISO 26262/21434）+ 多模态冗余（感知 + 决策双轨）+ 法规强制（UN R155/R156）" 来补。
1. 为什么车端模型的安全问题"和云端不一样"
1.1 四个根本性差异
| 维度 | 云端 Agent | 车载端侧模型 | 影响 |
|---|---|---|---|
| 失效后果 | 数据泄露、服务降级 | 人身伤亡 | 不可逆，工程标准必须是 ASIL-D |
| 网络依赖 | 默认联网 | 经常离线 / 弱网 | 不能依赖云端"实时兜底"，必须本地可决策 |
| 资源 | 算力无限 | 100W 功耗上限、几十 TOPS | 模型必须量化、蒸馏、剪枝 → 安全护栏空间被压缩 |
| 物理可接触 | 数据中心上锁 | 攻击者可接触整车 | 对抗样本、传感器欺骗、OBD 注入、物理篡改 |
1.2 三个被严重低估的新风险
- 物理世界对抗攻击（Physical Adversarial Attack）：贴个对抗贴纸到交通标志上，就能让 YOLO 误识别（已知多年，但端到端模型普及后才被大规模武器化）
- 传感器欺骗（Sensing Spoofing）：GNSS 欺骗、雷达干扰、激光雷达对抗点云 — 这些在云端不存在
- OBD/USB/充电桩的物理注入面：CAN 总线 + USB + 充电协议（GB/T 27930、ISO 15118）+ 后装 OBD 设备，全是新攻击面
2. 行业标准与法规：四层强制约束
| 层级 | 标准/法规 | 强制力 | 核心要求 |
|---|---|---|---|
| 国际功能安全 | ISO 26262 | 行业强制（OEM 准入） | ASIL A–D 功能安全分级；ASIL-D 要求冗余 + 多样性 + 故障检测 < 10⁻⁸/h |
| 国际网络安全 | ISO/SAE 21434:2021 | UN R155 法规强制 | CSMS 网络安全管理体系 + 全生命周期 TARA + 供应链安全 |
| 国际软件更新 | UN R156 | 法规强制 | OTA 流程 + 回滚机制 + 防篡改 |
| 国际预期功能安全 | ISO 21448 (SOTIF) | 行业推荐 | 应对 AI 模型的"未知不安全场景"（corner case） |
| 中国整车安全 | GB 44495/44496/44497（"三剑客"） | 2026 年 7 月强制实施 | 整车信息安全 + 软件升级 + 数据保护 |
| 中国数据合规 | 《汽车数据安全管理若干规定》 | 强制 | 座舱语音/视频数据境内存储、人脸分级保护 |
| 欧盟 | UN R155/R156、EU AI Act（高风险类） | 强制 | CE 认证 + 持续合规 |
关键判断：车端模型的"安全栈设计"必须先满足 ISO 26262 + 21434 + 中国三剑客的硬约束，再谈 AI 防护技术。没有合规底座，技术方案再好也无法上车。
来源：ISO/SAE 21434 详解 / Agent 时代 21434 改造难点 / 国标 GB 44495/44496/44497 三剑客
3. 威胁模型：车端模型特有的"四圈攻击面"
3.1 物理攻击圈（云端没有）
| 攻击类型 | 案例 | 防御 |
|---|---|---|
| 对抗贴纸 | 交通标志贴对抗贴 → 限速 60 识别为"停止" | 多模态融合（视觉 + 激光雷达 + 高精地图交叉验证） |
| 激光雷达对抗 | 对抗点云注入 → 凭空出现"障碍物"刹车 | 时序一致性检查 + 多帧投票 |
| GNSS 欺骗 | 伪造卫星信号 → 车辆被"挪到"错误位置 | IMU + 视觉里程计冗余 |
| 摄像头致盲 | 强光、激光笔、贴纸 | 多摄像头冗余 + 清洁系统 + 传感器健康监测 |
| 毫米波雷达干扰 | 同频段干扰 | 频率跳变 + 多雷达融合 |
3.2 网络攻击圈（继承通用 Agent）
| 攻击类型 | 案例 |
|---|---|
| CAN 总线注入 | OBD-II 接入 → 发送伪造刹车/转向指令（2013 Miller & Valasek 经典案例） |
| OTA 供应链 | 篡固件包签名 → 远程刷恶意模型 |
| 远程劫持 | 攻破 TSP 后台下发恶意指令（2022 年 16 家车企漏洞事件） |
| 语音注入 | 超声波 / 雷达频段命令注入车载 LLM Agent（类似 EchoLeak） |
| V2X 伪造 | 伪造路侧单元消息 → 误导车辆决策 |
3.3 模型攻击圈（端到端模型特有）
| 攻击 | 影响 |
|---|---|
| 数据投毒 | 污染影子模式采集的数据 → 模型学坏习惯 |
| 模型窃取 | 通过 API 查询重建决策模型 |
| 后门植入 | 训练时植入触发器 → 特定场景触发异常行为 |
| 权重篡改 | 物理接触存储介质 → 替换模型权重 |
| 端到端黑盒 | 模型决策不可解释 → 安全验证难通过 ASIL-D 认证 |
3.4 决策失控圈（最致命）
- 模型幻觉：端到端模型可能输出"看不见的障碍物"导致幽灵刹车
- 级联失效：一个感知模块失效 → 决策模块输出异常 → 控制模块执行错误动作
- OOD 场景：训练数据未覆盖的场景（如施工标志、异形车辆）
- 多模态冲突：视觉说"前方无车" / 毫米波说"有车" → 模型该如何处理
4. 车规级 AI 芯片：安全能力的"硬件根"
4.1 主流车规 AI 芯片安全特性对比
| 芯片 | 厂商 | 算力（典型） | 安全特性 | 应用场景 |
|---|---|---|---|---|
| NVIDIA Drive AGX Orin | 英伟达 | 254 TOPS | HSM（Hardware Security Module）+ Secure Boot + DRAM 加密 + OTA 签名验证 | L2+ 主流方案 |
| NVIDIA Drive AGX Thor | 英伟达 | 2000 TOPS（Blackwell 架构） | 隔离分区 + Confidential Computing + 安全启动链 | L4+ Robotaxi |
| Tesla HW3 / HW4 / HW5 | 特斯拉自研 | HW4 ~144 TOPS；HW5 算力 ×40 | 自研神经网络加速器 + 冗余双系统 | FSD 端到端 |
| NXP S32G | NXP | 多核异构（Cortex-A53 ×3 + Cortex-M7 ×2） | 集成 HSM（CSE / SHE+）+ 满足 ISO 26262 ASIL-D + AEC-Q100 Grade 1（-40°C~+125°C） | 网关、域控 |
| 地平线征程 5 / 征程 6 | 地平线 | 征程 5: 128 TOPS；征程 6: 560 TOPS | 首款通过 ISO 26262 ASIL-B Ready 认证的中国车规 AI 芯片 | ADAS / 智驾 |
| 黑芝麻华山 A1000 | 黑芝麻 | 196 TOPS（双芯片） | ISO 26262 ASIL-B / AEC-Q100 | 智驾域控 |
| 华为 MDC / 鲲鹏 | 华为 | MDC 810: 400+ TOPS | 自主芯片 + TrustZone + 安全启动 | ADS 智驾平台 |
| Mobileye EyeQ6 | Mobileye | EyeQ Ultra: 176 TOPS | EyeQ 自研 + 安全模块 | ADAS |
| 高通 Snapdragon Ride | 高通 | Flex: 2000 TOPS（外购） | Snapdragon 平台安全框架 + HSM | 智驾域控 |
来源：NVIDIA Drive / 地平线征程系列 / NXP S32G
4.2 国产车规级安全芯片（HSE / HSM）
| 厂商 | 代表产品 | 特性 |
|---|---|---|
| 国芯科技 | CCM4202S 等 | 累计出货 300 万颗（2025.3）；支持 AES/RSA/ECC + 国密 SM2/SM3/SM4；通过 AEC-Q100 + EAL5+ |
| 信大捷安 | XDSM3276/3275/1505 | 量产上车；XDSM3276 支持 V2X 每秒 2000+ 次签名验证 |
| 擎天信安 | qHSM（搭配 TI TDA4/AM263X） | 全栈车规级安全方案（密钥管理、生命周期、安全启动） |
4.3 关键安全特性解读
- HSM（Hardware Security Module）：硬件级密钥隔离区，存储根密钥、做签名验证、永不导出
- Secure Boot：启动链逐级签名验证（BootROM → Bootloader → OS → Application）
- TrustZone：ARM 的硬件隔离技术，把"安全世界"和"普通世界"在 CPU 层面分开
- AEC-Q100 Grade 1/2：车规可靠性认证（Grade 1：-40°C~+125°C）
- ISO 26262 ASIL-B/D：功能安全等级认证
- EAL5+：信息安全通用评估保证级（Common Criteria）
5. 端侧大模型上车的"三条技术路径"
5.1 国内头部车企端侧大模型布局
| 车企 | 大模型 | 参数量级 | 部署位置 | 关键技术 |
|---|---|---|---|---|
| 理想 | MindGPT → MindGPT-3o → MindGPT 3.1 | 数十亿参数（座舱） | 端云混合 | 云端负责复杂任务、端侧负责隐私/实时；自研 TaskFormer 架构 |
| 理想 | VLA 司机大模型 | 70 亿+ | 端侧（双 Orin-X） | 强化学习驱动；高频指令响应 200ms |
| 小鹏 | 灵犀大模型 XGPT + 端到端大模型（XNet + XPlanner + XBrain） | 70 亿+ 车端；720 亿云端基座 | 端云混合 | 自研图灵芯片（700 TOPS）；世界基座模型蒸馏上车 |
| 蔚来 | NOMI GPT | 数十亿 | 端侧（高通 8295） | 全球首个"汽车端侧多模态感知大模型" |
| 华为 | 盘古大模型 + ADS 3.0（GOD + PDP） | 数十亿+ | 端云混合 | GOD 通用障碍物识别 + PDP 预测决策规划 |
| 极越 | SIMO（接入文心一言） | — | 云端为主 | 国内首批接入大模型的车企 |
| 问界（华为系） | 小艺（接入盘古） | — | 云端为主 | M9 首发接入 |
5.2 特斯拉 FSD V14：纯视觉端到端的极端形态
- 参数量：V13 → V14 提升 4.5–10 倍
- 硬件：HW4（自研 AI 芯片，~144 TOPS）；HW5 算力为 HW4 的 40 倍
- 架构：纯视觉（无激光雷达、无高精地图依赖）
- 训练数据：180 万辆车 + 13 亿英里驾驶数据 + 自动标注 4D 数据
- 核心安全机制：
- 影子模式（数据闭环 → 自动标注 → 仿真 → 重训）
- 端到端+VLM 双系统（快系统感知 + 慢系统决策）
- 多模态冗余（8 个摄像头 + 超声波雷达 + GPS + IMU）
- xAI Grok 集成（语义理解 + 异常检测）
5.3 端侧模型量化与蒸馏的"安全副作用"
端侧部署必须做的事：
- 量化：FP32 → INT8/INT4，精度损失 1–3%
- 蒸馏：用大模型训练小模型，可能丢失"安全规则"
- 剪枝：去掉不重要的神经元，可能误剪"安全检测分支"
安全启示：模型缩小不等于攻击面缩小，反而可能引入新漏洞（如量化误差可被对抗样本利用）。端侧模型上车前必须重新做完整安全评估。
6. 端到端（E2E）模型的"功能安全悖论"
这是当前车端 AI 安全最尖锐的矛盾。
6.1 ISO 26262 的核心要求
- 系统必须有可验证的安全机制
- 故障必须能被检测 + 隔离 + 降级
- 关键决策必须有冗余（redundancy）和多样性（diversity）
- 要求"系统性失效"概率 < 10⁻⁸/h（ASIL-D）
6.2 E2E 模型的"先天不足"
- 黑盒：无法用传统 V&V（验证与确认）方法证明安全
- 不可解释：决策路径无法追溯，无法满足"可审计"
- 长尾问题：训练数据未覆盖的场景可能产生灾难性输出
- 级联失效：单点感知错误会传播到决策和控制
6.3 业界当前的"补丁"方案
| 车企 | 方案 | 本质 |
|---|---|---|
| 理想 | One Model + 安全逻辑网络 | 双轨：E2E 负责"正常路径"，规则网络负责"兜底" |
| 华为 ADS 3.0 | GOD + PDP + 本能安全网络 | 三层：感知 + 决策 + 安全本能 |
| 小鹏 | XNet + XPlanner + XBrain | 分层但联合训练 |
| 智己 + Momenta | 一段式端到端 + 安全逻辑网络 | 直觉 + 逻辑 |
| 特斯拉 | FSD + 驾驶员监控 + 影子模式 | 人 + 数据闭环 |
共识：当前没有车企敢把 E2E 模型作为唯一决策者。规则化兜底层仍是 ASIL-D 认证的"硬约束"。
来源：端到端自动驾驶关键技术研究 / 特斯拉 FSD V14 技术分析
7. 车端 Agent IAM：从"数字车钥匙"到"Agent 一等公民"
7.1 数字车钥匙：IAM 的"消费级"实例
主流标准：
- CCC Digital Key 3.0（Car Connectivity Consortium）：基于 BLE + UWB 的厘米级定位
- 2024 年宝马 + 恩智浦 首批获得认证
- 2025 年小鹏 P7+/G6/G9 通过认证（首批中国车企）
- 国内：长城魏牌、蔚来、小鹏、极氪、比亚迪、腾势、红旗、乐道、领克、星途、仰望、方程豹、岚图、奇瑞等
- Apple Car Key（基于 NFC + UWB）：宝马首发，已扩展到奥迪、保时捷、奔驰等
- 华为 HarmonyOS Wallet Key Cards：特斯拉最新版本正在集成
- IIFAA 数字车钥匙（中国）：金融级加密、独立芯片
- ICCOA（中国通信院）：跨厂商数字钥匙协议
关键安全机制：
- Secure Element（SE）：车钥匙密钥存在 iPhone Secure Enclave / 华为 InSE 等独立硬件中
- 低电模式：手机关机 5 小时仍可解锁
- UWB 厘米级定位：防中继攻击（Relay Attack）
- 活体检测：Face ID / 指纹认证
- 细粒度权限：可限制借车人的最高速度、区域、音量等
7.2 车端 AI Agent IAM 的新需求
车上现在有多种"Agent"，需要不同身份的 IAM：
| Agent 类型 | 身份类型 | 安全需求 |
|---|---|---|
| 驾驶员 Agent（智驾系统） | 物理用户 + 数字孪生 | 与驾驶员绑定，可被切换/禁用 |
| 座舱 Agent（理想同学、小艺、SIMO） | 个人身份 + 家庭成员 | 隐私保护、儿童模式 |
| 云端调度 Agent（云端下发指令给车） | 服务身份 + 委托链 | 双向认证 + 指令时效校验 |
| 车云 Agent（OTA 更新、数据回传） | 设备身份 + PKI 证书 | 设备证书、签名验证 |
| 多智能体调度（底盘、智驾、座舱跨域） | 域间身份 | 域隔离 + 安全通信 |
7.3 车端 IAM 的六大核心挑战
- 跨域身份联邦：座舱域（QNX/Linux）、智驾域（RTOS）、车身域（AUTOSAR）身份模型不同
- 离线认证：网络不可用时仍能验证身份
- 密钥生命周期：车寿命 10–15 年，密钥轮换策略必须长期
- 多模态认证：人脸 + 声纹 + 指纹 + 行为特征组合
- 儿童与老人：特殊人群的生物特征退化
- 跨厂商互信：车主从 A 品牌换 B 品牌，数字钥匙 / 数据 / 偏好如何迁移
7.4 域控制器时代的"内 IAM"
现代汽车采用域架构（中央计算 + 区域控制器），域间通信需"内部 IAM"：
┌──────────────────────────────────────────────┐
│ 中央计算单元（CCU） │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ 智驾域 │ │ 座舱域 │ │ 车身域 │ │
│ │ ASIL-D │ │ ASIL-B │ │ ASIL-A │ │
│ └───┬────┘ └───┬────┘ └───┬────┘ │
│ │ │ │ │
│ │ ┌────────┴────────┐ │ │
│ └──┤ TSN 以太网 + ├──┘ │
│ │ SOA 服务总线 │ │
│ │ + mTLS 双向认证 │ │
│ └─────────────────┘ │
└──────────────────────────────────────────────┘- SOA + mTLS：服务间通信用双向 TLS，每个服务有独立证书
- 域隔离：硬件防火墙 + 内核隔离（如英伟达 Drive OS 的分区）
- 审计日志：所有域间调用记录到 TEE（Trusted Execution Environment）
8. 端到端自动驾驶的"四层冗余"安全架构
业界共识的端到端安全架构（从底向上）：
| 层级 | 内容 | 责任方 |
|---|---|---|
| L4 监控与接管 | 驾驶员监控系统（DMS）+ 人机共驾（HMI 提示 + 自动紧急接管） | 整车厂 + Tier 1 |
| L3 安全本能网络 | 兜底规则网络：AEB、ELK、车道保持、限速；与 E2E 决策冲突时优先 | 算法供应商 |
| L2 端到端决策 | One Model / Two Model / 多段式；多模态融合；可解释性 | 算法供应商 + 芯片厂 |
| L1 感知冗余 | 摄像头 + 激光雷达 + 毫米波 + IMU + GNSS；多模态交叉验证 | Tier 1 + 芯片厂 |
| L0 硬件冗余 | 双 SoC、冗余电源、冗余 CAN、故障检测电路 | 芯片厂 + 域控厂 |
关键设计原则：
- 冗余 ≠ 多模态：多模态可能因共因失效（如摄像头被遮挡 → 视觉全失效），必须配合异构冗余
- 多样性（diversity）：算法多样性（E2E + 规则）+ 硬件多样性（不同厂商 SoC）
- 故障安全（fail-safe）：所有关键故障必须导向"最小危险状态"（如断电 → 缓慢停车 + 双闪）
- 故障运行（fail-operational）：ASIL-D 要求部分故障下仍能安全运行一段时间
9. NVIDIA DRIVE 安全体系：行业参考实现
NVIDIA 2025 自动驾驶安全报告提出的 AV 2.0 安全四大支柱：
- AI 设计与实施平台：从数据采集到模型部署的完整工具链
- 深度学习开发基础设施：DRIVE Sim 仿真 + DRIVE OS 安全内核
- 物理精准传感器仿真：DRIVE Sim 模拟传感器故障 + 对抗场景
- 全方位安全和网络安全计划：ISO 26262 + ISO/SAE 21434 + UN R155 全合规
DRIVE OS 关键安全特性：
- 安全启动（Secure Boot）
- HSM（Hardware Security Module）
- 加密内存（Encrypted DRAM）
- 隔离分区（Partition Isolation）
- 安全 OTA 更新
来源：NVIDIA 2025 AV Safety Report
10. OTA 安全：车端模型"持续进化"的命门
10.1 OTA 攻击面
OTA 是端侧模型更新的主要通道，也是最大攻击面：
- 包篡改（伪造模型权重）
- 重放攻击（旧版本回滚绕过新安全规则）
- 中间人攻击（劫持下载流量）
- 拒绝服务（不更新或错误更新导致系统不可用）
10.2 必须满足的安全要求（UN R156）
- 签名验证：每个 OTA 包由 OEM 私钥签名，HSM 验签后才安装
- 完整性校验：防止传输中被篡改（SHA-256 / SHA-384）
- 可回滚：更新失败必须能回滚到上一个稳定版本
- 用户告知：更新影响必须明确告知用户
- 审计日志：完整记录每次更新的时间、版本、原因
- 目标识别：防止错误更新到错误 ECU
10.3 国芯科技 / 信大捷安方案
- OTA 签名验签：车规级安全芯片（CCM4202S）做数字签名
- A/B 双分区：更新失败自动回滚
- 差分升级：减少下载流量（车端带宽宝贵）
- 断点续传：弱网环境友好
11. 物理世界对抗样本：车端特有威胁
11.1 经典案例
| 攻击 | 案例 |
|---|---|
| 交通标志贴纸 | Eykholt et al. 2018：贴几张黑白贴纸 → Stop Sign 被识别为 Speed Limit 45 |
| 3D 打印对抗眼镜 | 戴上特定眼镜 → 人脸识别绕过（已用于自动驾驶车内 DMS 欺骗） |
| 激光雷达欺骗 | 注入伪造点云 → 凭空出现"行人" |
| 毫米波干扰 | 同频段干扰 → 雷达失效或误报 |
| 超声波注入 | 倒车雷达被注入 → 误判距离 |
11.2 防御措施
- 多模态交叉验证：视觉 + 激光雷达 + 高精地图交叉确认
- 时序一致性：单帧异常 ≠ 真实目标，多帧投票
- 物理一致性：检测目标是否符合物理规律（光流、深度）
- 感知冗余：不同位置摄像头、不同厂商传感器
- 对抗训练：用已知对抗样本增强训练数据
- 传感器健康监测：摄像头脏污/激光雷达被遮挡实时告警
12. 车端 LLM Agent 的特殊安全挑战
12.1 端侧 LLM 的"Prompt Injection 物理化"
- 超声波注入：通过人耳听不到的超声波命令唤醒车载 LLM Agent
- 视觉注入：在路标、广告牌上印刷"特殊指令"诱导视觉 LLM 误解
- 语音注入：通过车载麦克风收音范围外的声源播放"伪造用户指令"
12.2 防御方案
| 攻击 | 防御 |
|---|---|
| 超声波注入 | 物理屏蔽：麦克风只接收中频段；软件检测：异常频率识别 |
| 视觉注入 | 多帧验证 + 来源可信度评估 + 物理一致性检查 |
| 语音注入 | 声纹识别 + 上下文合理性判断 + 关键操作二次确认 |
12.3 车端 LLM 的"决策边界"设计
- 保守性原则：LLM 不能单独执行影响车辆控制的指令，必须有规则网络兜底
- 行为白名单：LLM 只能输出已批准类型的动作
- 不确定性表达：当 LLM 不确定时，必须主动放弃决策权（"我不知道"）
- 可解释性输出：必须能告诉驾驶员"我为什么这样做"
13. 实践建议：车端 AI 安全落地的"五步走"
第一步：合规底座（必须先做）
- ✅ ISO 26262 功能安全流程认证
- ✅ ISO/SAE 21434 网络安全流程认证
- ✅ UN R155/R156 + GB 三剑客合规
- ✅ 建立 CSMS 网络安全管理体系
第二步：硬件信任根
- ✅ 选用带 HSM 的车规芯片
- ✅ 建立 PKI 体系（OEM 根 CA → 设备证书 → ECU 证书）
- ✅ 实现 Secure Boot 链
第三步：模型安全工程
- ✅ 端侧模型上线前必须重新做完整安全测试（量化后精度损失、蒸馏后安全规则是否保留）
- ✅ 建立对抗样本测试集（物理 + 数字）
- ✅ 部署安全本能网络作为兜底
- ✅ 实施影子模式持续收集长尾场景
第四步：IAM 体系
- ✅ 数字车钥匙符合 CCC 3.0 / IIFAA / ICCOA 标准
- ✅ 域间通信用 mTLS + 服务身份
- ✅ 车内多用户/家庭账户体系
- ✅ 儿童 / 老人 / 借车场景的细粒度权限
第五步：OTA + 监控
- ✅ OTA 包签名 + 完整性校验 + 可回滚
- ✅ 车端 IDS（入侵检测）+ 行为监控
- ✅ 异常事件 → 云端 SOC 联动
- ✅ 定期安全更新 + CVE 响应
14. 信息缺口与待验证
- ⚠️ 端到端 E2E 模型 ASIL-D 认证：目前全球尚无任何 E2E 模型通过完整 ASIL-D 认证的公开案例
- ⚠️ 车端 LLM Agent 的 ISO 21448 (SOTIF) 评估方法学：业界仍在探索
- ⚠️ 车端模型量化对安全的影响：缺乏公开基准
- ⚠️ CCC 3.0 与 ICCOA 互操作性：实际落地案例较少
- ⚠️ 中国 GB 三剑客（44495/44496/44497）的具体实施细则：2026 年 7 月强制实施前仍待细化
15. 参考来源汇总
| 类别 | 来源 | 链接 |
|---|---|---|
| 标准 | ISO/SAE 21434:2021 | iso.org/standard/70918.html |
| 标准 | ISO 26262 功能安全 | iso.org |
| 标准 | UN R155/R156 | unece.org |
| 标准 | 中国 GB 44495/44496/44497 | std.samr.gov.cn |
| 标准 | CCC Digital Key 3.0 | carconnectivity.org |
| 标准 | ICCOA 数字车钥匙 | iccoa.com |
| 协议 | Apple Car Key | developer.apple.com |
| 报告 | NVIDIA 2025 AV Safety Report | nvidia.com |
| 论文 | CausalArmor（间接 Prompt Injection） | arxiv.org/abs/2602.07918v1 |
| 厂商 | 特斯拉 FSD V14 技术分析 | news.qq.com |
| 厂商 | 理想 MindGPT / VLA | 佐思汽研报告 |
| 厂商 | 小鹏端到端大模型 | news.qq.com |
| 厂商 | 华为 ADS 3.0 | huawei.com |
| 厂商 | 地平线征程 5/6 | horizon.ai |
| 厂商 | 国芯科技车规 HSM | gxtech.com |
| 厂商 | 信大捷安 XDSM 系列 | xinda.com |
| 厂商 | NXP S32G | nxp.com |
| 漏洞 | 2022 年 16 家车企远程劫持事件 | bleepingcomputer.com |
| 学术 | Adversarial patch on stop signs | arxiv.org/abs/1712.02965 |
| 法规 | 《汽车数据安全管理若干规定》 | cac.gov.cn |
附录：与通用 Agent 安全的对照
| 维度 | 通用云端 Agent | 车载端侧模型 |
|---|---|---|
| 威胁框架 | OWASP ASI01-ASI10 + MITRE ATLAS | + ISO 21434 + ISO 26262 + UN R155 |
| IAM 主体 | 人 + Agent | 人 + Agent + 车（设备身份）+ ECU（域身份） |
| 身份协议 | OIDC-A | + CCC Digital Key 3.0 + IIFAA + ICCOA |
| 防护栈 | 6 层防护栈 | 复用 L1–L4 + 强化 L0（硬件信任根） |
| 沙箱 | Docker / MicroVM | CSE / HSM / TrustZone（车规级） |
| 决策安全 | 输出审查 + 执行门 | + 安全本能网络 + DMS 监控 + 驾驶员接管机制 |
| OTA | MCP 包签名 | UN R156 + 双分区 + 回滚机制 |
| 物理安全 | 不涉及 | 传感器对抗 + OBD 注入 + GNSS 欺骗 + 物理篡改 |
总结：车端 AI 安全不是"通用 Agent 安全的子集"，而是两个独立但有交集的领域。建议同时关注：
- 通用 Agent 安全（数据投毒、Prompt Injection、过度代理）
- 车规级安全（ISO 26262/21434、ASILD、对抗样本、传感器欺骗）
报告完成时间：2026-06-26 下次更新建议：GB 三剑客 2026 年 7 月生效后，需重新评估合规要求