Experiment on Side-Channel Key-Recovery

using a Real LPWA End-device

Kazuhide Fukushima

, Damien Marion

, Yuto Nakano

, Adrien Facon

, Shinsaku Kiyomoto

and Sylvain Guilley

KDDI Research, Inc., 2-1-15 Ohara, Fujimino, Saitama 356-8502, Japan

Secure-IC S.A.S., 80 avenue des Buttes de Co

esmes Rennes, 35700, France

Keywords:

Internet of Things (IoT), Low-Power Wide-Area (LPWA), LoRaWAN, Side-channel Analysis, Correlation

Power Analysis (CPA), Electromagnetic(EM)-leakage, AES.

Abstract:

The Internet of things (IoT) has come into widespread use, and data protection and integrity are critical for

connected IoT devices in order to maintain security and privacy. Low-power wide-area (LPWA) technologies

for IoT wireless communication achieve data protection and integrity by using encryption and message authen-

tication. However, side-channel analysis techniques exist that have the capacity to recover secret information

from a device. In this paper, we apply a side-channel analysis technique to the payload encryption process and

message authentication code generation process on a real LoRaWAN end-device. The entire AES-128 key for

the payload encryption can be recovered with 260 electromagnetic(EM)-leakage traces and 12 bytes of the key

for message authentication code generation can be recovered with 140 EM-leakage traces.

1 INTRODUCTION

The Internet of things (IoT) has been in widespread

use for several years. IHS Markit (Howell, 2017)

estimated that the number of IoT devices connected

to the Internet is nearly 27 billion as of 2017, which

will surge to 125 billion by 2030. IoT in the automo-

bile and industry ﬁelds has attracted attention due to

the projected growth rate. Moreover, Cisco (Bradley

et al., 2013) has estimated there were 1.5 trillion IoT

devices globally as of 2013, but 99.4% of these devi-

ces are still unconnected. This fact highlights the vast

potential value of IoT.

Low-power wide-area (LPWA) is a term used to-

describe communication technologies for IoT. These

technologies are characterized by low power con-

sumption, wide area coverage, and low cost. LPWA

technologies can be roughly categorized into the li-

censed and unlicensed spectrum. LoRaWAN (LoRa

Alliance

, 2017) and Sigfox (Sigfox, 2017) are ty-

pical examples protocols that run in the unlicensed

spectrum, meaning that a license is not needed to

build a network and provide services. LoRaWAN and

LoRa are open standards developed by the LoRa Alli-

ance. LoRaWAN deﬁnes the communication protocol

and system architecture in the medium access control

layer for the network while LoRa deﬁnes the physi-

cal layer or wireless modulation that enables long-

range communication links. A LoRaWAN network

can be built by buying equipment similar to wireless

LAN. Conversely, only one company in each coun-

try can build a Sigfox network according to the po-

licy of the French Sigfox company. LTE-M (GSMA,

2017) and NB-IoT (3GPP, 2016) operate over licen-

sed spectrum, and mobile operators build a network

and provide services. Their advantage is that existing

LTE base stations can be used to build a new LPWA

network.

Data protection and integrity are critical for con-

nected IoT. For example, user privacy is compromi-

sed by location information and activity information

acquired from a wearable device. As another moti-

vating example, an air conditioner can be manipula-

ted maliciously by modifying the value of the tem-

perature sensor, which can lead to panic in crowded

places, with possible fatalities. LPWA technologies

achieve data protection and integrity by using encryp-

tion and message authentication. However, many at-

tacks against the vulnerabilities of LPWA protocols

have been proposed, and some of them are poten-

tial threats as they can extract the secret keys. Furt-

hermore, side-channel analysis technologies exist that

have the capacity to recover secret information from

devices by using side-channel information including

Fukushima, K., Marion, D., Nakano, Y., Facon, A., Kiyomoto, S. and Guilley, S.

Experiment on Side-Channel Key-Recovery using a Real LPWA End-device.

DOI: 10.5220/0007259500670074

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 67-74

ISBN: 978-989-758-359-9

timing information, power consumption, electromag-

netic leaks, sound, and heat.

Our Contributions. We apply a side-channel ana-

lysis technique to the payload encryption process and

message authentication code generation process for

data transmission on a real LoRaWAN end-device.

The entire AES-128 key for the payload encryp-

tion can be recovered with 350 electromagnetic(EM)-

leakage traces. The required number of traces can

be reduced to 260 using a band-pass ﬁltering techni-

que. To the best of our knowledge, this is the ﬁrst

paper that describes extracting secret keys from a real

LPWA device with less than 300 EM-leakage traces.

Furthermore, the AES-128 key, except for the ﬁrst

four bytes for message authentication code genera-

tion, can be recovered with 140 EM-leakage traces

and the remaining four bytes by a brute force search

with 2

computational complexity to recover the en-

tire key.

2 RELATED WORK

Many studies have pointed out security issues, and at-

tacks against LPWA protocols and have proposed so-

lutions to improve security against such attacks. Most

of them target the LoRaWAN protocol since it is an

open technology and the speciﬁcation is publicly avai-

lable. Girard (Girard, 2015) pointed out the issues

in key provisioning for end-devices. Zulian (Zulian,

2016) and Tomasin et al. (Tomasin et al., 2017) de-

monstrated the possibility of a replay attack against

the join procedure in LoRaWAN due to the limitation

in the variety of the DevNonce generated by an end-

device, and theoretically and experimentally showed

that random number generators in a real end-device

are not secure. Na et al. (Na et al., 2017) argued

that LoRaWAN was vulnerable to a similar replay at-

tack and described countermeasures. Lee et al. (Lee

et al., 2017) proposed a bit-ﬂipping attack against an

encrypted frame payload using AES-CTR and a coun-

termeasure. Yang et al. (Yang et al., 2018) discovered

several vulnerabilities of LoRaWAN and demonstra-

ted ﬁve attacks: 1) replay attack leads to a selective

DoS attack, 2) plaintext recovery attack, 3) malici-

ous message modiﬁcation, 4) falsiﬁcation of delivery

reports, and 5) battery exhaustion attack. Aras et

al. (Aras et al., 2017) proposed a selective jamming

attack against the LoRa physical layer and its coun-

termeasure. Butun et al. (Butun et al., 2018) demon-

strated ﬁve attacks: 1) RF jamming attack, 2) replay

attack, 3) Beacon (Class B) synchronization attack,

4) network trafﬁc analysis and 5) man-in-the-middle

(MITM) attack against the latest version: LoRaWAN

speciﬁcation v1.1 released on Oct 11, 2017.

Side-channel analysis technologies to recover se-

crets are based on side-channel information such as

sound, heat, timing information, power consumption,

and electromagnetic-leakage. Some existing studies

target IoT or resource-constrained devices. Kocher

et al. (Kocher et al., 1999) were the ﬁrst to propose

a side-channel attack that leveraged a device’s po-

wer consumption on a device and demonstrated that

a DES key can be recover using the attack. Their at-

tack includes a simple power analysis (SPA), diffe-

rential power analysis (DPA), and higher-order DPA

(HO-DPA). Messerges et al. (Messerges et al., 1999)

theoretically derived the signal-to-noise ratio (SNR)

in a DPA attack against DES proposed by Kocher et

al. They improved the DPA to d-bit DPA by focu-

sing on multiple bits in the S-Box of DES. Joye and

Tymen (Joye and Tymen, 2001) proposed a DPA at-

tack against the scalar multiplication on an elliptic

curve-based cryptosystem (ECC), and Itoh et al. (Itoh

et al., 2003) proposed a DPA attack focusing on the

2004) were the ﬁrst to study a correlation power ana-

lysis (CPA) based on a Hamming distance model.

Komano (Komano et al., 2009) proposed a build-

in determined sub-key CPA (BS-CPA) that ﬁnds a

new sub-key by using the previously determined sub-

keys recursively and demonstrated that it can recover

a DES key with fewer power traces than the origi-

nal CPA. Clavier et al. (Clavier et al., 2011) applied

a CPA to ﬁrst-order protected AES implementations

and showed that the CPA requires fewer power traces

than classical second-order DPA. Dinu and Kizhva-

tov (Dinu and Kizhvatov, 2018) demonstrated that a

DPA can recover a partial AES-CCM key on a wi-

reless microcontroller. Tawalbeh and Somani (Tawal-

beh and Somani, 2016) evaluated the security of AES,

ECC, and RSA against timing and fault side-channel

attacks and showed countermeasures for IoT imple-

mentation. Moukarzel et al. (Moukarzel et al., 2017)

proposed μLeech, a side-channel evaluation platform

for IoT.

3 LoRaWAN PROTOCOL

We provide an overview of the LoRaWAN protocol.

The end-device activation to a set AES-128 key for

an end-device is described in Sect. 3.1, and data pro-

tection and integrity with AES-128 are described in

Sect. 3.2.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

3.1 End-device Activation

We have to personalize and activate the end-devices

to connect them to a LoRaWAN network. There are

two activation methods for an end-device: over-the-

air activation (OTAA) and activation by personaliza-

tion (ABP).

Over-the-Air Activation. In OTAA, an end-device

must complete a join procedure to be able to make

data exchanges with the network server. The join

procedure requires the end-device to be personali-

zed with a globally unique end-device identiﬁer (De-

vEUI), an application identiﬁer (AppEUI), and an

AES-128 key (AppKey).

Activation by Personalization. End-devices can be

activated by personalization (ABP). ABP directly as-

sociates an end-device to a LoRaWAN network wit-

hout having to use the join procedure needed in

OTAA.

Two session keys: NwkSKey and AppSKey, and

DevAddr are stored in the end-device directly in ABP,

while these keys are derived using the DevEUI, Ap-

pEUI, and AppKey in OTAA. The required informa-

tion is preset to the end-device to connect a LoRa-

WAN network. Each end-device has a unique set of

NwkSKey and AppSKey.

3.2 Data Protection and Integrity

Payload encryption using AES counter mode (AES-

CTR) provides data protection of the frame payload

for transmissions in the LoRaWAN protocol. AES-

CMAC is used to generate a four-byte message inte-

grity code (MIC) to maintain data integrity in payload

transmissions and the OTAA procedure.

Data Protection. FRMPayload is encrypted before

the MIC is calculated. The encryption key K de-

pends on the FPort of the data message: If Fport

is 0, then NwkSKey is used, and if Fport is in the

range of 1, 2, . . . , 255, then AppSKey is used. The

encryption algorithm deﬁnes a sequence of blocks

. A block A

contains one-byte 0x01, followed

by four-bytes 0x00000000, one-byte direction ﬁeld

(Dir), four-byte identiﬁer (DevAddr), four-byte FCn-

tUp or FCntDown, one-byte 0x00, and one-byte en-

coded i, or

= 0x01k0x00000000kDirkDevAddrkFCntUp or

FCntDownk0x00kencode(i).

Dir describes the direction ﬁeld: 0 for uplink frames

and 1 for downlink frames. The DevAddr identiﬁes

Algorithm 1: Payload Encryption in LoRaWAN

Protocol.

Input: FramePayload, Encryption key K

Output: EncrypredPayload

1 pld ← FRMPayload;

2 k ← dlen(pld)/16e;

3 for i ← 1 to k do

4 S

← AES-128(K, A

);

5 end

6 S ← S

k...kS

;

7 T ← (pldkpad

) ⊕ S;

8 EncryptedPayload ← First len(pld) bytes of

T ;

/* Data protection using AES-CTR */

9 return EncryptedPayload;

the end-device in the current network. The frame

counter FCntUp, incremented by end-devices, records

the number of uplinks to the network server and FCnt-

Down, incremented by the server, records the num-

ber of downlink frames from the server. Algorithm 1

shows the procedure of the payload encryption in de-

tail. Note that the pad

is a function that adds zero

bytes so that the data length is a multiple of 16, and

len returns the byte length of the data.

Data Integrity. All LoRa messages carry a PHY

payload (Payload) consisting of one-byte MAC hea-

der (MHDR), a MAC payload (MACPayload), and a

four-byte MIC. The MAC payload of the data messa-

ges starts with a frame header (FHDR) followed by

an optional port ﬁeld (FPort) and ends with an opti-

onal frame payload ﬁeld (FRMPayload). The FHDR

consists of the address of the end-device (DevAddr),

a frame control byte (FCtrl), a frame counter (FCnt),

and frame options (FOpts) to transport MAC com-

mands. The MIC for payload calculated on the entire

message is deﬁned as

msg = MHDRkFHDRkFPortkEncryptedPayload.

The block B

for the MIC calculation contains one-

byte 0x49, followed by four-bytes 0x00000000, one-

byte direction ﬁeld (Dir), four-byte identiﬁer (De-

vAddr), four-byte FCntUp or FCntDown, one-byte

0x00, and one-byte len(msg), or

= 0x49k0x00000000kDirkDevAddrkFCntUp or

FCntDownk0x00klen(msg).

The MIC is calculated as

MIC = AES-CMAC(NwkSKey,B

kmsg)[0...3].

The join procedure in OTAA is started from an

end-device by sending a join-request message. The

Experiment on Side-Channel Key-Recovery using a Real LPWA End-device

join-request message contains AppEUI, DevEUI of

the end-device, and a nonce of two bytes (DevNonce),

join-request msg = AppEUIkDevEUIkDevNonce

AppEUI and DevEUI are a globally unique applica-

tion ID of an end-device and an end-device ID in the

IEEE EUI64 address space, respectively. DevNonce

is a random value. The network server needs to keep

the list of used DevNonce values for each end-device

and ignores join requests with re-used DevNonce va-

lues to prevent replay attacks. The MIC for the join

request in OTAA is calculated as

MIC = AES-CMAC(AppKey,MHDRk

join-request msg)[0...3].

4 KEY RECOVERY ATTACK

We propose a key recovery attack based on side-

channel analysis, which applies to general LoRaWAN

end-devices. The goal and assumptions are explained,

and then the details of the attack are described.

4.1 Goal

The security of the LoRaWAN protocol is based on

Advanced Encryption System (AES), a symmetric en-

cryption algorithm. Data protection is ensured using

AES-CTR, and message integrity is guaranteed by

the computing of a MIC using AES-CMAC. Our key

recovery attack thus targets AES-128 keys: App-

SKey, NwkSKey, AppKey, stored in an end-device.

AppSKey and NwkSkey are used to achieve data

protection, and NwkSKey and AppKey are used to

achieve integrity for data transmission and join mes-

sages, respectively. An attacker can decrypt or forge

all messages and commands transmitted between the

server and end-devices, or connect malicious end-

devices to the LoRaWAN network by abusing these

keys.

4.2 Assumptions

We assume an attacker as a security evaluator can

access plaintext. The attacker does not have to con-

trol the plaintext and the corresponding ciphertext.

This condition can be met if the attacker knows the

data format and the data itself. For example, an end-

device transmits recently measured temperatures peri-

odically, and the attacker can guess the plaintext using

a separate thermometer. Another way to meet the con-

dition is to access an API for data transmission on an

end-device. Some LoRaWAN libraries provide public

APIs for data transmission that take plaintext messa-

ges or commands as input. Our side-channel key re-

covery attack is based on correlation power analysis

that requires multiple pairs of plaintext and ciphertext.

The attack is not applicable to ﬁxed messages such as

preﬁxed values in a protocol header since the Pear-

son correlation coefﬁcient cannot be calculated. Ho-

wever, we can recover the keys and all the messages

from the limited number of partial plaintext. In our

experiments, we modify the source code of an end-

device to set a trigger signal around the ﬁrst round of

AES-128. However, modiﬁcation of the source code

is not necessary if different EM-leakage traces can be

appropriately aligned along the time axis.

The proposed attack is focused on the ﬁrst round

of AES-128, using the knowledge of the plaintext

and guessing each byte of the AES-128 key indepen-

dently. Guessing each byte of the ﬁrst round key per-

mits each byte of the output of the S-box to be recove-

red independently at the ﬁrst round. The ﬁrst round of

AES-128 consists of four functions: AddRoundKey,

SubByte, ShiftRow and MixColumn.

4.3 Key Recovery Attack

We now describe the key recovery attacks in detail.

Our proposed attack consists of a leakage identiﬁca-

tion phase and key recovery phase.

4.3.1 Leakage Identiﬁcation

The ﬁrst phase of the attack is the identiﬁcation of

the EM-leakage traces produced by the execution of

AES-128. The EM-leakage of one hundred executi-

ons with the same key and plaintext have been avera-

ged. This permits an increase in the signal-to-noise

ratio (SNR) deﬁned as

SNR =

AES-128

Noise

where P

AES-128

and P

Noise

are respectively the power

of AES-128 leakage and the noise. The noise P

Noise

considered to follow a Gaussian distribution N(µ,σ

which explains the increase in the SNR by averaging.

The result of this recording is displayed in Fig. 1. This

graph permits identify the ten rounds of AES-128 to

be identiﬁed and we can manually delimit each round.

This delimitation revealed a repetition of four events

in each round (identiﬁed by four peaks) and corre-

sponds to AddRoundKey, SubByte, ShiftRow and Mix-

Column. The x-axis represents time in terms of the

number of samples, and the y-axis represents the elec-

tromagnetic range in volts.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

Figure 1: EM-leakage of hundred AES-128 executions.

Algorithm 2: Key Recovery Attack.

Input: Plaintext P

(0 ≤ i < Q)

Output: Guessed key k

1 for i ← 0 to Q − 1 do

2 for d ← 0 to D − 1 do

3 X

d,i

← EM-leakage of

AES-128(∗,P

);

4 end

5 end

6 for i ← 0 to Q − 1 do

7 for B ← 0 to 16 − 1 do

8 for k ← 0 to 256 − 1 do

9 Y

i,k

[B] ←

HW(SubByte(P

[B] ⊕ k));

10 end

11 end

12 end

13 for d ← 0 to D − 1 do

14 for B ← 0 to 16 − 1 do

15 for k ← 0 to 256 − 1 do

16 r

k,d

[B] ← ρ(Y

[B],X

);

17 end

18 end

19 end

20 for B ← 0 to 16 − 1 do

21 k

[B] ← arg max

0≤k<256



max

0≤d<D

k,d

[B]}



;

22 end

23 return k

;

4.3.2 Key Recovery

The second phase of the attack recovers the AES-key

based on analysis of the EM-leakage traces. The key

recovery attack uses correlation power analysis (Brier

et al., 2004) focused on the output of the SubByte

function in the ﬁrst round. The leakage model app-

lied is the Hamming weight (HW), which is justiﬁed

by the fact that it is a software implementation. The

following steps describe the procedure to compute the

correlation between the EM-leakage and Hamming

weight:

1. Record the EM-leakages during AES-128 encryp-

tion AES-128(∗,P

) and store them to X

d,i

, where

∗ is the unknown AES-128 key, P

is the plaintext

in ith trace, and X

d,i

(0 ≤ d < D and 0 ≤ i < Q) is

the d-th sample in the i-th trace out of Q traces of

D samples.

2. Compute the 16-guessed distributions (one by key

byte):

i,k

[B] = HW(SubByte(P

[B] ⊕ k))

for 0 ≤ k < 256, 0 ≤ i < Q, and 0 ≤ b < 16 where

[B] is the B-th byte of P

, k is the guessed value

of the key byte, and Y

i,k

[B] is a 16 × 256 distribu-

tions of Q elements.

3. Compare X

d,i

and all the 16 × 256 distribution

i,k

[B] using the Pearson correlation coefﬁcient:

r(k,d)[B]

= ρ(X

[B]) =

Cov(X

[B])

Var(X

)Var(Y

[B])

∑

Q−1

i=0

d,i

−

)(Y

i,k

[B] −

[B])

∑

Q−1

i=0

d,i

−

)

∑

Q−1

i=0

i,k

[B] −

[B])

(1)

where

Q−1

∑

i=0

d,i

and

[B] =

Q−1

∑

i=0

i,k

[B].

for 0 ≤ d < D, 0 ≤ b < 16, and 0 ≤ k < 256 .

Algorithm 2 describes all the steps involved in the

key recovery attack. The required number of traces

to recover B-th byte of the key N[B] is deﬁned as the

minimum q such that guessed key byte k

[B] using q

traces is identical to that using q traces for all q

> q.

5 EXPERIMENTAL RESULTS

We describe the experimental result of our key reco-

very attack against a real LoRaWAN end-device. The

experiment setup is sketched in Sect. 5.1 and results

of a key recovery attack on the payload encryption

key and MIC calculation key are shown in Sect. 5.2.

Section 5.3 demonstrates a technique to reduce the

number of EM-leakage traces to recover keys.

5.1 Experiment Setup

Our experiment used a LoRa Starter Kit. This starter

kit is composed of two end-devices: an end-device

with a plug-and-play LoRa module and an 868 MHz

Experiment on Side-Channel Key-Recovery using a Real LPWA End-device

Figure 2: Identiﬁcations of the payload encryption and MIC computation.

antenna, and a gateway equipped with a LoRa module

and an 868 MHz antenna. We used an API supplied

by the end-device for our experiment to access to an

implementation of AES-128. The source code of the

program provided by the starter kit was modiﬁed to

add a trigger signal at the ﬁrst round of the AES.

5.2 Key Recovery

In our experiment, we targeted AppSKey for payload

encryption and NwkSKey for MIC generation in the

data transmission phase. The EM-leakage traces were

recorded according to the following process.

1. The gateway generates a random plaintext P and

send it to an end-device.

2. The end-device encrypts P using AppSKey and

makes a ciphertext C.

3. The EM-probe gets the leakage information on

AppSKey, and the oscilloscope records the infor-

mation.

4. The end-device generates MIC for the payload

containing C.

5. The EM-probe gets the leakage information on

NwkSKey, and the oscilloscope records the infor-

mation.

6. The end-device send a frame including C and MIC

to the gateway.

7. Goto step 1 until a sufﬁcient number of traces is

captured.

In a key recovery attack, it is necessary to iden-

tify the distinct encryption phases in the EM-leakage

traces to bring out the ﬁrst round of AES-128 for the

payload encryption or MIC computation. We can ﬁnd

patterns in the EM-leakage traces. Figure 3 show the

measurement of the EM-leakage from a LoRaWAN

end-device.

We can identify two distinct parts; the ﬁrst part

corresponds to the encryption of the application pay-

load and the second part to the MIC computation. Fi-

gure 2 shows 20 similar patterns in the signal part

Figure 3: EM-leakage measurement from a end-device.

identiﬁed as the application payload encryption. The

application payload is composed of 32 bytes, and

AES-128 with ten rounds is executed twice; thus,

20 similar patterns appear. The same pattern can be

identiﬁed three times in a row within the second part

identiﬁed as the MIC computation. The MIC com-

putation for 40-byte data executes AES-128 three ti-

mes. Furthermore, inside each AES-128, the same

pattern could be identiﬁed ten times corresponding to

the number of rounds in a unique AES-128.

The key recovery attack is applied to the ﬁrst

round of AES-128. Figure 4 shows the result of the at-

tack against the payload encryption process and plots

[0] with the highest correlation. These values with

the highest correlation are identical to bytes of the

AES-128 key, or k

[B] = K[B] for all B. That is, the

key recovery attack reveals all bytes of the key. In

the sixteen traces of correlation, two peaks with an

amplitude around 0.4 are identiﬁable. It suggests that

the intermediate value {SubByte(P[B]⊕ k

[B])} (0 ≤

B < 16) is manipulated at least twice. The en-

tire AES-128 key for the payload encryption key can

be recovered with 350 electromagnetic (EM)-leakage

traces. Table 1 shows the number of required traces

N[B] to recover each key-byte. On the other hand, 12

bytes of the AES-128 key for the MIC calculation can

be recovered with 140 EM-leakage traces; however,

the four bytes from the second byte to the ﬁfth byte of

the key never converge in the key recovery algorithm.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

Table 1: Required number of traces to recover the key.

Byte (b) Raw De-noised Improvement

0 140 90 -36%

1 220 130 -41%

2 200 80 -60%

3 310 120 -61%

4 130 70 -46%

5 200 260 +30%

6 150 110 -27%

7 260 110 -58%

8 230 210 -9%

9 320 180 -44%

10 350 130 -63%

11 230 200 -13%

12 180 200 +11%

13 80 80 ± 0%

14 300 90 -70%

15 210 260 +23%

Maximum 350 260 -26%

Figure 4: Correlation between the EM-leakage and Ham-

ming weight for k

[0] .

The four bytes of the input to the ﬁrst execution of

AES-128 for the MIC calculation are DevAddr and

constant. The variances of {Y

i,k

[B]} thus vanish for

0 ≤ B < 4, and we cannot compute the Pearson cor-

relation coefﬁcient in Eq. (1). One way to recover the

four bytes is to use a brute force search with 2

com-

putational complexity. Alternatively, another leakage

model, such as leakage during the computation of the

MixColumn function, could be used .

Figure 5: Spectrogram of an EM-leakage trace highlighting

the activity of the microprocessor around 14-15 MHz.

Figure 6: Band-pass ﬁltered trace between 13 and 16 MHz

in green and raw trace in blue.

5.3 Reduction of Required Traces

Uncorrelated noise produced by non-cryptographic

circuits may increase the required number of EM-

leakage traces. The targeted end-device has a fre-

quency of 14 MHz. By computing the spectrogram

of the recorded EM-leakage around this frequency,

we obtain Fig. 5 where the colors gradient indicates

the signal amplitude as a function of the time (x-axis)

and of frequency (y-axis). This spectrogram shows

activity around 14 to 15 MHz, which corresponds to

the activity of the targeted microprocessor. We can

thus apply a software band-pass ﬁlter between 13 and

16 MHz to remove low and high-frequency noise and

improve the signal-to-noise ratio. Figure 6 illustrates

the effect of the de-noising process, and a raw trace

is plotted in blue and the associated de-noised trace

in green. Furthermore, the de-noising procedure also

facilitates visual analysis and sub-function separation

that is both instrumental and suitable the side-channel

analysis.

The application of band-pass ﬁltering on the raw

traces used in Sect. 5.2 improves the efﬁciency of the

key recovery attack. We summarized the number of

required traces N[B] to recover each key-byte in Ta-

ble 1 to compare both results. The column “impro-

vement” shows the difference (as a percentage) bet-

ween the number of traces required to recover each

key byte with the raw traces and the de-noised trace.

The ﬁltering reduces the number of traces required to

achieve the entire key by about 26%.

6 CONCLUSION

We applied a correlation power analysis to a real Lo-

RaWAN end-device to recover secret keys used for

the payload encryption process and message authen-

tication code generation. The entire payload encryp-

tion key can be recovered with 350 EM-leakage tra-

ces, and 12 bytes out of the MIC calculation key can

be recovered with 140 EM-leakage traces. The MIC

Experiment on Side-Channel Key-Recovery using a Real LPWA End-device

calculation key can be completely recovered with 2

computational complexity by specifying the remai-

ning four bytes by a brute force search. Furthermore,

we improved the efﬁciency of the key recovery attack

by reducing the number of traces required to recover

keys by 26% using a noise ﬁltering technique. In our

future work, we will try to recover the entire key for

the MIC calculation by focusing on an AES-128 le-

akage during computation of the MixColumn function.

REFERENCES

3GPP (2016). Standardization of NB-IOT completed.

Aras, E., Small, N., Ramachandran, G. S., Delbruel, S., Joo-

sen, W., and Hughes, D. (2017). Selective Jamming of

LoRaWAN using Commodity Hardware.

Bradley, J., Barbier, J., and Handler, D. (2013). Embracing

the Internet of Everything To Capture Your Share of

$14.4 Trillion .

Brier, E., Clavier, C., and Olivier, F. (2004). Correla-

tion Power Analysis with a Leakage Model. In Joye,

M. and Quisquater, J.-J., editors, Cryptographic Har-

dware and Embedded Systems - CHES 2004, volume

3156 of Lecture Notes in Computer Science book se-

ries (LNCS), pages 16–29, Berlin, Heidelberg. Sprin-

ger Berlin Heidelberg.

Butun, I., Pereira, N., and Gidlund, M. (2018). Analysis

of LoRaWAN V1.1 Security: Research Paper. In Pro-

ceedings of the 4th ACM MobiHoc Workshop on Expe-

riences with the Design and Implementation of Smart

Objects, SMARTOBJECTS ’18, pages 5:1–5:6, New

York, NY, USA. ACM.

Clavier, C., Feix, B., Gagnerot, G., Roussellet, M., and Ver-

neuil, V. (2011). Improved Collision-Correlation Po-

wer Analysis on First Order Protected AES. In Pre-

neel, B. and Takagi, T., editors, Cryptographic Har-

dware and Embedded Systems – CHES 2011, volume

6917 of Lecture Notes in Computer Science book se-

ries (LNCS), pages 49–62, Berlin, Heidelberg. Sprin-

ger Berlin Heidelberg.

Dinu, D. and Kizhvatov, I. (2018). EM Analysis in the IoT

Context: Lessons Learned from an Attack on Thread.

Cryptology ePrint Archive, Report 2018/076.

Girard, P. (2015). Low Power Wide Area Networks Secu-

rity.

GSMA (2017). Long Term Evolution for Machines: LTE-

Howell, J. (2017). Number of Connected IoT Devices Will

Surge to 125 Billion by 2030, IHS Markit Says.

Itoh, K., Izu, T., and Takenaka, M. (2003). Address-Bit Dif-

ferential Power Analysis of Cryptographic Schemes

OK-ECDH and OK-ECDSA. In Kaliski, B. S., Koc¸,

c¸. K., and Paar, C., editors, Cryptographic Hardware

and Embedded Systems - CHES 2002, volume 2523

of Lecture Notes in Computer Science book series

(LNCS), pages 129–143, Berlin, Heidelberg. Springer

Berlin Heidelberg.

Joye, M. and Tymen, C. (2001). Protections against Dif-

ferential Analysis for Elliptic Curve Cryptography —

An Algebraic Approach —. In Koc¸, C¸ . K., Naccache,

D., and Paar, C., editors, Cryptographic Hardware

and Embedded Systems — CHES 2001, volume 2162

of Lecture Notes in Computer Science book series

(LNCS), pages 377–390, Berlin, Heidelberg. Springer

Berlin Heidelberg.

Kocher, P., Jaffe, J., and Jun, B. (1999). Differential Power

Analysis. In Wiener, M., editor, Advances in Crypto-

logy — CRYPTO’ 99, volume 1666 of Lecture Notes

in Computer Science book series (LNCS), pages 388–

397, Berlin, Heidelberg. Springer Berlin Heidelberg.

Komano, Y., Shimizu, H., and Kawamura, S. (2009). Built-

in Determined Sub-key Correlation Power Analysis.

Cryptology ePrint Archive, Report 2009/161.

Lee, J., Hwang, D., Park, J., and Kim, K.-H. (2017). Risk

analysis and countermeasure for bit-ﬂipping attack in

LoRaWAN. In 2017 International Conference on In-

formation Networking (ICOIN), pages 549–551.

LoRa Alliance

(2017). LoRaWAN

Speciﬁcation v1.1.

Messerges, T. S., Dabbish, E. A., and Sloan, R. H. (1999).

Investigations of power analysis attacks on smart-

cards. In Proceedings of the USENIX Workshop

on Smartcard Technology on USENIX Workshop on

Smartcard Technology, WOST’99, pages 17–17, Ber-

keley, CA, USA. USENIX Association.

Moukarzel, M., Eisenbarth, T., and Sunar, B. (2017).

μLeech: A side-channel evaluation platform for IoT.

In 2017 IEEE 60th International Midwest Symposium

on Circuits and Systems (MWSCAS), pages 25–28.

Na, S., Hwang, D., Shin, W., and Kim, K.-H. (2017). Sce-

nario and countermeasure for replay attack using join

request messages in lorawan. In 2017 International

Conference on Information Networking (ICOIN), pa-

ges 718–720.

Sigfox (2017). Sigfox Technology Overview.

Tawalbeh, L. A. and Somani, T. F. (2016). More secure

Internet of Things using robust encryption algorithms

against side channel attacks. In 2016 IEEE/ACS 13th

International Conference of Computer Systems and

Applications (AICCSA), pages 1–6.

Tomasin, S., Zulian, S., and Vangelista, L. (2017). Secu-

rity Analysis of LoRaWAN Join Procedure for Inter-

net of Things Networks. In 2017 IEEE Wireless Com-

munications and Networking Conference Workshops

(WCNCW), pages 1–6.

Yang, X., Karampatzakis, E., Doerr, C., and Kuipers,

F. (2018). Security Vulnerabilities in LoRaWAN.

In 2018 IEEE/ACM Third International Conference

on Internet-of-Things Design and Implementation

(IoTDI), pages 129–140.

Zulian, S. (2016). Security threat analysis and counterme-

asures for LoRaWAN

join procedure. Master’s the-

sis, University of Padova.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy