LoRa security strengthened by Microchip secure authentication

Article By : Steve Taranovich

LoRa is based on a pre-shared key architecture, but that is not good enough to address network security basics.

Microchip is no stranger to security solutions. They began with a Crypto ASIC collaborating with IBM in 1998 and implemented a number of other security solutions over the years culminating in a most impressive Advanced IoT Secure Element solution with their ATECC608A.

At the 2018 MEMS Executive Congress, Cynthia Wright, Principal Cyber Security Engineer, MITRE Corporation presented a call-to-action keynote on cybersecurity. Also, my visit to Vancouver, Canada last summer alerted me to LoRa security needs. We heard Antony Passemard, head of product management for Google Cloud IoT, say that the LoRa Alliance’s vision around interoperability and openness aligns with the Google Cloud IoT mission to build the world’s most open cloud and enable faster innovation and tighter security.

Connected devices are under accelerated software attack by hackers in this age of the IoT. Trust/authentication is critical on all networks because hackers are talented and want to disrupt systems because they can, or for the glorification they will get from their peers, or even for international or corporate espionage and disruption.

Current LoRa security

LoRa is based on a pre-shared key (PSK) architecture right now, but that is not good enough to address network security basics (Figure 1).

Figure 1 LoRaWAN 1.1 authentication right now (Image courtesy of Microchip)

Device vulnerability
In the existing LoRaWAN system, authentication keys are typically stored in flash memory. These keys are accessible to hackers and subject to counterfeiting, enabling a device identity theft possibility.

Backend vulnerability
In LoRaWAN 1.0x an AppSKey can be derived by a network server provider owing the AppKey and thus associated customer data can be decrypted. Also, an application server provider can use an AppKey to derive the NwKSKey and clone LoRaWAN end nodes.

LoRaWAN 1.1 improved backend security so that when in the possession of an AppKey only the AppSKey is derived. Also, with the NwKKey, only the NwkSKey can be derived.

However, the AppKey and NwKKey are still accessible and exposed to software and people. More security is needed.

Re-keying vulnerability
We need to look at how to transfer a key from network to network servers as well as application to application servers at a global scale. The challenge is we first need to copy the key to move it and then we need to trust the old network.

In the server solution we need a new root key (re-keyed). This can be generated in the application or the network servers, but is still exposed to software attacks.

In the node solution we also need a new root key (re-keying). Today, the new key is pushed over the air between/from servers, but this is still exposed in the microcontroller and is created from the untrusted, unvalidated root key.

Supply chain vulnerabilities from humans to servers

Figure 2 The supply chain has vulnerabilities from humans to servers (Image courtesy of Microchip)

Figure 3 shows a summary of vulnerabilities in secure authentication in LoRaWAN.

Figure 3 A summary of vulnerabilities in secure authentication in LoRaWAN today (Image courtesy of Microchip)

[Continue reading on EDN US: Secure distribution of shared keys]

Steve Taranovich is a senior technical editor at EDN with 45 years of experience in the electronics industry.

Related articles:

Leave a comment