LoRaWAN based Secured Micro-Transactions

Prof. D. Janakiram, Dr. Susmita Mandal, Shri. Rajiv Ramachandran

Background

Financial inclusion is crucial to reaching the last mile and enabling economic growth in rural areas. Accordingly, the focus has been on exploring effective mechanisms to reach remote locations and provide access to banking facilities, including digital payments and other financial services. However, mostly the underserved population from rural India is still facing challenges in reaping full benefits of financial inclusion. This is primarily due to lack of reliable and affordable network infrastructure for using digital solutions like Micro ATM, mobile transactions, PoS transactions, etc.

IDRBT is exploring the possibility of implementing last-mile connectivity for banking services using LoRa technology, which is ideal for long-range, low cost, low power consumption, and secure data transmission. This can be achieved using a hybrid approach for connecting wireless and wired technologies for financial transactions.

What Is LoRa?

LoRa technology is a wireless modulation technique in the physical layer, allows long-range communication using chirp spread spectrum. LoRa technology uses dedicated radios, which are not usually present in end-user devices, limiting interferences from other devices. LoRa can operate on the 868 (EU), 433 (EU), 915 (US), or 430 (AS) MHz ISM bands. In India, LoRa frequency channels are in the license free 865 MHz – 867 MHz band.

Key Features of LoRa

Long-range connectivity, consumes low power, built-in security mechanisms, globally standardized, geolocation enabled, capacity to support millions of messages per base station, low operational cost, and provides over the air firmware updates.

LoRa based Micro ATM Connectivity Design

The Architecture include:

  1. End Node – End devices can be an actuator, a sensor or both, and these are mostly battery operated. The Micro ATMs will be connected to Raspberry Pi/Arduino single-board Linux device via Bluetooth radio connection.
  2. Gateway – The gateways act as a mediator for receiving LoRa messages from end devices, then forwards it to the network server. These Gateways are connected to the internet.
  3. Network Server – Servers route messages from End Devices to the right Application, and perform the required security, and scheduling tasks.
  4. Join Server – The over-the-air activation process for end devices include uplink join request frames and downlink join-accept frames. It manages the network server for connecting with the end-devices and sharing application session key.
  5. Application Server/Dashboard – Server on which the application software is running e.g. core banking applications.

Fig 1. Architecture of LoRaWAN network

Device Activation Schemes

An end device registration occurs in either of the two activation modes: (1) Activation By Personalization (ABP), (2) Over-The-Air Activation (OTAA). The activation requires an application session key (AppSKey), a device address and a Join Server Key. In case of ABP, all three individual keys are directly stored on the end device. Whereas, in case of OTAA, end devices use a global device identifier (DevEUI) and the join server key derives the session key for joining the device to the network.

LoRaWAN Security Features

The Security features include:

  1. Mutual Authentication: As a part of Network join procedure the mutual authentication is established between end-devices and the network.
  2. Secure Session Management: The end devices use the application key (AppKey) 128 bit AES algorithm to generate two session keys:
    a) NwkSKey contributes in proving and verifying packets authenticity and integrity, b) AppSKey contributes in encryption and decryption of the application payload.
  3. Confidentiality: LoRaWAN uses the CMAC mode for authentication followed by encryption. This protection, combined with mutual authentication, ensures data is not tampered, is coming from a legitimate device.
  4. Integrity: Message Integrity Code (MIC) ensures integrity check by signing the MAC payload for preventing the manipulation of the cipher text.

Workflow Process of PoC

The proposed Proof of Concept is designed considering a sender node-gateway placed at a proximity range to an end-device receiving a message via Bluetooth and forwarding it to a designated destination node-gateway. The process flow of receiving and forwarding the encrypted message packet passes through the intermediary node-gateways placed at an approximation of 900 meters from the previous nodes. To initiate the packet exchange, the DevAddr (ID) of every node-gateway is registered with the Join Server, then a secret AppKey is shared among all the nodes from the Join Server. This process can be achieved by Activation By Personalization (ABP). We have assumed one of the node-gateway acting as a join server/receiver node. The process flow is depicted in Fig. 2.

Fig 2.  LoRaWAN sequence flow of node-gateway authentication

  1. For establishing a secure session, the sender node gateway will send its DevAddr and an encrypted message to the join server as <IDs, EncAppkey (msg)>.
  2. After receiving the request, the join server will verify the node-gateway by checking its DevAddr.
    • If it is a registered node, then the join server will generate a secret session key (AppSKey).
    • Else discard the request.
  3. Then the join server shares the secret session key with the sender node by encrypting it with AppKey along with DevAddr <IDs, EncAppkey||IDs(AppSkey)>.
  4. Later, the join server shares the same secret session key and DevAddr to the application server through a secured channel.

After successful key sharing, the end device and application server can communicate in a secured way.

Phases of Test Setups

Individual Node Setup: The following are the components for individual node setup.

A. 900 m setup with 2 nodes

The communication between two nodes has been tested in a 900-meter line of sight near the Sanathnagar railway station, Hyderabad. The duplex communication was successfully executed with packet sending and receiving acknowledgement.

Fig 3.  LoRaWAN single node setup

Fig 4.  900-meter testing with two nodes

Fig 5.  Sender side output

Fig 6.  Receiver side output

B. 6 nodes architecture setup

Fig 7.  Probable test setup of LoRaWAN

The experimental setup has been made up of 6 nodes to cover a distance of approx.5KM in line of sight. However the test was conducted within IDRBT campus with 6 nodes setup of around 150 m. Each node-gateway will be capable of broadcasting and receiving LoRa signals. The sender node sends LoRa packets in an encrypted form using a 128-bit AES algorithm. The secret session key is shared between the sender and receiver node as discussed in the node-gateway authentication process flow in Fig.2. Hence the package can be decrypted only at the destination node. The intermediate nodes will be forwarding the packet as it is received. The duplex communication was successful with six nodes, and only the sender and receiver were able to encrypt and decrypt the packets. The same setup is capable to be deployed in the rural environment.

Fig 8.  Experimental setup with 6 nodes

Fig 9.  Sender side output

Fig 10.  Receiver side output

C. PIN Verification with Android Device

An android device can be connected to the sender Raspberry Pi node through Bluetooth. The android device may act as a Micro ATM or POS machine, which would be able to communicate with the sender node. The PIN entered by the user is transmitted to the sender Raspberry Pi using Bluetooth. The Raspberry Pi will add the PIN verification request to the LoRa payload and broadcast it to the nearest LoRa receiver.

Fig 11

Fig 11.  Connecting android device to Raspberry using Bluetooth

D. ID verification with Join Server

As per the LoRaWAN architecture, a join server is required to verify every node joining to the network. The join server receives a join request from the node-gateways, and the DevAddr field in the request will be selected as unique identification number for nodes verification. The serial number of the Raspberry Pi device has been considered as a unique DevAddr (e.g., 10000000bc7db52c). The join server stores the ID of all legitimate nodes. Once it receives the DevAddr or ID as an authentication request, it will verify the identity of the nodes and send a accept response to the nodes.

The experiment was done with four Raspberry Pi nodes. One acting as a join server and rest three nodes acting as the intermediate nodes and sender node. Join server is preloaded with DevAddr of all legitimate nodes and 128-bit AppKey. It is assumed that one of the three node-gateway is legitimate and the other two are malicious. The legitimate node is loaded with secure AppKey which sends its ID along with an encrypted message to the join server. The join server will check the device ID and confirm the device is trusted. If it is a genuine node, the join server will decrypt the message and send a response (AppSKey) back to the node in encrypted format using AppKey. Else the join server ignores the join request. The join server may send the same AppSKey to application server through a secured channel.

The trusted end-node is able to decrypt the join response message from the join server. Since the malicious node does not have the preloaded AppKey, it will be sending the request as plain text or encrypted using any random 128-bit AES key. In this case, the join server will ignore these requests and malicious nodes will not receive any response from join server.

A time consumption matrix has been implemented on the join server to analyze the time taken to verify a join request. It is found to be 40 to 50 ms to verify the request at the join server.

Output:

Fig 12.  Join server output for legitimate node

Fig 13.  Join server output for malicious node

Fig 14.  Response from join server

Phase II Experiment

A Real-time field test has been successfully completed with three nodes covering 6.66 km.

  • Node 1 (Sender) has been placed at IDRBT quarters, Begumpet (17.4455548, 78.4607506)
  • Node 2 (Relay) at Lakdi ka pul (17.4063154, 78.4676673)
  • Node 3 (Receiver) at IDRBT (17.3975147, 78.4490015)

Process Flow:

Node 3 acts as a bank server with a database containing user account details. Real-time transaction information (user mobile number, account number, and amount to withdraw) has been given as input from the sender node. The data is encrypted using a 128-bit AES algorithm with a pre-shared key between sender and receiver (bank server).

The relay node could capture the input message from Node 1 and forward it to Node 3. The receiver node has received the transaction request, and the data were acquired after decryption. Based on the transaction message, the receiver checks the database and sends the response back to Node 1 in encrypted format using the same pre-shared key.

The response can be of 3 types:

  1. Account does not exist
  2. Amount withdrawn, and the new balance is ****
  3. Not enough balance.

The response is captured by the relay node and forwarded to Node 1. The sender node receives the response from Node 3, decrypts the message, and displays it.

Fig 15.  Node 1 (Sender) at IDRBT Quarters, Begumpet (17.4455548, 78.4607506)

Fig 16.  Sender node input

Fig 17.  Node 2 (Relay) at Lakdi ka pul
(17.4063154, 78.4676673)

Fig 18.  Relay node output

Fig 19

Fig 19.  Node 3 (Receiver) at IDRBT
(17.3975147, 78.4490015)

Fig 20.  Receiver node output after decryption

Fig 21

Fig 21.  Receiver node output after checking database

Fig 22.  Sender node output

Result Analysis:

  • Receiver node and relay nodes should be active before starting sender.
  • The sender will ask user mobile number, bank account number and amount to withdraw, when it is ready.
  • User needs to provide these details (Fig. 16).
  • Sender device will concatenate all the details, encrypt it using 128-bit AES and send to receiver.
  • Bank server (Node 3) receives the data and decrypts the payload to get the user request (Fig. 20).
  • Server verifies the data with database and sends the response back to user in encrypted format (Fig. 21).
  • User receives the data from bank server and decrypts the payload to view the response (Fig. 22).

Fig 23.  Experimental setup with 3 nodes covering 6.66km

Future Scope

Based on the application, the application server can be connected with the destination node. This application has massive potential to be applied in the areas of banking, smart agriculture and supply chain logistics.

Summary

LoRaWAN is a promising solution, and the test cases show that the setup for LoRa works well without any packet loss on Line of Sight. The aim is to explore the possibilities of extending secure long-range communication between end devices and the gateway for financial transactions.

Acknowledgement

We thank Sravan S. S, Lakshmi Ramesh P and Manesh Kumar Behara, research students for supporting the experiments.