2. LoRaWAN 协议基础回顾：MAC层帧结构、Join流程与数据加密机制
好，咱们进入第二章。说实话，很多做LoRaWAN开发的朋友，一开始都急着调通数据收发，把协议细节丢到一边。我当年也犯过这个错——结果设备死活入不了网，抓包一看，帧结构全对不上。所以这一章，咱们把MAC层帧结构、两种入网方式（OTAA和ABP），以及那三把关键的密钥（NwkSKey、AppSKey、AppKey）彻底捋清楚。
2.1 MAC层帧结构：数据在空中的样子
LoRaWAN的MAC层帧结构，说白了就是数据在空中传输时的“信封”。你想想看，终端设备发出去的一串字节，接收端怎么知道哪部分是地址、哪部分是数据、哪部分是校验？全靠这个帧结构来约定。
一个完整的LoRaWAN上行帧（终端→网关）长这样：
| Preamble | PHDR | PHDR_CRC | PHYPayload | CRC |
但咱们做安全测试，最关心的是中间的 PHYPayload。它才是真正的“信”，前面的Preamble和PHDR只是物理层的“信封皮”。
PHYPayload的结构如下：
| MHDR (1 byte) | MACPayload (可变) | MIC (4 bytes) |
- MHDR：消息类型和协议版本。比如0x40表示未确认的上行数据帧，0x80表示入网请求。
- MACPayload：帧头（FHDR）+ 端口（FPort）+ 数据（FRMPayload）。
- MIC：消息完整性校验码，4字节。这是安全的第一道防线——我经常跟团队说，MIC就是数据的“指纹”，伪造不了。
再往下拆，MACPayload里的FHDR包含：
- DevAddr（4字节）：终端设备短地址。注意，这个地址不是全球唯一的，入网时动态分配。
- FCtrl（1字节）：控制标志位，比如确认位、ADR位。
- FCnt（2字节）：帧计数器。这个很重要！重放攻击就是靠篡改FCnt来实现的。
- FOpts（0~15字节）：可选的控制命令，比如链路检查。
重点：FCnt是递增的，不能回退。我在一次渗透测试中，发现某厂商的终端固件在掉电重启后FCnt归零，结果网关直接丢弃了后续所有数据包——这就是FCnt管理不当的典型问题。
2.2 Join流程：OTAA vs ABP
终端设备要接入LoRaWAN网络，有两种方式：OTAA（空中激活）和ABP（个性化激活）。我个人更推荐OTAA，原因后面说。
2.2.1 OTAA：安全但稍慢
OTAA的流程就像你去公司报到——先提交身份证明，HR审核通过后给你发工牌。具体步骤：
- Join Request：终端发送入网请求，包含AppEUI、DevEUI和DevNonce（一个随机数）。
- Join Accept：网络服务器验证通过后，返回Join Accept消息，包含DevAddr、NwkSKey、AppSKey等参数（这些参数用AppKey加密传输）。
- 会话建立：终端解密后，得到会话密钥，开始正常通信。
避坑指南：DevNonce必须唯一。我曾经见过一个项目，终端每次上电都生成相同的DevNonce，结果网络服务器认为这是重放攻击，直接拒绝入网。解决方案很简单——用硬件随机数发生器，或者把上次的Nonce值存进非易失存储器。
2.2.2 ABP：快速但风险高
ABP就简单粗暴了——终端出厂时就把DevAddr、NwkSKey、AppSKey写死在固件里。入网时直接发数据帧，不需要握手。
好处是快，上电即用。坏处呢？
- 密钥泄露风险：固件被提取，密钥就全暴露了。
- FCnt管理困难：终端和服务器必须同步FCnt，一旦不同步，数据就被丢弃。
- 无法更换网络：DevAddr是写死的，换网络就得换固件。
警告：如果你在做安全测试，ABP设备是重点关照对象。我曾在某智能水表项目中，用JTAG读出了固件中的AppSKey，然后直接解密了所有历史数据——整个过程不到10分钟。
两种方式的对比，我整理了一张表：
| 特性 | OTAA | ABP |
|---|---|---|
| 入网速度 | 慢（需2次握手） | 快（即发即用） |
| 密钥管理 | 动态生成，每次会话不同 | 静态写死，长期不变 |
| 安全性 | 高（防重放、防伪造） | 低（密钥易泄露） |
| 适用场景 | 大多数生产环境 | 实验室、快速原型 |
2.3 数据加密机制：三把钥匙
LoRaWAN的安全核心是三把密钥：AppKey、NwkSKey、AppSKey。很多初学者搞混它们的作用，我当年也花了点时间才理清楚。
- AppKey：只用于OTAA入网过程。它加密Join Accept消息，派生NwkSKey和AppSKey。终端和网络服务器各持一份，不参与数据加密。
- NwkSKey：网络会话密钥。用于计算MIC（完整性校验）和加密MAC命令（如FCtrl中的FOpts）。说白了，它保证“这条消息是网络认可的”。
- AppSKey：应用会话密钥。用于加密FRMPayload（应用数据）。它保证“只有真正的应用服务器能读懂数据”。
关键点：NwkSKey和AppSKey是分离的。网络层只负责传输，不关心数据内容；应用层只关心数据，不参与网络管理。这种“职责分离”的设计，是LoRaWAN安全架构的精髓。
加密算法用的是AES-128，模式是ECB（电子密码本模式）。嗯，这里要注意：ECB模式在密码学上被认为不够安全，但在LoRaWAN这种短数据包场景下，配合FCnt和MIC，实际攻击面有限。不过，如果你在做安全测试，可以试试“已知明文攻击”——如果FRMPayload是固定格式（比如温度值），攻击者可以尝试构建密文对照表。
最后，我用一张SVG图来总结本章的知识体系：