Cloning a TTN LoRaWAN node is a 15 min task

What does this say about SECURITY with LoRaWAN protocol?

ExpLoRer is a dream to use for hacking TTN & LoRaWAN systems.


Mark :sunglasses:

A few example payloads


QK0ZAS YAFwAB 7v5TJC8dh5IaiN4DjHO2uLwTZg==

QK0ZAS aAqhwB JGo5DISMVuhztdiU/alFzbYEStHU9nt+ZG4=

QK0ZAS aArRwB 7Cb38XzvkxbwHijjN4+aY6BgiT+oQ6MiKl0=


QK0ZAS YAHgAB 93OyDmEnKCZm/1eOdG7qrDJzlg==

QK0ZAS aAsBwB /Q/B6Kumcyh5uDgZJqUzcUXGsGnCNlN63EE=

QK0ZAS YAIAAB z/Ic3vSwJ7SbHLMbPWlccgt0nw==

All from the same node according to TTN & LoRaWAN protocol.

Anyone see any patterns?
Anyone care about SECURITY with IoT.

This was a 15 min exercise.

Imagine what i could do to your IoT system if you build around LoRaWAN protocol.

You are just showing encrypted payload, right? Anyone can pick that up, either on a gateway or even from the radiowaves. Now when you are able to decrypt this, then I get worried :wink:

What I find funny here is that the complete data packet is not encrypted!

It seems to me, that the data packet is split up into distinct parts visible to the hacker.
I guess the designers don’t understand the encryption fully.

QK0ZAS is static.
YAFwAB these seem to be incrementing.
These two fields seem to be predictive.

Not good when I can use the second board to clone packets.
If I send the same type of data, how will the end user know which is his under LoRaWAN?

How does LoRaWAN do authentication on data packets and nodes?
The SoDaQ ExploRer board with SoC LoRaWAN does not care its a clone of my other kit.

Why would a protocol doing MAC not care about cloning?

Other security issues.

IoT uses small data payloads.
You see when payloads go down to 64 bits.
We can start to look at cracking this, I think.

LoRaWAN is a failing protocol due to poor design.
It has to HIDE secrets in IT systems.

Security Via Obscurity

Hows that working out for the world?

$0.02 worth

@Mark_Edgar, certain parts of the message are indeed unencrypted, from which you may be able to derive the DevAddr. However, with no knowledge of the NwksKey or AppKey you are not able to reproduce valid messages that look like they are coming from this DevAddr. And even if you replay an old message, the sequency number will be off, so that can also be detected. And if you increment the (unencrypted) uplink sequence number yourself, the 4-byte Message Integrity Code will not match.
And your conclusion that the data is unencrypted is also wrong. The Frame Header is unencrypted, but the data payload is always encrypted.

And even if you line up a few supercomputers to brute-force break the encryption, spend a lot of time and energy, then you might find that the decrypted payload would read ‘20’ because the node you cracked happened to send the ambient temperature as a payload :wink:

It’s not as bad as you think it is… Not at all, it fits the purpose!

1 Like

Never said this.

AES is secure. Agree fully.

It is not fit for purpose because of one simple fact.

LoRaWAN security is hiding AES symmetric KEYS!

These keys are the wrong type of KEYS to use like this.
Security doesn’t use symmetric keys when asymmetric is required.

Most users don’t know what an HSM is.
They will continue to use keys in software & store them in a database.
These are hacked every day. This is the weak point.

It does not matter if you hide these AES keys behind hardware, you still have to manage KEYS.

I think you miss my point as many do here.
LoRaWAN is broken due to poor security via obscurity.

Encryption is not an issue.

Key management and Authentication are, however.!