LoRaWAN based Secured Micro-Transactions
Prof. D. Janakiram, Dr. Susmita Mandal, Shri. Rajiv Ramachandran
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:
- 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.
- 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.
- Network Server – Servers route messages from End Devices to the right Application, and perform the required security, and scheduling tasks.
- 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.
- 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:
- Mutual Authentication: As a part of Network join procedure the mutual authentication is established between end-devices and the network.
- 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.
- 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.
- 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
- 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)>.
- 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.
- 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)>.
- 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. 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.
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)
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:
- Account does not exist
- Amount withdrawn, and the new balance is ****
- 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
Fig 18. Relay node output
Fig 19. Node 3 (Receiver) at IDRBT
Fig 20. Receiver node output after decryption
Fig 21. Receiver node output after checking database
Fig 22. Sender node output
- 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
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.
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.
We thank Sravan S. S, Lakshmi Ramesh P and Manesh Kumar Behara, research students for supporting the experiments.