LoRa the Explorer - 2017 SyScan360 | SyScan360 …€¦ · · 2017-05-26LoRa the Explorer 1.What...

22/03/2016

LoRa the Explorer

Attacking and Defending LoRa systems

LoRa the Explorer

1.What is LoRa / LoRaWAN?

2.LoRaWAN Security Features

3.How to test LoRa systems

Introduction

Introductions

Introduction

+ Me

+ Security Consultant / Researcher @ MWR UK

+ Android Security

+ Head of OT Security practice

Why LoRa?

Why LoRa?

Why LoRa?

+ Protocols in use by industry

Why LoRa?


+ Assumptions:

Why LoRa?


+ Reality:

???

Why LoRa?Po

wer

usa

ge

Range 10s Kilometres+<10 Meters

CellularSatellite

WiFi

Bluetooth

ZigBeeZ-Wave

BTLE

NFC

LPWAN

Why LoRa?

+ LPWAN –Low Power Wide Area Network

+ Low Power (for end nodes)

+ Range of many kilometres

+ Low bit rate

+ Possible using clever modulation

+ Cheap!

Why LoRa?

+ LPWAN –What is it good for?

+Infrastructure

+Smart City

+Logistics

Why LoRa?

+ Main LPWAN modulation technologies

+UNB

+NarrowBand (cellular) (NB-IoT/NB-CioT/LTE-IoT)

+LoRa

Why LoRa?

+ Main LPWAN modulation technologies

UNB Cellular NB LoRA

NB-LTE

NB-IoT

NB-CioT

Why LoRa?

Why LoRa?

+ Main LPWAN semiconductor groups

Sigfox(UNB) Cellular NB LoRaWAN

Why LoRa?

+ Main LPWAN Telcos

Sigfox(UNB) Cellular NB LoRaWAN

Introduction

+ Why Research LoRa?

Why LoRa?

+ Why research LoRaWAN?

+Open source specification

+Already being rolled out in multiple countries

+Planning to be used for a number of purposes:

+ Railway level crossings

+ Burglar alarms

+ Monitoring Industrial Control Systems (ICS)

Why LoRa?

+ Current LoRaWAN security information?

From sales staff:

“It uses AES128bit encryption!”

Or from the official Spec:

https://www.lora-alliance.org

Why LoRa?

+ Questions from clients?

“Is it safe enough to use for $SOLUTION ?”

“Which of these two LoRa vendors is more secure?”

Why LoRa?

+ Research Goals

1. To find whether it is possible to use LoRaWAN

securely

2. To identify key security controls that must be in

place

3. To produce a list of tests that can assess these

controls in a LoRaWAN system

Why LoRa?

Review Specification

Review Implementations

Produce Security Paper

Produce Tools to Fill the Gap

Introduction

+ What is LoRa and LoRaWAN?

What is LoRaWAN?

+ LoRa -> LoRaWAN

LoRa = Proprietary modulation scheme (PHY layer)

Patented by Semtech, licenced to others

LoRaWAN = MAC layer

Open standard maintained by LoRa Alliance

What is LoRaWAN?

+ LoRa Systems have:

Nodes Gateways Network Server

LoRaWAN network

Node

Node

Node

Node

Node

Node

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

LoRaWAN network

LoRaWAN Security

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

LoRaWAN Security

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

Packet

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

DATA

Check Packet Sig. Decrypt DATA

Packet

LoRaWAN network

Node

Node

Node

Node

Node

Node

Gateway

Gateway

Network Server

Application Server

Application Server

Application Server

CMD

Sign Packet

Encrypt command

Joining a node to the network

LoRaWAN Security - Joining

+ Joining

+Two options

1. Activation by personalisation:

Nodes are shipped with the network and application keys

already configured


+ Joining

+Two options

2. Over the Air Activation

Nodes are shipped with an application key, which is then used

to derive the application session key and network session key


+ Over the Air Activation

+Each node is shipped with a unique Application ID,

device ID and application key


Node Server

Join-request ( AppEUI, DevEUI, DevNonce) signed with AppKey



Message:

App ID , Device ID , Device Nonce

Signed with the appKey (aes128_hmac)


Node Server

Generates AppNonce and then calculates AppSKey and NwkSKey



+Next step? Up to the server

+ It should retrieve the status for that node

+ Then get the application key

+ It should recreate the MIC

+ If successful then calculate and return the Network session and

Application session keys (encrypted and signed with the app

key)



NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)

AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)


Node Server

Join-accept (appNonce, NetID, DevAddr) encrypted and signed with AppKey


Node Server

Uses AppNonce to calculate AppSKey and NwkSKey


Node Server

Messaging

LoRaWAN Security - Messaging

+ Nodes use the NwkSKey and AppSKey to send messages

+ For application messages –

+ Encrypt with AppSKey

+ Sign with NwkSKey

LoRaWAN Security - Messaging

+ Nodes use the NwkSKey and AppSKey to send messages

+ For Network messages –

+ Encrypt with NwkSKey

+ Sign with NwkSKey

LoRaWAN Security – Application Messaging

+ Messaging – Application messages

+ AES128 in Counter mode (CTR)

+ Uses counters (FCntUp and FCntDown)

i = 1..k where

k = ceil(len(FRMPayload) / 16)

Ai = (0x01 | (0x00 * 4) | Dir | DevAddr | FCntUp or FCntDown | 0x00 | i)

Si = aes128_encrypt(K,Ai), for i = 1..k

S = S1|S2|..|Sk


+

+XOR message with keystream

MAC Payload:

PHY Payload:

FHDR Fport FRMPayload

MHDR MACPayload MIC

Class B LoRa systems

Class B system

+ How do Class B systems differ?

+What if the nodes move?

+What if the network server wants to initiate

messages?

Class B systems

+ How do Class B systems differ?

+ Gateways provide simultaneous GPS/timestamp

broadcasts

+ Used by nodes that need to update the network server

with their location

Class B systems

+ How do Class B Systems differ?

+ Nodes use these to create time windows to listen in

+ Allows multicast messages

But is it secure?

Complex systems = ~insecure systems

+ Testing


+ Messaging - Tests

Issue Effect

Decryption is performed before MIC is checked

Attacker could attempt to flip bits

Decryption is performed before MIC is checked

FCnt manipulation is possible leading to DoS

Counters are not incremented Could XOR out the plain text

AppSKeys / NwkSKeys are not unique If one node is compromised then all traffic can be read and spoofed

LoRaWAN Security – Application Messaging Attacks

+Decryption is performed before MIC is checked –alter cipher-text

{“ID”:”34”,”Temp”:”24”}

750f7f9b6366b4228172fb36fdbe51a3dcc1a85d463d70

Encrypted produces:


+Decryption is performed before MIC is checked –alter cipher-text

{“ID”:”34”,”Temp”:”24”}

750f7f9b6366b4228172fb36fdbe51a3dcc1a85d463d70

If we change 5d to 5a, then decrypt:

Encrypted produces:

{“ID”:“34”,“Temp”:“54”}


+FCnt manipulation

+Messages contain FCntUp or FCntDown

+Must be in sync, discarded if less than previous

+Updates using most recent message


+FCnt manipulation

+So if the FCnt value is altered to maximum value?

+Should be ignored when checking the MIC

+Otherwise discard all future messages

= bricked device


+Counters are not incremented - Could XOR out the plain text

+FCnt increments with each message

+Used to keep keystream unique

+ If FCnt doesn’t increment?

+ Or if we reset the FCnt?


+Counters are not incremented - Could XOR out the plain text

a⊕b=c c⊕b=a

+So if the same keystream is used twice then we could

try to derive the message


+Duplicate keys in use - If one node is compromised then all traffic can be read and spoofed

+Symmetric key issue

LoRaWAN Security

+ Messaging – MAC Only data messages

+MAC commands are used by network server for network administration

+Use the NwkSKey for both encryption and signing

LoRaWAN Security


+Commands include:

+Get Device status

+Change data rate/transmit power/ channel

+Change reception slot parameters

+Modify the definition of a radio channel

+“Proprietary”

LoRaWAN Security


+Why is this interesting?

“Network key / NwkSKey: a fixed network key for all The Things Network devices. It is 2B7E151628AED2A6ABF7158809CF4F3C”

LoRaWAN Security


+So an attacker can:

+Get Device status

+Change data rate/transmit power/ channel

+Change reception slot parameters

+Modify the definition of a radio channel

+“Proprietary”


+ Over the Air Activation - Tests

Issue Effect

The server does not check whether the node hasn’t already

replay attacks would cause a DoS

App keys can be guessed Replay attacks would cause a DoS to future devices

App keys can be guessed MitM of join request would allow offline brute force of keys

+ Key Management

LoRaWAN Security

+ Key Management servers

+ Simple enough problem…

+ Network Server and Application Server need access to

key database

+ Represents a single point of failure

LoRaWAN Security

+ Key Management servers - Tests

Issue Effect

Server access is not restricted Malicious employee/attacker can now decrypt and spoof messages

Server access is not restricted Malicious employee/attacker can encrypt/delete the database shutting down the whole system

Server runs on corporate IT network A second DHCP server? LoRa system stops functioning

LoRaWAN Security

+ Key Management in Nodes

+ Physical attacks

LoRa Node

UARTLoRaWAN

TransceiverAntennaMCUI/O

Key Management in Nodes

+ Nodes store App and Nwk key

+ Should be unique per node


+ Physical attacks

RN2483 Transceiver

Contains keys


+ Physical attacks

+ Steal keys from a node

+ Steal firmware from the transceiver (parsing bugs?)


+ Physical attacks – Debug interfaces?

+ Can we just read data/program memory?





PIC18LF MCU








+ Physical attacks – Side Channel?

+ Nothing mentioned in PIC18LF4xK22 datasheet

+ Could be protected using particular AES libraries


+ Proxying data through Transceiver

LoRa Node

UARTLoRaWAN

TransceiverAntennaMCUI/O


+ Proxying data through Transceiver

LoRa Node

UARTLoRaWAN

TransceiverAntenna

Malicious

MCU

LoRaWAN Security

+ Key Management nodes - Tests

Issue Effect

Attacker has physical access to device Attacker could recover keys

Attacker has physical access to device Attacker could send their own data in place of regular data without affecting encryption/signing

Internet Facing Components

LoRaWAN Security

+Traditional attacks

+Internet facing components

Gateway

Gateway

Network Server

LoRaWAN Security

+Traditional attacks

+Internet facing components

Gateway

Gateway

Network Server

3G

3G

INTERNETWEB

SERVICE

LoRaWAN Security

+ Internet Facing Components - Tests

Issue Effect

Network server’s web services are Internet facing

DDoS could cause LoRa system to sending/ receiving data

Network server’s web services are Internet facing

Malicious data can be sent by anyone

Gateways are configured to be Internet facing

Management services could be compromised

LoRaWAN Security

+ Network Server’s web service

+LoRaWAN messages are protected using encryption and

signing

+Remember we can affect the data (XOR attack)?

+ MIC is 4 bytes = 2^32 = ~4.3 billion attempts

+ Are you watching for errors?

LoRaWAN Security

+Internet facing components – protection

+Private APN (creds + whitelisted IMSI)

+VPN to ONLY web service

Gateway

Gateway

Network Server

3G

3G

INTERNETWEB

SERVICE

Class B Specific Attacks

Class B Networks

+Class B Networks - Tests

Issue Effect

Shared Keys between Nodes Attacker could message to/from multiple Nodes

Shared Keys between Nodes Key storage/distribution could be compromised

Gateway Beacons are not secured Malicious Beacons with bad Time values could cause DoS against multiple hosts (DoDS?)

Gateway Beacons are not secured Custom Network messages could be duplicated by attacker

Class B Networks

The LoRaWAN Class B specification does not specify means to remotely setup such a multicast group orsecurely distribute the required multicast key material.

They are not allowed to carry MAC commands, neither in the FOpt field, nor in thepayload on port 0 because a multicast downlink does not have the same

authentication robustness as a unicast frame

Class B Networks

Class B = Be Careful

Class B Networks

+ Multicast Messages

+ If you only use shared keys

+ Compromised keys = Whole networks compromised

+ Need to switch over to shared keys during multicast

window

+ Is this possible?

Class B Networks - Multicast Messages

+ Gateway Beacons

+ Contain GPS coordinates of the Gateway

– without encryption or signing

- Can also send “network specific broadcasts

+ Used by Nodes for timing

In Summary

LoRaWAN - Summary

+ It is possible to build a secure LoRAWAN system

+ But not guaranteed

LoRaWAN - Summary

LoRaWAN - Summary

LoRaWAN - Summary

LoRaWAN - Summary

Date post:	19-May-2018
Category:	Documents
Upload:	vuonghanh
View:	220 times
Download:	3 times

LoRa the Explorer - 2017 SyScan360 | SyScan360 …€¦ · · 2017-05-26LoRa the Explorer 1.What...

Documents