核心原则解读：无默认密码、漏洞披露、软件更新机制

各位工程师，咱们直接进入正题。ETSI EN 303 645 这个标准，说白了就三个核心原则撑起了整个安全框架。我拆解过不下二十款智能家居设备，发现凡是出过安全问题的，基本都能在这三条里找到根因。今天咱们一条一条掰开揉碎了讲。

一、无默认密码：最基础也最容易被忽视

ETSI 的要求其实很直白：设备不能使用通用的默认密码。每个设备要么强制用户在首次使用时设置密码，要么出厂时生成唯一的设备密码。

我见过最离谱的案例是什么？某款智能灯泡，出厂密码是「123456」，而且写在了说明书第一页。你想想看，这跟把家门钥匙挂在门外有什么区别？

具体来说，标准要求以下几点：

• Provision 5.1-1：每个设备必须有唯一的身份凭证，不能批量共用
• Provision 5.1-2：如果使用密码，必须强制用户在初始化时设置
• Provision 5.1-3：密码不能硬编码在固件里，要能修改

这里有个容易踩的坑：很多厂商觉得「我用二维码扫码绑定，不需要密码」。但 ETSI 看的是认证机制，不是形式。扫码绑定的密钥如果也是固定的、可预测的，照样违规。

二、漏洞披露：给安全研究员留条活路

这条原则很多人不理解。厂商会觉得：「我产品卖得好好的，为什么要公开漏洞？」

其实逻辑很简单：漏洞不会因为你不承认就不存在。与其让黑客私下交易，不如让白帽研究员有正规渠道上报。

ETSI 的要求包括：

条款	要求内容	常见违规点
Provision 5.2-1	公布漏洞披露策略和联系渠道	只留客服电话，没有安全专用邮箱
Provision 5.2-2	明确漏洞响应时间窗口	承诺「尽快修复」但没有具体天数
Provision 5.2-3	及时修复已确认的漏洞	拖过 90 天还不发补丁

说实话，很多小厂商觉得这条跟自己没关系。但欧盟市场已经明确：没有漏洞披露机制的产品，直接判定不合规。你想想看，因为少写一个页面，整批货被海关扣下，值不值？

三、软件更新机制：别让补丁变成新漏洞

这条是三条里技术含量最高的。ETSI 要求设备必须支持安全更新，而且更新过程本身要安全。

我拆解过一款智能门锁，它的 OTA 更新流程是这样的：

// 错误示范：明文传输固件
GET /firmware/latest.bin HTTP/1.1
Host: update.iot-device.com
// 没有签名验证，没有加密传输
// 攻击者可以中间人替换固件

正确的做法应该是：

// 正确示范：签名验证 + 加密传输
1. 设备向服务器请求更新元数据
2. 服务器返回：固件哈希 + 签名 + 版本号
3. 设备验证签名（使用预置公钥）
4. 下载加密固件，解密后校验哈希
5. 校验通过才允许刷写

ETSI 在软件更新方面的具体要求：

• Provision 5.3-1：更新包必须经过签名验证
• Provision 5.3-2：更新过程不能泄露用户数据
• Provision 5.3-3：设备要能自动检查更新（或用户手动触发）
• Provision 5.3-4：更新失败时设备要能回滚到安全版本

这里有个细节很多人忽略：更新服务器本身也要安全。如果你的 OTA 服务器被攻破，攻击者可以给所有设备推送恶意固件。所以 ETSI 要求更新通道必须使用 TLS，而且证书要定期轮换。

三条原则的内在逻辑

这三条原则不是孤立的，它们构成了一个安全闭环：

1. 无默认密码 —— 防止设备被轻易入侵
2. 漏洞披露 —— 发现入侵途径后有人管
3. 软件更新 —— 管了之后能真正修好

缺了任何一环，安全防线都会出现缺口。我经常跟团队说：安全不是做给审核看的，是做给用户用的。ETSI 标准之所以在全球被广泛采纳，就是因为它抓住了智能家居安全最本质的三个痛点。