简介：这份PPT资料聚焦智能汽车网络安全标准与技术，面向汽车电子、车载软件及信息安全方向的工程师与研究人员，帮助读者系统理解智能网联汽车在安全与功能安全层面的标准框架与落地实践。内容围绕关键零部件计算平台、可信计算、基于隔离的体系架构、生命周期与评估、标准化发展情况、团队标准实践及网络安全应用实践等模块展开，涉及TPM信任根、SHE规范、多域与跨域计算、虚拟化与可信执行环境等具体技术点，并辅以真实召回与攻击案例说明网络安全为何成为智能汽车刚需。资源包共1个pptx文件，约4.98MB，以演示文稿形式呈现，便于直接用于技术分享或内部培训。目前已有594人学习下载，适合需要梳理智能汽车网络安全标准脉络、了解可信计算与隔离架构设计思路的读者参考。
1. 智能汽车网络安全标准：从计算平台到可信隔离的工程拆解
2015 年菲亚特-克莱斯勒因黑客远程控制发动机和转向系统召回 140 万辆吉普车，2016 年挪威安全公司 Promon 通过移动 App 漏洞控制了一台特斯拉——这两件事把智能汽车网络安全从学术讨论拽进了工程刚需。这份《智能汽车网络安全标准》PPT 来自电子科技大学嵌入式软件工程中心与广东为辰信息科技，2018 年 10 月成稿，核心覆盖八个板块：关键零部件计算平台、可信计算（safety & security）、基于隔离的体系架构、生命周期与评估、标准化发展情况、团队标准实践、网络安全应用实践。它适合做车载安全架构的工程师、负责 T-BOX/网关安全设计的开发者，以及需要理解 ISO 21434 之前技术脉络的标准化从业者。下面按「计算平台怎么选 → 可信根怎么建 → 隔离架构怎么落 → 评估怎么过」的路径拆。
2. 关键零部件计算平台：从独立 ECU 到中央计算平台的选型逻辑
2.1 计算架构演进的三阶段与对应软件栈
PPT 把计算平台演进分成三个阶段，每个阶段对应不同的软件架构和总线速率。第一阶段是独立 ECU：独立硬件架构加独立软件架构，跑 AUTOSAR Classic 或 OSEK/VDX，低速数据总线（CAN/LIN），分布式计算网络，扩展靠增减处理器。第二阶段是多域系统控制器：域内融合，比如把信息娱乐和驾驶辅助各自归到一个域控制器，总线开始用 CAN FD 和以太网。第三阶段是中央计算平台：高速总线（千兆以太网），支持冗余的容错架构，跑 Adaptive AUTOSAR 加多操作系统，计算平台本身具备可扩展特性。
选型时核心判断点是：你的功能安全等级和网络安全等级要求是什么。信息娱乐系统属于 Cybersecurity-critical system，涉及隐私和金融数据；驾驶辅助系统同时是 Cybersecurity-critical 和 safety-critical，被注入恶意程序会直接危害驾驶人员。这两个域对隔离的要求完全不同，前者可以接受虚拟化隔离，后者往往需要物理隔离或硬件安全模块兜底。
2.2 多域融合下的两个核心问题与威胁面
PPT 明确点出软件平台的两个核心问题：硬件层面是异构多核或多 SoC，可信层面是 safety/fail-operational 与 security 的平衡。多域计算和跨域计算的关键技术是隔离，高性能带来的潜在威胁是安全状态被打破。
安全状态的定义在 PPT 里给了具体数字：L3 级别大概需要 7-15 秒的持续行驶直到人员介入，L4/L5 大概要几分钟，之后进入自主安全停止（无危害静止）。这意味着你的计算平台在检测到安全事件后，必须在 7-15 秒内维持可控状态，这对实时性和冗余设计提出了硬约束。
威胁面在 PPT 里列了完整清单：攻击服务器发送恶意车辆控制指令、攻击数据库窃取用户及车辆机密信息、攻击车内网关窃取汽车关键数据、攻击车主手机伪造身份、短距离无线攻击破解车身控制系统、攻击车间通讯发送虚假指令、攻击 OBD/T-BOX/车载终端侵入 CAN 总线、攻击路边单元发送恶意指令、空中拦截通讯数据非法读取。每一条对应不同的防护层，后面章节的可信计算和隔离架构就是针对这些威胁的工程回应。
注意：PPT 里提到的「高性能计算平台重大专项」是面向智能网联汽车的车载计算软硬件平台关键技术研究，属于项目背景，不是通用产品选型建议。
3. 可信计算：TPM、SHE 与信任根在车规环境下的落地方式
3.1 TPM 的三个信任根与信任链建立过程
TPM（Trusted Platform Module）在 PPT 里的定义是：开发者通常把 TPM 实现为一个外设，通过总线与系统中的另一个微控制器通信。TPM 规范定义了非易失存储器、密钥存储、随机数生成器、RSA、SHA-1、HMAC 和 Vernam 一次性密码本算法。车规场景下 TPM 有 Automotive-Rich Profile 和 Automotive-Thin Profile 两种配置，前者功能全但成本高，后者裁剪后适合资源受限的 ECU。
可信计算平台必须包含三个信任根：
- 可信度量核心根 CRTM（Core Root of Trust for Measurement）：从平台一加电就执行，是平台初始化代码中不可更改的一部分，是可信度量的起点。只有制造方可以更新、维护和修改，其它任何主体无法改动。
- 可信存储根 RTS（Root of Trust for Storage）：由 TPM 芯片和存储根密钥 SRK 组成，除制造方外任何主体无法通过非法手段获取和修改内部存储信息。
- 可信报告根 RTR（Root of Trust for Reporting）：由 TPM 芯片和背书密钥 EK 组成，用于对外证明平台状态。
信任链的建立过程是：CRTM 先度量 BIOS/引导加载程序，把度量值扩展到 TPM 的 PCR 寄存器，然后逐级度量操作系统加载器、操作系统内核、应用。每一级的度量结果决定下一级是否被信任。PPT 里的 Figure 5 展示了 OBD、Telematics Unit、Wireless Update、Central Gateway、Central Storage 和 Target ECU 之间的 TPM 部署关系，核心思路是 TPM 作为独立硬件锚点，不依赖主 CPU 的安全假设。
信任根的可信性依赖三个层面：物理安全（芯片防拆解、防侧信道）、技术安全（算法实现无漏洞）、管理安全（密钥生命周期管理）。任何一层出问题，整条信任链就是纸糊的。
3.2 SHE 与 J3101：轻量级硬件安全的工程取舍
SHE（Secure Hardware Extension）是 HIS 规范下的方案，PPT 给出的能力清单是：通过硬件提供基于 AES-128 的密码服务，包括加解密、消息认证码、引导加载程序认证、唯一设备 ID；以应用不可直接访问的方式存储密钥。SHE 的定位比 TPM 轻，适合对成本敏感的 ECU，但它不提供 TPM 那样的通用计算能力和完整的信任根体系。
J3101 在 PPT 里标注为 WIP（Work In Progress），说明当时标准还在制定中。工程选型时，如果功能安全等级要求 SIL2 以上且需要完整信任链，TPM 是更稳妥的选择；如果只是需要安全启动和密钥存储，SHE 的性价比更高。两者不是替代关系，很多架构里 TPM 做平台级信任根，SHE 做 ECU 级密钥保护。
提示：PPT 里 TPM 的算法清单包含 SHA-1，这在 2018 年是合规的，但新设计建议直接上 SHA-256 及以上，避免后续迁移成本。
4. 基于隔离的体系架构：MILS 与虚拟化在车载域控中的实现
4.1 MILS 架构的四个安全机制与评估优势
MILS（Multiple Independent Levels of Security/Safety）的核心思想来自 John Rushby 提出的分离概念：每个层次只负责自己的安全域，其它什么都不管。PPT 对比了传统架构和 MILS 架构：传统架构里 Applications、OS Services（设备驱动、文件系统、网络通信）、Memory Management 和 Hardware 混在一起，TCB（Trusted Computing Base）会膨胀到消耗整个系统，评估变得极其困难。MILS 架构在 Applications 和 Hardware 之间插入一个 Separation Kernel，中间件服务被隔离到独立分区，TCB 只包含 Separation Kernel 本身。
MILS 的四个安全机制在 PPT 里定义得很清楚：
- 信息流（Information Flow）：信息只能来自经过认证的来源，只能发送到期望的接收方。
- 数据隔离（Data Isolation）：分区里的数据只能被该分区访问，私有数据保持私有特性。
- 周期处理（Periods Processing）：微处理器在分区之间切换时不会泄露信息，防止信息从一个分区泄露到另一个分区。
- 损害隔离（Damage Limitation）：一个分区的故障不会级联到另一个分区，故障在本地检测、容错和恢复。
评估优势在于：TCB 小了，评估范围就小，认证成本大幅下降。这对需要过 ISO 26262 和 ISO 21434 的车载系统来说是实打实的工程收益。
4.2 虚拟化与可信执行环境的落地步骤
PPT 把「基于隔离的体系架构」的技术手段归结为虚拟化技术加可信执行环境。落地时常见做法是：
第一步，选 Hypervisor。车规级 Hypervisor 需要支持静态分区和实时调度，常见的有基于 ARM 虚拟化扩展的方案。选型时看它是否支持你需要的 Guest OS 数量和外设直通能力。
第二步，划分安全域。把信息娱乐系统、驾驶辅助系统、网关功能分到不同 VM，每个 VM 有独立的内存空间和 CPU 时间片。安全域之间的通信必须经过 Hypervisor 的受控通道，不能直接共享内存。
第三步，配置可信执行环境。把密钥管理、安全启动、身份认证等敏感操作放到 TEE 里，TEE 与 Rich OS 隔离，即使 Rich OS 被攻破，TEE 里的密钥和认证逻辑仍然安全。
第四步，验证隔离有效性。用故障注入测试一个分区的崩溃是否影响其它分区，用侧信道测试验证周期处理是否泄露信息。PPT 里 MILS 的损害隔离机制要求故障检测、容错和恢复都在本地完成，测试时要覆盖这三个环节。
注意：虚拟化隔离不是银弹。如果 Hypervisor 本身有漏洞，所有分区一起沦陷。所以 Hypervisor 的代码审计和形式化验证比普通软件更严格。
5. 生命周期与评估：从标准实践到应用落地的避坑清单
5.1 标准化发展情况与团队实践的关键节点
PPT 在标准化部分覆盖了生命周期与评估、标准化发展情况、团队在标准方面的实践、网络安全应用方面的实践。从工程视角看，生命周期与评估的核心是：安全活动必须嵌入到 V 模型的每个阶段，从概念设计到报废回收。概念阶段做 TARA（威胁分析与风险评估），设计阶段做安全架构设计，实现阶段做安全编码和单元测试，集成阶段做渗透测试，运维阶段做漏洞监控和 OTA 更新。
团队在标准方面的实践部分，PPT 没有展开具体案例，但从上下文推断，电子科技大学嵌入式软件工程中心与广东为辰信息科技在 2018 年前后参与了智能汽车网络安全相关标准的起草和验证工作。标准化发展情况部分提到根据行业标准和国家标准进行发展和实施，这意味着当时国内标准体系还在建设中，企业实践往往先于标准落地。
5.2 避坑清单：五条血泪经验
现象一：TPM 通信总线被旁路。原因：TPM 作为外设通过总线与主控通信，如果攻击者物理接触总线，可以窃听或注入。解决：总线加密或使用片内 TPM，物理层加防拆解设计。
现象二：信任链在 OTA 更新时断裂。原因：OTA 更新包没有经过 CRTM 验证就直接刷入，导致恶意固件获得信任。解决：OTA 包必须签名，更新前由 CRTM 验证签名，更新后重新度量并扩展 PCR。
现象三：MILS 分区配置错误导致信息泄露。原因：Separation Kernel 的配置表写错，两个本应隔离的分区共享了内存页。解决：配置表用形式化工具验证，上线前做分区隔离渗透测试。
现象四：安全状态时间窗口不满足。原因：L3 要求 7-15 秒持续行驶，但系统检测到安全事件后 3 秒就强制停车，导致后车追尾。解决：安全状态设计必须与功能安全团队联合评审，时间窗口写进需求规格。
现象五：SHE 密钥更新没有回滚保护。原因：SHE 的密钥槽更新时没有版本号，攻击者可以降级到旧密钥。解决：密钥槽加单调递增计数器，拒绝旧版本密钥。
提示：PPT 里提到的「攻击 OBD/T-BOX/车载终端侵入 CAN 总线」是最常见的入口，OBD 接口的访问控制往往被忽视，建议默认关闭写权限，诊断会话需要认证。
6. 进阶技巧：用威胁面反推架构设计，而不是先选方案再补安全
PPT 最后落在网络安全应用方面的实践和结语，但真正有价值的进阶用法是：不要先选 TPM 还是 SHE、先选 MILS 还是虚拟化，而是先把威胁面列全，再反推每一层需要什么机制。
我一般会这么做：拿 PPT 里那份威胁清单当检查表，逐条问「这条威胁在我的架构里被哪一层拦截」。比如「攻击车内网关窃取汽车关键数据」——如果网关和娱乐系统在同一个 VM 里，虚拟化隔离拦不住；如果网关有独立分区且通信经过 Separation Kernel 的受控通道，MILS 能拦；如果网关的密钥存在 TPM 里且通信加密，TPM 能拦。三层都配上，才算闭环。
验证方法上，PPT 里的信任链和 MILS 机制可以用一个简单测试矩阵来覆盖：
| 测试项 | 测试方法 | 通过标准 |
|---|---|---|
| 信任链完整性 | 篡改引导加载程序后启动 | 系统拒绝启动并告警 |
| 分区隔离 | 在一个分区执行越界访问 | 访问被拦截，其它分区无影响 |
| 周期处理 | 分区切换时抓取内存残留 | 无敏感数据泄露 |
| 损害隔离 | 注入故障使一个分区崩溃 | 其它分区正常运行 |
| 安全状态时间 | 模拟安全事件并计时 | 在 7-15 秒窗口内维持可控 |
从那以后我每次做车载安全架构评审，都强制走一遍「威胁清单 → 拦截层 → 测试用例」的闭环，缺一层就不签字。希望帮到你。
本文还有配套的精品资源，点击获取
