LoRaWAN security design tips: Designing with a stand-alone security chip

With the growth of the Internet of Things, cyber attacks are increasing at an alarming rate (Figure 1). Key provisioning, a process of key generation and device authentication, is a critical part of establishing security. Whoever holds the key will be able to access the payloads, i.e. the valuable data stored in the application server(s). While the LoRaWAN specification defines the process of key provisioning, it is up to developers to ensure that the key provisioning steps are securely carried out.

During the manufacturing process, the end devices are assigned two root keys as specified by the LoRaWAN specification v1.1 (NwkKey and AppKey ). When the end devices attempt to connect with the application server via the network server, by sending the root key related information over, there’s no guarantee that this process is secure. In some cases, the information is just written down by the contract manufacturer’s employees on a piece of paper. The real risk is that if a hacker gets ahold of the root key by either copying or re-keying, the system security will be compromised.

A security chip comes to the rescue

Last February, Microchip Technology introduced a single-chip (ATECC608A) solution where a separately downloaded, one-of-a-kind code is paired with a chip that has a unique ID. The security chip is an 8-pin, low-power IC which draws 150nA in sleep mode. As shown in Figure 2, ATECC608A is assigned a unique ID when it is shipped to the customer/manufacturer. Additionally, a manifest file can be downloaded by the customer. To further increase security, the customer obtains the chip and the manifest file via different channels.

How does the authentication process work?

As shown in Figure 2, there are multiple steps involved. Step 1 is self-explanatory. Steps 2 and 3 show the two important components that the customer will obtain to achieve security; the chip and the manifest file, as explained earlier. Step 3 is the most important. At this point, the customer will upload the manifest file information to the Join Server. (See footnote 1). In this case, the Join Server is supported by a third party, The Things Industries (TTI). Note that the manifest file contains all the needed information, including the unique ID of the device. Prior to this step, TTI has already received the chip information from Microchip. Any information uploaded by the customer can be verified by TTI. Once verified, true authentication is complete, as shown in Step 4.

What if the chip is stolen?

There’s always the possibility that the chip could be stolen and fake devices built. However, TTI has the chip identity on record, so if a manifest file is missing or a fake ID is created, the authentication will fail and the request to join will be rejected.

Using the combination of a security IC chip and a manifest file protects the true identity of the end device. The four-step process allows the customers/users to achieve a high level of security. Even if the security IC chip is stolen, hackers still cannot connect with the application server or join server to steal data. Finally, one other advantage of using the manifest file is its scalability. Tens of thousands of security ID’s can be efficiently uploaded to the join servers all at once. 

Footnote 1: The LoRaWAN specification calls out the application, network, and join servers. The network server is operated by the network provider. The application is operated by the end user. Alternately, the end user may choose not to own but to lease the application server from the network provider. Finally, the join server is typically operated by a third party independent of the network provider to increase security. In this case, the network provider will not have access to the security keys.