LoRaWAN入网方式以及加密进阶版

weilaizs

已于 2023-06-25 15:26:37 修改

阅读量3.2k

点赞数 4

文章标签：服务器网络安全

于 2022-08-20 15:08:21 首次发布

本文链接：https://blog.csdn.net/emmmmhhg/article/details/126439800

版权

LoRaWAN入网方式以及加密进阶版

文章目录

LoRaWAN入网方式以及加密进阶版

首先了解一下关于LoRaWAN入网的一些参数解释：(OTAA模式)

AppKey：由应用程序拥有者分配给终端，用于Join_Accept的解密以及加密参数AppSKey，NwkSKey生成，终端，服务器两端都必须具备。

DevNonce：每次请求时，该值设定为随机值。服务端会持续记录近段时间的DevNoce，如果同一个AppEUI的DeviNoce之前有重复，服务端会自动过滤Join-request命令(防止多播监听)。
AppEUI：作为应用标识，对设备来说并不是唯一的。同一设备入网不同的后台使用不同的应用服务器，就可以使用AppEUI来区分。
DevEUI：一个类似IEEE EUI64的全球唯一ID，标识唯一的终端设备。相当于是设备的MAC地址。

AppNonce：由服务端提供的随机值，该值唯一的作用就是计算NwkSKey和AppSKey。
DevAddr：32bit组成，用于标识当前网络中的终端设备。是在入网过程中由网络服务器(NS)分配。
NetID：网络ID，同时也用于计算NwkSKey和AppSKey。

AppSKey：应用会话密钥，用于加密FRMPayload。
NwkSKey：网络会话密钥，用于加密FRMPayload以及MIC生成和校验。

OTAA入网过程：

在这里插入图片描述

大致过程：

1.入网前，双方需提前约定好AppEUI，DevEUI和APPKey。
2.终端设备通过命令发起Join-Request向服务器进行入网请求。
3.服务器收到入网请求后，返回Join_Accept，终端设备收到后解析出秘钥。
4.终端节点和服务器通过加密秘钥完成数据收发。

具体过程：

一.终端节点发起Join_Request，其中包括：
在这里插入图片描述
MHDR：帧头，表示数据的类型(入网请求)。
AppEUI & DevEUI：入网请求命令中会携带这两个数据，服务器收到命令后，会通过该数据决定是否允许设备入网(因为在之前和服务器双方约定好了)。
DevNoce：每次请求时，该值设定为随机值，通过LoRa射频模块的RSSI(信号强度)或者时间戳加伪随机数列算出。服务端会持续记录近段时间的DevNoce，如果同一个AppEUI的DeviNoce之前有重复，服务端会自动过滤Join-request命令。
MIC：校验码，唯一需要注意的是，其值在入网请求时是通过AppKey作为密钥计算的(这点与数据传输时很不同，后面会说到)，MIC取AES运算后的前4字节，但是请求报文并未加密。具体算法如下：
CMAC = Aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce)
MIC = CMAC[0…3]

其中Join_Accept报文格式如下：
在这里插入图片描述
MHDR：为帧头，表示数据的类型(接受入网报文)。
AppNonce： 3字节的随机值，由服务器生成，解密得到AppSKey/NwkSKey 用到；
NetID：低7位用于区分相邻的LoRaWAN网络，叫NwkID，与DevAddr的高7位相同，也用于NwkSKey和AppSKey的生成；
DevAddr：设备短地址，类似于IP地址，由AS分配。
DLSettings：RFU为保留字段，RX1DRoffset用来指定下行第一个接收窗口RX1与上行TX的速率差，RX2 Data rate用来指定下行第二个接收窗口的速率。
在这里插入图片描述
RxDelay：用来指定第一个接收窗口与上行间的时延(上行之后到打开第一个接收窗口的时间)。
CFList：可选字段，用来指定通信信道，CN470频段CFList使用信道Mask的方式表示使能信道，每一位代表一个信道，为1则使能该信道，为0则禁止使用该信道。
MIC：校验码，用于NS检验数据包合法性，生成方式如下：
CMAC = Aes128_cmac(AppKey, MHDR | AppNonce | NetID | DevAddr | RFU | RXDelay | CFList)
MIC = CMAC[0…3]

对于这2个密钥的安全性：
首先，AppKey是Server和End Nodes的根密钥（至关重要），双方共同拥有，并且从不参与通信交换，因此攻击者无法通过窃听无线电而破解。
Server回复AppNonce和NetID给End Nodes时，使用了基于AppKey的128AES加密(具体加密方式参考上文ECB加密)，攻击者可以窃听无线电，但很难破解该密文。(End Nodes必须使用AppKey解密)

三.AS将NwkSKey直接发送给NS，之所以明文告诉NS，是因为：NS不做解密的工作，所以不能通过APPKEY解密负载得到，NwkSKey在NS对上下行数据进行校验(MIC)的时候会使用到。

同时将Join_Accept入网同意报文发送至终端节点后，终端节点会使用AppKey进行解密，得到报文中的AppNonce，NetID，DevAddr等参数。

四.终端节点服务器双方得到加密秘钥之后，就可以对数据进行加密和解密。
数据报文解析：
在这里插入图片描述
整体和TCP/IP协议里的数据包是类似的封装格式，发送时从应用层封装到物理层，上面一层的整个部分作为下面一层的Payload，每一层基本都有自己的头部，校验和，最后由物理层封装了发送出去，接收端是一个反过来的过程，会将数据帧一层层剥开，最后由应用层解析数据，具体的每个字段的详细解析这里不再细聊，主要解析一下关于数据的加密：

数据加密使用AES128加密，加密秘钥Key取决于消息字段里的FPort，具体规则如下：
在这里插入图片描述
其中，FPort为0表示FRMPayload中只有MAC命令，1-223表示应用数据，224用作LoRaWAN回环测试，225-255保留使用。

加密字段Pld = FRMPayload，采用分组加密，算法位每条消息数据定义一个块的序列，序列分为K块，K = ceil(len(pld)/16)(向上取整)，每组用Ai表示，i = 1…K，每块结构如下：
在这里插入图片描述
Dir字段：上行帧为0，下行帧为1

对Ai加密得到Si：
Si = Aes128_encrypt(Key，Ai) for i = 1…K
S = S1 | S2 |…| Sk

通过分割对payload进行加解密：
（pld | pad16）xor S

MAC层数据加密完成后，然后生成MIC校验码：(注意与入网请求和同意的MIC计算有所不同)
msg = MHDR | FHDR | FPort | FRMPayload
CMAC = Aes128_cmac(NwkSKey, B0 | msg) //无论Fport为多少，数据收发MIC都由NwkSKey计算
MIC = CMAC[0…3]

再由物理层封装成包之后将数据发送至服务器端，服务器的NS通过NwkSKey解析MIC校验码，检测数据包的完整性，无误后，然后将数据包上行至AS服务器，AS使用AppSKey解密，得到数据具体内容。(注意如果数据包仅仅为MAC命令，即FPort为0，则数据包由NS处理，这也是为什么NS具有管理终端节点的功能之一)，下行的数据的加密解密同理。
整体数据加解密过程大致如下图：
在这里插入图片描述

关于ABP模式：

以上所说关于Join_Request和Join_Accept都不再需要，而是通过终端节点和服务器双方事先固定所有的加密解密参数，不需要动态获取，当服务器第一次收到终端的数据就表示入网成功，具体细节不再赘述，数据收发的加密解密同OTAA。

两者区别：

OTAA就是在终端节点第一次发起Join Request入网请求，其中包括AppEUI，DevEUI，DevNonce(随机值)；服务器在收到入网请求确认之后发送Join Accept 其中包含AppNonce(随机值)，NetID，DevAddr，DLSettings，RxDelay，CFList；Join Accept为加密信息，需要节点使用AppKey解密，得到AppNonce，DevNonce，三者解密得到AppSKey和NwkSKey，之后节点和服务器通过AppSKey，NwkSKey，DevAddr对数据收发进行加密和机密。

ABP这种方法比较简单粗暴，直接配置 DevAddr，NwkSKey，AppSKey 这三个通讯的参数，不再需要join流程。在这种情况下，这个设备是可以直接发应用数据的，当ABP终端成功发送了第一条数据之后，我们就认为ABP终端入网成功了。