LoRaWAN Security: Encryption and Authentication

  • 4 May 2018
  • 13 reacties
  • 3140 keer bekeken

Reputatie 3
Badge

End-to-end encryption


All LoRaWAN devices are forced to encrypt their payload and header with the Advanced Encryption Standard (AES), using keys of 128 bits (or 32 hexadecimal characters). The LoRaWAN protocol offers two layers of security:
  • On the network layer, the integrity of a message is enforced by the Message Integrity Code (MIC).
  • On the application layer the payload is encrypted using the AppSKey.
This means it is possible to have end-to-end encryption of the LoRa data. For LoRaWAN the used network keys are in the KPN domain and the application keys are in the customer domain and must comply to usage policies to prevent easy to guess variables. In the case of Over The Air Activation (OTAA) the used Network Session Key (NwkSKey) and Application Session Key (AppSKey) are managed from the KPN domain (Join service) and can be periodically refreshed. The below figure shows the domain of the NwkSKey and the AppSKey.



KPN Security mechanisms


KPN depends not only on the included security mechanisms such as Over The Air Activation (OTAA) and AES128 in the LoRaWAN protocol specification but it also applies KPN security mechanisms. The complete solution is hosted in KPN owned datacentre premises on which the Corporate Security Policy Framework (CSPF) is applicable. The KPN CSPF consists of a set of policies, standards and guidelines and is derived from high level KPN Group Corporate Security Policy. The CSPF is based on the international standard for information security (ISO270013) and the international standard for business continuity (BS25999).

Connection towards the customer Application Server


The connection towards the customer Application Server is using the HTTPS protocol with TLS v1.2 signed certificate requirements. Within this tunnel the application data is authenticated by using bi-directional SHA-256 token calculation. For example code regarding token verification please refer to the Github information mentioned in the topic on online LoRa tools .

13 reacties

Reputatie 1
Badge
Last year in this topic (https://zakelijkforum.kpn.com/lora-forum-16/achterhouden-appskey-voor-kpn-in-combinatie-met-otaa-8459) it was mentioned that:

Het streven is een oplossing waarbij OTAA zo ingericht is dat end-2-end encryptie mogelijk is. Hierin moeten nog architectuur keuzes gemaakt worden en het resultaat hiervan zal worden meegenomen in een volgende release.

Has there been any progress in this area since then, in other words, is there an OTAA scheme possible whereby KPN does not 'see' the AppSKey? I believe a separate 'join-server' is needed?
Reputatie 3
Badge
Hi tonb,

The answer to your question:
is there an OTAA scheme possible whereby KPN does not 'see' the AppSKey?
is yes. KPN is currently working on implementing a Hardware Security Module (HSM) in the network, which will facilitate exactly this. The principle is based on the use of an RSA public and private keyset. Once more information on this topic is available we will of course make this known.

Kind regards,
Lennart
Hello,

I was wondering, why doesn't the dev portal decode the data from LoraWan if the link between the appplication server and the one of KPN is already trusted through SSL?

I am having troubles to decode the data in my application server, since was expecting the data to be already decoded from KPN portal. Could you point me out a way to decode my payload?

Kind regards
Reputatie 3
Badge
Hi JCL,

There is refence code available on Github, which is described in the topic on the availability of LoRa tools. This should probably help you along.

Kind regards,
Lennasrt
Hi JCL,

There is refence code available on Github, which is described in the topic on the availability of LoRa tools. This should probably help you along.

Kind regards,
Lennasrt


Hi Lennart,

Do you refer to this code https://github.com/kpn-iot/lora-reference/blob/master/payload-decryption/PayloadEncryption.php ?

In case it's so, since I am using node-red to read the payload I should implement such functions in node red so that I can decrypt my data right?

Kind regards
Reputatie 3
Badge
Hi JCL,

That is indeed the reference code I was referring to. There is also additional code specifically for node-red available on Github. This was posted by the IoT Academy. This might also be helpfull in getting started.
If you are using node-red I believe you should indeed perform the decryption there as well.

Kind regards,
Lennart
Thanks @Lennart Nordin

Hi JCL,

That is indeed the reference code I was referring to. There is also additional code specifically for node-red available on Github. This was posted by the IoT Academy. This might also be helpfull in getting started.
If you are using node-red I believe you should indeed perform the decryption there as well.

Kind regards,
Lennart


I have read the documentation and I have still a question, the LRC_AS_key that is mentioned in here https://github.com/iotacademy/NodeRed_KPN_LoRa/wiki/3.-Validating-the-Token, is my AppSKey or other value? Where should I get it?

Thanks!

EDIT: I overlooked, in the link it is explained as well that

Note that you have to change the LRC_AS_key to match your SHA key from your profile in the Developer Portal or the Application Server profile in the Thingpark deviceManager.
Hi JCL,

That is indeed the reference code I was referring to. There is also additional code specifically for node-red available on Github. This was posted by the IoT Academy. This might also be helpfull in getting started.
If you are using node-red I believe you should indeed perform the decryption there as well.

Kind regards,
Lennart


Then if I used node-red and if I understand well, first I have to get the LoraWAN payload from the DevPortal performing a SHA256 Check onto it, thus I will get the LoraWAN payload encrypted with the AppSKey. Secondly, I wil have to decryot that payload with the AppSKey in order to get my real payload.

Is this reasoning correct?

Thanks!
Reputatie 3
Badge
Hi JCL,

In the Developer portal documentation it states that:
"Messages are forwarded unencrypted. The developer portal already decrypts the LoRa data using the randomly generated AppSKey. No further decryption is necessary. In the Commercial LoRa Service end-to-end encryption is supported.

All payloads are hexadecimal however, meaning they have to be decoded in some way to be used in applications. The decoding scheme depends solely on what the device manufacturer programmed in your device."

Does this answer your question?

Kind regards,
Lennart
Hi JCL,

In the Developer portal documentation it states that:
"Messages are forwarded unencrypted. The developer portal already decrypts the LoRa data using the randomly generated AppSKey. No further decryption is necessary. In the Commercial LoRa Service end-to-end encryption is supported.

All payloads are hexadecimal however, meaning they have to be decoded in some way to be used in applications. The decoding scheme depends solely on what the device manufacturer programmed in your device."

Does this answer your question?

Kind regards,
Lennart


Hi @Lennart Nordin thanks for your answer, it answers my question partially. In that the payload that I am getting from the developer portal is not decrypted at all. When the forwarded payload hits my backend, the payload that I am getting is this
\"payload_hex\":\"940adfc976bffbf80dfe452c615a0410465d3549651967260c948e03\"
\"value\":\"940adfc976bffbf80dfe452c615a0410465d3549651967260c948e03\"

which seems encrypted to me becuase I don't send that data from my device.

Kind regards
Reputatie 3
Badge
Hi JBL,

Can you send your Device and account information to me in a private message, such that I can look into this?
Thank you in advance.

Kind regards,
Lennart
Hi JBL,

Can you send your Device and account information to me in a private message, such that I can look into this?
Thank you in advance.

Kind regards,
Lennart


Yes of course, I sent you a private message,

Thanks 😁
Reputatie 3
Badge
For all other LoRa developers that also have a problem with this, below is the solution that helped JCL.
On the LoRa developer portal the only FPort that is allowed is FPort=1. If you experience the same difficulties as mentiond bij JCL in this topic, try sending messages on FPort=1.
In case this does not work be sure to also check that there are no typo's in your AppSKey.

Kind regards,
Lennart

Reageer