一、NB-IoT安全概述
各位同学好，我是老张。在物联网安全这块摸爬滚打了十来年，今天咱们聊聊NB-IoT的安全问题。说实话，很多人觉得NB-IoT传输数据量小，安全不重要——这是个危险的误解。
1.1 物联网安全威胁分析
先说说物联网面临的安全威胁。我把它分成三类，你对照着看看自己的项目有没有踩过坑。
1.1.1 终端侧威胁
- 物理篡改：终端设备部署在户外，被人拆开读Flash、改固件。我在某智能水表项目里就遇到过，有人把水表拆了，改了计量参数。
- 固件逆向：通过JTAG/SWD接口读取固件，分析通信协议。说白了，你的加密算法、密钥存储位置，人家一读就知道。
- 侧信道攻击：通过功耗、电磁辐射分析密钥。嗯，这个在NB-IoT终端上相对少见，但高端场景要考虑。
1.1.2 网络侧威胁
- 伪基站攻击：伪造NB-IoT基站，诱骗终端接入。我2019年帮某运营商做测试时，用开源工具搭建过伪基站，成功率相当高。
- 信令风暴：大量终端同时发起连接，导致网络拥塞。你想想看，一个小区几千个水表同时上报数据，基站扛得住吗？
- 中间人攻击：在核心网侧截获或篡改数据。虽然NB-IoT有空口加密，但端到端加密不到位的话，核心网内部还是裸奔的。
1.1.3 平台侧威胁
- API滥用：攻击者通过伪造设备ID，向平台发送虚假数据。
- 数据泄露：云平台数据库被拖库，用户数据全曝光。
- 权限提升：从普通用户权限提升到管理员权限。
核心观点：NB-IoT的安全不是单点问题，而是终端、网络、平台三端联动的系统工程。我见过太多项目只做了空口加密，结果终端固件被逆向，密钥全暴露——白忙活一场。
1.2 NB-IoT安全需求
基于上面的威胁分析，NB-IoT的安全需求可以归纳为五个维度。我个人习惯用CIA模型扩展一下：
| 安全需求 | 说明 | 典型场景 |
|---|---|---|
| 机密性 | 数据在传输和存储过程中不被未授权方读取 | 智能电表上报用电量，防止被窃听 |
| 完整性 | 数据在传输过程中不被篡改 | 燃气阀门控制指令，防止被篡改导致事故 |
| 可用性 | 终端和网络能正常提供服务 | 火灾报警器，必须保证随时在线 |
| 身份认证 | 确认终端和平台的合法身份 | 防止伪基站或假终端接入 |
| 不可否认性 | 终端发送的数据不能被抵赖 | 智能门锁开锁记录，用于纠纷追溯 |
避坑指南：我曾经在某个项目中，客户只要求了机密性，没提完整性。结果攻击者篡改了传感器数据，导致系统误判。从那以后，我每个项目都会跟客户确认：你到底需要哪几个安全属性？
1.3 安全通信架构设计原则
好了，威胁和需求都清楚了，那怎么设计安全架构呢？我总结了四条原则，都是血泪教训换来的。
原则一：纵深防御
别指望单点防护能搞定一切。我的做法是：
- 终端侧：硬件安全单元（SE）存储密钥，固件签名校验
- 网络侧：空口加密（3GPP标准）+ 传输层加密（DTLS/TLS）
- 平台侧：API鉴权 + 数据脱敏 + 访问控制
说白了，就算攻破了一层，还有下一层等着。
原则二：最小权限
终端只拥有完成本职工作所需的最小权限。举个例子：
- 温度传感器只能上报温度数据，不能下发控制指令
- 固件升级服务器只能更新固件，不能读取业务数据
我见过一个项目，所有终端都用同一个API Key，结果一个终端被攻破，整个系统都沦陷了。
原则三：密钥分离
不同用途的密钥要分开管理：
- 通信加密密钥：用于数据加密
- 身份认证密钥：用于终端和平台双向认证
- 固件签名密钥：用于固件完整性校验
你想想看，如果通信密钥和认证密钥是同一个，那通信密钥泄露后，攻击者就能伪造终端身份——后果很严重。
原则四：轻量化设计
NB-IoT终端资源有限，不能照搬互联网的安全方案。我的建议是：
- 优先使用硬件加速的加密算法（如AES-128硬件模块）
- 避免使用计算密集型的非对称加密（如RSA-2048）
- 采用预共享密钥（PSK）代替证书链验证
重要提醒：轻量化不等于弱安全。我见过有人为了省电，把加密强度降到AES-64——这跟没加密差不多。记住，NB-IoT的功耗瓶颈在射频，不在加密计算。AES-128的功耗增加不到5%，完全可以接受。
小结
这一章我们聊了NB-IoT面临的安全威胁、安全需求，以及架构设计原则。说白了，安全不是功能，而是贯穿整个系统设计的思维方式。下一章我会详细讲终端侧的硬件安全方案，包括SE芯片选型和密钥注入流程——这些都是我在产线里踩过的坑，到时候跟大家好好聊聊。