3. 安全框架
聊到物联网安全，很多人第一反应是「加密算法」、「防火墙」、「入侵检测」。这些当然重要，但如果你没有一个顶层框架来兜底，安全建设就容易变成打地鼠——哪里出问题补哪里。
ETSI 在消费类 IoT 安全上做了件很聪明的事：先出了一份技术报告 TS 103 645，跑通了逻辑；然后把它固化成强制性的欧洲标准 EN 303 645。说白了，前者是「最佳实践指南」，后者是「合规底线」。我当年第一次接触这两个文档时，差点被编号绕晕，后来才搞明白——TS 是告诉你「应该怎么做」，EN 是告诉你「必须怎么做」。
核心关系：TS 103 645 是 EN 303 645 的技术前身和详细解释。EN 303 645 的 13 条安全条款，每一条都能在 TS 103 645 里找到对应的技术实现建议。
为什么需要两层标准？
你可能会问：直接出一个强制标准不就完了？嗯，这里有个现实问题。物联网设备品类太多，从智能灯泡到联网汽车，技术栈天差地别。如果一上来就强制，很多中小企业根本接不住。
ETSI 的做法是：先用 TS 把技术细节写透，让厂商有据可依；等产业成熟了，再提炼出 EN 作为市场准入的硬门槛。我在 2019 年参与过一款智能门锁的合规评估，当时 TS 103 645 刚发布，我们拿着它一条条对，发现很多设计缺陷——比如固件更新没有签名验证、默认密码写死在代码里。这些坑，后来都被 EN 303 645 的条款精准覆盖了。
EN 303 645 的 13 条安全条款概览
EN 303 645 的核心是 13 条安全条款，我习惯把它们分成三组：基础防护、生命周期管理、透明度与沟通。下面这张图可以帮你快速建立整体认知。
条款深度解读：我踩过的坑
条款 1：无默认密码
这条看起来最简单，但实际执行中翻车最多。EN 303 645 要求设备在首次使用时必须强制用户设置新密码，不能存在「admin/admin」这种出厂凭证。
我曾经评估过一款 IP 摄像头，厂商说「我们做了强制修改密码」。结果一测，设备在恢复出厂设置后，密码又变回了默认值。更离谱的是，这个默认密码是写死在 bootloader 里的，连 OTA 更新都改不了。嗯，这就是典型的「合规表面化」——流程上做了，但架构上没兜住。
实战建议：密码初始化逻辑必须放在安全启动之后，且不能依赖出厂固件中的硬编码值。我个人习惯在硬件安全模块（HSM）中生成设备唯一初始凭证，即使恢复出厂，HSM 也会重新生成随机密码。
条款 3：安全软件更新
EN 303 645 要求固件更新必须经过签名验证，且更新过程不能中断。这里有个容易被忽略的点：回滚保护。
标准原文说的是「防止安装未经授权的固件」，但很多厂商只做了签名校验，没做版本号检查。攻击者可以拿一个旧版本（有已知漏洞）的合法签名固件降级设备。我在 2021 年帮客户做渗透测试时，就成功利用这个手法攻破了一台智能网关——它允许用户手动上传任意版本的官方固件。
避坑指南：我曾经见过一个产品，OTA 更新时如果断电，设备就变砖了。EN 303 645 条款 3 明确要求「更新过程必须具有弹性」。解决方案是使用 A/B 分区（双备份系统），更新失败自动回滚到上一个可用版本。
条款 6：最小化攻击面
这条的核心是「只开必要的端口，只跑必要的服务」。但实际项目中，我经常看到开发团队为了方便调试，在正式固件里保留 telnet、调试串口、甚至后门账号。
EN 303 645 要求所有调试接口必须在生产环境中禁用。注意，是「禁用」不是「隐藏」。有些厂商把调试端口从 22 改成 2222，以为就安全了——这种掩耳盗铃的做法，扫描器一跑就现原形。
| 常见攻击面 | EN 303 645 要求 | 常见翻车点 |
|---|---|---|
| 未使用的网络端口 | 默认关闭，仅按需开启 | 开发阶段端口带入生产 |
| 物理调试接口（UART/JTAG） | 生产时物理断开或熔丝烧断 | 只做软件禁用，可被重新启用 |
| 云服务 API 暴露 | 最小权限原则，认证鉴权 | API 密钥硬编码在客户端 |
| 本地网络服务（UPnP/mDNS） | 默认关闭，用户按需开启 | 默认开启且无认证 |
TS 103 645 的技术实现指引
如果说 EN 303 645 是「考纲」，那 TS 103 645 就是「教材」。它针对每一条 EN 条款，给出了具体的技术实现建议。我挑几个重点说说。
安全凭证存储
TS 103 645 明确建议：私钥和证书必须存储在硬件安全区域（如 TEE 或安全元件）。纯软件方案（比如把密钥放在文件系统里加密存储）在标准里被标记为「不推荐」。
为什么？因为软件加密的密钥本身也需要保护，这就成了「鸡生蛋」的问题。我在一个智能门锁项目里见过厂商把 AES 密钥放在 NAND Flash 的保留区，以为没人能找到——结果用逻辑分析仪抓 SPI 总线，密钥明文就飘在线上。
技术底线：如果设备成本允许，优先使用独立安全芯片（SE）或可信执行环境（TEE）。如果成本受限，至少要用 MCU 内置的 OTP（一次性可编程）区域存储根密钥，且确保调试接口无法读取。
漏洞披露管理
EN 303 645 条款 2 要求厂商建立公开的漏洞披露渠道。TS 103 645 进一步细化：披露渠道必须包含安全联系邮箱、PGP 公钥（用于加密通信）、以及明确的响应时间承诺（通常 90 天内发布修复）。
我见过最离谱的案例：某厂商在官网留了一个「安全反馈」表单，但提交后自动回复说「感谢您的反馈，我们会在 3 个工作日内联系您」。结果等了两个月没人理。这种形同虚设的流程，在合规审计里直接判不合格。
合规检查清单（快速自检用）
下面这个清单是我做项目时常用的，你可以拿来对照自己的产品。
- 密码管理：设备首次启动是否强制修改密码？恢复出厂后密码是否重置？
- 更新机制：固件是否有签名验证？更新失败能否回滚？是否支持自动更新？
- 凭证保护：私钥和证书是否存储在硬件安全区域？调试接口能否读取？
- 通信安全：所有网络通信是否使用 TLS 1.2+？证书是否验证？
- 攻击面：生产固件是否关闭了所有调试端口？未使用的服务是否移除？
- 数据隐私：用户数据是否加密存储？删除功能是否彻底擦除？
- 透明度：是否有公开的漏洞披露渠道？安全更新支持周期是否明确？
一个小技巧：我习惯在产品的 CI/CD 流水线里加入自动化合规检查。比如用脚本扫描固件中是否包含 telnet、ssh 等服务的二进制文件，或者检查默认密码是否出现在代码仓库里。这样每次构建都能自动拦截不合规的版本。
从合规到安全：框架的真正价值
最后说点个人体会。ETSI 这个框架最厉害的地方，不是它列出了多少条要求，而是它把安全责任从「安全团队」转移到了「产品团队」。你看 EN 303 645 的条款，没有一条是纯技术难题——强制改密码、做签名验证、关掉调试端口——这些都是产品开发流程里就能解决的事。
我见过太多团队把安全当成「上线前最后一周的补丁工作」，结果漏洞百出。而 ETSI 框架逼着你从一开始就把安全设计进去。说白了，合规只是起点，安全才是终点。框架给了你一张地图，但路还是要自己走。