Enhanced LoRa security with Microchip Secure Authentication

Microchip is no stranger to security solutions. They started with the Crypto ASIC in partnership with IBM in 1998 and have implemented many other security solutions over the years, eventually introducing the most impressive Advanced IoT Secure Element solution and its ATECC608A.

At the 2018 MEMS Executive Conference, Cynthia Wright, chief Cyber Security Engineer at MITRE Corporation, delivered a call-to-action keynote speech on cybersecurity. In addition, when I visited Vancouver, Canada last summer reminded me of the security needs of LoRa. We heard that Antony Passemard, head of product management at Google Cloud IoT, say the LoRa Alliance's vision for interoperability and openness aligns with the Google Cloud IoT mission to build the world's most open cloud for faster innovation and stricter security.

In this era of the Internet of Things, connected devices are attacked by hackers' accelerated software. Trust/authentication is critical to all networks because hackers are gifted and want to undermine the systems because they can, or in order to gain the glory they receive from their peers, or even for international or corporate spies and destruction.

Current LoRa security

LoRa is currently based on the Pre-Shared Key (PSK) architecture, but this is not enough to address the basics of network security (Figure 1).

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

Device vulnerability

In the existing LoRaWAN systems, the authentication keys are typically stored in flash memory. These keys are accessible to hackers and are forged, enabling the possibility of device identity theft.

Backend vulnerability

In LoRaWAN 1.0x, AppSKey can be exported by a network server provider because the AppKey can decrypt relevant customer data. In addition, an application server provider can use an AppKey to derive NwKSKey and clone LoRaWAN end nodes.

LoRaWAN 1.1 improved back-end security so that only AppSKeys are exported when the AppKey is owned. In addition, with the NwKKey, only the NwkSKey can be exported.

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

Re-keying vulnerability

We need to understand how to transfer a key from network servers to network servers and application to application servers at a global scale. The challenge we face is to 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 it 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, unauthenticated root keys.

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)