2. 设备身份注册：注册流程设计、注册信息模型、注册API设计、注册状态机
设备注册，说白了就是给设备发一张「数字身份证」。这张证怎么申请、长什么样、谁来发、状态怎么变——就是这一章要聊的事。
我见过不少团队，一上来就写代码调接口，结果设备上线后才发现：咦，这个设备之前注册过吗？密钥丢了怎么补？状态乱了怎么办？嗯，这些坑，其实在注册阶段就能规避掉。
2.1 注册流程设计：从产线到云端的最后一公里
设备注册不是简单的「调一次API就完事」。它涉及产线、物流、用户激活等多个环节。我个人习惯把注册流程拆成三个阶段：
| 阶段 | 场景 | 核心动作 |
|---|---|---|
| 预注册 | 产线烧录 | 写入设备ID、初始密钥、证书 |
| 激活注册 | 用户首次上电 | 设备与云端完成身份绑定 |
| 重注册 | 密钥轮换/设备重置 | 更新身份凭证，保留设备ID |
这里有个关键点：预注册和激活注册要解耦。我在一个智能门锁项目里吃过亏——当时把产线烧录和用户激活绑在一起，结果物流环节设备被拆包，密钥泄露了都不知道。后来改成预注册只写初始身份，激活时再协商会话密钥，安全等级直接拉高一个档次。
核心原则：预注册只建立「你是谁」，激活注册才确认「你在哪、归谁管」。
2.2 注册信息模型：设备身份证长什么样
设备身份信息模型，我建议用三层结构：
- 设备标识层：设备ID（全局唯一）、型号、批次号、MAC/IMEI等硬件指纹
- 安全凭证层：初始密钥、证书链、密钥版本号、密钥生效时间
- 元数据层：注册时间、注册方式（产线/OTA/手动）、归属租户、标签
举个例子，一个典型的设备注册信息JSON长这样：
{
"deviceId": "sn-2024-a3b5c7",
"model": "GW-200",
"batch": "B20240301",
"credentials": {
"type": "PSK",
"keyId": "k-001",
"keyValue": "a1b2c3d4e5f6...",
"keyVersion": 1,
"notBefore": "2024-03-01T00:00:00Z",
"notAfter": "2025-03-01T00:00:00Z"
},
"metadata": {
"registeredAt": "2024-03-01T10:30:00Z",
"method": "factory",
"tenantId": "t-10086",
"tags": ["production", "v2"]
}
}我的经验：密钥版本号一定要带上。有一次设备批量升级，旧密钥要退役，结果发现版本号字段没设计，只能全量重注册——那叫一个酸爽。
2.3 注册API设计：接口要稳，别让设备「裸奔」
API设计这块，我踩过不少坑。先看一个我推荐的注册接口定义：
POST /v1/devices/register
请求体：
{
"deviceId": "sn-2024-a3b5c7",
"model": "GW-200",
"signature": "hmac_sha256(deviceId + timestamp, preSharedKey)",
"timestamp": 1709253000,
"publicKey": "base64_encoded_pubkey" // 可选，用于非对称方案
}
响应：
{
"code": 0,
"message": "success",
"data": {
"deviceId": "sn-2024-a3b5c7",
"accessToken": "eyJhbGciOiJIUzI1NiIs...",
"tokenExpire": 1709339400,
"serverPublicKey": "base64_encoded_server_pubkey"
}
}这里有几个设计要点：
- 签名防篡改：请求必须带签名，防止中间人伪造注册请求。我见过直接用明文传密钥的，那跟把钥匙挂门上没区别。
- 时间戳防重放：服务端校验时间戳偏差，一般允许±5分钟。太宽容易重放攻击，太窄设备时钟不准又注册不上。
- 幂等性：同一个deviceId重复注册，返回已有身份，不覆盖。我曾经没做幂等，产线并发注册时把一批设备的密钥全覆盖了……
注意：注册接口必须走HTTPS，且证书校验不能跳过。别问我为什么强调这个——你猜我见过多少设备因为「测试方便」把证书校验关掉的？
2.4 注册状态机：设备身份的「一生」
设备注册不是一锤子买卖。它的状态会随着生命周期变化。我画了一张状态机图，你看一眼就明白了：
这张图里，我特别想强调两个容易被忽略的状态：
- 预注册超时：设备在产线预注册后，如果半年没激活，应该自动吊销。我见过一批设备在仓库放了两年，预注册密钥早就该退役了。
- 待重注册：这个状态是「缓冲带」。密钥轮换或设备重置时，设备先进入这个状态，保留设备ID和历史记录，等新凭证到位后再回到预注册或已激活。
避坑指南：状态机一定要有「超时兜底」。我曾经设计过一个状态机，设备吊销后只能人工介入恢复，结果半夜告警响了，运维同学被叫起来手动重置——后来加了自动重注册流程，世界清净了。
2.5 注册流程中的安全红线
最后，我列几条注册阶段必须守住的底线：
| 安全要求 | 说明 | 常见错误 |
|---|---|---|
| 初始密钥唯一性 | 每台设备出厂密钥必须不同 | 产线用同一个密钥烧录所有设备 |
| 注册请求签名 | 防止伪造注册请求 | 明文传输设备密钥 |
| 注册频率限制 | 同一设备ID注册间隔不低于N秒 | 没做限流，被刷爆注册接口 |
| 注册记录审计 | 所有注册操作写入不可篡改日志 | 出安全事件后找不到注册记录 |