Hi, there is something I don’t understand: I want to encrypt my payload so only my app can read it and not the TTN network.
So I want to share the Network key with the Things network, but not share my App Key.
However in https://console.thethingsnetwork.org/ TTN keeps asking me for the App Key or autogenerates one that I have to use. But I don’t want that.
How do I keep the payload private?
Hi @kwinz, the app key is needed by the network, you cannot register a node without using one. If you need to keep your data secret from the LoRaWAN network operator then you have 2 options:
- Run a private LoRaWAN network and do not use any public network such as TTN.
- Add your own Over-the-Top encryption layer. Your encrypted data will transit TTN.
The TTI/TTN v3 stack is a good candidate for option (1).
Option (2) is not difficult to do at small scale if you have full control of the devices and the cloud application that receives the data via MQTT or HTTP, but is very difficult at large scale as you will get into the normal cipher key management issues and will either have to use Pre-Shared Keys or a Key Management System.
If you are going for option (2) then research the use of AES, https://en.wikipedia.org/wiki/Advanced_Encryption_Standard as the software is available in many libraries. Also take a look at https://en.wikipedia.org/wiki/Trusted_Platform_Module which is a standard hardware chip/module for storing keys and generating random numbers.
2 Likes
What about only Setting up a Private Handler connected to the Public Community Network? (That Labs story is almost 3 years old, so might be outdated. And one won’t have TTN Console to administer applications and devices then, I think, so the command line ttnctl is needed. Maybe one gets TTN Console when using the handler from the V3 stack, if at all possible with the community network.)
I am not 100% sure that a private handler mitigates LoRaWAN security: Can the Network Server generate the AppSKey? which describes a limitation in LoRaWAN 1.0.x, as currently used by the public network.
2 Likes
Indeed, while I’m not sure of the current practicalities with TTN, this is essentially why there is a distinction between the network server’s key and the application server’s key.
I am not 100% sure that a private handler mitigates LoRaWAN security: Can the Network Server generate the AppSKey? which describes a limitation in LoRaWAN 1.0.x, as currently used by the public network.
First that is only even a question if using OTAA, a protocol which doesn’t ultimately solve most of the problems that people hope it will when they decide to try using it.
But even in the context of it, there’s no real reason proposed why your own private application / join server shouldn’t be trusted to have the network keys of your own devices. For that to matter you’d seemingly need to have some very odd set of business / trust relationships between entities managing the different pieces, almost as if you were “renting” the nodes and wanting to make sure the customer couldn’t throw up their own gateways and network server and get the data without you. While in TTN, having the “customer” contribute extra gateways is explicitly encouraged.
1 Like