3. API认证基础机制

设备API的认证机制选择，本质上是在“设备算力、网络环境、密钥生命周期、威胁模型”四个约束下做权衡。同一套平台里，智能电表可能只能用HMAC，而边缘网关可以跑TLS双向认证加数字签名。理解每种机制的数学基础和工程代价，才能为不同设备分配合适的认证方案。

对称密钥：共享秘密的快速通道

对称密钥认证中，设备与平台持有同一把密钥K。设备发送请求时，用K对消息计算一个认证码，平台用同样的K重新计算并比对。典型形式是HMAC，也可以是对称加密后的校验值。它的优势是计算量小、延迟低，适合MCU级设备；缺点是密钥分发和存储风险集中——任何一端泄露，整个共享关系即被攻破。

在设备API中，对称密钥常用于：设备首次激活时的引导认证、低功耗传感器周期上报、以及作为TLS会话内的应用层二次校验。一个合理的教学示例参数是：设备使用HMAC-SHA256，密钥长度256位，每条消息附带时间戳和随机数，平台允许±300秒时钟偏差。若设备时钟不可靠，则改用平台下发的单调递增序列号防重放。

非对称密钥与数字签名：不可否认的信任锚

非对称密钥由私钥和公钥组成。设备持有私钥，平台持有公钥。设备用私钥对消息摘要签名，平台用公钥验签。常见算法包括ECDSA P-256、Ed25519和RSA-2048/3072。数字签名不仅证明“消息来自持有私钥的一方”，还提供不可否认性——设备无法抵赖自己发过的指令。

在设备API中，非对称签名适合：固件更新包的签名验证、设备身份证书的签发请求、高价值控制指令（如远程开锁、参数下发）的授权。代价是签名和验签的计算开销明显高于HMAC，且私钥必须存放在安全元件或TEE中，否则被提取后身份即被冒充。

HMAC：对称密钥的标准化认证码

HMAC不是独立于对称密钥的另一种体系，而是对称密钥认证码的标准构造。它用哈希函数和密钥生成固定长度的MAC值，公式为HMAC(K, M) = H((K ⊕ opad) || H((K ⊕ ipad) || M))。设备API中常见的用法是：请求头携带X-Device-Id、X-Timestamp、X-Nonce和X-Signature，其中X-Signature就是HMAC值。

canonical = method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + body_sha256
signature = HMAC-SHA256(device_secret, canonical)

平台收到后，用设备对应的secret重算HMAC，并检查时间戳窗口和nonce是否已使用。若一致且未过期，则认证通过。这个方案在设备端只需一次哈希运算，非常适合资源受限场景。

TLS双向认证：通道级身份绑定

TLS双向认证（mTLS）在握手阶段同时验证服务器和客户端证书。设备内置客户端证书和私钥，平台配置CA证书链。握手成功后，双方建立加密通道，后续API请求天然携带通道身份。mTLS的优势是把认证下沉到传输层，应用层无需重复签名；缺点是证书管理复杂，设备需要支持TLS栈和证书轮换。

在设备API中，mTLS适合：网关类设备、摄像头、车载终端等具备一定算力和安全存储的节点。对于NB-IoT或LoRa设备，完整TLS握手可能过于沉重，此时可用DTLS或预共享密钥（PSK）模式替代。

如何为设备选择认证机制

选择时先回答三个问题：设备是否有安全存储私钥的能力？API调用是否需要不可否认性？网络是否支持完整TLS握手？若设备只有对称密钥能力，HMAC是唯一可行选择，但必须配合时间戳和nonce防重放，并定期轮换密钥。若设备具备安全元件，优先使用mTLS建立通道信任，再在应用层对关键指令附加数字签名，形成“通道+消息”双重认证。

实际部署中常见组合是：设备用mTLS连接平台，平台在TLS通道内再校验HMAC或签名。这样即使TLS终止在负载均衡器，应用层仍能独立验证设备身份。对于固件更新，则必须使用数字签名，因为更新包可能经过CDN或离线分发，通道信任无法覆盖。

总结来看，对称密钥和HMAC解决“算力受限下的快速认证”，非对称签名解决“不可否认和离线验证”，TLS双向认证解决“通道级身份绑定”。三者不是互斥关系，而是可以在同一设备API体系中分层组合。理解每种机制的数学假设和工程边界，才能为不同设备分配合适的认证策略，而不是一刀切地全部上mTLS或全部用HMAC。