IoT 设备 MQTT 鉴权设计BCrypt AES TLS ACL 四层防护实战原创声明本文基于本人课程实训期间独立开发的智慧路灯 IoT 管理平台Spring Boot EMQX TDengine实战经验整理为第一手踩坑记录内容已脱敏。项目代码已开源https://github.com/smart-lighting-backend/SmartLightingExp实战复盘 · 物联网安全项目背景智慧路灯 IoT 管理平台通过 MQTT(EMQX) 与真实硬件设备小熊派通信。最初所有设备共用一套账号密码存在严重安全隐患本文记录了完整的设备独立鉴权体系设计与实施过程。一、背景与问题1.1 初始状态的安全隐患问题现状风险设备无独立身份后端 前端 模拟器共用一套账号任一泄露影响全局无 Topic 隔离任意客户端可发布到任意设备 Topic设备可伪装其他设备MQTT 明文传输无加密网络嗅探可直接获取密码无设备凭证表设备表无鉴权相关字段无法管理设备凭据1.2 设计目标每设备独立凭据用户名 deviceId密码 出厂编号 设备识别码 拼接BCrypt 哈希存储密码不可逆数据库拖库无法还原TLS 传输加密设备 → EMQX 走 SSL 加密通道Topic ACL 隔离设备只能操作自己streetlight/{deviceId}/#的 Topic不影响现有功能服务账号保持不变后端订阅/发布不受影响二、方案选型选用BCrypt 哈希 TLS 传输加密 EMQX 认证链方案评估项实际值结论EMQX 版本6.x Enterprise✅ 支持 MySQL 认证 BCrypt 认证链 ACL 变量SSL 监听器:8883✅ 无需重新生成证书WSS 监听器:8084✅ 前端改地址即可认证链6.x 原生支持多认证器串联✅ built_in → MySQL 链式认证ACL 变量支持${username}占位符✅ 设备 Topic 隔离三、数据模型设计新增device_credential表每设备一条凭证CREATETABLEdevice_credential(idBIGINTPRIMARYKEY,device_idVARCHAR(50)NOTNULLCOMMENT设备IDMQTT用户名,password_hashVARCHAR(255)NOTNULLCOMMENTBCrypt密码哈希EMQX直接读取校验,factory_serial_encryptedVARCHAR(255)NOTNULLCOMMENT出厂编号AES-256-CBC加密存储,device_id_code_encryptedVARCHAR(255)NOTNULLCOMMENT设备识别码AES-256-CBC加密存储,UNIQUEKEYuk_device_id(device_id))COMMENT设备MQTT鉴权凭证;双加密设计说明BCrypt单向哈希用于 EMQX 登录校验数据库拖库也无法还原密码AES-256-CBC可逆加密用于存储出厂编号/识别码——运维需要时能查回原始值比如重新生成密码、批量操作为什么 AES 可逆因为出厂编号 识别码既是密码组成也是设备身份信息。纯哈希后运维无法找回原始值纯明文又泄露身份。哈希 可逆加密结合兼顾安全与可运维。四、密码生成与验证流程4.1 凭证生成流程设备创建 → 生成随机识别码 → 密码 出厂编号 识别码 → password_hash BCrypt(密码) → 出厂编号/识别码 AES-256-CBC 加密存储 → 同步创建 EMQX 内置认证用户4.2 设备连接校验流程EMQX 认证链设备连接 → EMQX built_in_database 认证普通用户 → 未命中 → 继续 MySQL 认证器 → MySQL 认证器usernamedeviceId → 查 device_credential → BCrypt 校验 password_hash → 通过则放行 → ACL 校验${username} 只能访问 streetlight/{username}/# 主题五、ACL Topic 隔离EMQX ACL 规则使用${username}变量实现每设备隔离# 允许设备只能操作自己的主题 allow {username} subscribe streetlight/${username}/# allow {username} publish streetlight/${username}/telemetry deny {username} all设备 A 无法向设备 B 的主题发布消息——即使拿到 EMQX 地址也无法伪装。六、工程实现要点启动自动补发DeviceCredentialInitializer定时任务启动时自动为存量设备生成凭证避免历史设备连不上设备增删改自动同步设备 CRUD 接口联动 EMQX 用户创建/删除保持两侧一致独立 Topic 通道遥测/视觉/语音/指令各用独立主题telemetry/vision/event/voice/event/command互不干扰权限管控凭证查看/重建仅 SUPER_ADMIN 可操作device:credential权限码七、经验总结IoT 设备鉴权不能复用服务账号设备数量大、分布广、易泄露必须每设备独立身份哈希 可逆加密组合是设备凭证的正确姿势一个管登录校验一个管可运维性缺一不可EMQX 认证链按顺序尝试built_in 未命中自动落到 MySQL 认证器服务账号与设备账号互不影响ACL 用${username}做主题隔离比在应用层做权限判断更底层、更安全凭证要与设备生命周期联动增删改自动同步 EMQX 启动补发存量避免设备建了连不上的断档 IoT 设备 MQTT 鉴权设计：BCrypt + AES + TLS + ACL 四层防护实战
IoT 设备 MQTT 鉴权设计BCrypt AES TLS ACL 四层防护实战原创声明本文基于本人课程实训期间独立开发的智慧路灯 IoT 管理平台Spring Boot EMQX TDengine实战经验整理为第一手踩坑记录内容已脱敏。项目代码已开源https://github.com/smart-lighting-backend/SmartLightingExp实战复盘 · 物联网安全项目背景智慧路灯 IoT 管理平台通过 MQTT(EMQX) 与真实硬件设备小熊派通信。最初所有设备共用一套账号密码存在严重安全隐患本文记录了完整的设备独立鉴权体系设计与实施过程。一、背景与问题1.1 初始状态的安全隐患问题现状风险设备无独立身份后端 前端 模拟器共用一套账号任一泄露影响全局无 Topic 隔离任意客户端可发布到任意设备 Topic设备可伪装其他设备MQTT 明文传输无加密网络嗅探可直接获取密码无设备凭证表设备表无鉴权相关字段无法管理设备凭据1.2 设计目标每设备独立凭据用户名 deviceId密码 出厂编号 设备识别码 拼接BCrypt 哈希存储密码不可逆数据库拖库无法还原TLS 传输加密设备 → EMQX 走 SSL 加密通道Topic ACL 隔离设备只能操作自己streetlight/{deviceId}/#的 Topic不影响现有功能服务账号保持不变后端订阅/发布不受影响二、方案选型选用BCrypt 哈希 TLS 传输加密 EMQX 认证链方案评估项实际值结论EMQX 版本6.x Enterprise✅ 支持 MySQL 认证 BCrypt 认证链 ACL 变量SSL 监听器:8883✅ 无需重新生成证书WSS 监听器:8084✅ 前端改地址即可认证链6.x 原生支持多认证器串联✅ built_in → MySQL 链式认证ACL 变量支持${username}占位符✅ 设备 Topic 隔离三、数据模型设计新增device_credential表每设备一条凭证CREATETABLEdevice_credential(idBIGINTPRIMARYKEY,device_idVARCHAR(50)NOTNULLCOMMENT设备IDMQTT用户名,password_hashVARCHAR(255)NOTNULLCOMMENTBCrypt密码哈希EMQX直接读取校验,factory_serial_encryptedVARCHAR(255)NOTNULLCOMMENT出厂编号AES-256-CBC加密存储,device_id_code_encryptedVARCHAR(255)NOTNULLCOMMENT设备识别码AES-256-CBC加密存储,UNIQUEKEYuk_device_id(device_id))COMMENT设备MQTT鉴权凭证;双加密设计说明BCrypt单向哈希用于 EMQX 登录校验数据库拖库也无法还原密码AES-256-CBC可逆加密用于存储出厂编号/识别码——运维需要时能查回原始值比如重新生成密码、批量操作为什么 AES 可逆因为出厂编号 识别码既是密码组成也是设备身份信息。纯哈希后运维无法找回原始值纯明文又泄露身份。哈希 可逆加密结合兼顾安全与可运维。四、密码生成与验证流程4.1 凭证生成流程设备创建 → 生成随机识别码 → 密码 出厂编号 识别码 → password_hash BCrypt(密码) → 出厂编号/识别码 AES-256-CBC 加密存储 → 同步创建 EMQX 内置认证用户4.2 设备连接校验流程EMQX 认证链设备连接 → EMQX built_in_database 认证普通用户 → 未命中 → 继续 MySQL 认证器 → MySQL 认证器usernamedeviceId → 查 device_credential → BCrypt 校验 password_hash → 通过则放行 → ACL 校验${username} 只能访问 streetlight/{username}/# 主题五、ACL Topic 隔离EMQX ACL 规则使用${username}变量实现每设备隔离# 允许设备只能操作自己的主题 allow {username} subscribe streetlight/${username}/# allow {username} publish streetlight/${username}/telemetry deny {username} all设备 A 无法向设备 B 的主题发布消息——即使拿到 EMQX 地址也无法伪装。六、工程实现要点启动自动补发DeviceCredentialInitializer定时任务启动时自动为存量设备生成凭证避免历史设备连不上设备增删改自动同步设备 CRUD 接口联动 EMQX 用户创建/删除保持两侧一致独立 Topic 通道遥测/视觉/语音/指令各用独立主题telemetry/vision/event/voice/event/command互不干扰权限管控凭证查看/重建仅 SUPER_ADMIN 可操作device:credential权限码七、经验总结IoT 设备鉴权不能复用服务账号设备数量大、分布广、易泄露必须每设备独立身份哈希 可逆加密组合是设备凭证的正确姿势一个管登录校验一个管可运维性缺一不可EMQX 认证链按顺序尝试built_in 未命中自动落到 MySQL 认证器服务账号与设备账号互不影响ACL 用${username}做主题隔离比在应用层做权限判断更底层、更安全凭证要与设备生命周期联动增删改自动同步 EMQX 启动补发存量避免设备建了连不上的断档