Secure key management device, authentication system, wide area network, and method for generating session keys - Patents.com

Abstract

The present disclosure relates to a Secure Key Management Device (SKMD) for a wide area network comprising an End Device (ED), a Network Server (NS), an Application Server (AS) and a Participation Server (JS). The Secure Key Management Device (SKMD) comprises a Secure Storage Component (SSC) for storing private key information, a Secure Interface (I / F) for securely exchanging data with the Participation Server (JS), and at least one processing component. The at least one processing component is configured to generate and store at least one master key (Ka) in a secure storage component (SSC), generate at least one root key (RKey) based on the at least one master key (Ka) and a unique identifier (S / N) of the end device (ED), provide the generated at least one root key (RKey) to the end device (ED), receive a first request from the participation server via a secure interface (I / F) including the unique identifier (S / N) of the end device (ED) and session information (SID), generate at least one session key (SKey) based on the at least one master key (Ka) stored in the secure storage component (SSC) and the unique identifier (S / N) and the session information (SID) of the end device (ED) included in the first request, and provide the at least one session key (SKey) to the participation server (JS) via the secure interface (I / F).

Description

[Technical field]

[0001] The present disclosure relates to devices, systems, and methods for secure session key management. [Background technology]

[0002] US Patent Application Publication No. 2020 / 0 288 312 discloses a communication system including a terminal, a communication network server capable of providing network services to the terminal, and an application server capable of providing application services to the terminal via the network and the network server.

[0003] WO2018 / 148244A1 discloses a key provisioning procedure in which an application provider transfers a group master key to a network provider prior to device deployment, allowing the network provider to authenticate a large number of devices in the system without the need to manage each device with a unique key.

[0004] US Patent No. 10 880 743 describes a centralized, neutral system for activation and automatic onboarding of Internet of Things (IoT) devices on an end-to-end basis, as well as a technique for establishing secure communication between IoT devices and an IoT platform. Summary of the Invention [Problem to be solved by the invention]

[0005] It is an object of the present invention to provide an improved device, system and method for securely managing keys in a wide area network. [Means for solving the problem]

[0006] According to a first aspect, a secure key management device for a wide area network is provided, the secure key management device comprising an end device, a network server, an application server, and a participation server. The secure key management device comprises a secure storage component for storing private key information, a secure interface for securely exchanging data with the participation server, and at least one processing component. The at least one processing component is configured to generate and store at least one master key in the secure storage component, generate at least one root key based on the at least one master key and a unique identifier of the end device, provide the generated at least one root key to the end device, receive a first request from the participation server via the secure interface, the first request including the unique identifier of the end device and session information, generate at least one session key based on the at least one master key stored in the secure storage component and the unique identifier of the end device and the session information included in the first request, and provide the at least one session key to the participation server via the secure interface.

[0007] Storing the master key within a secure management entity establishes a centralized and secure environment for key management and storage. Root and session keys can be derived on-the-fly from the master key and provided to participating servers over a secure interface, eliminating the need to store security-sensitive data within remote or public components of a wide area network, such as participating servers.

[0008] According to a second aspect, there is provided an authentication system for authenticating an end device in a wide area network, comprising a secure key management device according to the first aspect and a participation server connected to the secure key management device via a secure interface, wherein at least one processing component of the participation server is configured to receive a second request from the end device, the second request including address information of the end device, provide a first request based on the address information of the second request to the secure key management device via the secure interface, and forward at least one session key received from the secure key management device via the secure interface to at least one of a network server and an application server.

[0009] By requesting at least one session key on demand from a secure key management device, participating servers in the authentication system can respond to queries from the wide area network in a standards-compliant manner without local access to the root key.

[0010] According to a third aspect, there is provided a wide area network comprising an authentication system according to the second aspect, at least one end device, at least one network server, and at least one application server, wherein the at least one end device is configured to send data packets to the network server, the data packets being encrypted on a network layer and on an application layer, the at least network server is configured to decrypt the data packets on the network layer using the at least one network session key received from the participating server and forward the partially decrypted data packets to the application server, and the at least application server is configured to decrypt the data packets on the application layer using the at least one application session key received from the participating server.

[0011] The above wide area network provides a high degree of network security by hiding security-sensitive data such as root keys from intermediate network components, thus ensuring end-to-end security of communications between end devices and application servers.

[0012] According to a fourth aspect, there is provided a method of generating a session key for use in a wide area network, the wide area network comprising an end device pre-registered with a secure key management device, a network server, an application server, and a participation server. The method includes receiving, by the secure key management device, a first request from the participation server via a secure interface, the first request including a unique identifier of the end device and session information, generating, by the secure key management device, at least one session key based on at least one master key stored in the secure key management device and the unique identifier of the end device and the session information included in the first request, and providing, by the secure key management device, the generated at least one session key to the participation server via the secure interface.

[0013] In the above method, the session key can be generated on-the-fly by the secure key management device.

[0014] According to a fifth aspect, there is provided a method of pre-registering an end device with a secure key management device for use in a wide area network, the pre-registration procedure including: generating, by the secure key management device, at least one master key and storing the at least one master key in the secure key management device; generating, by the secure key management device, at least one root key based on the at least one master key and a unique identifier of the end device provided to the secure key management device; and providing the generated at least one root key to the end device.

[0015] The method according to the fifth aspect may be used to pre-register the end device with the secure key management device before performing the step of receiving the first request according to the fourth aspect.

[0016] According to a sixth aspect, a data storage device storing instructions which, when executed by at least one processing device of a networked computing device, perform steps of a method according to the fourth or fifth aspect.

[0017] According to at least one embodiment, the wide area network is a LoRaWAN network and the secure interface is configured to exchange data with participating servers outside the address space of the LoRaWAN network, thereby hiding the secure key management device from the LoRaWAN network.

[0018] According to at least one embodiment, the step of generating the at least one master key is repeated after a predefined condition. During the pre-registration procedure, the end device is provided with version data related to the master key used to generate the at least one root key. In this embodiment, the first request received from the participation server further includes the version data.

[0019] For example, master key version data can be changed and tracked after a predefined time period or after a security breach, further enhancing cybersecurity by limiting the impact of a compromised key.

[0020] According to at least one embodiment, the address information of the second request includes an end device address identifier of the end device. During the pre-registration procedure, the unique identifier of the end device, the end device address identifier, and optionally version data related to the master key used to generate the at least one root key are provided to the participation server. The participation server maps the end device address identifier included in the second request to the unique identifier of the end device and generates the first request based on the mapping of the end device address identifier to the unique identifier. This hides the end device address identifier from the secure key management device.

[0021] Further aspects and embodiments of the present disclosure are set out in the accompanying claims. The devices and systems described above and in the accompanying claims are suitable for a method of generating a session key, and therefore the features and advantages described in relation to the devices and systems can be used in this method and vice versa.

[0022] The present disclosure is composed of several aspects, and any feature described with respect to one of these aspects is also disclosed herein with respect to the other aspects, even if the respective feature is not explicitly mentioned in the context of a particular aspect.

[0023] For a better understanding, the accompanying figures are included, in which elements of the same structure and / or function may be referred to with the same reference symbols. It should be understood that the embodiments shown in the figures are illustrative representations and are not necessarily drawn to scale. [Brief description of the drawings]

[0024] [Figure 1] FIG. 1 is a schematic block diagram of a secure key management device according to an embodiment of the present disclosure. [Diagram 2] FIG. 2 is a schematic sequence diagram of various method steps according to an embodiment of the present disclosure. [Diagram 3] FIG. 1 is a schematic block diagram of a WAN architecture that is typical of a LoRaWAN system. [Figure 4] FIG. 1 is a schematic block diagram of a secure communication flow in a LoRaWAN entity. [Diagram 5] 1 is a schematic block diagram of a wide area network including an authentication system according to one embodiment of the present disclosure. [Figure 6] FIG. 1 is a schematic sequence diagram of a secure key management device initialization, end device pre-registration and joining process in a wide area network according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] While the present disclosure is susceptible to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the intention is not to limit the disclosure to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure as defined in the appended claims.

[0026] The present disclosure aims to present an improved system and method for initializing, generating, and provisioning root keys in wide area networks, such as low power and wireless based LoRaWAN based systems.

[0027] As an example, this section provides a background on the workflow of a LoRaWAN-based system and the existing challenges in its key management, which this disclosure focuses on addressing and improving cybersecurity.

[0028] Fig. 1 shows a schematic block diagram of a secure key management device SKMD according to an embodiment of the present disclosure. The secure key management device SKMD comprises a secure storage component SSC for storing private key information, a processing component PC for executing stored instructions, and a secure interface I / F for securely exchanging data with other entities such as participating servers of a wide area network (WAN).

[0029] In the described embodiment, the secure key management device SKMD can be implemented as a server computer comprising conventional components suitable for storing and executing program instructions when the server computer is deployed in one or several data networks. The secure storage component SSC can be part of a hardware secure module (HSM) designed to securely store security-critical information such as private encryption keys and / or other secret key information and parameters. The HSM is protected against unauthorized data access and typically also comprises a processing component configured to perform cryptographic functions. In this way, security-critical information such as private keys never leaves the HSM during operation of the secure key management device SKMD.

[0030] In the described embodiment, part or all of the processing component PC is also part of the HSM: for example, a first part of the processing component PC may be in the HSM, and a second part of the processing component PC, which is used to perform non-security-critical operations, such as receiving and sending already encrypted data packets, may be implemented in a different part of the server computer.

[0031] In the described embodiment, the secure interface I / F may be a network interface or a user console, or a combination thereof. For example, information entering or leaving the secure key management device SKMD via the secure interface I / F may be protected using conventional network equipment protected with standard cryptographic methods based on a private key stored in the secure storage component SSC.

[0032] Fig. 2 shows a schematic sequence diagram of steps of various operating methods according to an embodiment of the present disclosure, showing both the internal interactions between the components SSC, PC and I / F of the secure key management device SKMD and the interactions of the secure key management device SKMD with an external user.

[0033] During the initialization of the secure key management device SKMD shown in the upper part of Fig. 2, for example by first setting up or starting a network server configured as the secure key management device SKMD, the processing component PC generates at least one master key Ka and stores the generated master key Ka in the secure storage component SSC. For example, the processing component can obtain a random or pseudorandom seed value for generating a secret master key based on a predefined cryptographic function. To improve security, the master key Ka may be changed from time to time, as will be explained in more detail later. In this case, each version of the master key Ka is stored in the secure storage component SSC of the secure key management device SKMD together with the corresponding version data Kn. Once the secret master key Ka data is securely stored in the secure storage component SSC, the secure key management device SKMD is ready for operation.

[0034] In another process shown in the middle part of Fig. 2, a user can pre-register a particular end device with the secure key management device SKMD. For this, the user first provides the processing component PC with a unique identifier S / N of the end device to be registered. For example, the user may manually enter the serial number of the end device. Alternatively, as will be described in more detail below, the serial number of the end device may be provided automatically at the end of the manufacturing process by the manufacturer of the end device using a pre-commissioning device (not shown in Fig. 2). Such a pre-commissioning device may have a machine-to-machine (M2M) interface directly and securely connected to the secure key management device SKMD.

[0035] To generate at least one root key RKey associated with an end device identified by a provided serial number, the processing component PC retrieves an active secret master key Ka from the secure storage component SSC. Then, based on a suitable cryptographic function, a root key RKey for the end device is generated by the processing component PC based on the unique identifier S / N and the active master key Ka.

[0036] In a final step, the root key RKey generated by the secure key management device SKMD is provided to the end device (not shown in FIG. 2). For example, the root key RKey may be communicated back electronically via the M2M interface of the precommissioning device to directly program the root key RKey into the end device. Thus, there is no need to keep a paper trail of transmitted information during the registration of the end device.

[0037] Depending on the security requirements of a particular device and application, the root key RKey and the unique identifier S / N, as well as any other security-critical data, such as the end device address identifier, may be stored in a secure element (SE) of the end device. For a relatively low security level, this information may also be stored in a conventional non-volatile memory of the end device. In this case, a corresponding hash value may be stored in the end device to avoid the stored data being manipulated later.

[0038] At the end of this process the end device is associated with the active master key Ka of the secure key management device SKMD and can be deployed to customers and used as an end device in WAN applications, as will be explained in more detail below, or can be indirectly linked to the secure key management device SKMD by an additional activation procedure involving further entities such as a participation server, as will be explained in more detail below.

[0039] During operation of the end device, the end device may attempt to contact a particular application running on an application server in the WAN. Before a corresponding communication channel is established between the end device and the application server, the network server in charge of routing data packets or the addressed application server may request one or more session keys for secure communication with the end device. As part of this procedure, the session keys for securing the communication between the end device and the network server or the application server, respectively, are generated in a further process, as shown in the lower part of FIG.

[0040] Thus, the processing component PC of the secure key management device SKMD may receive a first request REQ1 comprising the unique identifier S / N and the session information SID via the secure interface I / F. The request REQ1 may come from a participating server that has received a corresponding participation request for providing a session key to a network server or an application server, as will be described in more detail below. In response to the first request REQ1, the processing component PC retrieves a master key Ka from the secure storage component SSC. Then, based on the unique identifier S / N, the session information SID and the master key Ka, the processing component PC generates one or more session keys SKey specific to the end device. This key is returned to the requesting entity via the secure interface I / F as part of a first response RSP1. In particular, the processing component PC may return the response RSP1 to the participating server, which then provides the session key SKey to the requesting entity (such as a network server or an application server communicating with the end device).

[0041] We note the fact that the master key Ka never leaves the secure key management device SKMD. Furthermore, the root key RKey provided to the end device during pre-registration is not provided to the entity requesting the session key via the secure interface I / F. Thus, the participating server never gains knowledge of the underlying master or root key. So, even if the participating server is compromised, for example by being hacked, the potential intruder cannot obtain any information about the secret master key Ka or the root key RKey used by the end device.

[0042] Before describing further embodiments of the present invention in more detail, the general operation of an exemplary WAN that may be used in remote sensing applications will first be described below with reference to FIGS.

[0043] Figure 3 illustrates each of the participating entities in a LoRaWAN-based system. The workflow of the entire process is also described in the following section, where both this diagram and the workflow listed are specified according to the LoRaWAN specification version 1.1, the contents of which are incorporated herein.

[0044] The system in Figure 3 comprises an end device ED, a network server NS, an application server AS, an application App, and a participation server JS. For the sake of clarity, only one of these entities is shown in Figure 3. However, in an actual implementation, there may be many instances of each of the described entities.

[0045] The end device ED is a device with a LoRaWAN communication interface that can transfer data over the LoRaWAN communication network. The network server NS is a LoRaWAN communication network provider server that listens for data packets from the end device ED that are transferred over the LoRaWAN communication protocol. Upon receiving any data packet, the network server NS further forwards the LoRaWAN application data payload contained therein to the application server AS. The application server AS is a server that retrieves application-level data from the network server NS and then further forwards the data payload to the end application App, from which the data is monitored, controlled, or otherwise consumed. For example, the application App can be a monitoring application that monitors the operating status of an energy distribution network, or a billing application that queries a number of smart meters that function as end devices.

[0046] A Participating Server JS is traditionally a Key Management Server that manages the distribution of network session keys, i.e. the distribution of a set of "network level" session keys to one or more network servers, and the distribution of "application level" keys, also known as "application session keys" and referred to as "AppSKey" in the LoRaWAN specification, to one or more application servers AS.

[0047] For this, in a conventional setup, the Participation Server JS stores one or more root keys, i.e. initial or base keys. The initial keys used in LoRaWAN specification version 1.1 are the Network Root Key (NwkKey) and the Application Key (AppKey), which are AES 128-bit keys. These keys are further used to derive session keys that are used to secure the transmission of LoRaWAN traffic against cyber attacks, both at the network and application layers of the WAN. We note the fact that according to the LoRaWAN specification version 1.0, only a single root key, i.e. the Application Key (AppKey), is used to derive all session keys.

[0048] According to the standard, the LoRaWAN joining procedure to the LoRaWAN communications infrastructure can be performed in one of two ways, called "Over the Air Activation" (OTAA) or "Activation by Personalization" (ABP). The corresponding procedures are described in Sections 6.2 and 6.3 of the LoRaWAN 1.1 Specification 2, 2017, LoRa Alliance, Inc., the contents of which are incorporated by reference.

[0049] During device activation, the end device ED must be initialized with the following data items:

[0050] a.JoinEUI: This is an identifier in the form of IEEE EUI64 address of the Join Server JS so that the end device ED can communicate with the appropriate Join Server JS. This needs to be stored in each end device ED only if you want to opt for OTAA.

[0051] b.DevEUI: This is an identifier in the form of an IEEE EUI64 address for each end device ED so that the network server NS listening to LoRaWAN communication traffic can correctly identify each end device ED. This data is required if the end device ED wants to select OTAA, but is not mandatory for ABP. However, it is recommended that this data be stored within each end device ED.

[0052] NwkKey: This is the "Network Session Key", i.e. the key used to derive a set of network level session keys, e.g. FNwkSIntKey, SNwkSIntKey and NwkSEncKey in LoRaWAN standard version 1.1. These network level session keys are used to secure LoRaWAN communication traffic at the network layer, i.e. the communication between end devices ED and the network server NS. This data does not need to be stored in each end device ED when operating in ABP mode.

[0053] · AppKey: This is the key for deriving the "application level" session key (e.g. AppSKey in version 1.1 of the LoRaWAN standard) also called "application session key". The application session key is used to secure the LoRaWAN communication traffic at the application layer, i.e. the communication between the end device ED and the application server AS via the network server at OSI application layer 7. This data does not need to be stored in the end device ED when operating in ABP mode.

[0054] FIG. 4 illustrates the flow of this secure communication, aided by session keys placed at each of the following participating entities of a LoRaWAN-based communication system:

[0055] In a LoRaWAN communication network, the end device ED communicates securely with the network server NS aided by "network session keys" (i.e., forwarding network session integrity key FNwkSIntKey, serving network session integrity key SNwkSIntKey, and network session encryption key NwkSEncKey) derived from the root network key (i.e., NwkKey). Thus, the end device ED securely transmits LoRaWAN data to the network server NS, for example by encrypting MAC payloads and commands. Similarly, application level data exchanged between the end device ED and the application server AS is encrypted. That is, the end device ED performs cryptographic operations at both the network layer aided by the "network session key" and the application layer aided by the "application session key".

[0056] Upon receiving the LoRaWAN data, the network server NS further transmits the data securely to the application server AS. Note that in this step, the network server NS does not need to perform any cryptographic operations since the application payload segments of the LoRaWAN data have already been encrypted by each end device ED with the aid of an "application session key". Therefore, the network server NS can simply forward the LoRaWAN data to the application server AS for further processing, such as in-digesting the LoRaWAN data, and transmit the LoRaWAN data to the end application APP by a communication protocol, such as a secure communication protocol, for either monitoring or control.

[0057] It should be noted that LoRaWAN may span multiple physical networks, as also shown in Figure 4. For example, the first physical network PHY1 may be a LoRa low power wireless access network, and the second physical network PHY2 may be a wired core network. In the example shown in Figure 4, the network server NS also acts as a gateway between the first physical network PHY1 and the second physical network PHY2. However, this functionality may also be implemented in a different device, with the network server being located in either the first physical network PHY1 or the second physical network PHY2.

[0058] The LoRaWAN standard (including both version 1.0 and 1.1 of the specification) does not prescribe how to initialize and securely manage the set of root keys, i.e., NwkKey and AppKey, used to generate session keys - "Network Session Keys, i.e., a set of network level session keys" and "Application Session Keys" during Over-the-Air Activation (OTAA), which are later used to secure LoRaWAN communication traffic. The standard also does not prescribe any mechanism for securely handling the "Network Session Keys" and "Application Session Keys". Thus, no secure workflow is prescribed for the secure management of the above keys. It only prescribes their secure storage using a Secure Element (SE) and a Hardware Security Module (HSM).

[0059] However, as recognized by the inventors, the entire workflow for their management, i.e., the generation, transfer, and update of these root and session keys, is critical to the overall security of the system. Weak workflows in performing these steps can lead to cyber vulnerabilities in LoRaWAN-based systems. Secure management of the initial set of these root keys is the most critical aspect of the overall cybersecurity management of the system. Thus, the present disclosure provides methods and systems for securely managing these root keys, as well as the derived "network session keys" and "application session keys."

[0060] The next section details how the disclosed solution can be applied to a particular embodiment in the context of a LoRaWAN network with respect to Figures 5 and 6. The disclosed solution addresses at least some of the above challenges by introducing another entity called a Secure Key Management Device (SKMD) into the LoRa system. This entity handles the secure generation and transfer of the root keys (i.e., NwkKey and AppKey) and their derived session keys, i.e., network session keys (i.e., FNwkSIntKey, SNwkSIntKey, and NwkSEncKey) and application session keys (i.e., AppSKey).

[0061] FIG. 5 shows a schematic of both the system setup and the described workflow, which consists of steps A-G.

[0062] In these following sequence steps, keys are generated and then the used keys are transmitted. A prerequisite, and therefore a requirement, for these steps to successfully achieve their purpose is the initialization of the "JoinNonce", "NetID" and "DevNonce" which must be securely pre-generated and pre-stored in the Participating Server JS for each end device ED.

[0063] Steps A to F are described below with respect to Fig. 5 for the secure key management device SKMD. The secure key management device SKMD is a distinct entity that is physically separate from the other participants of the LoRaWAN system. As shown in Fig. 5, the individual steps A to G listed below are executed by a processing component PC of the secure key management device SKMD, except for steps B and E.

[0064] Step A: At start-up, the secure key management device SKMD generates and stores a master key Ka. K1 represents a first version of the master key Ka. The first master key K1 together with the corresponding version data Kn may be stored, for example, in a hardware security module of the secure key management device SKMD. This key K1 is further used to generate different root keys (i.e. NwkKey and AppKey) for each end device ED, as further explained below. After a certain number of iterations of using this first master key K1, the secure key management device SKMD generates a second master key K2. This master key K2 is also stored by the secure key management device SKMD together with the corresponding version data Kn, and so on. This certain number of times can be determined by a local security policy. Of course, it is also possible to manually force the generation of a new master key, for example after the intrusion of another security violation has been detected.

[0065] Step B: The secure key management device SKMD has an interface where the serial numbers of each end device ED can be entered. This can be done in any way, such as by a human or by a computerized script that reads these predefined serial numbers of each end device ED from any computerized file and enters them in the secure key management device SKMD.

[0066] Step C: For each new end device ED, an NwkKey and, for end devices ED compliant with LoRaWAN specification version 1.1, also an AppKey are generated based on their serial numbers and the currently active master key Ka and stored in the end device ED. For example, the NwkKey and the AppKey may be stored in a secure element of the end device ED. It should be noted that neither the master key Ka itself nor its version data Kn are stored in the end device ED.

[0067] The input parameters used in the cryptographic key generation function are: - Active Master Key Ka - The serial number of each end device, which serves as a device identifier S / N for each end device ED that uniquely distinguishes each end device ED.

[0068] Thus, for each end device ED, the key generation function is: NwkKey=F A (Ka,S / N) AppKey=F B (Ka,S / N), Here, F A and F B are any state-of-the-art cryptographic functions selected independently. The exact function generally depends on the applicable standard and is not limited by this disclosure.

[0069] Therefore, after performing step C, the new end device ED contains a different, unique NwkKey and AppKey.

[0070] Step D: The Participation Server JS also has an interface through which it is possible to input the serial number of each end device serving as the unique identifier S / N, the end device address identifier DevEUI of the end device ED in the WAN, and the version data Kn of the master key Ka (not the master key Ka itself) used to generate the NwkKey and the AppKey in step C. Again, this can be input in any way, such as by a human or by a computerized script that reads these predefined serial numbers of each end device ED from any computerized file and enters them in the Participation Server JS.

[0071] Step E: During the joining and activation process, the Participation Server JS requests the network session keys (i.e., FNwkSIntKey, SNwkSIntKey, and NwkSEncKey) and the application session key (i.e., AppSKey) from the secure key management device SKMD. For this, the Participation Server JS uses the DevEUI of the end device ED provided to the Participation Server JS in the Join Request to find the serial number of the end device ED and the version data Kn of the master key Ka used to generate the root keys NwkKey and AppKey of the end device provided to the Participation Server JS in step D. The Participation Server JS then provides a Session Key Request including the serial number serving as the unique identifier S / N of the end device ED, the version data Kn of the master key Ka, the joining nonce ("JoinNonce"), the network id ("NetID"), and the device nonce ("DevNonce") as described in the LoRaWAN standard. The transfer of the Session Key Request is performed by any state-of-the-art secure communication protocol.

[0072] Step F: Having obtained the respective values ​​from step E, the secure key management device SKMD generates a network session key (i.e., FNwkSIntKey, SNwkSIntKey, and NwkSEncKey) and an application session key (i.e., AppSKey) for each end device ED using the key generation algorithm specified in the corresponding LoRaWAN standard using the following steps:

[0073] - F using the data from step E of the end device ED described in the joining and activation process A and F B Generate NwkKey and AppKey using.

[0074] - Generation of FNwkSIntKey, SNwkSIntKey, NwkSEncKey, and AppSKey based on "JoinNonce", "NetID", "DevNonce", NwkKey, and AppKey.

[0075] It should be noted that the above steps of generating the NwkKey and AppKey, as well as the FNwkSIntKey, SNwkSIntKey, NwkSEncKey and AppSKey, can be performed on the fly, i.e. without storing the generated keys in the secure key management device SKMD, which further enhances system security.

[0076] Step G: The secure key management device SKMD securely sends the session keys generated in step 0 for the end device ED in the joining and activation process to the participating server JS as part of a Session Key Response. The data is transmitted using any modern secure communication protocol. The participating server JS forwards these session keys to one or more requesting network servers NS and / or application servers AS as required as part of the Join Accept. The participating server JS does not keep a local copy of these session keys.

[0077] As further shown in Figure 5, steps B, C and D may be performed by or under the control of a registration device RD of the device manufacturer OEM, which has one or several corresponding interfaces for communication with the end device ED, the secure key management device SKMD and / or the participation server JS. In one embodiment, these interfaces are secure machine-to-machine (M2M) interfaces that are outside the LoRaWAN network address space and / or communication protocols.

[0078] An exemplary sequence diagram detailing the complete flow of the initialization of a secure key management device SKMD in LoRaWAN and the pre-registration and joining of an end device ED is shown in Fig. 6. For ease of reference, steps A-F above are reproduced in Fig. 6 along with further steps of the disclosed procedure.

[0079] The above method may be implemented in part or in whole in software. For this purpose, a data storage device may store instructions which, when executed in at least one processing device of the networked computing devices, such as the processing component PC of the secure key management device SKMD, perform steps implementing those parts of the method for which the computing device has a role, for example steps performed by the secure key management device SKMD, the participation server JS, the registration device RD, the end device ED, etc.

[0080] The embodiments shown in Figures 1, 2, 5, and 6 above illustrate exemplary embodiments of the improved devices, systems, and methods, and thus do not constitute an exhaustive list of all embodiments of the improved devices, systems, and methods. Actual devices, systems, and methods may differ from the embodiments shown, for example, in terms of arrangement, devices, messages exchanged, and parameters.

[0081] Reference sign APP End Application AS Application Server ED End Device I / F Secure interface JS Participating Server NS Network Server OEM Device Manufacturer PC Processing Components SKMD Secure Key Management Device SSC Secure Storage Component AppKey Application root key AppSKey Application Session Key DevEUI End Device Address Identifier Ka (Active) Master Key Kn (master key) version data NwkKey Network Root Key NwkSEncKey, FNwkSIntKey, SNwkSIntKey Network session keys RKey Root Key REQ1 First request RSP1 First Response SID Session Information SKey Session key S / N Unique identifier (of the end device)

Claims

1. A secure key management device (SKMD) for a wide area network, comprising an end device (ED), a network server (NS), an application server (AS) and a participation server (JS), a Secure Storage Component (SSC) for storage of private key information; a secure interface (I / F) for securely exchanging data with said participating server (JS); at least one processing component (PC), - generating and storing at least one master key (Ka) in said Secure Storage Component (SSC); - generating at least one root key (RKey) based on said at least one master key (Ka) and a unique identifier (S / N) of said end device (ED), and providing said at least one generated root key (RKey) to said end device (ED); receiving a first request (REQ1) from said participation server (JS) via said secure interface (I / F) comprising said unique identifier (S / N) of said end device (ED) and session information (SID); generating at least one session key (SKey) based on the at least one master key (Ka) stored in the secure storage component (SSC) and the unique identifier (S / N) of the end device (ED) and the session information (SID) included in the first request; at least one processing component (PC) adapted to provide said at least one session key (SKey) to said participating server (JS) via said secure interface (I / F); A secure key management device (SKMD) comprising:

2. An authentication system for authenticating an end device (ED) in a wide area network, comprising: A secure key management device (SKMD) according to claim 1, a Participation Server (JS) connected to said Secure Key Management Device (SKMD) via said Secure Interface (I / F); Equipped with at least one processing component of said Participation Server (JS), receiving a second request from said end device (ED) comprising address information of said end device (ED); providing said first request (REQ1) based on said address information of said second request to said secure key management device (SKMD) via said secure interface (I / F); - an authentication system configured to forward the at least one session key (SKey) received from the secure key management device (SKMD) via the secure interface (I / F) to at least one of the network server (NS) and the application server (AS).

3. a registration device (RD) connectable to said end device (ED) and to said secure key management device (SKMD) during a pre-registration procedure, at least one processing component of said registration device (RD) during said pre-registration procedure, - determining the unique identifier (S / N) of the end device (ED); providing a third request to said Secure Key Management Device (SKMD) including said unique identifier (S / N) of said End Device (ED); receiving said at least one root key (RKey) provided by said secure key management device (SKMD); - storing said at least one root key (RKey) securely in said end device (ED); The authentication system of claim 2 , configured to perform the following:

4. The at least one processing component of the registration device (RD) during the pre-registration procedure: - determining an End Device Address Identifier (DevEUI) for addressing said End Device (ED) in said wide area network; - storing said end device address identifier (DevEUI) in said end device (ED); providing a registration message to said participation server (JS), said registration message including said unique identifier (S / N) of said end device (ED), said end device address identifier (DevEUI) and, optionally, version data (Kn) related to said master key (Ka) used to generate said at least one root key (RKey); The authentication system of claim 3 , further configured to:

5. 1. A wide area network, comprising: - an authentication system according to any one of claims 2 to 4, at least one end device (ED); at least one network server (NS), at least one Application Server (AS), Equipped with said at least one end device (ED) is configured to send data packets to said network server (NS), said data packets being encrypted on the network layer and on the application layer; said at least one network server (NS) is adapted to decrypt said data packets on said network layer using at least one network session key (FNwkSIntKey, SNwkSIntKey, NwkSEncKey) received from said participating server (JS) and to forward said decrypted data packets to said application server (AS); - a wide area network, wherein said at least one application server (AS) is configured to decrypt said data packets on said application layer using at least one application session key (AppSKey) received from said participating server (JS).

6. The wide area network of claim 5, comprising a low power wireless access network domain including the end device (ED) and a core network domain including the application server (AS), and the secure interface (I / F) is configured to exchange data with the participating server (JS) outside the low power wireless access network domain and / or the wired core network domain.

7. 7. The wide area network of claim 5 or 6, wherein the wide area network is a LoRaWAN network, the secure interface (I / F) is configured to exchange data with the participating server (JS) outside the address space of the LoRaWAN network, and the session information (SID) includes at least one of a participating nonce, a network id, and a device nonce.

8. 1. A method for generating a session key (SKey) for use in a wide area network comprising an end device (ED) pre-registered with a secure key management device (SKMD), a network server (NS), an application server (AS) and a participation server (JS), the method comprising the steps of: receiving, by said secure key management device (SKMD), from said participating server (JS) via a secure interface (I / F), a first request (REQ1) comprising a unique identifier (S / N) of said end device (ED) and session information (SID); generating, by said secure key management device (SKMD), at least one session key (SKey) based on at least one master key (Ka) stored in said secure key management device (SKMD) and on said unique identifier (S / N) of said end device (ED) and said session information (SID) included in said first request (REQ1); providing said generated at least one session key (SKey) to said Participation Server (JS) via said secure interface (I / F) by said Secure Key Management Device (SKMD); A method comprising:

9. 9. The method of claim 8, wherein at least one network session key (FNwkSIntKey, SNwkSIntKey, NwkSEncKey) and at least one application session key (AppSKey) are generated and provided to the participating server (JS) by the secure key management device (SKMD).

10. The generating of at least one session key (SKey) comprises: - calculation by said secure key management device (SKMD) of at least one first cryptographic function (F) using said at least one master key (Ka) stored in said secure key management device (SKMD) and said unique identifier (S / N) of said end device (ED) included in said first request (REQ1); Ａ , F Ｂ generating at least one root key (RKey) for said end device (ED) based on said generating, by said secure key management device (SKMD), said at least one session key (SKey) based on at least one second cryptographic function using said at least one root key (RKey) generated and said session information (SID) included in said first request; The method of claim 8 or 9, comprising:

11. The end device (ED) is pre-registered with the secure key management device (SKMD) prior to receiving the first request (REQ1) by the secure key management device (SKMD) in a pre-registration procedure, the pre-registration procedure comprising: generating, by said secure key management device (SKMD), said at least one master key (Ka) and storing said at least one master key (Ka) in said secure key management device (SKMD); generating, by said secure key management device (SKMD), at least one root key (RKey) based on said at least one master key (Ka) and the unique identifier (S / N) of said end device (ED) provided to said secure key management device (SKMD); providing said at least one generated root key (RKey) to said end device (ED); The method according to any one of claims 8 to 10, comprising:

12. said generating of at least one master key (Ka) is repeated after a predetermined condition, during said pre-registration procedure, said end device (ED) is provided with version data (Kn) related to said master key (Ka) used to generate said at least one root key (RKey); The method according to claim 11, wherein the first request (REQ1) received from the participating server (JS) further comprises the version data (Kn).

13. receiving, by said participation server (JS), from said end device (ED), a second request comprising address information of said end device (ED); providing, by said Participation Server (JS), via said secure interface (I / F), to said secure key management device (SKMD), said first request (REQ1) based on said address information of said second request; - transferring said at least one session key (SKey) received from said secure key management device (SKMD) to said network server (NS) and / or said application server (AS) via said secure interface (I / F); 13. The method of any one of claims 8 to 12, further comprising:

14. The address information of the second request includes an end device address identifier (DevEUI) of the end device (ED), and the method further comprises: providing said Participation Server (JS) during said pre-registration procedure said unique identifier (S / N) of said end device (ED), said end device address identifier (DevEUI) and, optionally, version data (Kn) related to said master key (Ka) used to generate said at least one root key (RKey); - mapping, by said participation server (JS), said end device address identifier (DevEUI) contained in said second request to said unique identifier (S / N) of said end device (ED); generating, by said Participation Server (JS), said first request (REQ1) based on said mapping of said end device address identifiers (DevEUI) to said unique identifiers (S / N); The method according to claim 13, which is based on any one of claims 11 or 12 and further comprises:

15. 15. A data storage device storing instructions which, when executed by at least one processing device of a networked computing device, perform the steps of the method of any one of claims 8 to 14.

Images