LoRa Security issue

With all the issues occurred a week ago where an estimated 100000 end devices caused the flooding and lot of US services and websites being affected made ma to look more closely to the LoRa protocol. 

According to the specification of the LoRaWAN the MAC Frame Payload Encryption (FRMPayload 4.4.3) the encryption scheme used is based on the generic algorithm described in the IEEE 82.15.4/2006 using AES with a key length of 128 bits.

Looking on the key this can be NwkSKey if FPort is zero or AppSKey if FPort is 0x01 ..0xFF. So it is a fixed key. This key is used to encrypt / decrypt as I've explained in this blog post. 

The problem appears on the first frame when every time will have the same key and probably the same data, so if someone is intercepting this for few times the key K and Ai can be found.

Si=aes128_encrypt(K,Ai)

Since the Ai is the same the only way to keep the LoRaWAN secure is to send as first data a RANDOM payload and maybe also an random value of FCntUp. 

In this way will be harder to find the K and decode the payload. 

I hope that the next version of LoRaWAN protocol will address the security issues we encounter these days.

New MOTE online

As you know I've received ten modules from dorji.com and I couldn't wait to test them, so today I've solder the first one.

Because the modules are build to be surface mount and I didn't had a board for that I had to improvise. To connect the pads to my development board I've used old terminals from resistors or LEDs. This step was much easy comparing to niceRF modules since the distance between the center of pads is 2mm instead of 1mm.

DRF1276G from dorji.com

DRF1276G modules is connected to an ESP8266 NodeMCU module and it runs the LMIC code.

Other great feature of the DRF1276G module is that I can solder a SMA connector for external antenna directly on it.

9 to go now...

I am curious if the one of the other 16 gateways in Eindhoven are receiving my data transmitted by my three nodes because I  receive packets transmitted by others.

In plan: ESP8266 with GPS and LoRa

Few months ago I bought an GPS receiver from http://navspark.mybigcommerce.com/navspark-mini-uart-to-usb-adapter/ along with an GPS antenna.

The board is "free", just need to pay $10 for delivery :-)
I recommend you to take also the antenna for an extra $9 since without it the board is useless.

The board is :

HARDWARE SPECS
* 100MHz 32bit LEON3 Sparc-V8 + IEEE-754 Compliant Floating Point Unit
* 1024KB Flash Memory + 212KB RAM
* 1x full duplex asynchronous UART
* 1x SPI shared with GPIO
* 1x 2-wire interface shared GPIO
* Atomic clock synchronized P1PPS time reference with +/-10nsec accuracy

GPS SPEC
* 167 channel Venus 8 engine
* Uses GPS, SBAS, QZSS signals
* 1 ~ 10 Hz update rate
* Position accuracy 2.5m CEP 
* Velocity accuracy 0.1m/sec
* Warm start TTFF under open sky 29sec average
* Cold start TTFF under open sky 30sec average
* Cold start sensitivity -148dBm
* Tracking sensitivity -165dBm
* Operating range : (altitude < 18km) or (speed < 515m/sec), both not exceeded simultaneously

http://navspark.mybigcommerce.com/content/GNSS_Viewer.zip 

http://navspark.mybigcommerce.com/content/GNSS-Viewer-User-Guide.rev0.2.pdf

The plan is to connect the GPS with the ESP8266 and with the new LoRa modules from Dorji.com to have a full LoRaWAN module.

I guess can use this setup also as a single channel gateway for LoRaWAN. It will be very small, cheap, battery operated, ideal for demos, students and as a LoRa STARTER KIT.

More devices IN

I've completed to code to add more devices, so now the module as common code can:

• update from OTA server if the version on server is bigger the its own version of code
• get the data from AUTH server (topics, type, MQTT server etc, credentials)
• get the time from NTP server
• log data to an external server
• log debug data to a DEBUG server
• do  CRON tasks on GPIO pins based on schedule received from Android App
• send status and its state to Android app.

All these features are part of the common code that will run an all my modules.
Now sky is the limit on what each module can do : 

• temperature,
• humidity, 
• noise, 
• presence,
• gas detection, 
• acceleration, 
• vibration, 
• measuring power consumption, 
• controlling blinds, 
• garage door, 
• boiler, 
• irrigation controller, 
• fish tank, 
• motors, 
• air conditioning or a thermostat etc
• coffee machines
• washing machines
• fridge
• remote control substitute for TV, Satellite dish, Cable TV or any other IR
• power sockets
• exterior lights
• interior lights
• power sockets
• air quality

And the beauty is that I am not limited by the WiFi, the same things I can do with my new LoRa modules.

The all power will be at your finger tips.

 Obs: Later I'll try to add some Artificial Intelligence (AI) to my system, because the IoT without AI  is pretty  much limited on manually or semi automatic control.

Esp8266 meets LoRaWan

I guess that you don't have any doubts that ESP8266 can do LoRaWan.

For this project I've used two modules:

1.LoRaWan Single Channel Gateway

Single channel gateway ( to be compatible with LoRaWan you must have 8 channes) was made using the SX1276 module and a Raspberry Pi2. Comunication is done over SPI using wiringPi library.

Single channel gateway

2.LoRaWan node with ESP8266 

For node I've used the Witty module with the modifications from this post.
As a software I've used the ported LMICv1.51 and modified to send data to only one channel since the gateway is single channel ( I am using 868.1Mhz).

Lora Node with ESP8266

Now the gateway is enrolled in TTN ( https://thethingsnetwork.org/) and the data has started to arrive. I've managed to receive also data from other surrounding nodes.


On the gateway data looks like:



Packet RSSI: -107, RSSI: -105, SNR: -11, Length: 108

rxpk update: {"rxpk":[{"tmst":368384825,"chan":0,"rfch":0,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":-11,"rssi":-107,"size":108,"data":"Wqish6GVYpKy6o9WFHingeTJ1oh+ABc8iALBvwz44yxZP+BKDocaC5VQT5Y6dDdUaBILVjRMz0Ynzow1U/Kkts9AoZh3Ja3DX+DyY27exB+BKpSx2rXJ2vs9svm/EKYIsPF0RG1E+7lBYaD9"}]}


and data from my nodes:

Packet RSSI: -28, RSSI: -105, SNR: 12, Length: 31

rxpk update: {"rxpk":[{"tmst":1060664170,"chan":0,"rfch":0,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":12,"rssi":-28,"size":31,"data":"QGIH4AIAqgABvJNVF4DpUapp/xQN1REVnI+jYoR6Ig=="}]}

Next I'll have to add sensors to nodes and to run some tests for range and buy a real gateway.

More info about LMIC port and code here.

About LoRa and LoRaWan

LoRa is based on opened radio-frequency communications, different frequencies are used depend on locations:

• 430 Mhz – valid for Asia
• 780 Mhz – valid for China
• 433 Mhz – valid for Europe
• 866 Mhz – valid for Europe
• 915 Mhz – valid for USA

LoRa supports different Data Rates and offer a large radio link budget over 160dB. The power consumption is about 40mA during transmission and 10mA during reception. It allows a wide coverage : about 2.5Km from antenna inside a city and up to 15km in a countryside.

LoRa is based on a Spead Spectrum technology this technology helps to reach long distance over noise boosting up to 10x the distances obtains with classical transmission systems. It also have a good shifting frequency immunity.  LoRa sound to have good results on movement. It uses wide-band linear frequency modulated pulses. Frequency increase or decrease to encode the information.

LoRaWAN Classes, © 2015 LoRa™ Alliance.

LoRaWAN™ is a Low Power Wide Area Network (LPWAN) specification intended for wireless battery operated Things in regional, national or global network. LoRaWAN target key requirements of internet of things such as secure bi-directional communication, mobility and localization services. This standard will provide seamless interoperability among smart Things without the need of complex local installations and gives back the freedom to the user, developer, businesses enabling the roll out of Internet of Things.

LoRaWAN network architecture is typically laid out in a star-of-stars topology in which gateways is a transparent bridge relaying messages between end-devices and a central network server in the backend. Gateways are connected to the network server via standard IP connections while end-devices use single-hop wireless communication to one or many gateways. All end-point communication is generally bi-directional, but also supports operation such as multicast enabling software upgrade over the air or other mass distribution messages to reduce the on air communication time.

Communication between end-devices and gateways is spread out on different frequency channels and data rates. The selection of the data rate is a trade-off between communication range and message duration. Due to the spread spectrum technology, communications with different data rates do not interfere with each other and create a set of "virtual" channels increasing the capacity of the gateway. LoRaWAN data rates range from 0.3 kbps to 50 kbps. To maximize both battery life of the end-devices and overall network capacity, the LoRaWAN network server is managing the data rate and RF output for each end-device individually by means of an adaptive data rate (ADR) scheme.

National wide networks targeting internet of things such as critical infrastructure, confidential personal data or critical functions for the society has a special need for secure communication. This has been solved by several layer of encryption:

• Unique Network key (EUI64) and ensure security on network level
• Unique Application key (EUI64) ensure end to end security on application level
• Device specific key (EUI128)

LoRaWAN has several different classes of end-point devices to address the different needs reflected in the wide range of applications:

• Bi-directional end-devices (Class A): End-devices of Class A allow for bi-directional communications whereby each end-device's uplink transmission is followed by two short downlink receive windows. The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol). This Class A operation is the lowest power end-device system for applications that only require downlink communication from the server shortly after the end-device has sent an uplink transmission. Downlink communications from the server at any other time will have to wait until the next scheduled uplink.
• Bi-directional end-devices with scheduled receive slots (Class B): In addition to the Class A random receive windows, Class B devices open extra receive windows at scheduled times. In order for the End-device to open its receive window at the scheduled time it receives a time synchronized Beacon from the gateway. This allows the server to know when the end-device is listening.
• Bi-directional end-devices with maximal receive slots (Class C): End-devices of Class C have nearly continuously open receive windows, only closed when transmitting. Class C

[Text from https://www.lora-alliance.org/What-Is-LoRa/Technology]

More details about the protocol can be found in the document.