How to prove security of node data sent over a gateway?
I just have listened to a talk about LoRA and sniffing the radio with an SDR (https://www.youtube.com/watch?v=NoquBA7IMNc). He practically showed up a working demonstration.
Given, that this may possible in general, I do not bother about that at all. But how do I prove, that my data, sent over a gateway, is encrypted and cannot be tampered with or read by that gateway?
What I mean, is special code needed despite the keys I put into the LoPy code (config file)?
Is the app eui and and application key used to encrypt the data within the device before sending it over the plain socket bytes, or should I (can I) take an extra step with encryption for the payload?
I bother just about this to take an extra security measure, if practical, without hosting my own backend.
@jmarcelino Securing keys on a device is always hard, or, not possible. If the program can decrypt the keys for use, then the decryption keys are known and thus the keys it self :-) And I think, every device get's it's own keys, thus if one is tampered with, all others may not be.
What do you mean with framecounters? The tcp/ip frames? And MIC attacks?
Sorry, I am dumb :-)
True for now at least ABP can be safer, iff:
- you can implement it properly - keep frame counters in check
- you can implement it securely - store keys safely on end devices
- you trust your network server to protect you from rogue gateways (MIC attacks)
To be honest I've found 1) and 2) really hard
@jmarcelino Thank you for the link to the paper. I do not worry about updating my devices to LoRaWAN 1.1. I do not yet have anyone in the field where I cannot get access to. Just generally I should keep an eye on the issue and be prepared for updates from pycom (firmware). If the LoRa modem it self needs to be updated anyhow and could be, then I have no problem with that. If not, I have only yet three LoPy devices I can live with. I am still in my prototyping milestone :-)
The keys are used to encrypt the data sent over LoRaWAN however ...
ABP keys e.g. NwkSKey and AppSKey are never sent over the air.
The keys are used to encrypt the data sent over LoRaWAN however an attacker could in fact read or tamper your data - several attack scenarios were revealed in the recent Rescuing LoRaWAN paper.
These attacks will be addressed in the upcoming LoRaWAN 1.1 specification likely coming next month, but it will be difficult to update everything. It will be complex - for example the current NwkSKey will become 5 different keys. Both nodes and the networks will need updating.
Just my opinion but adding layers of complexity don't usually go together with security so I remain sceptical these updates will solve everything.
Personally for my projects we've now gone with doing our own style of AES encryption and have started working with ST to use their STSAFE line of chips to implement a security system. I believe Microchip has similar chips.