I have a conceptional question that need some more insight from experienced TTNers.
A little bit of backstory: We are currently developing an air pollution measurement kit. It will be the first application officially running on TTN Graz/Austria. Our goal is, to make this device as accessible and easy to use as possible.
The end-user should put the sensor on her/his balcony, plug in the power cable ant that’s it. That’s why we set up our application to accept new nodes on-join, what works really well so far.
We want to publish the firmware once it is finished and this is where my real question begins. As we use on-join, each node will use the same App Key. Is it OK to publish this key in our repository? What are the risks?
I had a discussion with @sp1 on the openIOT slack channel and would like to continue it here to get more insights.
The current setup with OTAA is that the join request uses the AppKey to request it’s own set of ABP keys, which are then used for every subsequent transmission.
If everybody knows the AppKey, they would be able to listen for join requests and decrypt it. They would then have the ABP keys, and they can then use the ABP keys to decrypt everything.
While the chances of somebody hearing the OTAA join is much lower since it is not done very often, if they do, the whole session is compromised. You shouldn’t be sharing AppKeys at all!
Dynamically activated devices (OTAA) use the application key (AppKey) to derive the two session keys during the activation procedure. In The Things Network you can have a default AppKey which will be used to activate all devices, or customize the AppKey per device.
So it is OK to have multiple devices with the same App Key. But you have a point, when you say that someone knowing the App Key could intercept the activation and obtain the secret session keys.
Are you certain, that this enables said bad guy to decrypt all payloads by this one node?
Correct, this was my concerns!
And if someone messes around with it you cant block him.
Because he can obtain new Keys everytime he wants.
So you would have to change the APP Key!
What does this mean? You need to go out and update the Keys on all your devices! Wishing you a lot of fun @madc Of course, he has the app key, so he just needs to listen to the traffic, decrypt the join ac With the ABP Keys and he can decrypt your messages. (also reproduce Fake traffic)
I could now argue that it is an open project and the data sent are not sensitive at all. But i’d prefer to find a solution that does not undermine security.
We use OTAA because the end-user should not be concert with programming a chip to TTN in any way
We use on-join device creation because the end-user should not have to rely on us to create the device manually (plug&play if you will)
By using on-join we limit ourself to one App Key for all devices. That means, it should be fairly easy to obtain the App Key from a memory dump of the chip (given that the firmware is open source).
My opinion would be that this method would work, but is insecure and no matter how trivial the data is, it completely undermines the whole setup of LoRaWAN. There’s no guarantee that it will continue to work for the future as it’s not a supported setup.
In theory, you should have some system to automatically provision a DevEUI/AppKey combo on device creation. You could use API calls to generate these, and then hardcode it into the firmware of the device. You would of course have to recompile each time for this.
Generating unique AppKeys for each device is really the only secure way of going about this.
@madc of course you don’t worry about anyone getting the data it’s more like protecting the value of your data!
For example if you have a verified Sensor Station it could be verified! But anyone could inject data for this station
So I suggest you have your own Stations with different Keys and marked as trusted/verified
And the auto Join fimware for anyone to flash to the Arduino
What do you think about that?
But this also does not solve your problem (We discussed together), to Store the stations Position and Metadata
Keep in mind that if you use the same AppKey on all devices, but don’t publish it in the repository, it’s still insecure.
Somebody with the right know-how can extract the AppKey from the device, and compromise every device on the network. They are not only able to see the data, but also spoof the device.
People make a own APP and share the api keys with you (like @jpmeijers did at ttnmapper in the beginning
You get an integration, so everyone can add their applications to your Application
As you might want to make it easy for the enduser you could make a WebUI to manage the Devices/ Set sensor Postions and also download a commisioned Firmware! So if someone creates a device, he can click download Firmware: In the Background your sever obtains the Keys from TTN and Builds the Firmware
I thought about their concept but the thing here is that @madc wants the people to build the hardware by themselves. So he can’t commission the devices by himself.
So I had the idea with the commission firmware download.
On-Join registration can be useful for development but for production it’s a very bad idea. We therefore recommend finding a different solution, also because TTN will no longer support on-join registration in our upcoming v3 stack.
Keys should never be made public. An alternative solution could be to write an application that uses our API to register devices. Your users could use this application to “sign up” for your project, after which it will create a new device in your application, generate the keys and show them to the user. You can indeed also write the keys into some placeholder in a firmware file, and send that as a download to your user.
