Security risks can occur though out an IoT system and the aim of a system designer is to prevent the exposure of the communication between the sensor in the field and  the back end applications.

The use of secure Cryptographic communications such as used in LoraWAN of AES 128, a government could potentially crack the code in up to 6 months using Quantum Computing power it has. But often the nature of the keys used mean that the potential address space to test, can be reduced significantly. Example is GSM mobile phone encryption was deliberately compromised by Governments clandestine actions by padding “0” to enable the possible usable combinations to be reduced to an easily breakable system. This was exploited by hackers (see “blackhat” old videos) and software was published that broke the system in minutes. Risks can occur in many areas including:

  • Transport Backend Servers and Applications such as:
    • LAS (LoRaWAN Application Servers)
    • CUPS (Configuration and UPdate Servers)
    • Join Application Servers
    • LNS (LoRaWAN Network Server)
    • NM (Network Manager Used for configuration and Statistic of Gateways)
    • External Application Servers E.g. Cayenne™ Node-RED™
    • Transport network between Backend and Gateways/ Packet Forwarder
  • RF and transport protocols used between Nodes, Gateways and Applications
  • Data transfer between the Sensors and Nodes
  • Node or Gateway operation code open to hidden code, or open to side channel attacks.
  • Manipulation of the Gateway information such using it to locate a target node

Types of Attack

  • Gateway Spoofing similar to GSM “False Base-Station” attacks
  • Owner spoofing in “Backend” E.g. TTN Servers
  • Illegal access to Master Key Servers using keys for different attack vectors
  • Poor of False Node applications that have:
    • Lack of hardened Security Module
    • Access to node via programming ports
    • Able to be reloaded with Trojan / Malware in production or in field with servicing