LoRaWAN 1.0.4与1.1的协议差异：Join流程、密钥派生与帧计数处理的版本兼容策略

LoRaWAN 1.0.4 与 1.1 的差异，远不止版本号的小幅递增。1.1 是一次安全架构层面的重构：它把“信任”从网络服务器(NS)手中部分收回，交给了独立的 Join Server(JS)，并重新设计了 Join 流程的每一步。对于需要兼容两种版本的开发者而言，理解这些差异不是为了做学术对比，而是为了在设备端代码中正确实现“同一套逻辑，两种行为”。

Join 流程：从“随机数”到“计数器”的范式转变

1.0.4 的 Join 流程建立在随机数的新鲜性之上。设备生成一个 2 字节的 DevNonce，NS 检查这个值是否曾经出现过。如果出现过，Join Request 被拒绝。问题在于，设备重启后如果丢失了历史 DevNonce 的记录，可能重复使用旧值，导致入网失败。1.0.4 的补救方案是要求设备将 DevNonce 存储在非易失性存储器中，并且从 1.0.4 开始，Join Server 只接受**大于**前一个值的 DevNonce——这意味着 DevNonce 实际上已经从一个随机数变成了一个单调递增的计数器。

1.1 把这一趋势贯彻到底：DevNonce 和 JoinNonce(原 AppNonce)都变成了严格的计数器。设备不再需要记录所有历史值，只需记住“下一个该用多少”。这解决了小传感器节点上存储空间受限的现实问题。更关键的是，1.1 引入了**双向确认机制**。设备收到 Join Accept 后，不能直接认为入网成功，必须发送一条携带 RekeyInd MAC 命令的上行消息;网络服务器回复 RekeyConf 后，新的会话上下文才正式生效。如果设备没收到 RekeyConf，它必须重新发起 Join 流程。这一机制在 1.0.4 中完全不存在——1.0.4 的设备收到 Join Accept 即认为入网完成，网络服务器和设备的会话状态切换是单向的、无确认的。

密钥派生：从“两把钥匙”到“分权制衡”

1.0.4 的密钥体系简洁但存在结构性隐患：一把 AppKey 派生 NwkSKey 和 AppSKey。NS 在派生过程中接触到了 AppKey，理论上可以推导出 AppSKey，这意味着网络运营商在技术上具备解密应用层数据的能力。对于跨运营商漫游或对数据隐私敏感的场景，这是一个不可接受的信任集中。

1.1 的解法是引入**两把根密钥**：NwkKey 和 AppKey。NwkKey 只用于派生网络层会话密钥(FNwkSIntKey、SNwkSIntKey、NwkSEncKey)，AppKey 只用于派生 AppSKey。JS 掌握两把根密钥，但只把网络层密钥交给 NS，把 AppSKey 交给 AS。NS 再也无法接触 AppSKey 的派生材料，应用层数据的机密性从密码学层面与网络运营商解耦。

此外，1.1 新增了 JSIntKey 和 JSEncKey，专门用于保护 Join 流程中的信令消息——Join Accept 的 MIC 计算和加密不再依赖 AppKey，而是使用这两把 Join 专用密钥。1.0.4 的 Join Accept 加密和 MIC 都基于 AppKey，一旦 AppKey 泄露，整个入网流程的信任基础崩塌。

帧计数处理：32 位强制与上下行分离

1.0.4 对帧计数器的位宽没有强制要求。设备可以只维护 16 位计数器，依靠 16 位回绕(roll-over)来延续。网络服务器通过推断回绕次数来重建完整的 32 位计数器，但推断的精度受限于“连续帧之间最大间隔不超过 65K”的假设。如果设备离线时间过长，回绕次数超过一次，NS 可能无法正确推断，导致帧被丢弃或重放攻击窗口扩大。

1.1 强制要求**所有帧计数器为 32 位**，且不再允许计数器达到最大值后回绕——设备必须在计数器耗尽前重新入网。更重要的是，1.1 将下行帧计数器拆分为 **NFcntDown 和 AFCntDown** 两个独立的计数器：前者由网络服务器管理，用于 MAC 命令的下行帧;后者由应用服务器管理，用于应用数据的下行帧。1.0.4 只有一个 NFCntDown，NS 和 AS 共享同一个计数器，在多服务器架构下容易产生同步问题。

版本兼容的工程策略

设备端实现 1.0.4 与 1.1 的兼容，核心在于**判断网络服务器支持的版本**并相应地切换行为。LoRaWAN 规范允许 1.1 设备降级到 1.0.x 模式运行：当设备发现 NS 不支持 1.1 时，可以使用 AppKey 作为根密钥，按照 1.0.4 的流程完成入网，跳过 RekeyInd/RekeyConf 确认步骤。

代码实现上，建议将密钥派生和 Join 状态机抽象为独立的模块，通过一个 `lorawan_version` 配置项在编译期或运行期切换。Join 流程的状态机需要增加一个“等待 RekeyConf”的中间状态，仅在 1.1 模式下激活。帧计数器模块需要同时支持 16 位回绕推断和 32 位强制递增两种模式，下行计数器则根据版本决定是否拆分为两个。对于需要同时服务新旧设备的网络侧，NS 应避免使用 FOpts 字段携带 MAC 命令——1.1 设备会加密 FOpts，而 1.0.x 的 NS 无法解密，这是两种版本共存时最容易被忽视的互操作陷阱。

结语

1.0.4 到 1.1 的演进，本质上是 LoRaWAN 安全模型从“网络服务器中心化”向“网络与应用分权”的迁移。Join 流程的双向确认、根密钥的拆分、帧计数器的强制 32 位化，每一项变化都对应着一个具体的攻击面或工程痛点。对于开发者，兼容策略的关键不在于“同时支持两个版本的所有特性”，而在于识别出哪些行为是版本敏感的(Join 确认、密钥派生、帧计数)，并在这些关键路径上做好分支处理。其余的逻辑——射频收发、MAC 帧格式、区域参数——在两个版本之间保持了足够的连续性，可以作为共享的基底。