Credential Lifecycle Analysis in Private LoRaWAN Networks for

Industrial IoT (IIoT)

Sergio H. Silva

, Guilherme P. Koslovski

, Mauricio A. Pillon

and Charles C. Miers

Graduate Program in Applied Computing (PPGCAP), Santa Catarina State University (UDESC), Brazil

Keywords:

Industrial Internet of Things (IIoT), LoRaWAN, Access Control, Credentials Lifecycle.

Abstract:

The adoption of smart devices in the industrial context has led to the emergence of the Industrial Internet,

also known as the Industrial Internet of Things (IIoT). Compliance with security requirements and standards

is necessary for IIoT networks, including general Internet technology standards and speciﬁc standards for

IIoT regulation, such as those deﬁned by the Industrial Internet Consortium (IIC). In this article, we focus

on the issue of non-compliance with the credential lifecycle in private LPWAN LoRaWAN networks based

on ChirpStack, a widely used open-source solution for connecting IoT devices over large geographical areas.

Non-compliance with credential lifecycle standards can pose risks to business continuity. Our goal is to

analyze the lifecycle of credentials in the context of IIoT using the LoRaWAN 1.1 protocol with ChirpStack

servers. The contributions of this work include identifying the lifecycle of identities applied and analyzing the

identity lifecycle when used with ChirpStack open-source LoRaWAN Network Server.

1 INTRODUCTION

The adoption of smart devices in the industrial context

resulted in the so-called Industrial Internet, or Indus-

trial Internet of Things (IIoT). The incorporation of

smart devices in industrial complex and critical sce-

narios has several security requirements, application

areas, and others (De Sousa et al., 2019). Access con-

trol and identity management are the main ways to

guarantee the authenticity of devices in all computa-

tional contexts. In this critical context, the need to

adhere to security requirements and policies (Kobara,

2016). IIoT network arrangements must comply to

general Internet technology standards. In addition,

it must observe the standards of speciﬁc entities for

IIoT regulation such as the Industrial Internet Con-

sortium (IIC). IIC deﬁnes IIoT architecture, data an-

alytics, connectivity, and security. Furthermore, IIC

assigned standards comply with the referential stan-

dards (NIST, ISO, and IEEE). The standards include

security recommendations related to IIoT access con-

trol and credential lifecycle (Schrecker et al., 2016).

https://orcid.org/0000-0003-4923-189X

https://orcid.org/0000-0003-4936-1619

https://orcid.org/0000-0001-7634-6823

https://orcid.org/0000-0002-1976-0478

Low Power Wide Area Network (LPWAN) net-

works are used in industrial contexts in which the re-

quirements are of wide area with energy restrains (Lu-

visotto et al., 2018). LoRaWAN is a LoRa-based

protocol very popular and widely used by organiza-

tions to connect several IoT devices deployed on a

large geographical area. This implementation is of-

ten performed with a private LoRaWAN network ar-

rangement using ChirpStack servers (Yu et al., 2022).

These private LoRaWAN networks using ChirpStack

servers may include new security vulnerabilities in an

industrial environment.

Networks not complying IIC standards related to

identity management and credential lifecycle may

pose a risk for business continuity. We focus on the

issue of non-compliance of the credentials lifecycle

in the context of private LPWAN LoRaWAN private

networks based on ChirpStack. Moreover, we analyze

the lifecycle of credentials, identifying conformities

and problems related to the various existing identi-

ties/credentials in an IIoT LoRaWAN ChirpStack sys-

tem. Our main contributions are: (i) identiﬁcation of

the lifecycle of identities applied to LoRaWAN 1.1;

and (ii) identiﬁcation and analysis of the identity life-

cycle in LoRaWAN 1.1 based on ChirpStack.

This article is organized as follows. Section 2 in-

troduces basic concepts. Section 3 presents the prob-

lem. Section 4 summarizes related works. Section 5

Silva, S., Koslovski, G., Pillon, M. and Miers, C.

Credential Lifecycle Analysis in Private LoRaWAN Networks for Industrial IoT (IIoT).

DOI: 10.5220/0012615500003705

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 9th International Conference on Internet of Things, Big Data and Security (IoTBDS 2024), pages 157-165

ISBN: 978-989-758-699-6; ISSN: 2184-4976

157

presents our proposal and criteria. Finally, the Sec-

tion 6 presents our analysis and mitigation proposal.

2 FUNDAMENTALS

Like any computing arrangement, the IIoT needs to

ensure security when it comes to access control. A

central piece in access control is authentication and

authorization. In device authentication, credentials

are widely used to recognize these entities (Kim and

Lee, 2017). According to (Schrecker et al., 2016),

the deﬁnition of credential refers to evidence that sup-

ports a claim of identity or an attribute. This deﬁ-

nition complies with the standardization described in

revision number 4009 of the Committee on National

Security Systems (CNSS) glossary. The credentials

lifecycle in a computing environment must also com-

ply with standards and best practices. The security

and identity management standard endorsed by the

IIC has registration, management, and authentication

phases – Figure 1 (Schrecker et al., 2016).

INICIAÇÃO

VERIFICAÇÃO DA

ENTIDADE

REGISTRO

AUDITORIA

Credential

generation

ARMAZENAMENTO

DE CREDENCIAIS

Credential

binding

Credential

suspension and

revocation

Credential

issuance

Credential renewal,

replacement, rotation

Audit

AUTENTICAÇÃO

AUTORIZAÇÃO

Enrollment

phase

Credential management

phase

Entity authentication

phase

INICIAÇÃO

VERIFICAÇÃO DA

ENTIDADE

REGISTRO

Initiation

Entity

verification

Registration

Audit

Authorization

Authentication

Credential

storage

Figure 1: IIoT identity management lifecycle.

Figure 1 shows the recommended lifecycle con-

sists of three phases which in turn contain several

steps. The presented cycle serves as an analysis pa-

rameter in the analysis scenario of this work. In this

article, the deﬁnition of IIoT is interpreted, based on

(Lin et al., 2017), i.e., as a system in which there is

the connection and integration of industrial infrastruc-

ture and end devices. Thus, relying on a network and

control infrastructure to enable data analysis and vi-

sualization, in addition to centralized control by high-

level business systems (Figure 2).

The Edge Layer contains the devices which needs

to be identiﬁed in addition to the edge gateways are

found. This layer usually has devices in wireless net-

works that can use different protocols or technologies

(Gulati et al., 2022). The Platform Layer includes

the network and application servers, and is respon-

sible for storing, transporting, and transforming data.

Data Flow

Control Flow

Data Flow

Control Flow

Data

Transformation

Data analysis

Operations

Edge layer Platform Layer Corporative Layer

Business rules

Sensors

and

actuactors

Edge

Gateway

Wireless networks

Guided networks

Figure 2: IIoT referential architecture.

The Corporative Layer is where business operations

are carried out. From this layer originates the control

ﬂow of the entire IIoT system. The data ﬂow origi-

nates in the edge layer, passing through the platform

layer to the enterprise layer. Our work bases the stud-

ies on this referential architecture. In which the tech-

nology used for the transmission of the devices to the

gateways is LoRaWAN, based on the LoRa protocol.

This technology and protocol were chosen based on

cost, area, and availability of open server software.

However, there are two version of LoRaWAN proto-

col being currently used: 1.0 and 1.1 (Table 1).

Table 1: LoRaWAN security comparison: 1.0 vs. 1.1.

LoRaWAN 1.0 LoRaWAN 1.1

Session Keys AppSkey and NwkSkey

FNwkSIntKey, SNwkSIntKey,

NwkSEncKey and AppSKey

MAC commands Not encrypted Encrypted

Entities

End Devices, Network Server

and Application Server.

End Devices, Join Server,

Network Server and

Application Server

Roaming between

LoRaWAN networks

Does not support roaming

between networks

Supports roaming

between networks

Entity responsible

for the network

server joining process

Network Server Join Server

Reuse of counters

Do not persist counters, it may

compromise cryptography and

communication.

Corrected by storing the last

value of the counter in

non-volatile memory.

Repeat request

message failed

An invader must wait for just N

messages before playing a

message requesting a connection.

The repetition of messages

of the type join request is

prevented by the network

does not increase.

End-to-end

No protection from end to end.

As the AppKey is shared by

both the network server and the

application servers,

it is subject to interception.

End-to-end protection for OTAA

is achieved by providing two different

keys for the network (NwkKey) and

for the application (AppKey), from

which all other keys are derived.

The LoRaWAN protocol is deﬁned by the Lora

Alliance — a consortium of companies such as IBM,

Actility, Semtech, and Microchip — as a networking

protocol LPWAN was designed to connect battery-

operated devices on a long-range wireless network.

The LoRaWAN version 1.0 of was released in 2015,

undergoing updates in the following years until its up-

date to version 1.1 in 2017. We focus on version 1.1

as it is the most recent and recommended version for

an environment with (D

onmez and Nigussie, 2018)

security requirements.

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

158

3 PROBLEM

The development of the IIoT is surrounded by sev-

eral challenges when it comes to its safe, stable,

and proﬁtable implementation for industrial organiza-

tions. These challenges are related to the implemen-

tation of a reference architecture and security poli-

cies based on norms and standards. Other use case

characteristics of IIoT applications also bring addi-

tional considerations related to implementing a reli-

able and stable IIoT network. Our scenario is a lay-

ered architecture for IIoT with the use case of pro-

cess automation and monitoring. This architectural

pattern and end-use case result in an IIoT system

with requirements for a wide distribution area of the

end devices in the organization’s physical space. In

this work, under criteria of the low cost of end de-

vices, long-range, energy saving, and ﬂexibility, the

LPWAN LoRaWAN protocol was chosen. In terms of

LoRaWAN, some organizations require deployment

as a private network, ensuring isolation from poten-

tial attackers. Furthermore, the environment used in

the work procedures will use the ChirpStack software

component to implement the protocol entities. Even

though LoRaWAN with ChirpStack satisﬁes these re-

quirements, the traditional approach to the protocol

does not provide for a deﬁned lifecycle for the cre-

dentials used to verify the authenticity of devices.

Given the proposed study scenario, there is a con-

cern about how to safely manage IIoT devices re-

quiring secure credentials. It also raises the question

of how to implement the lifecycle recommended by

IIoT standardization entities in LoRaWAN networks,

which was not originally thought for the industrial

scenario. In a scenario in which their quantity is sig-

niﬁcant, improper/malicious management of devices

can cause authentic devices not to be well used and

non-authentic devices to join the network. The conse-

quences of not implementing an organized credentials

lifecycle can compromise the system’s security as a

whole, opening the possibility of devices with com-

promised keys continuing to integrate the network and

compromising the data sent to the business layer or

even enabling attacks of interception of information.

The evaluation criteria to verify whether there are

solutions to this problem in the literature should be

based on basically four motivating questions: Q1: It

proposes to use a lifecycle to ensure device access

control security? Q2: It proposes a solution for man-

aging credentials in environments with wide area re-

quirements with remote conﬁguration? Q3: It em-

ploys LPWAN LoRaWAN protocol in communica-

tion? Q4: Aimed at industrial contexts (IIoT)?

4 RELATED WORK

The selection of related works aimed to raise research

related to the problem addressed, and, in this sense,

we also sought to analyze trends regarding the

proposed problems. This mapping also aimed to

identify gaps in the number of publications on a

given subject through the production of a structured

classiﬁcation. The keywords to identify works

in academic search engines: (Industrial Internet of

Things OR IIoT) AND LoRaWAN AND (Control Access OR Identity

Management OR lifecycle management).

The process of selecting papers was carried out

in consideration of the recommendations arising from

(Galv

ao et al., 2015). Search sources selected were

IEEE Xplore, Science Direct, and Science.gov, due to

their availability of features such as advanced ﬁlters

and better data visualizations. Identiﬁed were sub-

mitted to the inclusion criteria (IC) and exclusion cri-

teria (EC). ICs: IC01: published on the last decade

(2012 - 2023); IC02: address access control in Lo-

RaWAN networks for IoT / IIoT; IC03: focus on the

management of identity and credentials of devices in

LoRaWAN networks; and IC04: evaluate the authen-

tication of industrial devices (IIoT). ECs: EC01: pub-

lished in commercial or non-academic journals, or has

not yet been reviewed; EC02: published more than a

decade ago, that is, it is before 2012; EC03: do not

address, or only indirectly addresses, the issue of cre-

dential management in LoRaWAN; and EC04: do not

address, or indirectly addresses, the use of IoT / IIoT

devices. Figure 3 shows from the initial identiﬁcation

of works in the ASEs to the ﬁnal synthesis.

Number of

works

identified:

332

Number of

papers

after

removing

duplicates:

289

Number of

works

evaluated

for

eligibility:

286

Number of

works included

in the

qualitative

synthesis:

Number of

works included

in the

quantitative

synthesis:

Number of works excluded with justification:

250

Figure 3: Related work evaluation process.

According to Figure 3, the works went through a

ﬁlter to remove duplicate works and, subsequently,

were submitted to an eligibility assessment accord-

ing to the inclusion and exclusion criteria. Then, the

works were included in a qualitative synthesis, whose

summary content and main topics of the publication

were evaluated. Thus, the number of papers included

in the ﬁnal quantitative synthesis was arrived at. Ta-

ble 2 reveals there were no works meeting all require-

ments from our research problem.

Credential Lifecycle Analysis in Private LoRaWAN Networks for Industrial IoT (IIoT)

159

Table 2: Related works identiﬁed.

Q1:

Propose lifecycle

credentials?

Q2:

Requirements for

wide area and

conﬁguration

remote?

Q3:

Uses networks

LPWAN and

protocol

LoRaWAN?

Q4:

Is aimed at

industrial

scenarios

IIoT?

(Ribeiro et al., 2020) Yes No Yes No

(Sanchez-Iborra et al., 2018) Yes No Yes No

(Naoui et al., 2016) Yes No Yes No

(Ralambotiana, 2018) Yes No Yes No

(McPherson and Irvine, 2020) Yes Yes Yes No

(e Margaret Lech e Liuping Wang, 2021) Yes Yes Yes No

(Naoui et al., 2017) No No Yes Yes

(Xing et al., 2019) Yes No Yes No

(Sanchez-Gomez et al., 2020) Yes Yes No No

(Felli and Giuliano, 2021) Yes Yes Yes No

5 PROPOSAL

The proposal consists of an analysis of the lifecy-

cle of credentials for private networks of LPWAN

networks, implemented with the LoRaWAN protocol

with servers using the ChirpStack component. Our

scenario is based on a layered architecture for IIoT,

based on the proposal of (Lin et al., 2017).

In the LoRaWAN context, the ﬁnal device pro-

vides credentials for the join procedure process. The

binding step between the credential and the Identity

and Access Management (IAM) entity is performed in

an operation between the edge and platform layer in

the join procedure before sending the join accept mes-

sage. Credentials are issued and stored in the platform

layer of the referential architecture, which is respon-

sible for infrastructure and network operations. Re-

garding the LoRaWAN protocol, the entities involved

are the Join Server and the network server, and op-

erations are performed after the join procedure. The

credential suspension and revocation is an operation

involving two layers of the architecture: the platform

and the enterprise layer. In parallel, in LoRaWAN,

this operation can be triggered by the Join Server or

the LoRaWAN application server through control sys-

tems.

Edge Layer Platform Layer Corporative Layer

Sensors

and

actuators

Edge

gateway

Wireless networks

Guided networks

NOTATION

Credential

generation

Credential

issuance

Credential

storage

Credential

binding

Credential suspension and

revocation

LoRaWan Network

Server

Business rules

LoRaWan

Application

Server

Dashboards and

corporative control

LoRaWan Join

Server

Control Flow

Data Flow

Control Flow

Figure 4: Proposal architecture.

Figure 4 shows the generic reference architecture

of IIoT can serve as a framework for LoRaWAN net-

works in the industrial context. This analysis sce-

nario is justiﬁed by requirements on IIoT services.

Implementing LoRaWAN networks is directly linked

to the use case requirements, number of devices, and

typical service area as per (Brown et al., 2018). At

the same time, using components for ChirpStack for

LoRaWAN servers is justiﬁed by being widely used,

having the most signiﬁcant active community, and

having periodic and current updates (Lund, 2022).

The application domain of the proposal can be

deﬁned as an industrial context with a large service

area, low power availability, and remote management.

Thus, the correct security management in the scenario

of this proposal takes to our problem (Section 3).

5.1 Testbed

The experimentation environment employs

GNU/Linux Ubuntu Server version 22.04 oper-

ating system. The architecture components are

simulated as depicted in Figure 4. The Edge Layer

features simulated end devices, speciﬁcally tempera-

ture gauges, and the simulated LoRaWAN gateway.

All components were conﬁgured in a ChirpStack

version 3.16.3 ecosystem, these components are

equivalent to factory ﬂoor end devices in the in-

dustrial scenario, and the gateway is equivalent to a

physical gateway. These components are simulated

on a computer with hardware integrated by an Intel

Core I3 64bit processor, 8GB of DDR4 memory,

and a 1TB hard drive. The servers are installed

under an Apache web server and Postgresql Server

database directly on the native operating system. At

the Platform Layer, the environment has a network

server and a join server, LoRaWAN 1.1, both imple-

mented by the ChirpStack ecosystem. The network

server and the join server are the same used in real

environments and similar to those used in a real

factory environment. The application server and the

Application Programming Interface (API) also from

ChirpStack are used in the Enterprise Layer. The

application server and the programming interface

are identical to those used in the real world. API

management is performed by the Insomnia API client

(Information at: https://insomnia.rest/, in version

2022.2.1. Detailing the experimentation environment

guarantees the reproducibility of the experiments.

Thus, it is possible to detail the testbed architecture

and the test plan related to the analysis.

5.2 Method of Analysis

The primary purpose of this research is to carry out

a lifecycle analysis of credentials in LPWAN Lo-

RaWAN 1.1 networks according to the recommended

standards for IIoT. We deﬁned criteria (C) employed

in our tests and experiments to allow our analysis and

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

160

indicate possible solutions for the identiﬁed problems.

Each criterion is based on identity management stan-

dards: (C1) - Credential lifecycle phases: Identify the

credential lifecycle phases of a LoRaWAN network

deployed with ChirpStack servers for IIoT. We ver-

ify that the procedures are categorized into registra-

tion, management, and authentication phases. (C2) -

Credential lifecycle phases: Identify which phases are

involved in the LoRaWAN ChirpStack context iden-

tity lifecycle phases. The registration phase should

contain initiation, veriﬁcation, and entity registration

steps. The management phase must add the genera-

tion, binding, issuance, and storage of credentials. In

addition, the management phase should cover contin-

gency measures such as suspension, renewal, and re-

placement of credentials. (C3) - Audit mechanisms:

Verify the audit mechanisms in the LoRaWAN Chirp-

Stack context in the credential lifecycle. The audit

process is a step present in all phases of the lifecycle.

It is evaluated whether the audit in this scenario goes

beyond these phases.

5.3 Environment Setup

The approach was chosen because it allows the im-

plementation of a LoRaWAN architecture in a local,

controlled environment with reduced cost and use of

resources. The architecture has the essential com-

ponents of a LoRaWAN network: end devices, join

server, network server, and application server. The in-

frastructure components are implemented by a Chirp-

Stack environment. The end devices and gateways

are simulations that interact with a Network Server,

a Join Server, and a conventional Application Server

installed on a local server (Figure 5).

End-device

LoRa Network

Server

Application

Server

End-device

Gateway

End-device

Join Server

Insomnia REST

Client

Chirpstack

Simulator

Chirpstack

API

Localhost

127.0.0.1

Figure 5: Overview of the experiment setup.

The LoRaWAN ChirpStack Network Server

(https://github.com/brocaar/chirpstack-simulator was

deployed to simulate devices and gateways, allowing

to have a conﬁgurable number of devices and gate-

ways, which can be automatically created when start-

ing the simulation. In these tests, the server is initial-

ized and has a simulation duration conﬁgured. It is

possible to read the metrics and complete the simula-

tion in the sequence. After this duration, the simula-

tor can be terminated, and the created devices, gate-

ways, applications, and device proﬁles are restarted.

The interfaces of the application server and the API

of ChirpStack were used to visualize and manage the

devices and collect data. This does not interfere with

the relationship with a real scenario, as it is strictly

the same as operating in a production environment.

The test plan was designed to synthesize the informa-

tion related to the tests of this work. We reinforced

that the analysis criteria are all analyzed in this test

environment in their respective scenarios (Table 3).

Table 3: Consolidated test scenarios.

Phase Step Analysis criteria Scenario HTTP Request Endpoint of ChirpStack API

Enrollment Initiation C1 and C2 Scenario 1 POST /api/devices

Enrollment Veriﬁcation C1 and C2 Scenario 1 POST /api/devices

Enrollment Registry C1 and C2 Scenario 1 POST /api/devices

Credential

management

Generation C1 and C2 Scenario 2 POST /api/devices/{device keys.dev eui}/keys

Credential

management

Vinculation C1 and C2 Scenario 2 POST /api/devices/{device keys.dev eui}/keys

Credential

management

Issuance C1 and C2 Scenario 2 POST /api/devices/{device keys.dev eui}/keys

Credential

management

Storage C1 and C2 Scenario 2 GET /api/devices/{dev eui}/keys

Credential

management

Renew, replacement

and rotation.

C1 and C2 Scenario 3 PUT /api/devices/{device keys.dev eui}/keys

Credential

management

Suspention and

revocation

C1 and C2 Scenario 3 DELETE /api/devices/{dev eui}/keys

Entity

authentication

Authentication C1 and C2 Scenario 4 POST /api/devices/{device activation.dev eui}/activate

Entity

authentication

Authorization C1 and C2 Scenario 4 POST /api/devices/{device activation.dev eui}/activate

Entity

authentication

Audit C3 Scenario 5 GET /api/devices/{dev eui}/events

6 RESULTS AND ANALYSIS

Each of these experiments analyzes a group of steps

in a phase of the lifecycle of credentials described in

the work’s rationale. Each experiment scenario starts

with a deﬁnition of objectives and the related scope.

Thus, the scope is relative to the steps and phases an-

alyzed. As well as carried out individually in each

scenario, a global analysis of the scenarios was car-

ried out. The deﬁnition of scenarios and experiments,

as well as the attributes that are part of the execution

of the tests, are described in Table 4 and Figure 6.

Table 4: Test results consolidation.

Test

Scenarios

Experiment

Execution

code

Credentias

involved

Requirements

compliance

Analysis

Criteria

Results

Scenario 1 Experiment 1

Code 1

Code 2

devEUI

Fully

fulﬁlled

Criterion 1

The operation performs the steps of

initiation, veriﬁcation and registration.

Scenario 2 Experiment 1

Code 3

Code 4

devEUI, appKey,

nwkKey, genAppKey

Fully

fulﬁlled

Criterion 1

The operation executes generation,

binding, issuance and store phases.

Criterion 2

The operation performs generation,

binding, issuance, and storage steps.

Scenario 3 Experiment 1

Code 5

Code 6

devEUI, appKey,

nwkKey, genAppKey

Partially

fulﬁlled

Criterion 1

The operation performs the renew

and replace steps. Do not perform

the rotation step.

Criterion 2

The operation performs the

credential management phase.

Experiment 2 Code 7

devEUI, appKey,

nwkKey, genAppKey

Partially

fulﬁlled

Criterion 1

The operation performs the

suspend step. Does not perform

the revocation step.

Criterion 2

The operation performs the

credential management phase partially.

Scenario 4 Experiment 1

Code 8

Code 9

appSKey, devAddr,

devEUI, fNwkSIntKey,

Fully

fulﬁlled

Criterion 1

The operation performs the

authentication and authorization steps.

nFCntDow, nwkSEncKey,

sNwkSIntKey

Criterion 2

The operation performs the

authentication phase.

Scenario 5 Experiment 1 Code 10 devEUI

Not

fullﬁlled

Criterion 3

The operation does not perform

an audit step in any of the credential

lifecycle phases.

Table 4 groups the tests by test scenarios. Each

scenario has experiments that use code to perform test

operations. For each experiment, the LoRaWAN pro-

tocol credentials involved are listed. In addition, each

experiment is analyzed through the prism of the anal-

Credential Lifecycle Analysis in Private LoRaWAN Networks for Industrial IoT (IIoT)

161

Gateway Join ServerNetwork Server

Application

Server

End device

Edge layer Platform layer Corporative layer

API

2 - Request of device data

GET

http://localhost:8080/

api/devices/dev_eui/

3 - Response of data solicitation.

Device Object or Null

1 - Device Registration

POST

http://localhost:8080/api/devices

Registry

2 - Request of device data

GET

http://localhost:8080/api/devices

/dev_eui/keys

Generation,

binding

andissuance

1 - Send device credentials

POST

http://localhost:8080/api/devices

/{device_keys.dev_eui}/keys

4 - Deleting Credentials

DELETE

http://localhost:8080/

/api/devices/{dev_eui}/keys

1 -Update and replacement

ofcredentials.

PUT

http://localhost:8080/api/devices

/{device_keys.dev_eui}/keys

5 - Request of device data

GET

http://localhost:8080/

/api/devices/{dev_eui}/keys

6 - Response of data solicitation.

DeviceKeys Object or Null

Replace-

ment

1 - Join Request (DevEUI)

3 - Success OK

2 - Join Request

4 - Join Accept

5 - Activation Request

POST

http://localhost:8080/api/devices/

{device_activation.dev_eui}/activate

5 -Requestactivation data.

GET

http://localhost:8080/

/api/devices/{dev_eui}/activation

6 - Response of data solicitation.

Object deviceActivation or Null

2 -Response of data request.

Object Device or Null

1 - Device events

GET

http://localhost:8080/api/devices/

{dev_eui}/event

3 - Response of data solicitation.

DeviceKeys Object orNull

2 - Request of device data

GET

http://localhost:8080/api/devices

/dev_eui/keys

3 - Response of data solicitation.

DeviceKeys Object orNull

Scenario 1

Scenario2

Scenario3

Scenario4

Scenario5

Delete

Authori-

zation

Events

Authenti-

cation

Figure 6: Sequence diagram of experiments.

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

162

ysis criteria.

Scenario 1 aims to test the initiation, veriﬁcation,

and registration steps in the registration phase. The

credential involved in the test is the devEUI. This sce-

nario had the analysis requirements fully met. There-

fore, this test ensures that the scenario executes the

steps and the analyzed phase, contributing to the re-

sults to attest that the test environment complies with

the standards.

Scenario 2 aimed to test the generation, bind-

ing, issuance, and storage in the credential manage-

ment step. We have devEUI, appKey, nwkKey, and

genAppKey credentials involved in this test. The re-

quirements were fully met, which adds to the result’s

proven suitability of the environment for the lifecycle

and adequacy to the phases of generation, binding, is-

suance, and storage and to the credential management

phase.

Scenario 3 has two experiments. In the ﬁrst,

the LoRaWAN credentials used are devEUI, appKey,

nwkKey, and genAppKey. In this experiment, the re-

quirements were fulﬁlled only partially because the

application server does not have a rotation step. Thus,

adding to the overall result, the point of attention is

that the LoRaWAN protocol implemented by Chirp-

Stack has dissonance with the lifecycle pattern. Still,

the scenario understands renovation and replacement,

so it partially lives up to the requirements.

In Scenario 3 and Experiment 2, the credentials

devEUI, appKey, nwkKey, and genAppKey are used,

and the requirements are only partially fulﬁlled. This

is since the environment does not have the credential

lifecycle revocation step. This is part of the overall

analysis with the ﬁnding that the credential manage-

ment phase is compromised in terms of revocation.

Scenario 4 looks at the appSKey, devAddr, de-

vEUI, fNwkSIntKey, nFCntDown, nwkSEncKey, and

sNwkSIntKey credentials. In the analysis carried out,

this scenario ﬁts the criteria so that the authentication

and authorization operations are performed. Conse-

quently, the authentication phase is available satisfac-

torily, adding to the result that authentication and au-

thorization operations exist and are available as part

of the cycle. This is vital for the functioning of an

authentication scheme, so this result was expected.

Scenario 5 uses the devEUI identiﬁcation creden-

tial and does not meet the analyzed requirements. Cri-

terion 3 is not achieved, implying there is no possi-

bility of auditing the test environment and not fulﬁll-

ing credential lifecycle standards requirements. Ta-

ble 5 summarizes the results obtained categorized by

phases and steps of the lifecycle.

Performing a general analysis of the credentials

lifecycle in private networks for IIoT implemented

Table 5: Summary of results.

Lifecycle

phase

Lifecycle

phase

Analysis Criteria Scenario

Result

obtained

Enrollment Initiation

Criterion 1

Criterion 2

Scenario 1

Suitable for

the lifecycle

Enrollment Veriﬁcation

Criterion 1

Criterion 2

Scenario 1

Suitable for

the lifecycle

Enrollment Enrollment

Criterion 1

Criterion 2

Scenario 1

Suitable for

the lifecycle

Credential

management

Generation

Criterion 1

Criterion 2

Scenario 2

Suitable for

the lifecycle

Credential

management

Issuance

Criterion 1

Criterion 2

Scenario 2

Suitable for

the lifecycle

Credential

management

Storage

Criterion 1

Criterion 2

Scenario 2

Suitable for

the lifecycle

Credential

management

Renew, replacement

and renew.

Criterion 1

Criterion 2

Scenario 3

Partially

suitable for

the lifecycle

Credential

management

Suspension and

revocation.

Criterion 1

Criterion 2

Scenario 3

Partially

suitable for

the lifecycle

Entity

authentication

Authentication

Criterion 1

Criterion 2

Scenario 4

Suitable for

the lifecycle

Entity

authentication

Authorization

Criterion 1

Criterion 2

Scenario 4

Suitable for

the lifecycle

Entity

authentication

Audit

Criterion 3

Scenario 5

Not Suitable for

the lifecycle

with ChirpStack, our key remarks are:

• The environment fulﬁlls the requirements related

to the initialization, veriﬁcation, and registration

steps of the registration phase.

• The environment fulﬁlls the requirements related

to the generation, binding, issuance, and storage

steps of the credentials management phase.

• The environment fulﬁlls the requirements asso-

ciated with the authentication and authorization

steps in the authentication phase.

• The environment partially fulﬁlls the require-

ments regarding the credentials management

phase. Because it correctly implements the re-

newal and replacement steps but does not perform

the rotation step.

• The environment partially fulﬁlls the require-

ments regarding the credentials management

phase. Because it correctly implements the sus-

pension step but does not execute the revocation

step.

• The environment only partially meets the audit

step. Step that is present in all phases.

In this way, the present work attests that the private

LoRaWAN networks implemented in ChirpStack are

not entirely adequate to the standards established for

the IIoT. Thus, our work analyzes this protocol and

the ChirpStack server so that developers can be aware

of this arrangement’s risks and necessary improve-

ments regarding the lifecycle of credentials in com-

pliance with standards.

Credential Lifecycle Analysis in Private LoRaWAN Networks for Industrial IoT (IIoT)

163

7 CONSIDERATIONS AND

FUTURE WORK

The IIoT is a relatively well-established concept. Sev-

eral standardization lead to a well-deﬁned architec-

ture following the standards bodies such as ISO,

NIST, and IIC. Thus, recommendations on security

and identity lifecycle guide the deﬁnition of objec-

tives. The characterization is in accordance with the

main regulatory institutions of the international mar-

ket in the ﬁeld of Industrial Internet. The path neces-

sary to achieve the goal of analyzing the lifecycle of

LoRaWAN credentials provided by ChirpStack. With

the approach of joining and activation procedures in

LoRaWAN, the steps and phases of the credential life-

cycle were related to the protocol credentials. This

intersectionality is an important characteristic of the

contribution of this work. The most concrete impor-

tance of this work was to avoid information security

incidents in industries due to vulnerabilities in the

lifecycle of credentials.

It was possible to state that the LoRaWAN pri-

vate networks provided by ChirpStack needs to be

improved to secure credentials during its lifecycle.

There are disparities between the recommended and

implemented lifecycle, mainly in auditing. Addition-

ally, this environment does not fully implement rec-

ommended lifecycle steps such as credential rotation

and revocation. Thus, it allows the work to serve as

a basis for deploying technologies such as LoRaWAN

in a risk-conscious manner or that the implementation

can provide the points at which this computational ar-

rangement falls short regarding the credentials lifecy-

cle.

Furthermore, this work points to future work. A

more comprehensive and updated bibliographic sur-

vey in terms of IIoT could be carried out, as it con-

tributes to the concept of IIoT. Another future work

that comes naturally from this work would be to im-

prove ChirpStack for a fully lifecycle-compliant cre-

dential lifecycle. Implementations aimed at tracking

lifecycle operations are vital. Another future work is

ﬁx security problems such as storing clear credentials

stored in the database used by ChirpStack.

ACKNOWLEDGMENTS

This work was funding by the National Council for

Scientiﬁc and Technological Development (CNPq,

grant 311245/2021-8), FAPESC, UDESC, and devel-

oped at LabP2D.

REFERENCES

Brown, G. et al. (2018). Ultra-reliable low-latency 5g

for industrial automation. Technol. Rep. Qualcomm,

2:52065394.

De Sousa, P. H. F., Navar de Medeiros, M., Almeida, J. S.,

Reboucas Filho, P. P., de Albuquerque, V. H. C., et al.

(2019). Intelligent incipient fault detection in wind

turbines based on industrial iot environment. Journal

of Artiﬁcial Intelligence and Systems, 1(1):1–19.

onmez, T. C. and Nigussie, E. (2018). Security of lo-

rawan v1.1 in backward compatibility scenarios. Pro-

cedia Computer Science, 134:51–58. The 15th Inter-

national Conference on Mobile Systems and Pervasive

Computing (MobiSPC 2018) / The 13th International

Conference on Future Networks and Communications

(FNC-2018) / Afﬁliated Workshops.

e Margaret Lech e Liuping Wang, X. C. (2021). A complete

key management scheme for lorawan v1.1 †. Sensors

(Basel, Switzerland), 21.

Felli, L. and Giuliano, R. (2021). Access control in wood-

land through blockchain and lorawan. In 2021 AEIT

International Conference on Electrical and Electronic

Technologies for Automotive (AEIT AUTOMOTIVE),

pages 1–5.

Galv

ao, T. F., Pansani, T. d. S. A., and Harrad, D. (2015).

Principais itens para relatar revis

oes sistem

aticas e

meta-an

alises: A recomendac¸

ao prisma. Epidemiolo-

gia e servic¸os de sa

ude, 24:335–342.

Gulati, K., Boddu, R. S. K., Kapila, D., Bangare, S. L.,

Chandnani, N., and Saravanan, G. (2022). A review

paper on wireless sensor network techniques in inter-

net of things (iot). Materials Today: Proceedings,

51:161–165.

Kim, H. and Lee, E. A. (2017). Authentication and au-

thorization for the internet of things. IT Professional,

19(5):27–33.

Kobara, K. (2016). Cyber physical security for industrial

control systems and iot. IEICE TRANSACTIONS on

Information and Systems, 99(4):787–795.

Lin, S.-W., Miller, B., Durand, J., Bleakley, G., Chigani, A.,

Martin, R., and Crawford, B. M. M. (2017). Indus-

trial internet consortium (iic) - the industrial internet

of things volume g1: Reference architecture.

Lund, F. (2022). Study of lorawan device and gateway se-

tups: with chirpstack implementation.

Luvisotto, M., Tramarin, F., Vangelista, L., and Vitturi, S.

(2018). On the use of lorawan for indoor industrial iot

applications. Wireless Communications and Mobile

Computing, 2018.

McPherson, R. and Irvine, J. (2020). Secure decentralised

deployment of lorawan sensors. IEEE Sensors Jour-

nal, 21(1):725–732.

Naoui, S., Elhdhili, M. E., and Saidane, L. A. (2016). En-

hancing the security of the iot lorawan architecture. In

2016 International Conference on Performance Eval-

uation and Modeling in Wired and Wireless Networks

(PEMWN), pages 1–7. IEEE.

Naoui, S., Elhdhili, M. E., and Saidane, L. A. (2017).

Trusted third party based key management for enhanc-

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

164

ing lorawan security. In 2017 IEEE/ACS 14th Interna-

tional Conference on Computer Systems and Applica-

tions (AICCSA), pages 1306–1313.

Ralambotiana, M. (2018). Key management with a trusted

third party using lorawan protocol: A study case for

e2e security.

Ribeiro, V., Holanda, R., Ramos, A., and Rodrigues, J. J.

(2020). Enhancing key management in lorawan with

permissioned blockchain. Sensors, 20(11):3068.

Sanchez-Gomez, J., Garcia Carrillo, D., Marin-Perez, R.,

and Skarmeta, A. (2020). Secure authentication and

credential establishment in narrowband iot and 5g.

Sensors, 20:882.

Sanchez-Iborra, R., S

anchez-G

omez, J., P

erez, S.,

Fern

andez, P. J., Santa, J., Hern

andez-Ramos, J. L.,

and Skarmeta, A. F. (2018). Enhancing lorawan secu-

rity through a lightweight and authenticated key man-

agement approach. Sensors, 18(6):1833.

Schrecker, S., Soroush, H., Molina, J., Hirsch, J. L. F.,

Buchheit, M., Ginter, A., Martin, R., Banavara, H.,

Eswarahally, S., Raman, K., King, A., Zhang, Q.,

MacKay, P., and Witten, B. (2016). Industrial inter-

net consortium (iic) - the industrial internet of things

volume g4: Security framework.

Xing, J., Hou, L., Zhang, K., and Zheng, K. (2019). An im-

proved secure key management scheme for lora sys-

tem. In 2019 IEEE 19th International Conference on

Communication Technology (ICCT), pages 296–301.

Yu, C.-E., Wang, C., and Zhang, S.-Q. (2022). Fault-

tolerant energy-efﬁcient lorawan networking architec-

ture. In 2022 11th Mediterranean Conference on Em-

bedded Computing (MECO), pages 1–4. IEEE.

Credential Lifecycle Analysis in Private LoRaWAN Networks for Industrial IoT (IIoT)

165