LoRaWAN Clone Detection via Join-Request Rejection Alerts
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for preventing clone attacks in LoRaWAN networks are costly and require substantial changes to connected objects, as they often rely on secure elements or additional cryptographic operations, and existing detection methods are complex and resource-intensive.
Innovation Solution
A method where a connected object in a LoRaWAN network transmits a join-request with a nonce value, detects if a reference message is rejected or ignored, and sends an alert message indicating this status to the server, using a new join-request with a specific value in the DevNonce field to indicate rejection or ignoring, allowing the server to detect potential clones without requiring additional cryptographic operations or secure elements.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a secure element is incorporated to prevent clone attacks, then network security is improved, but manufacturing cost increases
Solution Approach 1:
The patent replaces expensive secure elements with a disposable, software-based solution using standard microcontroller units. The clone detection mechanism uses readily available cryptographic libraries and standard communication protocols, eliminating the need for costly hardware security modules while maintaining adequate security for the application.
Solution Approach 2:
The patent creates a virtual copy of the secure element functionality through software implementation. Instead of relying on physical hardware security, the system replicates security functions using software-based cryptographic operations and protocol-level mechanisms that can be implemented on standard inexpensive microcontrollers.
2Reliability
If secure elements are used to protect against cloning, then clone attack resistance is improved, but device complexity increases
Solution Approach 1:
The patent extracts the essential security functionality from complex hardware secure elements and isolates it into a simplified software-based clone detection mechanism. By separating the core detection function from the underlying implementation complexity, the system achieves security without the burden of complex hardware architecture.
Solution Approach 2:
The system performs self-detection of clone attacks using its own existing cryptographic capabilities and communication infrastructure. Instead of requiring external hardware security modules, the connected object uses its own processor and standard cryptographic libraries to detect and report cloning attempts, eliminating the need for additional complex security hardware.
3Difficulty of detecting and measuring
If existing detection methods are implemented, then clone detection capability is improved, but object complexity increases due to additional cryptographic operations and communications
Solution Approach 1:
The patent makes the existing join-request communication protocol multi-functional by embedding clone detection capabilities within it. The same communication channel and cryptographic mechanisms used for initial network joining are also utilized for clone detection and reporting, eliminating the need for separate dedicated detection protocols and reducing overall system complexity.
Solution Approach 2:
The patent merges the clone detection function with the existing join-request authentication process. By combining these functions into a unified protocol flow, the system achieves clone detection without requiring separate communication channels, additional cryptographic operations, or extra hardware resources, thereby minimizing the increase in object complexity.
Data Source
AI summary
The invention proposes a method for an object (1) to communicate with a server (2) of a connected objects network to report that a clone may be impersonating the object in the network, which method comprises the following steps implemented by the object (1): transmitting (106) to the server (2) a request from the object (1) to join the connected objects network; after transmitting the join-request, detecting (110) whether a reference message (uplink) transmitted by the object (1) to the server (2) was rejected or ignored; in response to the detection, transmitting (114) to the server (2) an alert message indicating the rejection or ignoring.