威胁建模：IoT设备面临的安全威胁全景图
各位同学，欢迎来到《固件加固》的第一章。
做IoT安全这些年，我见过太多产品“裸奔”上市。厂商急着抢市场，固件一写完就量产。结果呢？被挖出后门、被植入僵尸网络、被提取私钥……说白了，就是没在设计阶段想清楚“谁会攻击我、从哪下手”。
这一章，我们就来干这件事——威胁建模。它不是纸上谈兵，而是帮你把攻击者的思路摸透，然后反过来加固自己的设备。
1.1 IoT设备面临的安全威胁全景图
先看一张全景图。我习惯把IoT设备的威胁分成四个维度：
| 维度 | 典型威胁 | 真实案例（我遇到的） |
|---|---|---|
| 物理层 | 调试接口暴露、芯片开盖、侧信道攻击 | 某智能锁，JTAG口直接焊在PCB边缘，用夹子就能连 |
| 固件层 | 固件提取、逆向分析、签名绕过 | 某路由器固件未加密，binwalk一把梭，配置文件明文 |
| 通信层 | 协议重放、中间人攻击、密钥协商劫持 | 某智能灯泡，UDP广播不加密，隔壁能控制你家灯 |
| 应用层 | Web接口未授权、云平台API滥用、OTA更新劫持 | 某摄像头云平台，固件下载链接是HTTP，直接替换 |
你想想看，这四个维度几乎覆盖了从硬件到手、到固件运行、到联网通信、再到云端交互的全链路。任何一个环节出问题，整个设备就沦陷了。
核心观点：威胁不是孤立的。物理攻击可以辅助固件提取，固件逆向又能找到通信密钥。攻击者从来不会只打一个点。
1.2 STRIDE模型在嵌入式系统中的应用
说到威胁建模，微软的STRIDE模型是绕不开的。它把威胁分成六类：Spoofing（假冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。
但注意——STRIDE原本是为PC软件设计的。直接套到嵌入式系统上，会漏掉很多IoT特有的威胁。我自己的做法是做一次“嵌入式适配”：
- S - 假冒：在IoT里，不仅是用户假冒，还有设备假冒。比如伪造一个传感器向网关上报假数据。
- T - 篡改：固件被篡改是最常见的。我记得有个项目，OTA包没做签名校验，攻击者中间人替换固件，直接拿到了root shell。
- R - 抵赖：嵌入式设备日志能力弱，攻击者擦除日志后，你根本不知道谁动过设备。
- I - 信息泄露：固件里的硬编码密钥、调试接口的明文输出，都是重灾区。
- D - 拒绝服务：IoT设备算力有限，一个畸形数据包就能让MCU死机。
- E - 权限提升：从用户态提权到内核态，或者从普通传感器提权到网关管理员。
我的习惯：每分析一个设备，我都会拿STRIDE六类挨个过一遍。哪怕觉得“这个应该没问题”，也要写下来。因为“觉得没问题”往往是最大的问题。
下面这张图，是我自己画的一个STRIDE威胁映射图，把六类威胁对应到IoT设备的典型攻击面上：
1.3 资产识别与攻击面分析
威胁建模的第二步，是搞清楚你要保护什么。这就是资产识别。
IoT设备的资产，不只是硬件和固件。我一般会列一个资产清单：
- 硬件资产：MCU/SoC、Flash、RAM、传感器、调试接口（JTAG/SWD）、安全元件（SE/TPM）
- 固件资产：Bootloader、内核、文件系统、配置参数、密钥证书、应用程序
- 通信资产：Wi-Fi/BLE/Zigbee协议栈、MQTT/CoAP/HTTP客户端、TLS会话
- 数据资产：设备标识、用户隐私数据、遥测数据、日志
- 云/后端资产：API密钥、设备注册表、OTA更新服务器
注意：很多团队只把“固件”当资产，忽略了调试接口和通信协议。我曾经遇到一个项目，固件加密做得很好，但JTAG口没锁，攻击者直接通过调试接口读取了内存中的明文密钥。加密固件？白费功夫。
资产识别完了，下一步就是攻击面分析。说白了，就是看攻击者能从哪些入口接触到这些资产。
我习惯用“入口-资产-威胁”三元组来梳理。举个例子：
| 入口 | 目标资产 | 威胁（STRIDE） | 风险等级 |
|---|---|---|---|
| 物理USB口 | 固件镜像 | T - 篡改 | 高 |
| OTA更新通道 | 固件签名密钥 | T, I | 高 |
| 调试串口 | root shell | E - 权限提升 | 高 |
| Wi-Fi扫描 | 通信密钥 | I - 信息泄露 | 中 |
| Web管理界面 | 管理员凭证 | S, E | 高 |
这张表一出来，你就知道该优先加固哪里。比如OTA通道和调试串口都是高风险，那就必须上签名校验和调试接口锁定。
避坑指南：我曾经在一个智能网关项目里，只分析了“外部网络”攻击面，忽略了“本地Wi-Fi”入口。结果攻击者连上同一Wi-Fi后，直接通过mDNS发现设备，用默认密码登录了Web界面。所以，攻击面分析一定要覆盖所有入口，包括物理、本地网络、蓝牙、甚至NFC。
1.4 威胁建模的输出：一份可执行的安全需求清单
威胁建模不是画几张图就完事了。最终要输出一份安全需求清单，直接指导开发团队改代码。
我一般会这样组织输出：
- 威胁ID：唯一编号，方便追溯
- 威胁描述：谁、通过什么入口、攻击什么资产、造成什么后果
- STRIDE分类：明确是哪一类威胁
- 风险等级：高/中/低（结合攻击难度和影响范围）
- 缓解措施：具体怎么做（比如“OTA包必须使用ECDSA签名并校验”）
- 验证方法：怎么确认措施生效（比如“尝试替换签名后的固件，看设备是否拒绝更新”）
举个例子：
威胁ID：TH-001
描述：攻击者通过物理USB口连接设备，利用未签名的固件更新机制，刷入恶意固件，获得设备完全控制权。
STRIDE：T（篡改）
风险：高
缓解：1. 所有固件更新包必须使用硬件安全模块签名的RSA-2048签名；2. Bootloader在加载前验证签名；3. 禁用USB口的固件更新功能（量产时熔断）。
验证：1. 使用自签名固件尝试更新，设备应拒绝；2. 使用正确签名但内容被篡改的固件，设备应拒绝。
嗯，到这里，第一章的核心内容就差不多了。威胁建模这件事，说白了就是“先想清楚敌人怎么打，再决定自己怎么防”。STRIDE模型帮你分类威胁，资产识别帮你锁定目标，攻击面分析帮你找到入口。三者结合，你就能在开发之前把大部分安全漏洞堵死。
记住：安全不是加功能，而是做减法——减少攻击者可以利用的路径。