初识 AppKey 与 NwkKey：为什么 LoRaWAN 需要两把钥匙？

各位好，我是老周。今天咱们聊聊 LoRaWAN 里最基础、也最容易搞混的两个概念——AppKey 和 NwkKey。

说实话，我刚接触 LoRaWAN 那会儿，也被这两把钥匙绕晕过。明明都是 128 位的 AES 密钥，长得一模一样，为什么非要分两个？后来在几个实际项目里踩了坑，才真正明白其中的门道。

从一把钥匙说起

LoRaWAN 早期版本（1.0.x）其实只有一把钥匙，叫 AppKey。那时候的架构很简单：

• 终端设备入网时，用 AppKey 推导出会话密钥
• 网络层和应用层共用一套加密机制
• 所有数据都靠这把钥匙保护

听起来挺省事，对吧？但实际用起来问题就来了。

举个例子。我在做一个智慧农业项目时，终端设备上报土壤湿度数据。网络服务器需要知道设备 ID 和帧计数器，才能正确路由数据包。但应用数据（湿度值）应该只有应用服务器能看。用同一把钥匙？那网络服务器就能解密所有应用数据了。这显然不合理。

为什么需要两把钥匙？

LoRaWAN 1.1 版本引入了 NwkKey，把网络层和应用层的密钥彻底分开。说白了，就是各管各的：

密钥	负责范围	谁持有
NwkKey	网络层安全：入网认证、MAC 命令加密、帧完整性校验	终端 + 网络服务器
AppKey	应用层安全：应用数据加密、应用数据完整性	终端 + 应用服务器

你想想看，这样一拆分，网络服务器只管网络层的事，应用服务器只管应用层的事。谁都不能越界。这在多租户场景下尤其重要——网络运营商和应用开发者可能是不同的公司。

两把钥匙的派生关系

这里有个关键点：NwkKey 和 AppKey 都是根密钥，存储在终端设备中。它们不会在网络中传输。入网时，终端和服务器会基于这两把根密钥，派生出会话密钥：

• FNwkSIntKey / SNwkSIntKey / NwkSEncKey：由 NwkKey 派生，用于网络层
• AppSKey：由 AppKey 派生，用于应用层

嗯，这里要注意：1.0.x 版本的 AppSKey 是从 AppKey 直接派生的。1.1 版本虽然保留了 AppKey，但派生方式变了。如果你在维护老设备，一定要确认它用的是哪个版本。

两把钥匙的实战意义

可能你会问：我做个简单的传感器，就自己用，有必要搞这么复杂吗？

我的回答是：有必要。原因有三：

1. 安全隔离：即使网络服务器被攻破，应用数据仍然是安全的
2. 职责分离：网络运维和应用开发可以是不同团队，互不干扰
3. 合规要求：很多行业标准（如金融、医疗）要求应用数据端到端加密

说白了，两把钥匙不是 LoRaWAN 团队闲得没事干搞出来的。它是从实际部署中总结出的最佳实践。

核心知识体系

下面这张图，是我自己梳理的 LoRaWAN 密钥体系。建议你保存下来，后面几章会反复用到：

版本兼容性提醒

最后说个实际中经常遇到的问题：版本兼容。

LoRaWAN 1.0.x 的设备只有 AppKey，没有 NwkKey。1.1 的设备两者都有。如果你在同一个网络中混用两种版本的设备，网络服务器需要同时支持两套密钥派生逻辑。