Application Server - ThingPark - End to end security

Question

From the LoRa Alliance specification, we know that the LoRaWAN Application Server handles the decryption (uplink) and the encryption (downlink) thanks to the AppSkey. The first thing which is not clear is that Thinkpark is a LNS, so supposed to deal only with authentication but obviously goes further in the process as it can decrypt the payload which should be the App Server work.

The second point that I can't understand is how I can perform an "end to end" security as the payload is sent decrypted from Thingpark to my IoT Platform. This seems obvious because my IoT Platform doesn't have the AppSKey and anyway, has no direct connection with the Join Server. To summarize my questions:

• How come the Actility community calls the IoT Platform the App Server as it doesn't have the AppSkey?
• How come Thinkpark is called LNS if it does the App Server work?

I've admitted this behavior so far, but that is really too confusing when I try to explain it to someone else. Why don't we say that ThingPark is a LoRaWAN Server (LNS+AppS) and that the IoT Platform is just a User Application which has nothing to do with LoRaWAN? That would be easy to explain that if we want end to end security , we just have to shortcut Actility App Server and build our own (as well as our User App).

Thank for your insight and clarification.

Answer 1

You are right. Thingpark is doing much more than what a simple LNS is supposed to do. It is an advanced LPWAN connectivity platform including Network Server, Join Server, Reliable Multicast Server, Location Solver, Message Broker and many other components. It also provides connectivity for 3GPP devices (NB-IoT, LTE-CatM, etc.)

But Thingpark is definitely not an Application Server since it is not storing, not processing, and not visualising any data sent by end-devices. Thingpark is just enabling the communication between end devices and the Application Servers that have such functionalities. From this perspective your IoT platform should be considered as an Application Server.

Regarding your other question on receiving decrypted frame payloads at your AS: Yes, Thingpark decrypts the data in case you use Over the Air Activation with Thingpark's embedded Join Server. This is so because in that environment your AS does not know the AppSkey and cannot decode the data. Please note that the AppSKey is generated during the Join procedure at the end device and at the Join Server and the AS requires special integration with the system to receive the AppSKey in a secured way.

If you want to set up End to End security with Thingpark, you need to use an external Join Server. It could be either your own Join Server or Actility's cloud based Join Server service called Thingpark Activation. If you use Thingpark Activation, then ThingPark will add the encrypted AppSKey to every uplink message so that your AS can decrypt the AppSKey and use the decrypted AppSKey to decrypt the frame payload.

Answer 2

When using the embedded Join Server, the ThingPark platform already knows the AppSKey because it computes it... rather than pretending it doesn't know it, in this case it decoded the frames for the AS and sends them over chosen secure link. This allows to add additional services like CoDecs to make it even easier for the AS.

In some use cases (typically mass metering), the application server does not want to trust the network infrastructure. In this case a shared Join Server with HSM (preventing access to session keys) or own Join Server is used. In both these cases (external JS for ThingPark), your app will receive encrypted payload.

In the case of a shared secure AS (such as ThingPArk Activation), the AS and JS share a key encryption key beforehand using public key crypto (JS generates a key and sends it encrypted by Public Key of AS), then the AppSkey computed by the JS during Join is tunneled with the uplink metadata, encrypted by previously shared key. This tunelling is a better design than the separate independent communication with JS, because in ensures synchronization of LoRaWAN uplink and the related AppSkey.