2、嵌入式系统安全基础：威胁模型、攻击面、常见攻击类型（侧信道、故障注入、逆向工程）、安全需求分析
嵌入式系统一旦部署到物理环境中，便脱离了数据中心的物理防护边界。攻击者可以直接接触设备，通过调试接口、电源波动、电磁辐射甚至温度变化来获取密钥或篡改固件。理解威胁模型与攻击面，是设计HSM（硬件安全模块）和安全启动方案的前提。本章将系统梳理嵌入式系统的安全基础，建立从威胁识别到安全需求落地的完整分析框架。
上图展示了嵌入式系统面临的三类攻击面及其典型攻击手段。物理攻击面强调攻击者与设备的直接交互，逻辑攻击面关注软件与协议层面的漏洞，供应链攻击面则贯穿设备从制造到退役的全生命周期。这三者并非孤立，例如一次成功的故障注入（物理）可能绕过安全启动校验，进而为逆向工程（逻辑）打开通道。因此，安全设计必须从系统整体出发，而非孤立地防御某一类攻击。
2.1 威胁建模：从资产识别到攻击路径分析
核心原理
威胁建模是安全设计的起点，其核心是回答三个问题：要保护什么？（资产）、谁可能攻击？（威胁源）、如何攻击？（攻击路径）。在嵌入式系统中，资产不仅包括固件和密钥，还包括用户数据、设备身份、功能可用性以及品牌信誉。威胁源则从脚本小子到国家级APT不等，其能力差异巨大——一个消费级IoT设备的威胁模型与军用通信设备的威胁模型截然不同。
判断方法：STRIDE与攻击树
实践中常用微软的STRIDE模型进行系统化威胁识别，每个字母代表一类威胁：
| 类别 | 含义 | 嵌入式场景示例 |
|---|---|---|
| Spoofing（伪装） | 冒充合法实体 | 伪造设备身份接入网关 |
| Tampering（篡改） | 修改数据或代码 | 篡改固件升级包 |
| Repudiation（抵赖） | 否认已发生的操作 | 否认发送过恶意指令 |
| Information Disclosure（信息泄露） | 机密数据被读取 | 通过侧信道提取AES密钥 |
| Denial of Service（拒绝服务） | 系统不可用 | 故障注入导致安全启动死循环 |
| Elevation of Privilege（提权） | 获得更高权限 | 从用户态提权到Secure World |
攻击树则从顶层攻击目标出发，逐层分解攻击手段。例如“获取固件加密密钥”这一目标，可分解为“侧信道分析”“故障注入绕过”“从内存转储提取”等子节点，每个子节点又可继续细化。攻击树帮助安全工程师直观地识别最薄弱的攻击路径，从而优先投入防御资源。
实战要点：威胁建模不是一次性的活动。在硬件选型阶段、固件架构设计阶段、量产部署阶段以及每次固件更新时，都应重新审视威胁模型。例如，当产品从室内环境扩展到户外无人值守场景时，物理攻击面的风险等级会显著上升，此时必须考虑增加主动屏蔽层或传感器融合检测。
案例拆解：智能电表威胁建模
某智能电表项目在威胁建模阶段识别出以下关键资产：计量数据、费率配置、远程升级密钥、设备认证证书。通过STRIDE分析，发现主要威胁包括：攻击者通过物理接触UART接口获取调试权限（信息泄露+提权）；通过伪造电表向数据中心发送虚假用电数据（伪装）；通过电磁干扰使计量芯片产生偏差（篡改）。针对这些威胁，设计团队决定：禁用UART引导模式、采用安全启动验证固件签名、为计量芯片增加电压/温度监测以检测故障注入。这一案例表明，威胁建模的输出直接指导了后续的安全架构决策。
常见误区：许多团队将威胁建模等同于“列一份威胁清单”，却未评估威胁发生的可能性与影响程度。建议使用DREAD模型（Damage, Reproducibility, Exploitability, Affected Users, Discoverability）对每个威胁进行量化评分，优先处理风险值最高的前20%威胁。
2.2 攻击面分析：硬件、软件与通信接口
核心原理
攻击面是系统暴露给攻击者的所有入口点的总和。嵌入式系统的攻击面远比纯软件系统复杂，因为它同时包含物理触点、无线接口、传感器通道以及供应链环节。攻击面管理的目标是最小化——每减少一个不必要的调试接口、每关闭一个未使用的通信协议，系统的安全基线就提高一分。
操作流程：攻击面枚举与分类
- 硬件接口盘点：列出所有物理引脚、连接器、测试点，包括JTAG/SWD、UART、SPI、I2C、USB、以太网PHY、天线接口等。使用万用表和逻辑分析仪确认每个接口的实际功能。
- 软件接口盘点：梳理所有网络服务（如HTTP、MQTT、CoAP）、本地进程间通信（共享内存、Socket）、文件系统接口以及调试日志输出。
- 无线接口盘点：包括Wi-Fi、BLE、Zigbee、Sub-1GHz、NFC、蜂窝网络等，记录协议版本、加密方式、配对机制。
- 分类与评级：将每个接口按“可访问性”（物理接触/远程）和“权限级别”（用户态/内核态/安全世界）进行矩阵分类，标注高风险项。
案例拆解：工业控制器的攻击面收敛
某工业PLC控制器在安全评估中发现攻击面过大：PCB上保留了未焊接的JTAG排针、UART调试口在量产固件中未禁用、以太网口开放了Telnet服务。攻击者只需拆开外壳，用杜邦线连接UART即可获得root shell。整改措施包括：1) 硬件改版移除JTAG排针，仅保留激光切割的测试焊盘；2) 量产固件中禁用UART控制台，仅保留不可交互的日志输出；3) 将Telnet替换为SSH，并启用证书认证。整改后，攻击面从“物理接触即可完全控制”降低为“需要专业设备进行侧信道分析”。
经验提醒：攻击面分析应贯穿硬件设计评审、PCB Layout评审、固件集成测试和量产前安全审计四个阶段。特别是在PCB Layout阶段，应检查是否有测试点暴露了敏感信号线（如SPI Flash的MISO/MOSI），这些信号线可能被用于嗅探固件内容。
2.3 常见攻击类型深度剖析
侧信道攻击：从功耗到电磁辐射
侧信道攻击利用密码算法执行过程中泄露的物理信息来恢复密钥。最经典的是简单功耗分析（SPA）和差分功耗分析（DPA）。SPA直接观察功耗轨迹中的特征模式，例如RSA模幂运算中“平方-乘”操作的不同功耗波形；DPA则通过统计大量功耗轨迹与密钥假设之间的相关性来恢复密钥。电磁辐射（EM）攻击是功耗攻击的非接触变体，攻击者可在数厘米外用电感探头采集芯片的电磁泄漏。此外，时序攻击通过测量密码操作的执行时间差异来推断密钥位，例如某些软件实现的AES在特定密钥字节下会触发更快的查表路径。
故障注入：破坏计算的正确性
故障注入通过外部物理手段使芯片产生计算错误，从而绕过安全机制。常见手段包括：电压毛刺（在芯片供电引脚上叠加纳秒级尖峰）、时钟毛刺（瞬态改变时钟频率导致时序违规）、电磁脉冲（用线圈产生局部强磁场干扰）、激光注入（聚焦激光束照射特定晶体管区域）。典型攻击场景是：在安全启动校验过程中注入故障，使CPU跳过签名验证分支，直接跳转到攻击者代码。防御措施包括：电压/时钟监测电路、冗余计算、故障检测位、以及HSM中的主动屏蔽层。
逆向工程：从固件到算法
逆向工程的目标是提取固件、恢复算法逻辑、定位密钥存储位置。攻击者首先通过固件提取获取二进制镜像——手段包括直接读取外部SPI Flash、利用调试接口转储内存、或通过降级攻击诱导设备加载旧版本固件。随后使用静态分析工具（如Ghidra、IDA Pro）进行反汇编和反编译，识别密码算法调用、密钥比较逻辑和硬件寄存器操作。对于混淆过的固件，攻击者会结合动态分析——在模拟器或真实设备上运行，通过插桩监控函数调用和内存访问。硬件安全模块（HSM）的核心价值之一，就是将密钥和关键算法封装在物理隔离的安全边界内，使逆向工程无法触及。
| 攻击类型 | 攻击者所需条件 | 典型目标 | 主要防御手段 |
|---|---|---|---|
| 侧信道（SPA/DPA/EM） | 物理接触或近距离（<10cm） | AES/RSA/ECC密钥 | 掩码、隐藏、恒定时间实现 |
| 故障注入 | 物理接触或高精度设备 | 安全启动、安全存储 | 电压/时钟监测、冗余校验 |
| 逆向工程 | 固件提取能力+分析工具 | 算法逻辑、密钥存储位置 | 安全启动、HSM、代码混淆 |
| 协议攻击 | 网络接入或无线嗅探 | 通信密钥、会话令牌 | TLS/DTLS、双向认证 |
风险提示：侧信道攻击并非实验室中的理论威胁。2023年公开报道的某款车规级MCU被通过EM攻击在30分钟内恢复了AES-128密钥，攻击设备成本不足2000美元。对于高价值资产，必须假设攻击者具备中等以上的侧信道分析能力。
2.4 安全需求分析与设计原则
核心原理：从威胁到需求的映射
安全需求不是凭空产生的，而是威胁模型与业务约束共同作用的结果。一个完整的嵌入式安全需求体系应覆盖以下维度：机密性（密钥、数据不被未授权读取）、完整性（固件、配置不被篡改）、可用性（安全机制不因故障注入而失效）、真实性（设备身份和消息来源可验证）、不可抵赖性（关键操作可审计追踪）。
操作流程：安全需求规格化
- 资产分级：将系统资产按敏感度分为公开、内部、机密、绝密四级，不同级别对应不同的保护强度。
- 威胁-需求映射：针对每个已识别的威胁，明确对应的安全需求。例如“通过UART获取root shell”的威胁，对应需求为“量产固件禁用UART调试接口”和“启用安全启动验证”。
- 性能与成本权衡：安全机制会引入额外的功耗、延迟和BOM成本。例如，全盘加密需要额外的CPU开销和存储空间；HSM芯片增加单板成本。需求分析必须明确安全等级与产品定位的匹配关系。
- 可验证性：每条安全需求都应具备可测试的验收标准。例如“安全启动时间不超过500ms”或“侧信道攻击尝试超过10000次无法恢复密钥”。
案例拆解：车载T-Box安全需求落地
某T-Box（车载远程通信终端）项目定义了以下安全需求：1) 安全启动：仅允许运行经HSM签名的固件，启动时间<300ms；2) 安全存储：私钥存储在HSM内部，不可通过软件读取；3) 安全通信：与云端使用TLS 1.3双向认证；4) 故障注入防护：检测到电压异常时自动进入安全状态并记录日志。在实现过程中，团队发现HSM的签名验证操作耗时约80ms，加上镜像加载时间，总启动时间达到350ms，超出需求。通过优化启动流程——将签名验证与硬件初始化并行执行——最终将启动时间压缩至280ms。这一案例说明，安全需求必须与工程实现反复迭代，而非停留在文档层面。
总结复盘：嵌入式安全设计应遵循“纵深防御”原则——不依赖单一安全机制。即使HSM被攻破，安全启动和通信加密仍能提供后续防线。同时，安全需求应具备可演进性，随着攻击技术的进步（如量子计算对RSA的威胁），需求体系需要定期更新。
本章从威胁模型、攻击面、攻击类型到安全需求，建立了嵌入式系统安全分析的完整方法论。下一阶段将深入探讨HSM的硬件架构与密钥管理机制，将本章的安全需求转化为具体的芯片选型和电路设计决策。