📚 课程目录第4章身份与认证基线

4、身份与认证基线：设备身份唯一性、证书管理、多因素认证、弱口令防护

身份与认证，说白了就是回答三个问题：你是谁？你凭什么证明？我怎么相信你？

在物联网里，这个问题比互联网复杂得多。互联网上，用户忘了密码可以重置，账号被盗可以申诉。但物联网设备呢？一个传感器部署在偏远基站，一个智能门锁装在用户家里，如果身份被冒用，你连现场操作的机会都没有。

我早年做过一个智慧水务的项目，现场有上千个水压监测终端。结果发现，因为设备身份没有做唯一性绑定，攻击者伪造了一个假终端，往平台里灌了整整两周的假数据。要不是运维人员发现某个监测点的水压曲线异常平滑，根本没人察觉。嗯，从那以后，我对设备身份唯一性这件事，就特别较真。

4.1 设备身份唯一性：给每台设备一个“身份证号”

设备身份唯一性，不是简单地给设备编个号。你得保证这个ID在设备的整个生命周期里，不可篡改、不可伪造、不可重放。

核心原则：设备身份必须与硬件绑定，且具备防克隆能力。

我建议的做法是这样的：

硬件级唯一标识：利用芯片内置的唯一序列号（如MCU的UID、TEE的OTP区、安全芯片的ID）。这些信息出厂时一次性烧录，无法通过软件修改。
身份注册流程：设备首次上电时，向平台发起注册请求。平台验证设备携带的硬件ID和预置密钥，生成设备证书并下发。注册完成后，平台将设备ID、证书指纹、硬件ID三者绑定。
防重放攻击：每次身份认证时，必须携带随机数（Nonce）和时间戳。平台校验通过后，记录本次Nonce，拒绝重复使用。

你想想看，如果设备ID只是写在配置文件里的一个字符串，攻击者只要读一下文件，就能克隆出无数个“合法设备”。所以，硬件绑定是底线。

我的经验：在产线烧录环节，一定要做“身份唯一性校验”。我曾经遇到一个项目，产线工人把同一批次的UID写入了1000台设备，导致上线后平台无法区分设备。后来我们加了一道工序：烧录时平台实时校验，发现重复ID直接报警并锁定烧录工位。

4.2 证书管理：从颁发到吊销，一个都不能少

证书是物联网设备在数字世界的“护照”。但很多团队只关注证书怎么发，不关心证书怎么管。结果呢？证书过期了设备离线，私钥泄露了无法吊销，整个体系形同虚设。

我个人习惯把证书管理分成四个阶段：

阶段	关键动作	常见问题
颁发	设备注册时，由平台CA签发设备证书。证书包含设备ID、公钥、有效期、颁发者信息。	证书有效期设置过长（如10年），私钥泄露后风险敞口太大。
存储	私钥必须存储在安全区域（TEE、SE、HSM）。证书可以明文存储，但需校验完整性。	私钥以文件形式存储在Flash中，攻击者通过固件提取即可获取。
更新	证书到期前，设备主动发起续期请求。平台验证设备身份后，签发新证书。	续期流程没有身份验证，攻击者可以冒用设备身份申请新证书。
吊销	设备报废、私钥泄露、设备被篡改时，平台将证书加入CRL（证书吊销列表）或使用OCSP（在线证书状态协议）实时查询。	CRL更新不及时，导致已吊销证书的设备仍能通过认证。

注意：物联网设备数量巨大，CRL会变得非常庞大。我建议采用“分级吊销”策略：平台维护一个增量CRL，设备每次认证时只拉取增量部分。对于资源受限的设备，可以使用OCSP Stapling，由平台代理查询证书状态。

这里有一个我踩过的坑。有一次，客户要求所有设备使用自签名证书。理由是“省事，不用搭CA”。结果设备上线后，平台无法统一管理证书，某个设备私钥泄露后，我们只能一台一台手动更新。那段时间，我几乎每天都在想：为什么当初不坚持用PKI体系？

4.3 多因素认证：别把鸡蛋放在一个篮子里

单因素认证，比如只靠密码或者只靠证书，风险都太高。密码可能被猜解，证书可能被提取。多因素认证，就是让攻击者即使拿到一个因素，也无法完成认证。

物联网场景下，我常用的多因素组合有：

设备证书 + 硬件指纹：认证时，设备不仅出示证书，还提供当前硬件状态（如Bootloader哈希、固件版本、安全芯片状态）。平台验证证书有效后，再比对硬件指纹是否与注册时一致。
设备证书 + 行为特征：平台记录设备的历史行为模式（如上报频率、数据格式、网络路径）。如果认证时的行为与历史模式偏差过大，即使证书有效，也触发二次验证。
设备证书 + 动态令牌：设备内置TOTP算法，每30秒生成一个动态验证码。认证时，平台同时验证证书和动态码。

你可能会问：资源受限的传感器，跑不了TOTP怎么办？

嗯，这里有个折中方案。设备可以只做“轻量级多因素”：证书认证为主，同时携带一个由平台预置的“设备秘密”（Device Secret）。这个秘密在设备注册时由平台生成，存储在设备的安全存储区。认证时，平台验证证书后，再验证设备能否正确解密一个用该秘密加密的挑战值。虽然不算严格的多因素，但比单因素强得多。

我的建议：不要为了追求“多因素”而牺牲设备性能。对于MCU类设备，优先保证证书认证的可靠性，再考虑增加第二个因素。对于网关或边缘计算设备，必须启用多因素认证。

4.4 弱口令防护：最容易被忽视的防线

弱口令，是物联网安全里最老生常谈、但又最屡禁不止的问题。你想想看，一个摄像头出厂密码是admin/admin，用户买回去不修改，攻击者扫描一下全网就能直接登录。这不是技术问题，这是意识问题。

我从合规和工程两个角度，说说怎么防：

4.4.1 合规层面：强制要求

禁止出厂默认口令：设备首次使用时，必须强制用户修改初始密码。密码复杂度必须满足：长度≥8位，包含大小写字母、数字、特殊字符中的至少三种。
口令策略可配置：平台应支持管理员自定义口令策略，如密码有效期、历史密码禁止重复、登录失败锁定等。
弱口令字典检测：用户设置密码时，平台实时比对弱口令字典（如123456、password、admin123等），命中则拒绝。

4.4.2 工程层面：技术兜底

口令加密存储：设备本地和平台侧，口令必须使用bcrypt、scrypt或Argon2等慢哈希算法存储。禁止使用MD5、SHA-1等快速哈希。
登录频率限制：设备登录接口必须做频率限制。比如，同一IP在1分钟内失败5次，锁定该IP 30分钟。
无密码模式：对于纯传感器类设备，建议直接取消口令登录，改用证书认证。既然不需要人操作，就别留一个可能被猜解的口令入口。

我曾经遇到一个案例：某厂商的智能插座，用户可以通过App设置一个“设备密码”来防止他人本地控制。结果这个密码以明文形式存储在设备的Flash中。攻击者通过固件逆向，直接读出了所有用户的密码。后来我们给出的整改方案是：密码必须哈希存储，且每次验证时使用加盐哈希。

4.5 知识体系总览

下面这张图，把身份与认证基线的核心逻辑串起来了。你可以看到，设备身份唯一性是根基，证书管理是骨架，多因素认证是加固，弱口令防护是兜底。四者缺一不可。