I also set up a private TTN Stack on my server. But I dont want to host it all by myself but instead be able to use the existing TT-Network and its gateways for it (if required).
Are there any up-to-date tutorials or guides on setting up true end to end encryption without setting up a full stack / components not necessary?
Hey,
I dont fully understand your answer.
I need to have e2e encryption between my node and my server parsing the payload.
With HTTP(s) Webhooks or MQTT-Client I receive the payload in already decrypted / payload parsed format.
Essentially what you want to do is to run the application server yourself, and have TTN be only the network server. Thus you hold the application keys and can decrypt traffic, but TTN only has the network key to validate traffic.
I’m not sure exactly how one would go about setting that up today; it is something that should be supported however, as keeping these roles distinct is fundamental to the design of LoRaWAN being able to include a network-as-a-service type of approach. It gets more complicated if you also want to do OTAA, as then you also have to be the join server.
Of course you could also do your own encryption of what goes into and comes out of LoRaWAN overall, either using some other algorithm or re-using the AES code that a LoRaWAN node already has to have.
Hi @Marcel2508, e2e encryption over LoRaWAN on the community TTN network is not difficult at all. I have built systems doing this.
Choose device and server that have compatible crypto libraries. I used AES in ECB mode on Pycom LoPy4 and RPi.
Create per-device keys to be device–server Pre-Shared Keys (PSK).
Write the software for the devices and server to encrypt/decrypt the ciphertext.
On a device you create a plaintext uplink payload and then encrypt this to ciphertext.
You uplink the ciphertext.
Use MQTT to subscribe to the TTN application and receive the ciphertext.
Decrypt to plaintext on your server.
TTN and all the servers between your device and your server only ever see the ciphertext. The software is simple. The tough bit is the key management at scale.
Before you invest a lot of effort, TTN Will be moving to V3 of the stack in the (hopefully near) future. At that point this solution won’t work as it is V2 based.
Thanks for your replies! @cslorabox thanks for this description. So there is no ´officially supported´ method of doing this I guess?
So using a complete private TTN Stack would be easier than probably…
@cultsdotelecomatgmai This setup would not work for me because I need to use industrial grade devices, where I’m not able to modify the payload.
@kersing Thanks for this warning. Yeah I wasn’t even able to get the tutorial working. So I think only my own Stack or cslorabox method might work?
Anyone hosting / using theire own application server out here?
Sure, decrypted, but not necessarily parsed, that is up to you. Still delivered by encrypted channels, but you are correct, for some moment in time, TTN will have the unencrypted payload in its servers memory.
So why not setup your own server instance or use TTI?
And I’d never advocate encryption by obsfucation, but the format of the payload is up to you so there can be an element of security in that.
There are many many many solutions for efficient encryption, checksums & signing, from software library only to external to the MCU to built in to the MCU, along with plenty of chipsets for storing keys securely or software solutions for deriving the one-way encryption from serial numbers.
When Tim describes the tough bit being key management, I’ve seen biblical level disasters due to Excel based errors. So what ever you do, design until you eyeballs bleed and then find someone to audit the whole scheme.
Simple encryption & payload signing can be done software on a SAMD (which could be an Arduino, indeed, you could use the Arduino ecosystem to do it). If you need to invoke this level of paranoia, always remember xkcd: Security and don’t let your staff go home, ever.
Although quoted, that seems to ignore the part about the asker wanting to use off-the-shelf sensors which implement only the LoRaWAN standard encryption (and presumably have well documented packet formats, too)
LoRaWAN is supposed to support not sharing the application key with the network provider.
“Industrial grade devices” - I saw grade - which is a level of rank - as in they are of the standard of industrial devices.
“not able to modify the payload” - not payload format.
From my perspective, there is a fundamental dichotomy in wanting this level of security and using off the shelf devices & a public / community network, so this really didn’t cross my mind, nor Tim’s it would seem.
If you can’t live with the risk of some bad-actor gaining access to the TTN servers and being able to observe the payload decrypted in the memory of the TTN Application server before being re-encrypted to be sent via MQTT TLS/SSL or HTTPS, then these are not the droids the OP is looking for. That’s assuming the hacker can determine which of the machines in the cluster that an uplink is passing through amongst all the other uplinks. Like trying to pick out one bee returning to a group of bee hives. I’m working on the broad assumption that there are no logs that have decrypted payloads in them, which opens up a whole new set of ‘who audits TTN security’ but that would be another thread.
There also seems to be some confusion about using a “private TTN Stack” - yes to private stack, no to then having use the community gateways (at least as I understand it), but yes to TTI but a solution you have to discuss with TTI.
As with many of these edge case enquiries, it takes a bit of back & forth to find out the real needs are. Hopefully the OP will be more forthcoming if they want some practical solutions - one of which may well be one of us creating the aforementioned “industrial grade device with payload encryption using user keys” - as well as what the device should be sensing, as even if there were a range of industrial grade devices with payload encryption, they’d still have to support the sensors …
But TTN holds the Application key as well, so whilst it decrypts at Network Server to know where to send it, for TTN it goes to a TTN Application Server which then decrypts at that level and processes it as per the configuration of the application.Unless I’ve missed an integration, albeit I only use HTTP, MQTT and for convenience for testing, Data Storage, I don’t see a route out of TTN at Network Server level. I will be delighted to be informed otherwise as this would solve a couple of use cases for the purposes of testing.
LoRaWAN is designed with the idea that the Network Server and Application Server are distinct jobs often performed by different parties - network providers run network servers, customers run their own application servers. Of course that could be delegated to the network provider, but as a convenience not of necessity.
I was under the impression that there was one, and it sounds like in v3 there will be a different one.
Anyway, lack of such would be a shortcoming in the implementation of LoRaWAN by TTN - form a LoRaWAN perspective, this is supposed to work because it’s an explicitly designed feature of the whole scheme.
Indeed. And they linked to a guide for how to accomplish this very thing using TTN.
What this thread should have been about is understanding why that is apparently not working in their attempt, not a bunch of why would you think such a silly thing should be possible type responses.
To be fair though, Marcel could have helped things by being more specific about how the attempt is not working.
With the V3 stack, we provide this option out of the box using the skip_payload_crypto option.
Skipping payload crypto on application-level via application link’s skip_payload_crypto field.
This tells the Application Server to simply forward the encrypted application payload upstream (to an integration for example).
You can then fetch the Application session keys from the Join Server yourself and do the decryption on your own servers.
Pro Tip: We have stopped all development activities on our V2 stack are going to retire TTN v2 in the coming months so I wouldn’t recommend spending time/effort on that.
Ah yeah indeed. Good one. V3 supports external Join Servers from a long time ago (I think right from the time we open sourced it) so for me that was implied. But good to point out that we do work with external Join Servers.
So you keep the keys in your own JS and allow the TTI/TTN Network Server to only query the Network Layer Session Key (different notations in LW 1.0 and LW 1.1) to handle MAC operations and MIC checks.
And for “true” end to end encryption, either host the application server yourself (yes we do support this) or skip the decryption and receive the encrypted payload directly.
Additional Note:
and transferring them over the Internet
V3 supports wrapping of Session Keys using KEKs (RFC 3394) for transferring them over the internet. The Root Keys never leave the Join Server.