LoRaWAN: Dream wireless communication for IoT

(Above: The LoRaWAN Logo. Nope, I'm not affiliated with them in any way - I just find it really cool and awesome :P)

Could it be? Wireless communication for internet of things devices that's not only low-power, but also fairly low-cost, and not only provides message authentication, but also industrial-strength encryption? Too good to be true? You might think so, but if what I'm reading is correct, there's initiative that aims to provide just that: LoRaWAN, long-range radio.

I first heard about it at the hardware meetup, and after a discussion last time, I thought I ought to take a serious look into it - and as you can probably guess by this post, I'm rather impressed by what I've seen.

Being radio-based, LoRaWAN uses various sub-gigahertz bands - the main one being ~868MHz in Europe, though apparently it can also use 433MHz and 169MHz. It can transfer up to 50kbps, but obviously that's that kind of speed can also be reached fairly close to the antenna.

Thankfully, the protocol seems to have accounted for this, and provides an adaptive speed negotiation system that lowers data-rates to suboptimal conditions and at long range - down to just 300bps, apparently - so while you're not going to browsing the web on it any time soon (sounds like a challenge to me :P), it's practically perfect for internet-of-things devices, which enable one to answer questions like "where's my cat? It's 2am and she's got out again....", and "what's the air quality like around here? Can we model it?" - without having to pay for an expensive cellular-based solution with a SIM card.

It's this that has me cautiously excited. The ability to answer such questions without paying thousands of pounds with certainly be rather cool. But my next question was: won't that mean even more laughably insecure devices scattered across the countryside? Well, maybe, but the LoRa alliance seems to have thought of this too, and have somehow managed to bake in 128-bit AES encryption and authentication.

Wait, what? Before we go into more detail, let's take a quick detour to look at how the LoRaWAN network functions. It's best explained with a diagram:

1. The IoT device sends a message by radio to the nearest gateways.
2. All gateways in range receive the message and send it to the network server.
3. The message travels through the internet to the network server.

In essence, the LoRa network is fairly simple multi-layered network:

• IoT Device: The (low-power) end device sending (or receiving) a message.
• Gateway: An internet-capable device with a (more powerful) LoRa antenna on it. Relays messages between IoT Devices and the requested network sever.
• Network Server: A backend server that sends and receives messages to and from the gateways. It deduplicates incoming messages form the gateways, and sends them on to the right Application Server. Going in the opposite direction, it remembers to which gateway the IoT device has the strongest connection, and sends the message there to bee transmitted to the IoT device in the next transmit window.
• Application Server (not pictured): The server that does all the backend processing of the data coming from or going out to the IoT Devices.

Very interesting. With the network structure out of the way, let's talk about that security I mentioned earlier. Firstly, reading their security white paper reveals that it's more specifically AES 128 bit in counter mode (AES-128-CTR).

Secondly, isn't AES the Advanced Encryption Algorithm? What's all this about authentication then? Well, it (ab?)uses AES to create a CMAC (cipher-based message authentication code) for every message sent across the network, thus verifying it's integrity. The specific algorithm in use is AES-CMAC, which is standardised in RFC 4493.

Reading the white papers and technical documents on the LoRa Alliance website doesn't reveal any specific details on how the encryption keys are exchanged, but it does mention that there are multiple different keys involved - with separate keys for the network server, application server, and the connecting device itself - as well as a session key derivation system, which sounds to me a lot like forward secrecy that's used in TLS.

Since there's interest at the C4DI hardware meetup of possibly doing a group-style project with LoRaWAN, I might post some more about it in the future. If you're interested yourself, you should certainly come along!

Sources and Further Readings

• Rob Miles on LoRa
• LoRaWAN Technical Introduction
• LoRaWAN White Papers
• LoRaWAN Security White Paper
• RFC 4493: AES-CMAC
• arduino-lmic: A LoRaWAN implementation in C

My robot works!

I went to the hardware meetup again today. For the last 2 times I've either managed to forget or I've been on holiday (probably both...), but I remembered this time around and I decided to go. I'm glad I did, because, with Rob's help I fixed my robot! It is now trundling around on the floor quite happily :D

The problem was that I assumed that the digital pin numbers on the wemos D1 R2 were the same as the GPIO pin numbers, which isn't the case apparently. Here's a table:

Digital	GPIO
D0	GPIO 16
D1	GPIO 5
D2	GPIO 4
D3	GPIO 0
D4	GPIO 2
D5	GPIO 14
D6	GPIO 12
D7	GPIO 13
D8	GPIO 15

(Table from wemos.cc)

Very odd numbering. It's rather frustrating actually! Anyway, there seemed to be quite a lot more people there this time as compared to last time - it looks like the idea is taking off, which I'm very glad about :-)

If you're in the Hull area and interested in hardware, you should seriously consider coming along. There's a page on meetup.com that contains the details of the next meetup, but the general rule of thumb is that it happens at C4DI every first and third Thursday of every month at 6pm - 8pm.

Before I forget, I'm going to end this post off by posting the modified version of Rob's hull pixelbot dance code that works on the Wemos:

(Git Repo, Raw)