Wireless Networks
The LoRaWAN® specification is a Low Power, Wide Area (LPWA) networking protocol designed to wirelessly connect battery operated and powered ‘things’ to the internet in regional, national or global networks. Unlike Wi-Fi and Bluetooth, it can send data securely over longer distances whilst consuming considerably less power.
What is LoRaWan?
LoRawan is an integral part of IOT (Internet Of Things) where data is retrieved from remote battery-powered devices via a local gateway and then retransmitted over the internet or local network to an application server. The data is then converted into readable information and displayed on cloud-based dashboards using all forms of graphs and tables. This information can then be used to assist companies in the areas of efficiency, health and safety and many more benefits too numerous to list here.
Where did LoRaWan come from?
The LoRa Alliance® is an open, nonprofit association that has become one of the largest and fastest-growing alliances in the technology sector since its inception in 2015. Its members closely collaborate and share experiences to promote and drive the success of the LoRaWAN® standard as the leading open global standard for secure, carrier-grade IoT LPWAN connectivity.
The members of the LoRa Alliance® believe that the time of the Internet of Things is now and that standardization and a strong, growing ecosystem is the only way drive volume deployments for low power wide area (LPWA) networks .These LPWA networks are projected to connect 50% of the predicted IoT volumes. The LoRa Alliance® is standardizing LPWA with the LoRaWAN® specification and has created a certification and compliance program to ensure interoperability. LoRaWAN® end-devices will be able to be deployed in multiple networks and roam from one network to another irrespective of network infrastructure or operator.
Please follow the link for Introduction Video on LoRawan https://youtu.be/rQ1AEA06Byw
​
Please follow the link for LoRawan Alliance Website https://lora-alliance.org/
Security Measures
LoRaWAN security is designed to fit the general LoRaWAN design criteria: low power consumption, low implementation complexity, low cost and high scalability. As devices are deployed in the field for long periods of time (years), security must be future-proof. The LoRaWAN security design adheres to state-of-the-art principles: use of standard, well-vetted algorithms, and end-to-end security.
IoT Platform
Data Points
Events
Configuration
Commands
4G /HTTPS
LoRawan Gateway
LoRawan Sensors
Gateway to IoT Platform Security Measures
There is 2-way communication between the gateway and the IOT Platform to ensure effective operation and maximum security. The gateway sends data points and events to the IOT Platform whilst the IoT platform sends configurations and commands to the gateway.
The sections below detail the security measures employed between them.
End-to-End Encryption
The encryption process takes care of encoding a message or information so that only authorised entities can access it. Transportation Layer Security (TLS) is an industry-standard communication layer for sending encrypted data over a wide area network. The TLS connection is initiated by a secure key exchange, symmetric encryption, and message integrity checks. All communication, especially between our gateway to IoT platform is over TLS and follows the three main properties:
Communication is private, and nobody can spy on the content of the exchange.
The integrity of the communication is guaranteed, and nobody can modify the content of data transferred between the Box and the IoT platform.
The identities of both the Box and the IoT platform is authenticated.
To secure the communication between the gateway and our IoT Platform, we use TLS with both server authentication (default) and client authentication mode. That is, the gateway confirms that it is connected to its own IoT platform, and our IoT platform makes sure that the gateway that connects is authentic. To achieve this, the gateway uses the Certificate Authority (CA) to validate that the IoT platform it is connecting to the correct IOT platform, while the IoT platform uses uniquely generated certificates to validate the gateway's identity, these certificates are generated and securely stored at the IoT platform. Such an authentication mechanism adds multiple security layers and prevents any spoofing or man in the middle attacks.
By default, the gateways connect via 4G to the service, reducing the scope of potential attacks.
Box Status Monitoring
The presence of anomalies in the gateway connection and data sent to the IoT platform may indicate the presence of a security incident. The status of our gateways are actively monitored and will be flagged on our system if its gone offline.
Publish / Subscribe Model
The publish/subscribe paradigm enables a secure workflow to connect remote gateways with the IoT platform while communicating over a set of defined channels or topics.
Each Box has a uniquely generated certificate to authorize the communication with the IoT platform. The IoT Platform relies on these certificates to authorize the gateway to exchange data with the server using its private communication channels. Hence, in case the certificate of a gateway is compromised, we can revoke the access to these channels by revoking the certificate.
Outbound-port-only Design Pattern
Leaving inbound ports open may lead to potential attacks on the software using the said ports, which can cause malware infections, the modification, and theft of data, DoS attacks, and arbitrary code execution. Considering this, the gateway follows an outbound-port-only design pattern owing to the publish/subscribe model thereby protecting against the attacks described above. The gateway communicates with the outside world rather than external communications being sent to specific Box ports.
Secure Firmware & Software Updates
A major requirement for an efficient security model is to keep the Box software and firmware up-to-date correctly. At Wattsense, we employ an enterprise-grade platform to update Boxes over the Air (OTA) by means of encrypted channels securely. Our platform comes with features such as constraining software deployment to a specific set of Boxes, cascading deployments, emergency stops to software roll-outs in case of failure and breaches. Moreover, we also use state-of-the-art software integrity checks, e.g., checksums of software binaries, to ensure the authenticity of existing or updated firmware and software.
LoRaWan Security Measures
Securing an Internet of Things (IoT) deployment and keeping it safe and secure is not only a matter of choosing the right protocol, it relies on the implementation process as well as embracing best practices and industry standards.
LoRaWAN is by design very secure—authentication and encryption are, in fact, mandatory—but networks and devices can be compromised if security keys are not kept safe, not randomized across devices or if cryptographic numbers used once (nonces) are reused, as is shown by numerous blog posts. That’s why it is critical to look for LoRaWAN CertifiedCM devices to ensure the device has been tested against the standard and works as expected.
The LoRa Alliance has always kept security front and center in its development of the LoRaWAN specification and has been highly transparent about the protocol’s security features (see Figure 1). The LoRaWAN specification has been designed from the outset with security as an essential aspect, providing state-of-the-art security properties that meet the needs of highly scalable low-power IoT networks. Unlike many other IoT technologies, the LoRaWAN specification already offers dedicated end-to-end encryption to application providers.
(By LoRa Alliance® Technical Committee)
Mutual Authentication
Mutual authentication is established between a LoRaWAN end-device and the LoRaWAN network as part of the network join procedure. This ensures that only genuine and authorized devices will be joined to genuine and authentic networks.
Each LoRaWAN device is personalized with a unique 128 bit AES key (called AppKey) and a globally unique identifier (EUI-64-based DevEUI), both of which are used during the device authentication process. Allocation of EUI-64 identifiers require the assignor to have an Organizationally Unique Identifier (OUI) from the IEEE Registration Authority. Similarly, LoRaWAN networks are identified by a 24-bit globally unique identifier assigned by the LoRa Alliance.
​
The Over-the-Air Activation (a.k.a. Join Procedure) proves that both the end device and the network have the knowledge of the AppKey. This proof is made by computing an AES-CMAC4 (using the AppKey) on the device’s join request and by the backend receiver. Two session keys MUTUAL AUTHENTICATION are then derived, one for providing integrity protection and encryption of the LoRaWAN MAC commands and application payload (the NwkSKey), and one for end-to-end encryption of application payload (the AppSKey). The NwkSKey is distributed to the LoRaWAN network in order to prove/verify the packets authenticity and integrity. The AppSKey is distributed to the application server in order to encrypt/decrypt the application payload. AppKey and AppSKey can be hidden from the network operator so that it is not able to decrypt the application payloads.
End-to-End Encryption
LoRaWAN security implements end-to-end encryption for application payloads exchanged between the end-devices and application servers. LoRaWAN is one of the few IoT networks implementing end-to-end encryption. In some traditional cellular networks, the traffic is encrypted over the air interface, but it is transported as plain text in the operator’s core network. Consequently, end users are burdened by selecting, deploying and managing an additional security layer (generally implemented by some type of VPN or application layer encryption security such as TLS). This approach is not suited in LPWANs where over-the-top security layers add considerable additional power consumption, complexity and cost.
All LoRaWAN traffic is protected using the two session keys. Each payload is encrypted by AES-CTR and carries a frame counter (to avoid packet replay) and a Message Integrity Code (MIC) computed with AES-CMAC (to avoid packet tampering).
Security Implementation and Deployment
The LoRa Alliance works towards ensuring its protocol and architecture specifications are secure, while recognizing that the overall security of the solution also depends on the specific implementation and deployment. Implementation security issues need to be taken up by the relevant manufacturers and deployment issues need to be taken up by the relevant network operators. These two types of issues are not specific to the LoRaWAN technology and usually equally applicable to any radio technology implemented on the same platforms/networks.
Please follow the link for FAQs on LoRaWan Security Click Here