AMA - Missing puzzle pieces of LoRaWAN Security

1

Hi Everyone

This forum topic will be used for question and answers for the security webinar by @johan.
Link to the video/livestream - https://youtu.be/6IDaUxhEgaI
Slides - Security_Webinar_Missing-Puzzle-Pieces.pdf (3.7 MB)

–
Rish

1 Like
2

Hey hey!
What’s the reason for using symmetric cryptography? When LoRaWAN would switch to asymmetric cryptography?

3

I’m using the I-CUBE-LRWAN 1.2.0 firmware provided by STMicroelectronics in my project (which can be found here. In the Commisioning.h file, I’m using the pre-provided hardcoded keys unchanged:

#define LORAWAN_F_NWK_S_INT_KEY     { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }
   
#define LORAWAN_S_NWK_S_INT_KEY     { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }

#define LORAWAN_NWK_S_ENC_KEY       { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }

#define LORAWAN_APP_S_KEY           { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }

Once I’m using OTAA activation method, would these hardcoded pre-provided keys screw things up when I try to connect to my gateway, once each OTAA operation resets all keys? BTW: I’m having problems to connect to my gateway, and I’m trying everything to get connected.

4

If your use case is “localization”, ie., no payload, what are your security/privacy options?

5

When we’re looking at ‘Red Flags’ - what exactly in unsafe about hardcoded keys? Assuming it’s because it doesn’t give an option to change these. Are we referring to root or shared keys?

1 Like
6

Is there a mechanism to provision LoRa devices with unique identities completely over the air? I.e., that during manufacturing, the devices do not need any unique key material, but are identical, only to become unique after provisioning?

7

Is there a default session duration for the multicast group tokens?

8

Thanks all for watching the webinar! I’m here to answer questions.

We’re uploading the recording with higher framerate. Any feedback is welcome!

The primary reason for using symmetric crypto is the payload size; you get block ciphers which fixed lengths plus a signature size. Both RSA and ECDSA produce way too big results to be sent over one LoRaWAN message.

A secondary reason is the cost; these are computationally heavy operations which incur hardware and operational (battery, so lifetime) costs.

A third reason would be the ease of provisioning, although this can be solved by process. In fact, provisioning will be more complicated anyway with dedicated Join Servers too, and this is also where we see a role for ourselves, to make that process easy.

9

I see the markets are learning faster, where banks are using HSMs for decades already, mobile device manufacturers for some years and, now there is, surprise, requirements for HSMs in LoRaWAN as well. I assume these security updates were introduced not from the beginning as it would otherwise have hampered the adoption of this technology in the IoT market (wise decision probably). :slight_smile:

Anyway, I’m wondering, to what degree is having an HSM in your LoRaWAN device a “requirement”, e.g., will the LoRaWAN device not get a “LoRaWAN compliant” stamp, say, in 2019 anymore when you don’t have one? I’d say, the requirement of an HSM on a device strongly depends on the use-case and the risk appetite of the user/company.

10

These are LoRaWAN 1.1 session keys; so these would be used when you’re using ABP. If you are using OTAA, these keys indeed get generated.

For R&D, it’s fine to hardcode JoinEUI, DevEUI, AppKey and NwkKey. In TTN V3 you can just create your device, just like you do now. However, when scaling up, it’s not feasible to hardcode this per device, plus these values are stored “in clear” on flash. So therefore, use a secure element or other secure environment on the end device.

Apart from that, I’m not expert myself in the ST firmware, but I do now that we have a getting started kit available with them very soon, exactly with that kit.

1 Like
11

Even if the location is inferred from the RX metadata (so no coordinates in payload), you still have the authenticity and integrity part of security that you need. You still want to be sure that you’re dealing with the device that says it is, and you don’t want anything tampered with.

Also, there’s not only payload on the application level; MAC commands are also payload and they are also encrypted in LoRaWAN 1.1. For that, you still want authenticity.

So basically security matters even if you don’t send application payload.

12

Regarding asymmetric cryptography with LoRaWAN, I just wrote a paper about it that should be published early next year. It analyses the overhead of using digital signatures (message size, airtime, energy required on a low power MCU and/or using a secure element to compute the signatures). It is in the context of blockchain integration.

I won’t share the paper before it is published but I can share some of the data I gathered if someone has some interest in it.

1 Like
13

If OTAA root keys (NwkKey and AppKey) are hardcoded, like literally in your code, they are stored in the clear in the hex file, you probably check them in to version control and it’s pretty hard to change them per device so a lot of times we see the same root keys being used for multiple devices.

If ABP session keys (*SKey) are hardcoded, you have the same problem as above, plus you can never change them so once these session keys are compromised, your devices is compromised, while with OTAA, you can rejoin to get new session keys.

That’s why it’s a red flag. Hope it’s more clear now.

14

There is no such mechanism built in LoRaWAN spec.

There are two approaches here;

  1. Use a dedicated hardware secure module (HSM) that is already provisioned by the manufacturer. This HSM contains the JoinEUI and DevEUI, so the Join Server can be identified and can identify the device. There will be cheap modules on the market that are preprovisioned on The Things Industries Join Server (that works with any LoRaWAN network)
  2. Almost same as 1, but this time there is a “first join” procedure that configures the device with its final JoinEUI and DevEUI.

So essentially it comes down to adding a secure element to your PCB that differentiates the device; your application code is exactly the same. This secure element is pre-provisioned; you just buy a reel and you’re done.

1 Like
15

Johan,

in the streetlights example… all lanterns must be pre provioned (with HSM) to be able to use multicast control ?

16

But does it mean that anyone who sets up his own receivers and a triangulation algorithm can track LoRa nodes without the need to decrypt anything? So the “privacy” of the lora node is compromised?

17

There’s not really an end session time, but there is a timeout. We defined for class C a timeout of 2^TimeOut in seconds with TimeOut a 4 bit value, so you get about 22 days maximum, with no traffic, and for class B 128*2^TimeOut in seconds. Should you need longer, either multicast ping down, or set up new multicast groups every now and then.

Next to the timeout, there’s a maximum frame count, which is a 32-bit unsigned number, like normal frame counters.

18

Hi @johan,
Thanks for the overview. I am missing some privacy features in LoRaWAN similar to the randomized addressing in Bluetooth LE, capable of protecting a roaming device (person) against geo-tracking. Is this problem being addressed? Or do everyone just assume that all devices are stationary and that geo-tracking therefore is an irrelevant threat.

19

Your analysis is correct indeed! Also larger industrial adoption requires HSMs, plus availability of them is also better and better, just like isolation without dedicated hardware.

Certification is about compliancy with specification (LoRa Alliance) and regulations (FCC, EC, etc).

Indeed, the costs that HSMs bring are not worth it for many LoRaWAN use cases. This is not just the bill of material, but also sourcing, power consumption, PCB space, testing, Join Server SLA, etc. However, it is crucial for many use cases, so it must be available. Also, there’s a role for manufacturers to come with integrated, pre-provisioned modules, sips and socs.

Also do note that you do not need to use a dedicated HSM on the end device. There’s the relatively new Arm TrustZone, also available in low cost chips (like Arm Cortex M23 and M33), that offers hardware isolation from secure operations (like key derivation, MIC check, encryption/decryption) and the application. Much cheaper, also more secure than doing things in memory.

20

They would need to be pre-provisioned for their unicast (class A/B/C) session anyway, and part of that provisioning, there is provisioning for multicast.

In LoRaWAN 1.1, this is free, as the McKEKey is derived from McRootKey, which is in turn derived from AppKey that you already need for unicast. In LoRaWAN 1.0.x, you need a second root key, next to AppKey that you already have.

However, as multicast devices share the same security session, you want them to use HSMs that also keeps the session keys secure, because otherwise an attacker with access to one device can read the session keys and start spoofing downlink.

Therefore, it is highly recommended to use HSMs for multicast. You would only setup multicast groups with devices of which you know they are using an HSM. As you setup multicast groups per device using their unicast session, and as the McKey is sent encrypted using that McKEKey, you need to ensure that the end device’s AppKey has once been provisioned in an HSM. If you are street light company P, you know how your street lights are provisioned, so that’s easy.

2 Likes