"鉴权"这个词在物联网资料里出现频率极高，但不少人对它的理解停在"连 Wi-Fi 输密码"。真正把设备接入做深了，绕不开一个机制：挑战-响应，以及由它组成的双向鉴权。
单向认证的问题
设备拿预置密钥跟云端过 TLS，这只证明了"设备知道密钥"。反过来，设备怎么知道对面是真云端，而不是攻击者架的假服务器？中间人攻击利用的就是这个盲区：截获设备的连接，假装云端收数据，再转发给真云端，全程神不知鬼不觉。
所以严谨的接入要求双向：云端验设备的身份，设备也验云端的身份。
挑战-响应是怎么回事
以最典型的设备向云端自证为例：
云端生成一个随机数（挑战），发给设备；
设备用自己的私钥对随机数签名（或用共享密钥算 MAC），把结果（响应）发回；
云端用设备公钥验签，通过则确认设备身份。
核心在随机数：每次挑战都不同，响应也不同。攻击者即便录下整个握手过程，下一次也重放不出来。这就是为什么"随机数质量"会成为安全指标——如果设备的随机数发生器可预测，整个机制的根基就塌了。正经的安全芯片都会内置 TRNG 真随机数发生器，用物理噪声而非软件伪随机，JC100 这颗低成本认证芯片里 TRNG 就是标配，官方资料里明确它用于密钥生成、协议随机数注入和防重放这类场景。
双向鉴权的完整拼图
把方向反过来走一遍，就构成双向鉴权：
设备向云端证明"我是我"：设备私钥签名，云端验签；
云端向设备证明"我是我"：云端证书链 + 签名，设备验签；
双方身份确认后，协商会话密钥，建立加密通道（TLS/DTLS 干的就是这件事的工业化版本）。
在资源受限的终端上，这些运算（ECC/SM2 签名验签、密钥协商）交给安全芯片跑，主控 MCU 的负担和攻击面都小得多。
工程上的两个提醒
时钟和计数器别落下。 纯随机挑战防重放已经够用，但加上单调计数器或时间窗口，可以进一步压缩重放和乱序攻击的空间。
证书生命周期要规划。 双向鉴权依赖证书，证书会过期、设备会报废，签发、更新、吊销的流程要在量产前想清楚，而不是等设备铺出去再补。
双向鉴权不复杂，复杂的是让每一台设备都持有不可挪用的私钥——这正是硬件安全芯片存在的意义。珈港科技这类安全芯片厂商的价值，就在于把"可信身份"做成一颗几块钱、I²C 一挂就能用的标准件。