But even with the technology, we can apparently do better. We’re going to focus today on the LoRaWAN collection of wireless networks dedicated to low-throughput remote device communication. Now… you may be aware that the LoRaWAN network writ large uses LoRa technology, which originates out of Semtech. So you might expect this new discussion to involve Semtech. Nope. It originates both out of the latest 1.1 version of LoRa and out of a program put together by Microchip in conjunction with The Things Industries (TTI). It features a Microchip security device and a service from TTI, but… well, I’m getting ahead of myself. Let’s talk about the problem first.

And I’ll say that this stuff can get yoAfter all of these years (I know, it’s not actually a lot – just feels like it), you’d think that we had security sorted for the IoT. To be clear, I’m talking about the “in theory” parts of it. In other words, the how-to technology. That bit about getting product planners to use it? Yeah, we’ve still got some work to do there.

u a little… woozy thinking too much about it. So I’ve endeavored to make sure it’s right (while hijacking Microchip’s and TTI’s time asking for clarifications). If any of the details get pointed out as being off, I’ll update.

LoRaWAN Authentication

With the 1.0 version of LoRa, you have an application running in the cloud somewhere on what’s called the App server. Getting to that server requires permission to communicate, and that’s handled by a Network server. Each of these servers is unlocked by a separate session key. But – and this is critical – those session keys are derived from a single root key.

It’s important to note here that LoRa relies on AES for encryption. That means symmetric keys, and it means you don’t have a session key exchange in the way you might for authentication via the public-key infrastructure (PKI). PKI involves a public key that can be sent out in the clear; messages are encrypted using that public key, but they’re decrypted using the private key that, supposedly, only the owner has.

The good thing about that is that you have a way to exchange symmetric keys, since the public key can be used to encrypt any other keys being exchanged. So the act of sending a key somewhere isn’t particularly dangerous if you do it right. But edge devices using LoRa don’t use PKI, so they can’t do that. Instead, they rely on pre-shared keys (PSK) that are set up during provisioning on the manufacturing floor.

So these root keys that LoRa uses to generate session keys are shared ahead of time, and, during actual use, the session keys are created by some function involving a nonce – or one-use-only – number. That nonce can be easily exchanged in the clear, since it isn’t a secret, and it’s not useful without the root key.

This may remind you of a discussion we had last week about LonWorks private keys. The difference here is that, where LonWorks uses the same key for all devices, LoRa has separate keys for each edge device. That would seem to mean that a database must be kept of all of the keys associated with different device IDs, but… well, we’ll come back to this.

OK, so, back to our original problem: we’ve got a single pre-shared root key that’s creating two session keys – one for the network and one for the application. But those keys are typically stored in the edge device in flash – possibly not encrypted in order to keep the computing requirements in the edge device low. That means that, in theory, the app server could find it and figure out the network session key, and vice versa.

So, change number one: there are now two separate root keys: one used to generate the network session keys; one used to generate the application session keys. That helps, but if those root keys are still wallowing about out there in open flash memory, they’re still vulnerable. Here’s where Microchip and TTI have come together to make authentication tougher (and, unfortunately, more complicated).

First, let’s talk about the network topology. Everything that an edge device talks to goes through a gateway. Since that gateway is always involved, I’m going to simplify the following discussion and figures by omitting the gateway from any communications between the edge device and anything else. You won’t see it, but it’s there.

The next important point is that the edge device never talks directly to the application server. Everything goes through the network server. So, per the 1.0 version of all of this, the edge device requests to “join” the network and the application by sending the request to the network server, which generates the application session key and sends it to the application server. It then sends a “join accept” message back to the edge device. This is illustrated in the following figure.

The Join Server Joins the Party

What’s changed now is that a join server has been added to the network. This join server is provided as a service by TTI. TTI has shared two master root keys with Microchip; one of them is for provisioning. Both the tester or trusted platform module (TPM) and the join server use this master key with a device ID to create device root keys. The join server gets the IDs from a “manifest” that the customer downloads from Microchip and then sends to TTI.

Both Microchip and TTI have the key-creation algorithm that uses the device ID, so the join server doesn’t have to store the keys in a database; all it needs is that ID to figure out the root key. Microchip provisions the edge device at test – we’ll come back to that in a sec, and the customer sends the device ID to TTI via that manifest. The join server then gets the device ID during a join request, and, from that, the join server can re-create the root keys. So there’s no key storage database to hack; just a list of device IDs (and you could even do without that if you didn’t want to check whether a particular device ID was valid).

So when the edge device requests to join the network, the network server summons the join server for authentication. The join server creates the two session keys from the two root keys (having created the root keys from the device ID) and from the nonce and sends them to the app and network servers, as illustrated below. The join server then bows out; it does not participate in normal application traffic.

You might wonder how those keys get safely sent to the other servers, since we just talked about not having PKI to work with. Well that applies only to the edge device, since PKI uses valuable resources. But the servers themselves use PKI, so the keys can be sent encrypted to the other servers. The edge device can create its own session keys, since it has the root keys, and it generates the nonce, from which the session keys are derived. So there’s no need to send keys to or from the edge device.

But does that mean that, in the edge device, we are still left with that issue of keys stored in flash? No, because Microchip is recruiting one of its own devices – the ATECC608A – to act as a secure element. We mentioned the predecessor of this device – the 508A – a few years back, from Atmel. Atmel was bought by Microchip, and the 608A has a few extra features – in particular, AES acceleration – that make it well suited for this application.

This device has keys programmed in during manufacturing or test, done by Microchip. After that, those keys are never accessible. There is no instruction that allows them to be output; they’re locked in there, and any operations that use them are done within the device.

While it would be sheer hubris to suggest that it’s impenetrable, they have taken many steps to thwart physical attacks, like encrypting the contents, encasing it in a metal pattern to block EMI, and having it destroy contents if it detects that it’s being brutally hacked open. So… even if not provably perfect, it’s orders of magnitude better than keeping keys in the clear in flash.

Retaking Control

OK, so this gets us through the basic provisioning and onboarding or joining processes. But here’s the thing: when it comes to security, some companies want to keep as much control as they can. And yet this process involves a third-party server – TTI’s join server – in every operational step. And, at some point, that service may not be free. What if you don’t want that?

It’s possible to move the join server to a private server controlled by the edge-device manufacturer. You may remember that I mentioned that TTI shared two master keys with Microchip. We’ve looked at only one of them – the one used to derive the root keys both at manufacturing and in the join server during a join request.

The second one is a rekeying master. It’s used with a separate nonce to generate new root keys; this is done with a rekeying server (are you still with me?). If you change join servers, you want new root keys (so that data in the old one is no longer valid). During manufacturing, you’d still be engaging with the original TTI join server, but then you’d move each device off of that join server to the new join server with new root keys.

The means by which the rekeying server sends the new root keys to the new join server has apparently not been defined yet, so it has not been implemented. Once you’ve moved to a new join server, the rekeying server (owned by TTI) is now out of the picture.

It’s theoretically possible even to do your own “first-join” server – the one used in manufacturing. Instead of using the TTI join server and then moving the devices off to the new join server, you’d use your own join server for everything. However, doing so means engaging closely with TTI and Microchip, getting master keys, and licensing technology. Sounds like it’s not a simple deal. But doable if it’s that important.

So there you go. Between LoRa 1.1, with two root keys, Microchip’s 608A device, and TTI’s join servers, there’s a more robust way to handle key exchange and management without needing the edge device to get bogged down with PKI.

While we slogged through some details here, end users and even edge-device manufacturers mostly aren’t exposed to those details. The following image from Microchip summarizes the purchase-and-manufacturing steps needed. The rest of the details are handled by the technology.

(Click to enlarge; image courtesy Microchip)

By the way, I mentioned that limited resources make PKI hard to implement in some edge devices. Yes, they could add more resources, but that costs money. What about this 608A device that’s now added to the bill of materials? It also costs money, but quick scans suggest it’s less than a buck, so hopefully not something that will break the bank.

More info:

Microchip LoRaWAN security

Sourcing credit:

Xavier Bignalet, security product marketing manager, Microchip Technology, Inc.

Johan Stokking, CTO & Co-Founder, The Things Industries