CONDUCT OF

THREAT ANALYSIS OF LoRaWAN SECURITY

ARCHITECTURE AND RECOMMEND IMPROVEMENTS

WAQAS TAHIR
REG ID # 151053
Guidance and Evaluation
2
Committee (GEC)
Dr Liauqat Ali Khan Dr Ammar Masood
Department of Avionics HOD, Department of
Engineering, Institute of Avionics Engg, Institute of
Avionics and Aeronautics Avionics and Aeronautics
(IAA) Air University (IAA) Air University

Dr Mansoor A Khan Dr Rai Mehmood

Department of Avionics Department of Avionics

Engg, Institute of Avionics Engineering, Institute of
and Aeronautics (IAA) Air Avionics and Aeronautics
University (IAA) Air University
Sequence 3

• Introduction to LoRaWAN Protocol

• Overview
• Security Architecture
• Threat Analysis
• Improved Security Architecture in LoRaWAN v1.1
• Existing security challenges in LoRaWAN
• RSSI based technique for detection of Replay / Identity Based
Attacks on LoRaWAN
• Improved Model for Node Identification in Replay / IBAs
• Conclusion
• Questions
 Launched
by
Semtech 4
in 2015

Bi
ISM Band
directional

LoRa
3~5 Kms Upto 25
Urban KMs Rural
areas areas

50Kbps with
255 bytes
Max
LoRa Network Architecture 5

• Comprises of Nodes and gateways in Star topology

 The LoRaWAN 1.0 Protocol Stack 6

Pure Aloha type transmission following

duty cycle limitations in ISM band

LoRa devices classified into 3 classes based on

their network access

LoRa employs CSS waveform for its wireless

communication with variable spreading factor
 LoRa End Devices Classes 7
Class - A
• Power efficient, remains in sleep mode unless transmitting
• End-device‘s uplink transmission followed by two short downlink
receive windows
• In order to communicate with the device, the Application /
Network Server have to wait for transmission from the ED

Mandatory Class for all devices

 LoRa End Devices Classes 8
Class – B & C
• Class B allows more scheduled receive slots in addition
to the Class A random receive windows
• Using a time synchronized Beacon from the gateway

• Time slots are known to Net Serv & App Serv

• Class C devices are always in receive mode unless

transmitting at the cost of more power consumption
 LoRaWAN v1.0
Protocol Stack & Security Framework
 LoRaWAN v1.0 Protocol Stack 10

• LoRaWAN frame starts with a

• Preamble (8 bytes of 0x34),
• Physical Header with Physical Header CRC
• Physical Payload and a Phy Pyld CRC added only for Uplink
messages from the End devices to Network Server

Preamble PHY HDR PHDR CRC PHY PAYLOAD *CRC

 LoRaWAN v1.0 Protocol Stack 11

Preamble PHY HDR PHDR CRC PHY PAYLOAD *CRC

FRM
DevAddr FCtrl FCnt FOpts F HDR F Port MAC HDR MAC PAYLOAD MIC
PAYLOAD

000 Join Request

001 Join Accept
Indicate presence of MAC commands May contain MAC
010 Unconfirmed Data Up
or App data in Frame Payload field commands or App data
011 Unconfirmed Data Down
100 Confirmed Data Up
101 Confirmed Data Down
110 RFU M Type RFU Major Indicates the format of messages
111 Proprietary being exchanged in Join Procedure
 LoRaWAN 1.0 Security Framework 12

Signing AES 128 Bit Encryption

• Key usage is based on how nodes Join a LoRa network

• Over The Air Activation mode (OTAA), involves handshake and computing of
Session keys from pre-shared root key

• Activation By Personalization Mode (ABP), no handshake required, devices

use Permanent fixed keys and other parameters
 Over the Air Activation (OTAA) – Join Request 13

• All End Devices are deployed with unique 128-bit App key (AppKey)
• The Node sends Join Request message containing following fields
• AppEUI  Unique Global application 8 bytes ID that uniquely identifies the
application provider of the end-device
• DevEUI is a globally unique end-device identifier (8 bytes)
• DevNonce is a randomly generated 02 bytes value
CMAC = AES128_cmac(AppKey, MHDR|AppEUI|DevEUI|DevNonce)
MIC = CMAC [0...3] (4 byte)

Join Request 8 8 2 Not Encrypted but Signed

Message App EUI Device EUI DevNonce using App Key
 Over the Air Activation (OTAA) – Session Keys 14

• The Network Server, upon receiving a Join Request message

• Verifies Device Nonce & Re-calculates MIC using pre-shared AppKey
• If valid, may respond with a Join Accept message within receive
windows of the Node
• Network Server further generates End Device specific 3 byte
random value, Application Nonce or AppNonce
• Both ED & Net Serv derive two new 128 bit Session keys
• NwkSKey  Network Session Key
• AppSKey  Application Session Key
 Over the Air Activation (OTAA) – NwkSKey 15

• Network Session Key (NwkSKey) used by Net Serv & End-device

• NwkSKey = AES128_encrypt (Appkey,0x01 | AppNonce | NetID | DevNonce | pad16)

• Application Session Key (AppSKey) used by Net Serv & End-device

AppSKey = AES128_encrypt ( Appkey, 0x02 | AppNonce | NetID | DevNonce | pad16)

• CalculateCalculate
& Verify an App
& Verify MIClevel MIC thattomay
of all messages beData
ensure included
Integrityin payload
of Application specific data messages

Encrypt / decrypt Frame Payload field (FRMPayLoad) of App specific data msgs
 Over the Air Activation (OTAA) – Join Accept 16

• Network server responds with a Join-Accept message containing

• AppNonce, Application nonce generated by Network Server
• NetID, Network Identifier for end device if permitted to join a network
• DevAddr, 32 bit End-device address
• DL Setting, Device Receive windows offset and version information
• RxDelay, Delay between Tx and Rx windows of End device
• CFList, List of channel frequencies, optional

Bytes 3 3 4 1 1 16(optional)
Join Accept AppNonce NetID DevAddr DLSettings RxDelay CFList
 OTAA – Join Accept Encryption & MIC 17

• MIC for Join-Accept message

CMAC = AES128_cmac(AppKey, MHDR | AppNonce | NetID | DevAddr |
DL Settings | RxDelay | CFList)
MIC = cmac [0...3] JA message Signed & Encrypted
using App Key
• Encryption of Join-Accept Encrypted
AES128_decrypt = (AppKey, AppNonce | NetID | DevAddr | DL Settings|
RxDelay | CFList | MIC)

Net Srv uses AES decrypt operation in ECB mode to encrypt the JA message
ED use AES Encrypt to decrypt, only implement AES encrypt operation
Over the Air Activation (OTAA) - Completed 18

• The End device upon receiving the Join-Accept message

• First decrypts J-A by encryption operation using the AppKey
• Validates the MIC using AppKey
• Calculates the AppSKey and NwkSKey key using AppNonce and NetID
• After activation, End Device is stored with following fields in
addition to pre-stored fixed values
• 32 bits Device Address (DevAddr)
• 128 bit Network session key (NwkSKey)
• 128 bit Application session key (AppSKey)
 LoRa Communication – Data Encryption 19

• If a data frame carries a payload

• FRMPayload is encrypted before Message Integrity Code (MIC) is calculated
using AES 128 in ECB mode
• Key K used for encryption, depends on value of FPort field
• By default, the encryption / decryption is done for all FPort values

FPort K FRMPAYLOAD
0 NwkSKey Payload is either empty or contains MAC commands only

1,2,3…..255 AppSKey Payload contains application specific data

 LoRa Communication – Data Encryption 20

• For each data message, the algorithm defines a sequence of Blocks Ai

for i = 1…...k Bytes 1 4 1 4 4 1 1

with k = ceil ( len (pld) / 16) Ai 0x01 4x0x00 Dir DevAddr

FCntUp or
0x00 i
FCntDown
Direction field (Dir) is 0 for uplink frames & 1 for downlink frames

The blocks Ai are encrypted to get a sequence S of blocks Si:

Si = AES 128_encrypt (K, Ai) for i = 1..k
S = S1 | S2 | ….. | Sk
• Encryption and Decryption of the payload is done by truncating
(pld | pad16) XOR S to the first len (pld) octets
 LoRa Communication – Data Encryption 21

• LoRa v1.0 employs two Frame counters

• Employed in Key generation process as well as to counter replay attacks

• FCntUp
Frames
Frames sent
sent Uplink to Net
Downlink fromServer incremented
Net Server, by theby
incremented end-device
Net Serv
• FCntDown
• After JA completion, Frame counters on both sides reset to 0
• Subsequently FCntUp & FCntDown are incremented at sender side by 1 for
each data frame sent in respective direction & synched at other end
Bytes 1 4 1 4 4 1 1

Ai 0x01 4x0x00 Dir DevAddr FCntUp or FCntDown 0x00 i

LoRa Communication – MIC Calculation 22

• The 4 byte Message Integrity Code (MIC) is calculated over Cipher-

text and other values such as DevAddr, FCntUp or FCntDown
msg = MHDR | FHDR | FPort | FRMPayload (encrypted)
cmac = AES128_cmac (NwkSKey, B0 | msg)
Bytes 1 4 1 4 4 1 1
Bo 0x49 4x0x00 Dir DevAddr FCntUp or FCntDown 0x00 Len(msg)

MIC = cmac [0..3]

The direction field (Dir) is 0 for uplink frames and 1 for downlink frames

len(msg) denotes message length in bytes

 Activation by Personalization - ABP 23

• ABP differs from OTAA , In ABP mode the End Devices are shipped
with
• Unique Device address (DevAddr)

• 02 permanent keys i.e NwkSKey and AppSKey, instead of the DevEUI,

AppEUI and the AppKey

• ABP is plug n play type device, which starts communicating to

a specific LoRa network by-passing the Join request & Join
accept procedure
Threat Analysis of LoRa v1.0
 Keys Update / Revocation 25

• Specifications do not mention any procedure to revoke / update

root keys
• For ABP mode, pre-stored keys in the devices are permanent keys
• For OTAA mode, the AppKey is the root key

• Keys stored in ED & Net Serv for life time without being updated
• In ABP mode, the session keys are permanent keys
• In OTAA mode, Session keys generated from permanent AppKey
 Single Root Key & App Key Info 26

• Single Root Key is used to generate all session keys

• Compromise of Root key by any means would subsequently reveal all session keys
for life time

• A trust relationship is assumed to exist between Net Serv & App Serv
• Net Serv has root AppKey which further generates session keys, contents of App
specific data is accessible to Net Server

• Specification do not specify anything on secure and tamper proof

storage of keys, frame counter and Nonce values
Key Authentication & Key Confirmation 27

• Owing to Symmetric key architecture, Key confirmation & Key

Authentication are two desirable properties required to
ensure identification of participating nodes & keys
• Due to absence of root key update procedure, digital
signatures or any certification authority
• Key authentication & Key Confirmation is not possible
• Therefore both ED or shared key can be compromised for lifetime
without being noticed
 Replay Attacks using Frame Counter 28

• Frame Counters reset to Zero after counter overflow or a Device Reset

• Messages grabbed in the previous session can be replayed in the
current session
• FCnt values are transmitted in plain text with no time stamps

• OTAA mode  Difficult to execute, counter overflow is a remote

possibility while new session keys established upon device reset
• ABP mode  Possible owing to fixed permanent keys, likelihood of
launching a replay attack / Dos attack is quite high
 Exploiting Counter GAP value for DOS attacks 29
in ABP mode
• Counter GAP (FCnt_GAP) is programmable value (16384 by default)
• Uplink counter value of the malicious message = F Cntm
• Uplink counter value of the end device = F Cntcurr

• NS accepts the messages if counter value is within the Gap value

• First monitor and store the uplink messages of an ABP-activated node
• Second, wait until the device has reset the counter value FCnt
• Third, replay message with F Cntm − F Cntcurr ≤ Gap
 Exploiting Counter GAP value for DOS attacks 30
in ABP mode
• F Cntm = Gap + F Cntcurr (will take max time to recover)
• Attacker sends previously recorded msg in current session
• Messages from the victim with counter value smaller than 70
will be ignored as the subsequent frames sent by the
legitimate node are out of sequence
• Can periodically replay the message and block the end
device permanently

• Or until the keys of end device are changed

 Beacon Jamming for Class – B 31

• Beacon contain following information for Class-B type LoRa WAN devices
• Net ID  For identification of Gateway for the nodes
• Time  In seconds from 00:00 , 01 Jan, 1970
• GW Specific  Gateway Specific GPS Coordinates
• Beacon pld is transmitted in plain without any signatures or encryption
• The attacker can use information to locate the gateway for any malicious attempt
i.e Jamming, Physical access, traffic analysis, Replay attacks etc
• Transmit fake beacon  De-synch, opening of receive windows, battery exhaustion
• Incorrect / Inconsistent information about device location
 Implementation of AES in ECB Mode with 32
Stream Cipher – Known Plain Text Attack
• LoRaWAN implements Confidentiality through AES in CTR mode
• Upon device reset, the counters also reset
• With same key, the block cipher will recreate exactly same key material
• Two messages P1 and P2 encrypted under the same keystream
P1 ⊕ K = C1, P2 ⊕ K = C2
• Adversary can eliminate Secret key or Recover key if part of PT is known
C1 ⊕ C2 = (P1 ⊕ K) ⊕ (P2 ⊕ K)
= P1 ⊕ P2 ⊕ (K ⊕ K)
= P1 ⊕ P2 or
P1 ⊕ C1 = K
Misc Issues 33

• MIC verified by NS, Encrypted payload is forwarded to

Application server
• Terminating integrity check too early can lead to change in the
message by an adversary in transit without even being noticed at
Application Served
• ACK does not state which message it is confirming
• Captured ACK can be delayed and used to selectively ACK
successful receipt of another unrelated message, even when not
arrived at backend provider
 OTAA Joint Request Problem 34

• Dev Nonce is sent in plain in JR msg, can be replayed again later stage
• In Case JR is received with old nonce value then either
Dev Nonce stored by Net
• Rejected, Net Serv waits for other JR or ED is permanently blocked Serv to avoid Replay attack
• LoRa specification does not specify
fj = Number of valid Join procedures / node / day Time duration
Number forNonce
of Dev which
DevNonce stored
stored by by NS
Net Serv
ND = Number of previously used device nonce stored by NetSrv
Tr = Time in days the attacker waits to perform replay attack
• Objective of attacker, send a previously captured JR with a DevNonce not
yet stored by Net Serv
Tr [days] = ND / fj  ideally we want Tr to be max by increasing ND
 OTAA Joint Request Problem 35

• As Dev Nonce is a 16 bit random number

ND (max) = 216 (max) implies Tr < 216 / fj
• There exist a possibility that ED may generate an already used Device
Nonce for a valid Join request message
Interested in Probability of
• Now if Net Server drops a legitimate request generating a stored Dev
N = Total number of device nonces Nonce for a given ND

S = Set of stored device Nonces, where

|S| = ND
Supposedly, we have a TRNG with uniform probability
of generating Device Nonce from [ 1,……,N = 216 ]
 OTAA Joint Request Problem 36

• Probability Pr [dk ε S] = ND / N (𝑑𝑘 is Dev Nonce generated at 𝑘𝑡ℎ JR)

• Naturally, Prob of generating stored Dev Nonce is higher if ND is higher
• Now it’s a trade off between Pr and Tr
Tr  Desire to maximize by storing Device nonces  increasing ND
Pr  Reduce probability of generating used Dev Nonce  reducing ND
• LoRa specification neither talks about ND nor the life time of
storage values
 OTAA Joint Accept Problem 37

• The App Nonce value generated and sent by the Net Srv is not
stored by the End device and is discarded after calculating
Session keys
• Any old recorded message if replayed against a valid JR can lead
to calculation of incorrect session keys, Net ID & Dev Address
• No parameter to confirm JA message freshness

• Device can’t recognize whether it’s a legitimate msg or a malicious one

Counter Measures 38

• In light of the threat analysis of LoRa v1.0, researchers also

suggested various counter measures
• Limited power, memory & processing resources remain constraints
• Following security exploits & suggested measures Semtech,
launched LoRa v1.1 in Oct, 2017
• Multi-layered Security architecture with additional keys
• JR & JA procedures re-defined and Re-Join procedure introduced
• Counter storage / use policy modified with two additional counters
introduced
LoRa V1.1 39

• ED specific AES 128 bit two root keys introduced instead of single key for
OTAA type devices

• NwkKey  To derive multiple keys pertaining to Network Server

• AppKey  To derive the AppSKey (Application Session Key)

• App Serv & Net Serv segregated & treated as separate entities
• Join Server introduced to handle Join Requests only
 LoRaWAN v1.1 Modified Join Procedure 40

• Join EUI introduced instead of Application EUI

• DevNonce  Counter starting at 0 when device initially powers up,
Incremented with every Join-request, cannot be reused for a given JoinEUI
• Resetting DevNonce without changing JoinEUI, NS discards Join-request
• NS tracks last DevNonce & ignores any JRs if DevNonce is not incremented
• MIC for Join Request calculated in same manner
cmac = AES 128_cmac(NwkKey, MHDR|JoinEUI|DevEUI|DevNonce|)
MIC = cmac [ 0 .. 3 ]
Bytes 8 8 2
Join Request Join EUI Device EUI DevNonce
 LoRaWAN 1.1 Join Accept Encryption & MIC 42

• End Device specific Join Nonce instead of App Nonce introduced

• Increment by one with every successfully processed Join Accept
• Device tracks, stores last used JoinNonce in last successful key derivation
• JA accepted if MIC is correct & JoinNonce is strictly greater than last one
Bytes 3 3 4 1 1 16 (Optional)
Join Accept Join Nonce Net ID Device Addr DL Settings Rx Delay CF List

• Key to Encrypt JA msg is function of Join / ReJoin-Request that triggered it

Triggering Join Accept or Re-JA Join Accept Encryption Key
Join-request NwkKey
Re-Join-request Type 0, 1 or 2 JSEncKey (Join Session Encryption Key)
 LoRaWAN 1.1 JA with OptNeg bit Set
43
Encryption & MIC Computation

• AES128 Decrypt operation in ECB mode is used to encrypt JA message

Encrypt JA = AES128_Dcry(NwkKey/JSEncKey, JoinNonce | NetID | DevAddr |
DLSettings | RxDelay | CFList | MIC) ECB mode for JA msg only

• MIC value of the Join-Accept message is calculated as follows

CMAC = AES128_cmac (JSIntKey, JoinReqType| JoinEUI| DevNonce| MHDR |
JoinNonce | NetID | DevAddr |DLSettings | RxDelay | CFList )
MIC = CMAC [0..3]
Join Request 0xFF (1 byte)
Rejoin-request type 0 0x00
Rejoin-request type 1 0x01
Join Session Integrity Key
Rejoin-request type 2 0x02
 LoRaWAN 1.1 Multi Keys Architecture 44
Key Derivation with OptNeg bit Set
• App Session Key to en/decrypt application data (CCM  Counter with CBC-MAC)
AppSKey = AES128_encrypt ( AppKey, 0x02 | JoinNonce | NetID |DevNonce | pad16 )
• Forwarding Net Session Integrity Key, calc MIC/part of MIC of all uplink data msgs
FNwkSIntKey = AES128_encrypt ( NwkKey, 0x01 | JoinNonce | NetID |DevNonce | pad16 )
• Serving Net Session Integrity Key to compute MIC of all downlink data msgs, MIC of
half of the uplink messages & Rejoin Requests Type 0 or 2
SNwkSIntKey = AES128_encrypt ( NwkKey, 0x03 | JoinNonce | NetID |DevNonce | pad16 )

• Net Session Enc Key, to encrypt / decrypt MAC commands (CCM  Counter with CBC-MAC)

NwkSEncKey = AES128_encrypt ( NwkKey, 0x04 | JoinNonce | NetID |DevNonce | pad16 )

 LoRaWAN 1.1 – Life Time Keys & 46
Session Context
• Two specific lifetime Keys are derived from the NwkKey
• JSIntKey  For MIC calculation of Rejoin-Request Type 1 and JA msgs
JSIntKey = AES128_encrypt (NwkKey, 0x06 | DevEUI | pad16)
• JSEncKey  To Encrypt the Join-Accept triggered by a Rejoin-Request
JSEncKey = AES128_encrypt (NwkKey, 0x05 | DevEUI | pad16)
• For ABP devices, all keys are loaded for lifetime during fabrication
• To cater for JA vulnerabilities, RekeyInd MAC command introduced
• For confirmation of new security context after processing of JA message
• Device Tx the RekeyInd MAC cmd until receives the RekeyConf cmd
 LoRaWAN 1.1 Post Join Accept &
47
Re-Join Procedure
Network Session Application Session
F/SNwkSIntKey AppSKey
RekeyInd
Respective used by NS
Session
NwkSEncKey FCntUp
as a signal
Context to switch
is maintained
at to
Netnew security
/ App Server FCntUp FCntDown (LW 1.0) or AFCntDwn (LW 1.1)
context
and ED FCntDwn (LW 1.0) or NFCntDwn (LW 1.1)
DevAddr

• Re-Join procedure introduced to ensure keys freshness

• Device may periodically transmit a Rejoin-request message or can
also be transmitted following a ForceRejoinReq MAC command
• Ensuring Key freshness to avoid Replay attacks
• Opportunity to establish new session periodically or in case of any incident
LoRaWAN V1.1 Frame Counters 48
Countering Replay Attacks
• 3 frame counters used, instead of two
• Frame Counters reset to 0 & increment with traffic exchange in OTA
• For ABP devices, the Frame Counters never reset for life time
• For OTAA devices, Frame counters never repeat with given key
• New Session Context established well before saturation of frame counters
• FCntUp for Data frames sent Uplink, incremented by the end-device
• NCntDown For MAC communication frames sent Downlink
• ACntDown For Application data sent Downlink from the Network server,
received by the end-device, is managed by the Application server
 49
Existing Threat Scenarios
LoRaWAN Ver 1.1
 Re Keying of End Devices 50

• ABP mode of LoRaWAN v1.1 do not support re-keying of

permanent keys
• In case of Frame counters reset, there is no mechanism to revoke root
keys on demand or periodically, ED is no more useable in such cases

• It is assumed that root keys are stored in tamper proof

environment in devices during fabrication
• Specifications don't recommend any measures or guidelines
Downlink Routing Vulnerability 51

• Downlink routing path database used for downlink

communication with ED
• Routing path database contains routing information based on signal
strength of last uplink received
• False routing path entry can be made in path database
• Capturing a packet and replaying it to Net Serv using another
gateway with strong signal (wormhole attack)
• Would result in incorrect entry in routing table owing to higher RSSI
 Misc Vulnerabilities 52

• Class B sessions are still vulnerable to Rogue-Gateway attack, i.e Beacon

Jamming through incorrect information
• Cam be mitigated by authenticated beacon transmissions
• Authenticated GWs (GW to NS, GW to ED) can be employed to avoid Rouge Gateways
• No procedure / signalling for deactivation of end device permanently
• As per specifications, Device Nonce cannot be reused with same JoinEUI,
therefore in case of Device Nonce reset owing to any reason
• Requires JoinEUI change, which is practically not possible as it would make all other
previously loaded devices using same JoinEUI non-functional or the end device cannot
be used anymore on the network
 Misc Vulnerabilities 53

• Integrity check is terminated at NS, while encrypted data is

forwarded to application server
• Application providers employ integrity check at their end to ensure data
integrity in transit
• The slow data rate & long air time of LoRa makes it prone to
Selective jamming
• By jamming a particular type of message
• Or jamming all messages coming from a particular end-device
• Can be mitigated by
• Having multiple gateway environment
• Selecting transmission frequencies randomly
LoRaWAN Attacks Classification 54

• Based on LoRa v1.0 threat analysis and further improvements in v1.1,

researchers tried to categorize different possible attacks on LoRaWAN,
based on
• Likelihood of executing an attack

• Impact of an attack in various domains

• Detectability and recoverability

• As per the research the attacks based on Physical capture of the

device and Replay attacks, Identity based attacks have been classified
as a major threat to LoRaWAN
 Problem Scenario 55
Downlink Routing Path Vulnerability, Replay Attacks, IBAs

• In scenario whereby an attacker node captured packet from an ED

and retransmitted it to NS with higher signal strength using another
Gateway
• Even if jamming is not achieved & both packets make it to NS with in same
receive window of Net Srvr, an incorrect routing path would be added

• Similarly with large number of devices still operating on LoRa V1.0,

vulnerabilities associated with Frame Counters, Device Nonce &
Join procedure can be exploited to execute Replay attack or IBAs
Countering Measures 56

• Conventional techniques cannot be used owing to highly

resource constraint environment
• Multiple approaches used by researchers utilizing physical
properties associated with wireless transmission
• Physical layer authentication using channel characteristics,
preamble, challenge-response, Received Signal Strength e.t.c [9]–[14]
• Mostly been tested in Zigbee, Wifi and Wireless Sensor Networks
• Researchers have mostly employed RSSI based techniques for node
identification, node localization and distance estimation purposes
Utilizing RSSI for 57
Replay Attack & IBA Detection
• Advantages associated with using RSSI
• By default available in almost all wireless systems
• Difficult for the attacker to predict the power level of frames
collected by a given receiver
• Malicious device cannot simply adjust their transmitted power levels
to match the RSS of the legitimate nodes
• Suited for both Line of Sight and Non-Line of Sight, indoor or urban
outdoor environment
 58
Literature Review
RSS Based Detection Technique
Publication Problem Technique used Environment

An Improved RSSI Node localization Results published

RSSI measurement using
Measurement In Wireless and
Sensor Networks
distance
estimation accuracy
improved suggested model
using
model
59
simulation

Empirical path loss model for

Decentralized malicious Node spoofing in
RSSI measurement in WSN
node detection and Wireless Sensor Matlab simulation
environment, training phase to
localization Network
model channel characteristics
Detecting 802.11 MAC
MAC Spoofing in Gaussian mixture modelling for Practical Wifi
Layer Spoofing Using
802.11 Wifi Networks RSS profiling and detection Environment
Received Signal Strength
Measurement of RSSI with
Detection of Identity
Detection of IBAs in neighbouring nodes and
Based Attacks in WSN Matlab simulation
WSNs Using Signal prints building signal print vector for
environment
each node
Signal print vector of each
Detecting IBAs in
MAC Spoofing in Wifi node generated at all APs is Actual office
Wireless networks using
Networks tagged with authentication environment
signal prints
request for identification
 Protecting End-Device from Replay Attack
on LoRaWAN -
• Problem : Replay attack, Node identification in
case of a legitimate ED sending a JR with
previously used value of Device Nonce in v1.0
• Technique used : RSSI value of LoRa v1.0 ED is
measured at different locations, same used for
node identification and replay attack detection

Compared with RSSI of

malicious node
attacking from 1, 1.5
and 2 Kms range RSSI of LoRa ED measured at different
ranges in NLoS environment
 Protecting End-Device from Replay Attack
on LoRaWAN

Problem Case 2  ED Range & Attacker

In Case 1 
Identification & ED Range =detection
improved 1 Km
Node
Even in have
In case case almost
3, a1, sameofranges
proprietary
Chances handshake
having and
false
Attacker Node at approx. 05 Km
accuracy in Case 1 & 2 can be achieved Range
cannot beemployed
technique
positives isidentified
also high using RSSI
where
owing only
to RSSI
values
single
with multiple sensors receiving signalto&
The attacker node identified owing
ofSuggested
both nodes
sensor method
measuring : Proprietary
are likely to RSSI
the be same RSSI of LoRa ED measured at different
usinglarge
it forvariation in RSSI
node identification
handshake ranges in NLoS environment
 Problem Scenario – Attack Model 62

N2

N1

NNN111 NN222
N
RSSI
RSSI
RSSI RSSI
RSSI
RSSI
-10
-10
-10 -6
-10
-6
 Modified Model 63

N2

N1

NN
1N11 NNN
222
RSSI
RSSI
RSSI RSSI
RSSI
RSSI
-10,-10
-10-10 -10
-6,-12
-6
Node Profiling for Detection of Replay & IBAs in
LoRaWAN using Signal Footprint
Simulation of LoRa Network Environment 65

• In order to simulate the LoRa environment, we used following

parameters
• Transmission Power (max) = 20 dBm
• Receiver Sensitivity = -130 dBm (link budget ~ 150dBm)
• Frequency = 963 Mhz
• For measurement the RSS, two models used
• Basic Free space path loss model using Friis equation
• Complex signal propagation using large city HATA model to cater for
shadowing and fading effects
 Simulation of LoRa Network Environment – 66
Signal Propagation Modelling
• Free space path loss model for RSSI measurement using Friis model
Pr = Pt . Gt . Gr . 𝝀2 (Watts)

(4 𝝅 d)2
Pr (dBm) = 10 Log 10 (Pr in watts)
Pr = Received Power ; RSSI in Watt
Pt = Transmitted Power ; 0.1 Watt
Gt = Gain of Transmitting antenna ; assumed 1
Gr = Gain of Receiving antenna ; assumed 1
d = Distance between Node and Gateway
 Simulation of LoRa Network Environment – 67
Signal Propagation Modelling
• Empirical path loss HATA model for large cities, in a more realistic
and complex signal environment
PL (dB) = [69.55 + 26.16 Log10 (f) − 13.82 Log10 (ht) –A (hr) + {44.9 −
6.55 Log10 (ht)} Log10 (d)]
• A (hr) = Correction factor for antenna height based on the size of the
coverage area. For larger cities and f > 300 MHz, it is computed as
A (hr) = 3.2 (Log10 (11.75 hr))2 − 4.97 dB
Pr (dBm) (RSSI) = PTr - PL (dB)
ht = Height of transmitter antenna, 100m assumed
hr = Height of receiver antenna, 5m assumed
Simulation of LoRa Network Environment 68

With receiver sensitivity of ~ 129

12 Nodes
50 x(10
50 LoRa & 02
Kms X-Y attacker)
plane
Euclidean
dBm, maxdistance
coveragehas beenfor
range used
freeto
areFree
randomly deployed following
space path loss model
calculate distance
space model between
& large the
city Hata
Gaussian
22 x distribution with Omni
22 Kms X-Y plane
nodes
model and the gateway
is calculated as 23Kms &
Fordirectional antenna
large city HATA model
12Kms respsectively
Assumptions 69

• Attacker Nodes can launch an attack by replaying a packet

captured from any node N1 to N10 randomly during each of the
total five iterative rounds
• An arbitrary value of + 0.5 dBm for free space and + 1.5 dBm
for large cities has been assumed to cater for variations in
RSSI. The actual adjusted values will be based on recorded
variations in real operating environment
• The Net Serv is communicated pre-hand information about
the node status whether static or mobile
Node Profiling for Detection of Replay & IBAs 70
in LoRaWAN using Signal Footprint
• NS receives packets from nodes through one or more
gateways along with RSS value recorded at each gateway
• Node profiling for each node is achieved using following
parameters
• Device EUI
• Static or mobile node
• Number of gateways receiving the signal along with respective RSSI
• NS uses this info to build node profile using signal foot print
• NS can also be trained with some initial test transmissions for
building up signal footprints of all end nodes
Node Profiling for Detection of Replay & IBAs 71
in LoRaWAN using Signal Footprint
• Based on static / mobile behaviour of ED & attacker, the
model is further subdivided into 3 cases for each path loss
model
• In Case 1 & 2, RSSI value is used for node identification
• The Case 3 is handled in exactly same manner as suggested in
original technique through exchange of proprietary

Case End Devices Attacker Applied Technique

1 Static Static Free Space path loss model using Friis
2 Static Mobile equation / Hata model
3 Mobile Mobile / Static Proprietary message
Friis Model Case 1

72
Friis Model Case 2, R1

73
Friis Model Case 2, R2

74
Friis Model Case 2, R3

75
Friis Model Case 2, R4

76
Friis Model Case 2, R5

77
Hata Model Case 1

78
Hata Model Case 2, R1

79
Hata Model Case 2, R2

80
Hata Model Case 2, R3

81
Hata Model Case 2, R4

82
Hata Model Case 2, R5

83
Hata Model Case 1 – Special Case

84
Experimental Analysis & Application 85

• LoRa Node profiling was achieved at Net Serv using RSS in

simulated LoRa environment using two different signal
propagation models
• Using modified technique the Net Server was able to identify Replay
attacks using multi sensor environment
• In few cases were also observed where the attacker node was
successfully able to conduct the replay attack
• Which indicate that this technique can be utilized as first layer to identify a replay
or identity based attack
• Additional measures can also be adopted at various layers in order to ensure
complete security
Conclusion 86

• Research objective was to highlight weakness and

vulnerabilities in LoRaWAN protocol and propose mitigation
strategies
• Employment of RSSI based technique as a first layer of
protection against the threats besides having other counter
measures
• The proposition of the research work is required to be
verified in practical scenarios utilizing actual hardware
environment
References 87

• LoRaWAN Specifications 1.0

• Robert Miller “MWR Labs Whitepaper on LoRa Security and Building a Secure LoRa
Solution” 2015
• LoRaWAN Specifications 1.1
• Xueying Yang, Evgenios Karampatzakis, Christian Doerr and Fernando Kuipers Security
Vulnerabilities in LoRaWAN, Published in 2018 IEEE/ACM Third International
Conference on Internet-of-Things Design and Implementation
• Emekcan Aras, Gowri Sankar Ramachandran, Piers Lawrence and Danny Hughes, KU
Leuven, Belgium, 3rd IEEE Conference on Cybernetics 2017, “Exploring the Security
Vulnerabilities of LoRa”
References 88

• Eef van Es, Harald Vranken, Arjen Hommersom, Open University of the Netherlands,
Heerlen, 13th International Conference on Availability, Reliability and Security 2018,
“The Netherlands “Denial of Service Attack on LoRaWAN”.
• Ismail Butun, Nuno Pereira, Mikael Gidlund, Information Systems and Technology, Mid
Sweden University, Sweden, Security Risk Analysis of LoRaWAN and Future Directions,
MDPI Journal, 21 December 2018
• Stefano Tomasin, Simone Zulian, Lorenzo Vangelista, “Security Analysis of LoRaWAN
Join Procedure for the Internet of Things Networks”, IEEE Wireless Communications
and Networking Conference Workshops, 2017
• Ahmad Raza Cheema, Malek Alsmadi, Salama Ikki, Department of Electrical
Engineering, Faculty of Engineering, Lakehead University, Thunder Bay, Ontario,
Canada, Survey of Identity-based Attacks Detection Techniques in Wireless Networks
Using Received Signal Strength, 2018 IEEE Canadian Conference on Electrical &
Computer Engineering
References 89

• Murat Demirbas, Youngwhan Song, Department of Computer Science and Engineering

Department State University of New York, “An RSSI-based Scheme for Sybil Attack
Detection in Wireless Sensor Networks”
• Yong Sheng, Keren Tan, Guanling Chen, David Kotz, Andrew Campbell, Institute for
Security Technology Studies, Dartmouth College, Department of Computer Science,
University of Massachusetts Lowell, “Detecting 802.11 MAC Layer Spoofing Using
Received Signal Strength”
• Daniel B. Faria, Computer Science Department, David R. Cheriton, Computer Science
Department, Stanford University, “Detecting Identity Based Attacks in Wireless
Networks Using Signal Prints”
• Woo-Jin Sung, Hyeong-Geun Ahn, Jong-Beom Kim, Seong-Gon Choi, Information &
Communication Engineering, ChungBuk National University, Cheongju-si
Chungcheongbuk-do, Korea, Protecting End-Device from Replay Attack on LoRaWAN,
International Conference on Advanced Communications Technology, 2018
 90
Thankyou
Questions
91
 LoRa Network Architecture 92

• Gateways are dumb bi-

directional relays that
communicate with Network
Server

• Network Server responsible for

encoding / decoding of packets
 Chirp Spread Spectrum 93

• Linear increase / decrease

in frequency with time
• Chirp Rate = Programmed
bandwidth chirp-per-
second-per-Hz
Spreading Factor 94

• Variable depending upon

• Communication distance

• Desired on-air time

• SF = Logarithm in base 2 of the number of chirps per symbol

• i.e, if we are using

• 27 Chirps / symbol for encoding of information

• Then SF used would be Log 2 of 27 i.e SF = 7

 96

Key Derivation with OptNeg bit unset LoRa V1.

 97

Key Derivation with OptNeg bit set LoRa V1.1

 LoRaWAN 1.1 Re-Join Requests 98

• Ensuring Key update and freshness to avoid Replay attacks

• Especially useful in roaming scenarios
• Opportunity to establish new session context periodically
• Immediate incident response option available
Re-join
Req Type Content purpose

Used to reset a device context including all radio parameters (devAddr, session keys, frame
0
counters, radio parameters)
Equivalent to the initial Join-Request message. Used to restore a lost session context (Example,
1
Network Server has lost the session keys and cannot associate the device to a JoinServer)
Used to rekey a device or change its DevAddr (DevAddr, session keys, frame counters). Radio
2
parameters are kept unchanged, can only be transmitted following a ForceRejoinReq MAC command
LoRaWAN 1.1 Re-Join Request Type – 0, 2 99

• MIC for Rejoin-request message Type 0 or 2 is calculated as follows

cmac = AES128_cmac( SNwkSIntKey, MHDR | Rejoin |Type |
NetID | DevEUI | RJcount0 )
MIC = cmac[0..3]
• RJcount0 is initialized to 0 each time a Join-Accept is successfully
processed by the end-Device and incremented with every Type 0 or 2
Rejoin frame transmitted
• For each end-device, the Network Server MUST keep track of the last
RJcount0 value (called RJcount0_last) used by the end-device
• Ignores Rejoin-requests if (Rjcount0 <= RJcount0_last)
LoRaWAN 1.1 Re-Join Request Type – 1 100

• MIC for Rejoin-request message Type 1 is calculated as follows

cmac = AES128_cmac( JSIntKey, MHDR | RejoinType | JoinEUI|

DevEUI | RJcount1 )

MIC = cmac[0..3]
• The Network Server may or may not respond with the Join Accept
message
LoRa 1.1 Encrypt for MAC Commands in FOpts 101

• MAC commands can either be present in FOpts field or as Frame Payload

• FPort is other then 0 & pld = FOpts
• Encryption of FOpts is carried out before MIC calculation
• For each message, the algorithm defines a single Block A
1 4 1 4 4 1 1
A
0x 01 4 x 0x00 Dir = 0 for Uplink 1 for Downlink Dev Addr FCntUp Or NFCnt Dwn 0x00 0x00

• The block A is encrypted to get a block S:

S = AES128_Encrypt (K,A)
K = NwkSEncK (Network Session Encryption Key both for Uplink & Down Link)
• Encrypt / Dcrypt of FOpts is done by truncating (pld | pad16) XOR S to the first
len(pld) octets
 LoRa 1.1 Encryption for Frame Payload 102

• Key K is a function of FPort value for both Uplink & Downlink frames
If FPort = 0 then K = NwkSEncKey Contains MAC commands only as payload

If FPort = 1…224 then K = AppSKey Contains Application data

pld = Frame Payload  0 … N

N = N < M – 1 – (Len of FHDR in Octets) Depends on regional regulations

M = Maximum MAC Payload length

 LoRa 1.1 Encryption for Frame Payload 103

• The algorithm defines a sequence of Blocks Ai

1 4 1 4 4 1 1
A Dir = 0 for Uplink F CntUp or NFCntDwn
0 x 01 4 x 0 x 00 Dev Addr 0 x 00 i
Dir = 1 for Downlink or AFCntDwn

for i = 1…...k
with k = ceil ( len (pld) / 16)
The blocks Ai are encrypted to get a sequence S of blocks Si:
Si = AES 128_encrypt (K, Ai)
S = S1 | S2 | ….. | Sk
• Encrypt / Decrypt by truncating (pld | pad16) XOR S to the first length (pld)
octets
 LoRa 1.1 MIC Calculation for Frame Payload 104

• Message Integrity Code is calculated as follow

msg = MHDR | MAC PAYLOAD ( FHDR | F Port | FRM PLD) |
len (msg) = Length of message in octets
• For Downlink Frame
CMAC = AES 128_cmac (SNwkSIntKey, Bo | msg)
MIC = cmac [ 0 .. 3 ]
1 2 2 1 4 4 1 1
Bo
0x 49 ConfFCnt 2 x 0x00 Dir = 0 x 01 Dev Addr AFCnt Dwn or NFCnt Dwn 0x00 Len(msg)
If Network Server supports Lora 1.1 & ACK bit of Downlink Frame is set i.e this
msg is ACK of last uplink confirmed frame then
ConfFCnt = | FCnt | mod 216 else Conf FCnt = 0 x 0000
 LoRa 1.1 MIC Calculation 105

• For MIC of Uplink Frames, LoRaWAN 1.1 defines two blocks Bo & B1
1 4 1 4 4 1 1
Bo
0x 49 0x0000 Dir = 0x00 Dev Addr FCnt Up 0x00 Len (msg)
1 2 1 1 1 4 4 1 1
B1
0x 49 ConfFCnt TxDr TxCh Dir = 0x00 Dev Addr FCnt Up 0x00 Len(msg)
TxDr = D/rate for Trx & TxCh = Channel Index for Trx
If Net Srvr is Lora 1.1 & ACK bit of D/link Frame = 1 (ACK of last Uplink confirmed frame)
ConfFCnt = | FCnt | mod 216 else Conf FCnt = 0 x 0000
CMAC S = AES 128_cmac (SNwkSIntKey, B1 | msg)
CMAC F = AES 128_cmac (FNwkSIntKey, Bo | msg)
MIC = cmac S [0..1] | cmac F [0..1]
If the device is connected to a LoRaWAN 1.0 Net Srvr then MIC = cmac F [0..3]
Replay Attack through Selective Jamming JRs 106

• Transmission of a Join-request from a legitimate ED

• Join−request#1 with DevNonce #1 is jammed

• Join − request # 1 is also captured at the same time

• After timeout to receive the Join-accept

• ED retries to join the network and sends another Join-request

• Join_request # 2 with a new DevNonce value (DevNonce # 2)

• The attacker jams this message too

Replay Attack through Selective Jamming JRs 107

• The attacker replays the previously saved Join_request

• Join − request # 1 message

• By checking the value of DevNonce (DevNonce#1)

• NS would accept the join_request, as this value has not been used
before (Jammed by attacker)

• The NS,JS & ED are de-synchronized in terms of session keys derived as

being independently generated by the ED and JS using the DevNonce

• Difficult to launch in multiple gateway environment

Selective Jamming Vice Versa 108

• Same technique can be employed to Jam Join accept messages by the

Network Server leading to blocking of End device after maximum
allowable retries, since the communication of the messages is limited
(max 14 packets per day)
• This problem has been solved in LoRaWAN 1.1 by storing the value of
last used Join Nonce in end device
• JA message is only accepted if the value is strictly incremented by one
• Also difficult for the attacker with the existence of several receive
paths for the NS packets to the ED through multiple gateways
Identity Based Attacks 109

• In a large-scale constrained-environment wireless

network, adversaries can launch the Identity-based
attacks by forging identities of one or more legitimate
devices in the network
• Popular variants of identity based attacks are
• Spoofing attack : One or more malicious devices can imitate
identity of a legitimate device
• Sybil attack : A malicious device (sybil node) that spoofs
multiple identities in a network at the same time
Identity Based Attacks 110

• Aims to inject malicious traffic to affect the normal

operation of the network
• The identity-based attacks can facilitate in mounting several
other attacks
• Data Falsification
• Injection attack
• Man-In-The-Middle (MITM) attack
• Rouge Base Station or Access Point
• Session Hijacking attack
• Various types of Denial-of-Service (DoS) attacks
 Third Party Counter Arrangements 111

• Employment of trusted third party and PKI infrastructure to in order to

ensure integrity between NS and Application Server
• Root Key update: Latest session keys can act as new keys for subsequent
use
• The application level MIC can be incorporated using separate key
Received Signal Strength Indicator 112

• RSSI is a term used to measure the relative quality of a received signal

to a client device, but has no absolute value
• RSS or RSS Indicator (RSSI) values are readily available in nearly every
wireless system without additional hardware or system modifications
• Utilized for essential radio functions such as clear channel assessment,
link quality estimation, handover, and resource management