LoRaWAN Reference Key Derivation Without Preloaded AppKey
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing LoRaWAN protocol requires preloading of the application key AppKey in the object's memory during configuration, which is restrictive as it assumes a known server at commissioning time, limiting flexibility in key sharing between objects and servers.
Innovation Solution
A method involving the object applying a predetermined function to specific data and a secure element key to generate a reference key, which is then shared with the server through a join request without transmitting the key itself, allowing the server to derive the secure element key using stored candidate keys and integrity codes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the application key AppKey is preloaded in the object's memory during configuration, then security is ensured through secret sharing, but flexibility is reduced as the server must be known at commissioning time
Solution Approach 1:
The patent applies preliminary action by pre-loading candidate keys into the server's memory during server configuration, rather than requiring the object to pre-load the actual AppKey. This allows the server to be prepared to derive the correct key later when the object joins, without the object needing to know the server in advance. The preliminary setup creates a mapping between object identifiers and candidate keys that enables flexible key derivation.
Solution Approach 2:
The patent uses an intermediary approach by introducing candidate keys as intermediate values stored on the server. These candidate keys serve as mediators between the object identifier and the actual AppKey. When an object joins the network, the server uses the object's identifier to select the appropriate candidate key and derive the AppKey through a key derivation function, eliminating the need for direct pre-sharing of the actual key.
2Ease of operation
If the object transmits the application key AppKey to the server, then key sharing becomes simpler, but security is compromised due to transmission risks
Solution Approach 1:
The patent extracts the actual AppKey from the transmission process entirely. Instead of transmitting the AppKey itself, only the object identifier (such as DevEUI in LoRaWAN) is transmitted during the join request. The server then uses this identifier to locally derive the AppKey using the pre-stored candidate keys and a key derivation function, completely eliminating the security risk of key transmission.
Solution Approach 2:
The patent replaces the mechanical approach of physical key transmission with a cryptographic derivation mechanism. Rather than moving the key through the communication channel, the system uses a deterministic key derivation process where the server generates the same AppKey locally that the object already possesses, based on shared identifiers and pre-configured candidate keys.
3Adaptability or versatility
If multiple candidate keys are stored on the server, then adaptability increases for different objects, but device complexity increases
Solution Approach 1:
The patent manages server complexity through parameter changes by organizing candidate keys with associated metadata parameters such as application identifiers (AppEUI) and activation types (OTAA or ABP). The server maintains a structured database where each candidate key is associated with specific parameters, allowing efficient lookup and selection based on the object's identifier and activation mode. This parametric organization enables scalability without linearly increasing complexity.
Data Source
AI summary
A method of sharing of a reference key (AppKey) between a connected object and at least one server. The method includes the object applying a function (f) to at least one datum (DevEUI, AppEUI, DevNonce) and to a key (KSE) specific to a secure element of the object to generate the reference key, transmitting to the server a join request of the object to a network of connected objects, which include the datum, and the key (KSE) of the secure element not being transmitted to the server. The method further includes obtaining, by the server, of the key (KSE) of the secure element on the basis of the request, the server applying the function (f) to the datum and to the key (KSE) obtained by the server, so as to obtain the reference key.