I am trying to understand Lorawan security implementation using OTAA (Over the Air Activation). Correct me where I am wrong.
Network Server (NS) stores in database device unique ID - “DevEUI” and “routing routing_profile_id” as information to which Application Server (AS)/client redirect uplink/messages. It also has connectivity with JoinServer (JS).
When device with specific DevEUI sends join request message to NS, NS accept that join request message if specified DevEUI exist on its database. NS creates JoinRequest payload in json format and sends over https to JS.
JS holds secrect key associated with specified devEUI. It generates two session keys NwkSKey and AppSKey and encrypts JoinResponse payload which will be send back as answer to NS, NS back to device. Device can verify and decrypt payload with secrect key, then further on can use session keys to encrypt/decrypt uplink/dowlink messages. That fine.
NS will also get from JoinServer two session keys in plain text. NwkSKey - which will be saved into database and AppSKey will be redirected to AS. Plain AppSKey send over internet to Application Server? Event NS uses SSL transport, it seems it could be a security flaw?
Another scenario: evil Application client will generate many random devEUI, if one of those at some point in time will match real device devEUI, joinRequest will be redirected to wrong application? (Owner of device will not able to create device on NS with the same devEUI).
@eugenev Video explains Lorawan spec 1.0.2. without JoinServer.
But If l run public Network Server, you will have Application Server, why you should trust me of holding AppKey (secrect key) and forward only AppSkey (application session key) to AS? Then I can have control of all devices do not belong to me. This is not end-to-end encryption. Am I wrong?
This is privacy policy question, based on that You can trust or not to the server owner.
1 Like
The question is why NS (Network Sever) as middleman should hold secret key at all. In newer Lorawan version that responsibility was moved to trust party - JoinServer. That’s understandable. But from Chirpstack Network Server code (on github.com) I can see that NS is handling with JoinServer and forwanding AppSKey to Application (see my first question above). Isn’t reverse will be proper way: Application will forward NwkSKey to Network Server?
Please note that the AppSKey communication between the NS and AS can be encrypted using a Key Encryption Key, known by the JS and AS. The NS then only tunnels the encrypted AppSKey in step 7.
Please note that the AS retrieving the AppSKey from the JS could add more complexity to the architecture. E.g. some JS providers provide credentials to the Network Server provider to authenticate against the JS. When these credentials are not shared with the AS, then the AS might not even be able to fetch the AppSkey:
1 Like
@brocaar Thanks for explanation. I will try to build on that idea. My intention is that I could run public Network Server (NS) without worrying that NS could leak AppSKey.
