Tech Journal

On-boarding Devices to the Helium Network

Posted by Kent Williams on May 18, 2020 12:00:00 AM

On-boarding Devices Securely

There are many diverse applications for LoRaWAN® devices. Similarly, there is a wide and diverse population of end users. These factors lead to a device on-boarding process that takes just as many forms. Device on-boarding is the process of associating a device with a particular network and application server. It is the foundation of a device's level of security. It precedes and enables device activation, whether over-the-air activation (OTAA) or through activation by personalization (ABP), which themselves become compromised if the device on-boarding is done incorrectly.

This is our second post in a series on the LoRa® Developer Portal introducing you to the Helium Network. For an introduction to Helium, see the first article in this series. In this article we’ll cover some of the most common methods of distributing devices and provide a high-level discussion of the security implications involved with each. We’ll then look at the available on-boarding options from Helium and look at how each can best be used.

Security vs. Simplicity and Flexibility

When on-boarding devices, there are several important considerations related to storing and possibly displaying keys that can affect the security of the product. The end user, the application and the deployment environment will all dictate the tradeoffs that make the most sense.

Let’s look at some of the most common ways in which devices are on-boarded and the tradeoffs involved. Keep in mind that, as is true for all on-boarding cases, if the hardware is compromised, it’s pretty safe to assume the device and its data are also compromised. Here, we are only discussing the handling of AppKeys, and how it relates to vulnerabilities introduced by the end user handling these during the on-boarding process. The goal is to avoid compromising the AppKey, preventing a bad actor from listening to the packets when the device is joining the network, and ultimately being able to decrypt all future traffic.

Scenario 1

The AppKey of a device is prominently displayed on the device or another medium given to the user.

  • Pros:
    • This allows the user to freely and easily on-board the device with any compatible network.
  • Cons:
    • This is the least secure on-boarding method. The device can be easily compromised if this information is lost or stolen.

 Scenario 2

The device can reset its AppKey during deployment and it can be securely read out of the device a single time.

  • Pros:
    • This again allows the user to freely on-board the device with any compatible network with ease.
    • Limits the likelihood of the user improperly storing the AppKey.
  • Cons:
    • Requires more tooling to enable the retrieval of the AppKey from the device.

 Scenario 3

The device only displays a DevEUI in text or QR code form so that it can be identified by an application when a customer receives and registers the device. In this scenario, the AppKey is never handled by the user.

  • Pros:
    • This on-boarding scenario is more secure than the previous examples in that the user never handles the AppKey directly.
  • Cons:
    • This approach requires that the manufacturer have a reasonably complex application backend to coordinate the association of the device with a stored AppKey that can be shared with a network server.

Scenario 4

The device is only on-boarded by the manufacturer in a trusted environment.

  • Pros:
    • This provides a seamless experience for the user, relieving them from the need to perform the on-boarding step themselves.
  • Cons:
    • As with Scenario 3, this requires that the manufacturer have a reasonably complex application backend to coordinate the association of the device with a stored AppKey that can be shared with a network server. The manufacturer in this scenario also has the additional burden of conducting the on-boarding process themselves.
    • By off-loading the device on-boarding process, the user has less flexibility in managing their devices.

As you can see, there are many options, each with their own unique tradeoffs. Fortunately, the diversity of applications is one of the greatest strengths of the LoRaWAN ecosystem and we have the tools at Helium to help you on-board all of them.

Helium Console

Console is Helium’s device management product. It provides three ways for users to onboard and manage their devices on the Helium Network, regardless of whether they are a device manufacturer, application provider or end user.

Web-based Dashboard

The web-based Console is our most feature-rich tool. It is useful not only for large companies but for individual makers as well. With this tool you can easily manage thousands of devices or just a few. You can learn how to use it here.

CLI Utility

Our Console CLI tool is best for those who prefer to work from a command line or who aim to automate the management of a large number of devices. This tool is typically used in the manufacturing process, to easily add devices as they are provisioned and programmed on the line. For more information, see this recent blog post.

API

Our Console API is for those wanting to tightly integrate on-boarding and device management with their own products or tools. You can check out the APIs here.

Up Next

In the next post, we’ll build on device security and take a deep dive into deploying some LoRaWAN sensors to the Helium Network. Until then, get started with Helium here:

 

 

Semtech, the Semtech logo and LoRa® are registered trademarks or service marks of Semtech Corporation or its affiliates.

Topics: LoRa Developers, LoRaWAN Deployment, LPWAN