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)
Or is it asymetric crypto?
AES 128 is symmetric, so you’re right.
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
OTAAbecause the end-user should not be concert with programming a chip to TTN in any way - We use
on-joindevice 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).
I think your method of using the same AppKey for all devices will work. However it is definitely insecure, and should be described as such…
Definitely not a recommended method, but if it works, why not!
So I guess, my questions now are:
- Do you agree with the implementation described above? Is there any other way?
- What options are there, given we do not publish the
App Key?
@sp1 I know, you have explained some options to me already, but maybe reiterate them here, so people can jump in and share their opinion…
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.
(Position, … for the Display on Dustmap)
What I suggestet @madc in private chat was:
- 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
1 Like
Thats not handled via TTN, the node does not know where it is…
Can you elaborate a bit more?
No I’m sorry, I found this news article just this morning and thought ’ maybe it fits your needs
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.
Yes, exactly Point three from Earlier post: Open Source Project and the App Key
Maybe both options Key access [ for advanced users] and Firmware download for beginners, so they don’t need to install an IDE
We know luftdaten.info and are currently in contact with folks there. Our project goals slightly differ, that’s why we require our data in an isolated instance. Certainly we’ll share our data with them once we believe them to be good enough. I don’t want to go too far off topic, but feel free to get in touch if you have any further questions.
1 Like
Check!
Very nice project!
I mean DasNordlicht, a guy from our com. contact you (mail).
Greets and have a nice day! 