3. 设备身份凭证类型与选型
设备要接入云端，第一步不是“连上网络”，而是让云端确认“你是谁”。这一步依赖身份凭证。凭证类型选错，后面要么密钥泄露风险高，要么设备算力扛不住，要么运维成本失控。本节把五类常见凭证放在同一张选型地图上，说明它们各自解决什么问题、代价是什么、什么场景该用哪一种。
一、五类凭证的本质差异
对称密钥：设备和云端共享同一把密钥（如 AES-128/256）。认证时常用挑战—响应：云端下发随机数 nonce，设备用共享密钥计算 HMAC-SHA256，云端用同一密钥验算。优点是计算量小、握手快，适合 MCU 级设备；缺点是密钥一旦泄露，攻击者可冒充任意持有该密钥的设备，且密钥分发和轮换必须安全。
非对称密钥：设备持有私钥，云端持有公钥。设备用私钥对挑战签名（如 ECDSA P-256），云端用公钥验签。私钥不出设备，云端无需保存能冒充设备的秘密，安全性明显优于对称密钥。代价是签名运算和密钥存储要求更高，且公钥本身需要可信绑定到设备身份，否则会遭遇中间人替换公钥。
X.509 证书：本质是“公钥 + 身份信息 + CA 签名”的容器。设备证书把设备 ID、公钥、有效期、颁发者绑定在一起，云端通过验证证书链（设备证书 → 中间 CA → 根 CA）确认设备身份。它解决了非对称密钥“公钥怎么可信”的问题，是 TLS 双向认证的标准做法。代价是需要 PKI 体系：CA、注册、吊销（CRL/OCSP）、有效期管理。
令牌凭证：如 OAuth 2.0 的 access token、JWT 或云平台颁发的临时安全令牌。它通常不是设备根身份，而是“设备用根凭证换取的一次性/短期通行证”。优点是权限可细粒度、可短期失效、便于云端审计；缺点是令牌本身可能被窃取重放，必须配合短有效期、绑定设备指纹或 mTLS 使用。
HSM 与 TPM：这两者不是凭证类型，而是凭证的硬件载体。TPM 是设备主板上的可信芯片，可生成并保护密钥、执行度量启动，常配合非对称密钥或证书使用；HSM 是更高安全等级的专用硬件，用于云端或网关侧保护 CA 私钥、批量签发证书、执行高速签名。它们决定“私钥放在哪里、能否被导出”，而不是替代凭证本身。
二、选型对比：从算力、安全、运维三个维度看
选型时不要只问“哪个最安全”，而要同时看设备算力、网络条件、生命周期和运维能力。下表给出典型判断依据（参数为教学示例，实际以芯片和云平台规格为准）：
| 凭证类型 | 典型算力开销 | 私钥/密钥是否可导出 | 适合场景 | 主要风险 |
|---|---|---|---|---|
| 对称密钥 | 极低（HMAC 微秒级） | 可导出，需软件保护 | 超低功耗传感器、一次性设备 | 密钥泄露即全量冒充 |
| 非对称密钥 | 中（ECDSA 毫秒级） | 私钥可不出设备 | 有 MCU 的网关、摄像头 | 公钥绑定不可信 |
| X.509 证书 | 中高（含 TLS 握手） | 私钥可不出设备 | 需要标准 mTLS 的设备 | PKI 运维复杂、吊销延迟 |
| 令牌凭证 | 低（验签/查表） | 不涉及根私钥 | 临时授权、权限分级 | 重放、过期管理 |
| TPM | 低（芯片内运算） | 私钥不可导出 | 工业网关、边缘服务器 | 依赖主板支持、初始化复杂 |
| HSM | 高（专用硬件） | 密钥不可导出 | 云端 CA、批量签发 | 成本高、需集群高可用 |
三、实际选型路径与配置示例
一个可落地的判断顺序是：先看设备是否有安全硬件，再看是否必须走标准 TLS，最后看运维能否承担 PKI。下面给出一个典型决策路径，并用一段配置示例说明 X.509 设备如何完成 mTLS 接入。
- 设备是纽扣电池供电、每月只上报一次 → 优先对称密钥 + 短期令牌，降低功耗。
- 设备有 MCU 且能存私钥，但无 TPM → 用非对称密钥 + 设备证书，私钥存于受保护 Flash。
- 设备有 TPM/安全 enclave → 私钥在芯片内生成、不可导出，配合 X.509 证书做 mTLS。
- 云端需要批量签发、保护根 CA → 使用 HSM 托管 CA 私钥，设备侧仍用证书或非对称密钥。
以 MQTT over TLS 双向认证为例，设备侧需要准备三样东西：设备证书、设备私钥、CA 根证书。连接时云端会校验设备证书链，设备也会校验云端证书。下面是一段常见的客户端配置片段（以教学示例为主，具体字段随平台变化）：
# 设备侧 mTLS 连接参数（示例）
broker: "mqtts://iot.example.com:8883"
client_id: "dev-9f3a21"
ca_file: "/etc/iot/ca-root.pem" # 用于验证云端证书
cert_file: "/etc/iot/device-cert.pem" # 设备证书，含设备 ID 与公钥
key_file: "/etc/iot/device-key.pem" # 设备私钥，权限 600
keepalive: 60
clean_session: false
连接建立后，云端从设备证书的 CN 或 SAN 中提取设备 ID，再结合策略决定该设备能发布/订阅哪些主题。如果设备证书被吊销，云端应在 CRL/OCSP 检查中拒绝连接。这里的关键判断点是：证书里的身份字段必须与云端设备注册表一致，否则会出现“证书有效但设备未注册”的拒绝。
四、把凭证放进整体信任链
下图把设备侧凭证、硬件载体、云端验证与授权放在同一条信任链上。它不重复正文步骤，而是帮助你看清“谁信任谁、私钥在哪里、令牌在哪一步出现”。
回到选型本身，可以把结论压缩成三句话：算力极低、成本敏感的设备优先对称密钥加短期令牌；需要标准互操作、有基本安全存储的设备用非对称密钥加 X.509 证书；对私钥保护有硬要求的场景，必须把私钥放进 TPM 或安全芯片，云端则用 HSM 守住 CA。令牌不是根身份，而是授权层，不能替代设备身份凭证。把这几层分清，后续的注册、轮换、吊销和审计才有稳定的基础。