📚 课程目录第4章认证协议基础

4. 认证协议基础：对称认证 vs 非对称认证、挑战-响应机制、基于TLS/DTLS的传输层安全

各位好，欢迎来到第四章。这一章我们聊聊认证协议的基础。说实话，很多IoT设备出安全问题，根源就在于认证没做好。要么选错了协议，要么实现得不够严谨。今天我把这块掰开揉碎了讲清楚。

先问个问题：你的IoT设备要和服务器通信，怎么证明自己是合法的？

两种主流思路：对称认证和非对称认证。它们各有各的脾气。

我个人习惯：能选非对称就别用对称。为什么？

我在项目中遇到过一件事：某智能门锁厂商用了对称密钥，每个设备出厂时烧录同一个密钥。结果一台设备被逆向，所有门锁都能被远程打开。嗯，这就是典型的「一把钥匙开所有锁」的悲剧。

但非对称认证也不是万能的。你想想看，一个Zigbee传感器只有几十KB的RAM，跑一次ECDSA签名可能要几百毫秒，电池扛不住。所以实际项目中，我经常采用混合方案：

我的建议： 对于MCU类设备（如ESP32、STM32），优先考虑Ed25519算法。它比ECDSA更快，签名更小，而且不容易出现侧信道攻击。我在几个量产项目里都用了它，效果不错。

对称认证有个致命弱点：重放攻击。攻击者截获一次认证报文，下次直接重放，服务器就以为他是合法设备。

怎么防？用挑战-响应（Challenge-Response）机制。

说白了就是：服务器先发一个随机数（挑战），设备用密钥加密后返回（响应）。每次挑战不同，重放报文就没用了。

流程如下：

这里有个细节：nonce 必须足够随机，而且不能重复使用。我曾经见过一个项目，服务器用时间戳当 nonce，结果攻击者伪造时间戳就能绕过认证。避坑指南：永远用密码学安全的随机数生成器，别偷懒用 rand()。

核心要点： 挑战-响应机制的核心是「一次一密」。nonce 的随机性和唯一性决定了整个认证的安全性。别小看这一步，很多IoT漏洞就出在这里。

聊完认证协议，我们看看传输层。TCP用TLS，UDP用DTLS。这是IoT通信的事实标准。

为什么非要用TLS？直接加密不行吗？

你想想看，TLS不只是加密，它还提供了：

但IoT设备资源有限，标准TLS握手太「重」了。我建议做以下优化：

优化项	做法	效果
会话复用	缓存会话ID或使用会话Ticket	减少握手次数，降低延迟
精简密码套件	只支持TLS_ECDHE_ECDSA_WITH_AES_128_GCM	减少握手包大小，降低计算开销
证书压缩	使用原始公钥或预共享密钥（PSK）	避免证书链传输，节省带宽
DTLS 1.3	使用最新版本，减少握手往返	1-RTT握手，甚至0-RTT

注意： 0-RTT虽然快，但有重放攻击风险。如果你的设备对数据一致性要求高（比如固件升级），建议禁用0-RTT，或者配合额外的防重放机制。

我在一个智能照明项目里，设备用的是ESP8266，RAM只有80KB。标准TLS握手根本跑不起来。后来我改用DTLS 1.2 + PSK模式，握手包从4KB降到1.2KB，内存占用从60KB降到30KB。嗯，这才跑通了。

下面这张图总结了本章的核心逻辑。你可以把它当作一个决策树：

这张图展示了认证协议的核心分支。你可以看到，对称认证和非对称认证各有各的适用场景，而传输层安全（TLS/DTLS）是独立于认证方式的基础设施。实际项目中，我通常把这三层结合起来：

一个小技巧： 如果你的设备支持硬件安全模块（如ATECC608A），把私钥放在里面，TLS握手时用硬件签名。这样即使固件被逆向，私钥也拿不到。我在几个金融级IoT项目里都这么干，审计一次过。