CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62/456,370, filed February 8, 2017 and U.S. Provisional Patent Application No. 62/456,957 filed February 9, 2017, the disclosures of which are incorporated by reference in their entireties.

BACKGROUND

[0002] It is expected that a very large number of Internet of Things (IoT) units will be deployed, serving many different end-user control and surveillance needs. Many of these units will have limited resources. For example, the units may be battery driven and resource constrained. Furthermore, large numbers of IoT units serving a single application domain, such as for industry plant control or a city surveillance system, may require that the costs per unit be kept at a minimum. Current cellular networks do not meet these cost demands, as a single unit subscription cost is far too high. At the same time, wireless networks are the most cost efficient way to deploy a large number of IoT units in a certain geographical area. Such a network may be offered by a dedicated wireless network which is not part of the 3G/4G/5G infrastructure, by deploying wireless gateways serving a low power wireless license-free network in the areas where network connectivity is needed. This type of network is often referred to as a Low-Power Wide- Area Network (LPWAN) or Low-Power Network (LPN). An example of the network structure of such a network is depicted in FIG. 1. As shown, wireless gateways WGWl, WGW2, and WGW3 are deployed throughout an IP network to form a LPWAN through which wireless IoT units can communicate with an IoT Server. SUMMARY

[0003] Methods and systems for key provisioning in Low Power Wide- Area Network (LPWAN) systems are disclosed. In one aspect, a key provisioning procedure is disclosed in which an application provider transfers a group master key to a network provider prior to device deployment. This key may allow the network provider to authenticate a large number of devices in the system without the need to manage device unique keys. Several different application domain providers may be able to share a common LPWAN infrastructure with low key management overhead at the LPWAN infrastructure side and without compromising end-to-end security needs of the application providers. This procedure may be fully interoperable with systems that implement the LoRa LPWAN industry standard.

[0004] In another aspect, methods and systems for identity protection and identity assignment in LPWAN systems are disclosed. A key management structure may be provided where each IoT unit in the wireless network is configured with key material from the home application domain in a credential provisioning step. In a first embodiment, an application owner, in addition to generating a domain unique master secret, may also generate a domain unique identity protection key that is generated independently of the unique master secret or may be generated based on the unique master secret. The domain unique identity protection key may be pre-configured into an IoT device prior to deployment. In a second embodiment, instead of giving the domain unique master secret to the provider, the domain unique master secret may be kept in the application domain and, at first network connect, the provider may need to request the domain unique master secret from the application domain. In a third embodiment, a domain identifier may be generated based on pseudo random value such that neither an external attacker nor a user from another domain will be able to identify if a network attachment is done from a certain domain in the system.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The foregoing Summary, as well as the following Detailed Description, is better understood when read in conjunction with the appended drawings. In order to illustrate the present disclosure, various aspects of the disclosure are shown. However, the disclosure is not limited to the specific aspects discussed. In the drawings:

[0006] FIG. 1 shows an example wireless network scenario; [0007] FIG. 2 shows an example key provisioning method using a LoRa system;

[0008] FIG. 3 shows an example diagram of a LoRa system;

[0009] FIG. 4 shows an example message protection method using the LoRa system shown in FIG. 3;

[0010] FIG. 5 shows an example LPWAN system diagram comprising two different IoT domains running on an infrastructure operated by a third party;

[0011] FIG. 6 shows an example key provisioning and management procedure performed at the IoT back-end domain according to an embodiment of the invention;

[0012] FIG. 7 shows an example system diagram for a key provisioning and management procedure performed at the provider domain according to an embodiment of the invention;

[0013] FIG. 8 shows an example flow chart for a key provisioning and management performed at the provider domain according to an embodiment of the invention;

[0014] FIG. 9 shows an example key provisioning and management procedure performed at the IoT unit according an embodiment of the invention;

[0015] FIG. 10 shows an example key distribution and IoT device authentication and communication system diagram according to an embodiment of the invention;

[0016] FIG. 11 shows a first key provisioning procedure according to an embodiment of the invention;

[0017] FIG. 12 shows an example embodiment comprising a bike provider and a city surveillance system;

[0018] FIG. 13 A shows an embodiment of a message chart;

[0019] FIG. 13B shows another embodiment of a message chart;

[0020] FIG. 14 shows an example device identity protection method according to an embodiment;

[0021] FIGS. 15A and 15B show another embodiment of a message chart;

[0022] FIG. 16 shows an example procedure implemented by an IoT device;

[0023] FIG. 17 shows an example procedure implemented by a provider domain;

[0024] FIG. 18 shows an example food delivery and city surveillance example;

[0025] FIG. 19 shows an exemple wireless transmit/receive unit (WTRU) that may be employed as an IoT device or server; and [0026] FIG. 20 shows an exemple network entity.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0027] A LPWAN may be considered cost efficient if the wireless gateways (WGWs) are able to cover a reasonably large geographical area (wide area), the wireless IoT units only have limited mobility (e.g., no hand over or roaming support in the network), and the network bandwidth demands of the IoT units are low. There are many IoT use cases that meet these network expectations. Accordingly, a large number of such networks may be deployed. One example is the LoRa Alliance new IoT industry standard (see N. Sorin, M. Luis, T. Erich, T. Kramp and O. Hersent, "LoRaWAN Specification", V. 1.0, January, 2015). Other examples include the DASH7 Alliance Protocol (see Dash7 alliance, "Wireless Sensor and Actuator Network Protocol", Version 1, 2015), SigFox, the 3 GPP narrow band NB-IoT initiative, and NB- Fi from Waviot.

[0028] The LoRaWAN specification provides a set of basic security features for the protection of the communication between an IoT unit, the so-called "end-device," and the back- end server, the so-called "network server," as well as an application server. Example features of the LoRaWAN specification are shown in FIGS. 2, 3 and 4. Some of these example features include integrity protection of the Media Access Control (MAC) payload layer between the end- device and the network server using a Message Integrity Code (MIC) and a truncated (32 bits) AES based message integrity code, encryption of MAC commands between the end-device and the network server using an AES 128-bit key, encryption of the MAC payload between the end- device and the application server using an AES 128-bit key, and a secure session key derivation procedure between the end-device and the network server and application server.

[0029] The LoRa system does not provide any protection between the WGW and the end-device, but instead only provides protection between the end-device and the network server. LoRa utilizes a key hierarchy with three different keys:

[0030] A device individual long term key, the application key, Appkey;

[0031] A device individual network session key, NwkSkey; and

[0032] A device individual application session key, AppSKey.

[0033] The specification allows omitting the usage of the Appkey, and instead may allow a device to be activated in a so-called personalization step in which the NwkSkey and the AppSKey are directly loaded into the end-device and transferred to the network server and application server respectively. Additionally or alternatively, the NwkSkey and the AppSKey may be derived during a so-called "join procedure" in which the Appkey is used to calculate securely the NwkSkey and AppSKey.

[0034] It may be assumed that the Appkey is securely pre-configured to the end-device and the application server respectively. In a so-called "federated network" configuration, the network server and the application server may be separated, and the network server may need to communicate with the application server during the join procedure in order to get the NwkSkey. In a default configuration for the first version of the specification, the network server and the application server may be co-located and the co-located server has full access to the Appkey.

[0035] The NwkSkey may be used to calculate the MIC and also to encrypt the FRMPayload in the case of a MAC command. The AppSKey may be used to encrypt the FRMPayload for non-MAC commands and optionally also to integrity protect the application payload.

[0036] The first version of the LoRa specification does not discuss identity privacy, and the provider may have full access to the true identities of all IoT units that attach to the network. At the initial network connect, there is no identity privacy offered according to the current specification. However, the specification allows the provider to "arbitrarily assign" the 25 least significant bits of the device address to be within a session.

[0037] The Dash7 LPWAN technology also offers secure communication features. Different from the LoRA model, the Dash7 specification defines the interface between the wireless gateway and the end-device (endpoint in Dash8 terminology) or through end- devices/gateways and so-called subcontroller (two hop wireless networks). Hence, the protocol does not run between an IoT unit and a networking unit, but only over the wireless interface.

[0038] From a security perspective, Dash7 offers payload encryption and integrity protection though the AES counter mode (AES-CTR), AES Cipher-block chaining with integrity protection (AES-CBS-MAC) and authentication with CMC MAC, and encryption with AES counter mode (AES-CCM). The specification only includes a network key, and no key management routines are specified. Instead, these are expected to be handled by routines not part of the Dash7 specifications. Hence, identity privacy is not part of the specification. This also implies that the specification does not cover any identity protection mechanisms. [0039] SIGFOX is another example of proprietary LPWAN technology. From a security point of view, it currently offers the following main features: at the radio interface, Ultra Narrow Band (UNB) native protection, frequency hopping, data encryption, authentication, and anti-replay protection (i.e., the security ends at the WGW) may be applied; the connection from the WGW to the SIGFOX network server may be protected with an IP VPN connection (i.e., IPSEC); and end-to-end security may be offered through TLS from the device to the customer back-end.

[0040] TLS is not particularly suitable for LPWAN communication as it consumes bandwidth and may prevent message buffering at the network service provider. Furthermore, Pre-Shared Key (PSK) TLS or standard client certificate TLS variants do not give identity privacy. For example, see P. Eronen and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)," IETF, RFC 4279, 2005; T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2," IETF, RFC 5246, 2008; and E. Rescorla and N. Modadugu, "Datagram Transport Layer Security," IETF, RFC 4347, 2006.

[0041] Since the end of 2015, work has been ongoing within 3GPP to specify a narrowband version of LTE named narrowband IoT (NB-IoT), targeting so-called Machine Type Communication (MTC) for applications with low data rate and with limited battery capacity. NB-IoT can be deployed on a GSM carrier or in the guard bands of LTE spectrum allocations, or using part of an operator's LTE spectrum (see M. R. Palattella et al., "Internet of Things in the 5G Era: Enablers, Architecture, and Business Models," in IEEE Journal on Selected Areas in Communications, vol. 34, no. 3, pp. 510-527, March 2016). The disclosed access security principles may become the standard for cellular GSM/UMTS/LTE security procedures with a physical SIM-card or an embedded SIM (see V. Niemi and K. Nyberg, UMTS Security, Wiley, November, 2003; D. Forsberg, G. Horn, W-D. Moeller, V. Niemi, LTE Security, Wiley, June, 2011; and ETSI, "Smart Cards: Embedded UICC; Requirements Specification," TS 103 383, October, 2015).

[0042] Group authentication schemes may be employed to provide security features in LPWAN systems. According to the current 3GPP cellular authentication and key agreement AKA specification, each device may perform a full authentication procedure that involves both the serving network (e.g., the local network that provides services to the device) and the device's home network. When many devices require access simultaneously, a situation determined by the IoT scenario, the signaling between serving and home network represents a bottleneck, which may decisively affect, for example, the promised high speed of future cellular networks. For this reason, a new group-based AKA protocol has been identified as one of the security enablers to be introduced in 5G.

[0043] The goal of a group-based AKA protocol is to reduce the signaling between serving and home networks when a group of many devices requires access at the same time. Several new protocol suggestions and principles have been provided. For example, see Broustis, G. S. Sundaram and H. Viswanathan, "Group authentication: A new paradigm for emerging applications", Bell Labs Technical Journal, 17(3), pp. 157-173, 2012; C. Lai, H. Li, H., R. Lu and X. S. Shen, X. S., "SE-AKA: A secure and efficient group authentication and key agreement protocol for LTE networks", Computer Networks, 57(17), 2013; D. Choi, H-K Choi and S-Y. Lee, S.-Y, "A group-based security protocol for machine-type communications in LTE- advanced", Wireless Networks, 21(2), pp.405-419, 2014; J. Cao, M. Ma and H. Li, "Gbaam: group-based access authentication for MTC in LTH networks", Security and Communication Networks, 8(17), pp. 3282-3299, 2015; and R. Giustolis and C. Gehrmann, "Threats to 5G Group-Based Authentication", to appear in proceedings of SECRYPT, Lisboa, Portugal, June, 2016.

[0044] The main principle in many of the above discussed protocols is that the authenticating unit may use a type of "master secret" or public key mechanism to authenticate several devices in the network without the need to communicate back to the devices' home network. Alternatively, a public key distribution mechanism may provide similar behavior.

[0045] With respect to privacy, NB-IoT shares the 3 GPP standard property where the true identity (i.e., the International Mobile Subscriber Identity (FMSI) of a mobile unit) only is visible on the network during first network attachment. During all subsequent communication with the network, the so-called Temporary Mobile Subscriber Identity (TMSI) is used instead. Although this principle makes it considerably harder for an attacker to track an individual user or device, it does not provide full identity privacy.

[0046] New and improved methods and systems for key provisioning and identity privacy in LWANs, such as those disclosed herein, may be desired.

[0047] In this detailed description, the following notations may be used:

[0048] A set of IoT units in a domain D: U _D . [0049] A single IoT unit in the set: u E U _D .

[0050] An IoT back-end manager: Μΐοτ

[0051] A wireless access domain manager: Mp.

[0052] An IoT application access server: SD.

[0053] A wireless provider access server: SP.

[0054] A provider wireless gateway: G _P

[0055] An ID of the domain D: IDD.

[0056] A domain unique ID of IoT unit u: ID _U .

[0057] A temporary unique ID of IoT unit u: TID _U .

[0058] A first random nonce: Ni.

[0059] A second random nonce: N2.

[0060] A third random nonce: N3.

[0061] A master key used by Μΐοτ for the set UD: MKD.

[0062] An access key for unit u: KA _U .

[0063] An end-to-end long term protection key fror unit u: KE _U

[0064] A secure access session key shared between the IoT unit u and the provider domain: KASu.

[0065] A secure end-to-end session key shared between the IoT unit u and the IoT application domain: KESu

[0066] A domain wide identity protection master key: MKID.

[0067] A domain ID protection master key: MKDD.

[0068] A LoRa LPWAN integrity and confidentiality protected "Join Accept" message: am.

[0069] Encryption of the message m with the key k: c = E(k,m).

[0070] Decryption of the ciphertext c with the key k: m = D(k,c).

[0071] A cryptographic strong Pseudo Random Function, PRF with two input parameters, a key, k, and a random value, r, and with a pseudo random string, s as output parameter: s = PRF(k,r).

[0072] A pseudo ID generation function, F, that takes two input parameters, MKDD and N3 and generates a pseudo domain ID, IDD' = F(MKDD, Ni). [0073] A domain mapping function, G, that takes a pseudo ID generated by the function F and a domain ID protection key, MKDD and gives as output one (or several) domain IDs matching the pseudo ID: ID = G(MKD, IDD'), where ID denotes the set of matching domains IDs and MKD denotes the set of domain ID master keys stored at the provider.

[0074] Several different IoT application domains may share a LPWAN infrastructure managed by one of the application domain owners. Additionally or alternatively, the LPWAN infrastructure may be run as a separate wireless infrastructure service.

[0075] FIG. 5 shows an example LPWAN system in which two different IoT domains (i.e., IoT Domain A and IoT Domain B) are running on an infrastructure operated by a third party. The LPWAN system of FIG. 5 may comprise a number of wireless networks, such as Wireless Network 1, Wireless Network 2, and Wirelss Network 3. Each of the wireless networks may be associated with a wireless gateway, such as WGW1, WGW2, and WGW3, respectively. One or more wireless IoT units associated with one or more of the IoT domains may be connected to the one or more wireless networks. For example, Wireless Network 1 may comprise three IoT units associated with IoT domain A and two IoT units associated with IoT domain B.

[0076] An IoT domain server and network infrastructure provider may have a number of security expectations. For example, the wireless infrastructure provider may need to make sure that only IoT units from domains where a service contract between the domain owner and the infrastructure are connected. The IoT domain owner may need to make sure that the IoT units only connect to "approved" IPWANs run by an infrastructure provider with whom the IoT domain owner has an agreement. The IoT owner may need to protect the communication between the IoT units and the IoT domain server end-to-end. As the system may include a very large number of IoT units, it may be desirable to avoid a situation where the IoT domain owner needs to share individual secrets for all of the IoT units with the infrastructure provider as this is a cost driver for the management of the system. The key management and security infrastructure may need to be compatible with existing industry standards such as the one from the LoRA alliance. In addition, it may be desired that the systems are not dependent on public key operations on the device side.

[0077] Some current LPWAN solutions (e.g., LoRa) provide network authentication and key-agreement on layer three when the device first joins the network. This implies that any device is allowed to make a layer two (radio) connection with the WGW while the actual network authentication and key agreement takes place over an IP connection at the network server (which serves several WGWs in the system). This is quite different from traditional cellular networks where authentication is always performed at layer two during "network attach" and based on secrets stored on SIM-cards on the devices. Although this LPWAN approach has some clear network management and ease of deployment advantages, it also has some general security disadvantages. Independent of those, in such systems, there must be means for the network server during first network connect from a device to authenticate the connecting device and to derive keys needed to protect the communication for a complete network session.

Furthermore, there must be means for the device to also derive the very same keys at the network server to be used to protect the communication. There should also be means for the application domain to protect the application specific communication between the IoT server and the device end-to-end. However, according to the current LoRa industry standard, the specification supported solution to provide this is limited with respect to the following:

[0078] (1) In order to authenticate connection of a device during network session establishment, the network server needs to have access to individual, long-term keys for each connection IoT device in order to perform both authentication and session key derivation. This means that currently the only two directly supported options to support this are the following:

[0079] The network server has access to a local database with all IoT device IDs and device long-term keys stored; and

[0080] The network server has an interface towards the application domain, from which it can fetch the long-term device unique keys (potentially derived from a "master secret" at the IoT domain) in "online" mode when a new IoT device connects to the network.

[0081] (2) The Network Server derives all session and application level keys using the single, long term key shared with the device instead of using separate keys for end-to-end and access level protection, which implies that the end-to-end security (application level) is broken.

[0082] Hence, there is a need for a LPWAN key management solution that allows making key agreement on layer three during device session establishment but without the need to manage all the device individual keys on the network server side or being forced to have an "online" key fetching interface toward the application domain (as this makes the system less robust and complex). Furthermore, the key management solution should allow application data to be protected end-to-end and not just from the device towards the network server. The solution should meet the security expectations of the network and be cost efficient.

[0083] A cost efficient key management solution for LPWANs with multiple IoT domains is discussed further herein.

[0084] The disclosed solution may employ the basic principle of using a shared master secret in order to avoid communication between the entity in the network and the key back-end. However, in contrast to group authentication schemes suggested for cellular applications, a general LPWAN approach may be utilized that does not assume any cellular authentication infrastructure and instead assumes the IoT application provider itself takes the key access, key generation, and management responsibility.

[0085] A key management structure may be employed in which each IoT unit in the wireless network is preconfigured with key material from the home application domain in order to protect the IoT units, the application domain server, and the provider network in a cost efficient way. However, this is not intended to be limiting and the pre-reconfiguration process may be implemented in a number of ways. For example, the pre-configuration process might be done through direct transfer prior to device deployment. In one embodiment, each IoT unit may be securely equipped (over an authenticated and protected connection or through direct configuration) with at least the following security parameters:

[0086] An application domain ID, IDD;

[0087] A unique device ID (within the domain) which may be at least 32 bits long,

IDiof,

[0088] A device unique wireless access key, KA; and

[0089] A device unique end-to-end key, KE.

[0090] The device ID may be the same in Domain A and Domain B. In one embodiment, the unique device ID may need to be long enough so that it may be used as input to a key generation process. This general process is described using two different application domains. However, it is understood that this process is general and may apply to any number of application domains.

[0091] FIG. 6 illustrates example details of the key management and key provisioning procedure as performed at an IoT back-end domain. [0092] As shown, in step 1, the / ₀ r may use a good random source to generate a unique domain ID for the domain D. Alternatively, it may receive an assigned domain ID, IDD,

[0093] In step 2, the Μΐοτ may use a good random source to generate a domain master

[0094] In step 3, the / ₀ r may use a secure channel (authenticated, integrity and confidentiality protected) to transfer MDD and IDD to MP (if not received at step 1).

[0095] In step 4, the Vu G U _D , MI ₀ T may use a good random source to generate a device unique key: KE _U .

[0096] In step 5, the Vu G U _D , MI ₀ T may use a good random source to generate a unique device ID: ID _U .

[0097] In step 6, the Vu G U _D , MI ₀ T may use the PRF to calculate a device unique access key: KA _U = PRF(MDD, ID„).

[0098] In step 7, the Vu G U _D , MI ₀ T may transfer the keys KE _U , KA _U and the ID values IDD. IDU to u at manufacture, customization or at IoT unit deployment using a secure provision mechanism.

[0099] In step 8, SD may establish a secure channel with Sp.

[00100] In step 9, SD may wait for new IoT unit access requests from a unit u through

[00101] In step 10, if a new request is received, SD may use the IoT ID, ID _U , given in the request to look up the key KE _U .

[00102] In step 11, the key KE _U may be used to authenticate the connecting unit u and to derive a fresh application session key KESu. KESu may then be used to integrity and confidentiality protect all further communication between SD and u.

[00103] FIGs. 7 and 8 illustrate example details of the key management and key provisioning procedure as performed at the provider domain. As shown in FIG. 7, the provider domain may comprise a wireless access domain manager denoted Mp, a wireless provider access server denoted SP, and a gateway denoted Gp. Note that secure access protection may end at SP or may alternatively end at the Gp. In the case that the procedure ends at the Gp, the Gp may need to interact with the Mp to derive the necessary key materials. [00104] Referring to FIG. 8, in step 1 , the Mp may receive MDD and IDD from Μΐοτ over an integrity and confidentiality protected channel or alternatively may just receive MDD and may generate IDD and send it over to Μΐοτ.

[00105] In step 2, the Sp may wait for new connection requests from IoT units.

[00106] In step 3, the Sp may receive a new access request from unit u. The access request may contain the values ID _U , IDD as well as a random nonce, Ni.

[00107] In step 4, the Sp may use IDD and ID _U to request the device unique access key

[00108] In step 5, the Mp may use the IDD to look up MDD which in turn together with IDu may be used to calculate KA„ = PRF(MDD, IDU).

[00109] In step 6, the Mp may return KA _U to Sp.

[00110] In step 7, the Spmay calculate a random nonce, N2 and optionally also calculate an authentication response, Ri using at least the parameters KASu, Ni,N2 as input.

[00111] In step 8, the Spmay return N2 and optionally Ri.

[00112] In step 9 (optional), the Sp may receive an authentication response, R2, from u. If R 1S received, Spmay authenticate u by checking R2 towards an authentication function, taking at least the parameters KA _u ,Ni,N2 as input. If the authentication fails, the procedure may be aborted.

[00113] In step 10, the Sp may use at least the parameters KA _u ,Ni,N2 to calculate a session access key, KASu, shared with u.

[00114] In step 11, all further communication between the Sp and u may be integrity protected using the key KASu and optionally also confidentiality protected using the key KASu.

[00115] In step 12, the Sp may use IDD XO look up the correct application domain and all valid traffic received from u, Sp forwards to SD.

[00116] FIG. 9 illustrates example details of the key management and key provisioning procedure as performed at an IoT device. As discussed above in connection with FIGs. 7 and 8, the secure access connection may be terminated at G _P . Alternatively, the secure access connection may be terminated at S _P . The examples discussed herein refer to an implementation in which the secure access connection is terminated at Sp. However, it is understood that this is done for simplicity and is not intended to limit the disclosure. [00117] Referring to FIG. 9, in step 1, before or at deployment, u may securely receive the following parameters from Mm : KE _U , KA _U , IDD, ID _U .

[00118] In step 2, u may detect a new LPWAN and may try to connect.

[00119] In step 3, u may generate a random nonce Ni and send at least the following parameters to Gp or SP: ID _U , IDD and Ni.

[00120] In step 4, u may receive N2 and optionally an authentication response Ri from

[00121] In step 5, if an authentication response is received at step 4, u may authenticate SP by checking Ri towards an authentication function taking at least the parameters KA _u ,Ni,N2 as input. If the authentication fails, the procedure may be aborted.

[00122] In step 6 (optional), u may calculate an authentication response, R2, using at least the parameters KA _U , Ni,N2 as input and send this to SP.

[00123] In step 7, u may use at least the parameters KA _u ,Ni,N2 to calculate a session access key, KASu, shared with SP .

[00124] In step 8, all further communication between the Sp and u is integrity protected using the key KASu and optionally also confidentiality protected using the key KASu.

[00125] In step 9, u may send an access request containing at least the parameter IDu to SD (routed through Sp).

[00126] In step 10, u may use the key KE _U to authenticate SD and to derive a fresh session key KESu. KESu may then be used to integrity and confidentiality protect all further communication between u and SD.

[00127] In one embodiment, the IoT application domain may not generate MDD but instead receive it from the network provider. Furthermore, the IoT application domain manager may also receive a range of device IDs that it is allowed to use in the system together with MDD.

[00128] In another embodiment, the IoT application domain may not use a single domain ID and corresponding single master key for all its units connected to the wireless provider, but instead has multiple domain IDs and corresponding master keys for its devices. Hence, it is possible to give different network service levels for different classes of devices that the IoT application domain manager deploys in the system. [00129] FIG. 10 illustrates an example overview of an IoT protection process according to an embodiment of the invention. The example key distribution and IoT device authentication and communication process shown in FIG. 10 may comprise the following steps:

[00130] In step 1, prior to IoT deployment, the domain manager may generate or receive the above security parameters and use a suitable secure provisioning mechanism to provision each of the IoT units.

[00131] In step 2, the application domain owner may use a secure channel to securely transfer a domain master secret, MKD, to the wireless network provider. The domain unique master secret, MKD may have been securely generated by the application domain owner. If the network provider has not chosen the domain ID, also the domain ID, IDD, may be securely transferred to the network provider.

[00132] In step 3, each time the IoT unit tries to make a new network attachment to the WGW, it may transfer the ID values IDD and IDioT to the wireless provider and a mutual authentication and wireless access network key derivation process may be performed based on the key KA. If the authentication and key derivation is successful, the wireless provider network servers may open up a secure (integrity and confidentiality protected) forwarding channel that forwards all communication from the IoT unit to the IoT Back-end Server in the application domain IDD. All wireless communication may be integrity and confidentiality protected using the session keys derived from the key KA at the session establishment.

[00133] In step 4, an authentication and session keys establishment procedure may be performed between the IoT unit and the application domain Back-end Server using the key KE. The session key may be consecutively used to confidentially and integrity protect all message exchanges between the IoT unit and the IoT Back-end Server.

[00134] FIG. 11 shows an example implementation of the key management and provisioning procedures illustrated generally in FIG. 10 and described above.

[00135] In step 1, the IoT backend manager may generate a domain master key MDD and a domain ID IDD using a random value.

[00136] In step 2, the IoT backend manager may register the domain ID IDD with the domain app server.

[00137] In step 3, the IoT backend manager may send to the IoT access server the domain master key MDD and the domain ID IDD. [00138] In step 4, for each device, the IoT backend manager may generate a device end-to-end key KEu and a device access key KAu.

[00139] In step 5, the IoT backend manager may send to the IoT device the device ID IDu, the device end-to-end key KEu, the device access key KAu, and the domain ID IDD.

[00140] In step 6, the IoT device may generate a first nonce Ni.

[00141] In step 7, the IoT device may send to the network provider an access request comprising the device ID IDu, the domain ID IDD and the first nonce Ni.

[00142] In step 8, the network provider may send to the IoT access server a request for a device key. The request may comprise the domain ID IDD and the device ID IDu.

[00143] In step 9, the IoT access server may perform a master key lookup using the domain ID.

[00144] In step 10, the IoT access server may generate a device access key KAu.

[00145] In step 11, the IoT access server may send to the network provider the device access key KAu.

[00146] In step 12, the network provider may generate a second nonce N2.

[00147] In step 13, the network provider may send to the IoT device an access response. The access response may comprise the second nonce N2.

[00148] In step 14, the network provider may generate a device session access key KASu based on the device access key KAu, the first nonce Ni, and the second nonce N2.

[00149] In step 15, the IoT device may generate a device session access key KASu based on the device access key KAu, the first nonce NI, and the second nonce N2.

[00150] In step 16, the IoT device and the network provider may communicate using an encrypted communication using the device session access key KASu and the device end-to-end key KEu.

[00151] In step 17, the network provider may decrypt the communication using the device session access key KASu.

[00152] In step 18, the IoT device may communicate with the IoT access server through an encrypted communication using a channel protected under the device end-to-end key

KEu.

[00153] The disclosed methods and systems offer many advantages over prior LPWAN solutions. For example, similar to prior solutions with separate network servers and application servers (federated configurations), full trust from the application domain perspective in the network provider may be avoided. The network server/WGW may only use a trustworthy procedure for the generation of the network access keys, while all end-to-end protection keys may be kept in the application domain. In addition, the separation of application protection and network protection can be done without the need for any direct (e.g., online) access key transfer interface between the application domain and the provider domain as the domain key can be transferred once and then the network domain can use this key for the device authentication and network protection key generation without the further involvement of the application domain. This opens up to services like message buffering at the provider side at, for example, application domain network down periods, which makes the IoT system more robust.

[00154] Furthermore, it may be possible to achieve these advantages without the need for any public key operations at the IoT side or any need for public key or certificate transfer at connection establishment. The device unique access keys may be calculated using a domain master secret shared with the network provider. This avoids the need for sharing device unique secrets between the application domain and the network domain. In addition, the proposed solution is fully interoperable with the LoRa LPWAN standard.

[00155] FIG. 12 shows a real world implementation of the key provisioning and management procedures discussed herein. This real world implementation is represented as a scenario where a LoRa network provider offers LPWAN to several different application providers in a city. The example comprises a public city surveillance system that jointly utilizes the offered network together with a city bike rental provider. The public city surveillance provider system utilizes the LPWAN to measure traffic flows including all type of transport such as motor vehicles, bikes and pedestrians, through sensors located all over the city. The sensors may communicate with the city surveillance system using the LoRa LPWAN infrastructure.

[00156] The city bike rental provider offers bikes for rental all over the city with tamper protected electronic locks on each and every bike. Each bike is equipped with GPS as well as a bike local control unit with LPWAN support and that communicates with the city bike provider back office system. The city bike provider allows anyone, after correct payment, to utilize any of the bikes in the city for a certain payed time period. Once the user has rented the bike, it will have sole access to it during the paid period and the bike will indicate through a red LED signal to other users that is in use. The user is allowed to park the bikes after usage at any outdoor public location within the city boarders and the bike controller keeps track of whether the bike is kept within the allowed areas or not, automatically locks (done through an inbuilt break lock system) the bike and sends out a warning through LPWAN to the back-end system. The LPWAN is also used to unlock, through a command from the back-system ,when a user has made a purchase for a certain bike and time period. Such purchase is done by the user through a mobile application communicating with the city bike provider back office. The bike provider also utilizes the GPS support and LPWAN communication capabilities of the bikes to keep track of each and every bike deployed in the system (can also be used to indicate to end-users where to find free bikes) and to locate bikes that have been brought out of allowed areas (can also be used to indicate to end-users where to find free bikes). This example scenario is depicted in FIG. 12, and is further described below. The below description relates only to application of the proposed methods in perspective of the bike provider system and not the city surveillance system.

However, the very same principle applies for that application domain.

[00157] In this example, the bike provider may follow the procedure described herein and generate a domain general master key for access control, MDD, which may be transferred to the LPWAN LoRA provider and get a unique application ID from the provider, IDD = AppEUI according to the LoRa specification terminology.

[00158] The bike provider may generate bike specific keys for all bikes that it deploys in the system according to the procedure described herein and according to the LoRas definitions DevEUI = IDu and AppKey = KA _U = PRF(MDD, ID _U ). The device unique end-to-end key, KE _U , may replace the LoRA AppSKey as it has exactly the same end-to-end protection function and is not derived from the AppKey but is chosen uniquely and random by the bike provider at bike deployment.

[00159] When a new bike is deployed in the system, it may use the LPWAN radio interface to try to find a LoRa network. If such network is found, it may use the LoRA join procedure to connect to that network using the AppKey and by giving its device and application IDs, AppEUI, DevEUI. The LoRa server is then able to use AppEUI to find the right domain master key, MDD, which in turn can be used together with DevEUI for the server to derive the correct AppKey. The LoRa network server uses this key to derive a network access session key, NwkSKey (KASu) using the standardized key derivation function. NwkSKey may be used by the LoRa Network Server to authenticate the connecting IoT unit and to protect the control commands between the IoT unit and the network server.

[00160] After successful authentication of the bike and identification of the application domain, the network server may forward all application messages from the bike to the bike provider back-end server. This communication may be integrity and confidentiality protected using the key KE _U as master key to set up a secure session between the bike provider back-end server and the bike as described in our invention.

[00161] The LoRa specification allows the key derivation to be done at a separate application server and hence full interoperability with the current LoRa specification can be achieved with this modification by just omitting the application key derivation process at the application server and simply directly using the key KE _U for application message protection at the IoT unit instead of the AppSKey. If full interoperability is needed, the IoT unit can set AppSKey = KE _U but that gives less security and it is preferable to use a separate application session key derivation process between the IoT unit and the application server, as described herein.

[00162] Turning now to issues of identity privacy, in addition to the security expectations discussed above to which the key provisioning and management methods of FIGs. 6-12 are directed, there may be a number of security expectations concerning identity privacy as well. For example, it should not be possible for any external attacker (i.e., all entities except the provider or other users of the LPWAN infrastructure) to track an individual device based on the information sent during network establishment or re-connect; it should not be possible for the provider to track an individual device based on the information sent during network

establishment or re-connection; and it should not be possible for any external attacker to either track the application domain an individual device belongs to using the information sent during network establishment or to re-connect.

[00163] To address these and other issues of IoT identity privacy protection, disclosed herein are methods and systems for identity protection and identity assignment. The methods and systems below may be additive to or aligned with the key provisioning and management methods and system described above in connection with FIGS. 6-12. The disclosed methods and systems may also be interoperable with the LoRa LPWAN standard. Exemplary embodiments make use of a key management structure where each IoT unit in the wireless network may be preconfigured with key material from the home application domain in a credential provisioning step. The methods and systems disclosed herein are not, however, limited in any way as to how this pre-reconfiguration may be performed. For example, in one embodiment it may be performed through direct transfer prior to device deployment. Each IoT unit may be securely (over an authenticated and protected connection or through direct configuration) equipped with at least the following security parameters:

[00164] An application domain ID, IDD.

[00165] A unique device ID (within the domain), ID _U .

[00166] A device unique wireless access key, KA _U .

[00167] In addition, in certain embodiments, each IoT unit may be securely (over an authenticated and protected connection or through direct configuration) equipped with at least the following security parameter:

[00168] A domain wide identity protection key, MKID.

[00169] In a first embodiment, an application owner, in addition to generating a domain unique master secret, MKD, may also generate a domain wide unique identity protection key, MKID. This key may be either generated independently of MKD and/or may be generated from MKD. The key MKID may be pre-configured into the IoT device(s) prior to deployment.

Additionally or alternatively, if MKID is not generated from MKD, it may be sent by the application owner over a secure channel to the provider together with KD.

[00170] An overview of the identity protection process described in the first embodiment may comprise one or more of the following steps:

[00171] During the first network connection establishment, IDD may be sent in clear from the device to the network provider;

[00172] During the first network connection establishment, ID _U may not be sent in clear but encrypted using the key MKID and a random value, Ni;

[00173] During the first network connection establishment, the provider may use IDD to identify the correct identity protection key, MKID, which is used together with Ni to obtain IDu. IDu is then used to derive the wireless access key, KA _U ;

[00174] The provider may then select a second random nonce, A¾

[00175] The provider may use a random secure selection procedure to assign the IoT device a unique temporary identity, TID _U ; [00176] The provider may calculate (using KA _U , Ni, and Ni) a session access key KASu, as well as a "Join Accept" message, am, including the value TID _U ;

[00177] The provider may communicate the calculated "Join Accept" message am and establish a secure session with the device u using KASu as the access protection key; and

[00178] The device may use TID _U as its identifier for all subsequent access during the same network session.

[00179] In this embodiment, it may be assumed that the initialization and key generation procedure is performed in accordance with the methods and system of key

provisioning discussed above in connection with FIGs. 6-12.

[00180] FIG. 13 A illustrates a device network access process according to the first embodiment, in which message interactions between a device u, a provider server Sp, and a provider manager are shown. The following procedures may be in place prior to the device network access process described in connection with FIG. 13 A:

[00181] The IoT back-end manager system, Mm, and the wireless access provider manager system, Mp, may share the knowledge of a unique IoT domain ID, IDD;

[00182] The IoT back-end manager system, Mm, and the wireless access provider manger system, Mp, may share the knowledge of a unique IoT domain master key, MKD;

[00183] The IoT back-end manager, Μΐοτ, may use a PRF-function to derive a device unique access key for each device in the domain it serves. For example, for device u: KA _U =

[00184] Vii G U _D , MioT may transfer the keys KA _U and the ID values IDD, ID _U to u at manufacture or during an IoT device customization step.

[00185] In addition, the following credential pre-configurations may be performed:

[00186] The IoT back-end manager may equip the access provider manger system, Mp, with a domain wide identity protection key, MKID. In one example, the key may be sent protected together with MKD. In another example, the key may be calculated by Mp from MKD as MKID = PRF(M&>, s), where s is an agreed fixed random string; and

[00187] Vu E U _D , MioT may transfer the key MKID to the unit u at manufacture or during an IoT device customization step.

[00188] Turning to FIG. 13 A, in step 1, device u may use a random source to generate a sufficiently long (e.g., at least 16 bits) random nonce value, Ni. In some embodiments, a string longer than 16 bits may be used. However, in order to remain interoperable with the current LoRa standard, only 16 bits are available. As an alternative, the device ID or domain ID field may be shortened (currently 64 bits long) and the freed bits instead used as an initialization vector for the protection of the device ID.

[00189] In step 2, device u may use a suitable encryption algorithm (such as AES, etc.) to encrypt the device ID, ID _U , by a process E(MKID, ID _U ) using the nonce Ni as an Initialization Vector (IV) for the encryption.

[00190] In step 3, device u may make a network request sending the following parameters to SP: E(MKID, IDU), IDD, NI.

[00191] In step 4, Sp may forward the access request parameters, E(MKID, IDU), NI, to the provider manager, Mp.

[00192] In step 5, Mp may use the domain ID, IDD, to look up the key MKID which is in turn used together with the received nonce, Ni, as the IV to decrypt the device ID: ID _U =

[00193] In step 6, Mp may use ID _U and MDD to derive the device unique access key:

[00194] In step 7, M _P may generate a second random nonce, N2, and using the received nonce, Ni, and the generated nonce, N2, calculate a session access key, KASu, for the device u. For example, in one embodiment, such a key may be calculated as KASu = PRF( _J &4 _M , N1WN2). For clarity, || denotes a concatenation of two values.

[00195] In step 8, Mp may use a random source to generate a wireless access domain device unique random temporary identity: TID _U . In some embodiments, a function may be used to generate TID _U based on a result obtained from a random source.

[00196] In step 9, M _P may calculate a "Join Accept" message am, which includes at least the values N2 and TID _U , and which is integrity and confidentiality protected using the key

[00197] In step 10, M _P may return KASu and am to S _P .

[00198] In step 11, Sp may establish a secure session with device u by sending am.

[00199] In step 12, during the secure session establishment, device u may decrypt am and verify its integrity using KA _U . The decrypted message may include the values TID _U and N2, which are then used by device u to calculate the session access key: KASu = N1WN2). [00200] In step 13, device u may use TID _U as its identifier for all subsequent network access within the same "network session" with Sp.

[00201] The particular messages and methods of calculation of values are meant to describe an example scenario only, and do not limit the scope of the disclosure. For example, alternative methods may be used for encryption and decryption of values; alternative messaging structures beyond "Join Accept" messages may be used to communicate the temporary ID to the IoT device; and/or the like. In some cases, rather than utilizing a session access key, the provider may retrieve the unique key associated with the IoT device (i.e., KA _U ) and use the unique key to secure messages between the provider server and the IoT device, such as illustrated in FIG. 13B.

[00202] In a second embodiment, instead of giving a domain unique master secret MKD to the provider, this secret may be kept in the application domain and at the first network connection, the provider may need to request the access key from the application domain.

[00203] FIG. 14 illustrates an access key derivation procedure in accordance with the second embodiment.

[00204] In step 1, during a first network connection establishment with the provider network server, IDD is sent in the clear by the IoT device, while ID _U is encrypted using an IoT domain wide secret key, MKID, and a random value, Ni, prior to its transmission.

[00205] At step 2, at the first network connection establishment, the encrypted identity and the nonce are forwarded from the provider domain to the IoT domain. The responsible server in the IoT domain then uses the secret key, MKID, and the received nonce, Ni, to decrypt the device ID, ID _U .

[00206] At step 3, the IoT domain server uses ID _U to look-up or calculate the correct device unique key, KAu.T e IoT domain server then selects a second random nonce, N2, and generates a device temporary identity, TID _U .

[00207] At step 4, the IoT domain server calculates (using KA _U , Ni, and Ni) a session access key KASu, as well as a "Join Accept" message, am, including the value TID _U .

[00208] At step 5, the IoT domain server returns KASu and am over a protected channel to the provider.

[00209] In step 6, the provider forwards the received "Join Accept" message am and establishes a secure session with the device u using KASu as the access protection key. [00210] In the example key derivation procedure, credential pre-configurations may not be carried out. In particular, the IoT domain master key MKD may not leave the application domain. Thus, in some instances, the following credential pre-configuration steps may be performed:

[00211] The IoT back-end manager system, Mm, and the wireless access provider manager system, Mp, may share the knowledge of a unique IoT domain ID, IDD; and

[00212] Vu E U _D , MIOT may transfer the keys KA _U and MKID and the ID values IDD and IDu to u at manufacture or during an IoT device customization step.

[00213] FIG. 15A-15B shows an example of a device network connection procedure in accordance with the second embodiment. Specifically, FIG. 15A-15B depict example message interactions between a device u, a provider server Sp, an application server SD, and an IoT back- end manager Μΐοτ.

[00214] In step 1, device u may use a random source to generate a sufficiently long (e.g., at least 16 bits) random nonce value, Ni. In some embodiments, a string longer than 16 bits may be used. However, in order to remain interoperable with the current LoRa standard, only 16 bits are available. As an alternative, the device ID or domain ID field may be shortened

(currently 64 bits long) and the freed bits instead used as an initialization vector for the protection of the device ID.

[00215] In step 2, device u may use a suitable encryption algorithm (such as AES, etc.) to encrypt the device ID, ID _U , by a process E(MKID, IDU) using the nonce Ni as an Initialization Vector (IV) for the encryption.

[00216] In step 3, device u may make a network request sending the following parameters to SP: E(MKID, IDU), IDD, NI.

[00217] In step 4, Sp may forward the access request parameters, E(MKID, IDU), NI, to the application server SD corresponding to the received domain ID, IDD.

[00218] In step 5, SD may forward the access request parameters, E(MKID, IDU), NI, to the IoT back-end manager Mm.

[00219] In step 6, Μΐοτ may use the received random nonce as the IV to decrypt the device ID: ID _U = O(MKID, E(MKID, ID _U )) and identify the corresponding access key, KA _U .

[00220] In step 7, Μΐοτ may generate a random nonce, N2. [00221] In step 8, Μΐοτ may calculate a session access key: KASu = PRF(KA _U , N1WN2). For clarity, || denotes a concatenation of two values.

[00222] In step 9, Μΐοτ may use a random source to generate a wireless access domain device unique random temporary identity: TIDu. In some embodiments, a function may be used to generate TIDu based on a result obtained from a random source.

[00223] In step 10, Μΐοτ may calculate a "Join Accept" message am, which includes at least the values N2 and TIDu, and which is integrity and confidentiality protected using the key

[00224] In step 11, Μΐοτ may return KASu and am to SD.

[00225] In step 12, SD may forward the received message am to Sp.

[00226] In step 13, Sp may establish a secure session with device u by sending am.

[00227] In step 14, during the secure session establishment, device u may decrypt am and verify its integrity using KA _U . The decrypted message may include the values TIDu and N2, which are then used by device u to calculate the session access key: KASu = PRF(X4 _M , N1WN2).

[00228] In step 15, device u may use TIDu as its identifier for all subsequent network access within the same "network session" with Sp.

[00229] In a third embodiment, rather than a fixed value, the domain identifier may be a pseudo random value selected such that neither an external attacker nor a user from another domain may identify if a network attachment is performed from a certain domain in the system. In this embodiment, the following characteristics may be assumed:

[00230] Each domain may be given a unique domain ID protection master key, MKDD. In one example, this key may be given together with the key MKD to the provider as part of a basic domain set-up. Additionally or alternatively, MKDD may be given to the provider using a master key distribution procedure, but the key MKD is kept in the application domain.

[00231] During the first network connection establishment, the device u may use a predefined function, F, with two input parameters - N3 and MKDD, where N3 is a random nonce - to generate a pseudo-random domain ID value, such that TDzr = F(MKDD, N3). This value may be sent, together with the device ID, to the provider domain.

[00232] During the first network connection establishment, when the provider receives the pseudo-random domain ID value IDD; it may use an algorithm to identify the domain ID protection master key MKDD that matches IDD; and may thus identify the connecting unit's real domain ID, IDD. In cases where more than one domain ID protection master key MKDD matches the received IDD; the provider may test which is the correct one by attempting to complete the network registration using the received (and potentially encrypted) device ID and corresponding access key. If this procedure fails, the next matching MKDD may instead be tested, and so forth.

[00233] It should be noted that the managers and servers discussed, rather than or in addition to distinct elements, may be unified (e.g., applications running on the servers, etc.).

[00234] In this embodiment, credential configurations and key generations may be implemented to address domain ID privacy. In some instances, the following credential configuration steps may be performed:

[00235] The IoT back-end manager system, Mm, and the wireless access provider manager system, Mp, share the knowledge of a unique IoT domain ID protection master key,

[00236] The IoT back-end manager system, Mm, and the wireless access provider manager system, Mp, share the knowledge of a unique IoT domain identification "magic word" string, SD. This string is simply a fixed length string used for domain matching purposes; and

[00237] Vu E U _D , MioT transfers the key MKDD and SD to the unit u at manufacture or during an IoT device customization step.

[00238] FIG. 16 shows an example IoT domain ID management procedure performed at an IoT device in accordance with the third embodiment.

[00239] In step 1, device u may generate a random nonce N3 of suitable length. For a LoRa application, a length of 4 bytes may be recommended.

[00240] In step 2, device u may use a function F to generate a pseudo ID: IDD' =

[00241] In step 3, during network establishment, u may use IDD' as the domain identifier.

[00242] The function F may be chosen as follows:

[00243] F(MKDD, NS) = N3\ \E(MKDD, SD), where E is a suitable encryption algorithm taking N3 as an IV for the encryption, and where || denotes a concatenation.

[00244] FIG. 17 shows an example IoT domain ID management procedure performed at the provider side in accordance with the third embodiment:

[00245] In step 1, during network establishment, Sp may receive IDD' from u. [00246] In step 2, Sp may forward IDD' to Mp. In some embodiments, S _P and M _P may be a single entity.

[00247] In step 3, Mp may use the key MKDD, IDD', and a function G to derive a domain ID candidate set: ID = G(MKD, IDD').

[00248] In step 4, if ID = 0, Mp may return an error message to Sp indicating that no domain ID matched the received pseudo domain ID.

[00249] In step 5, if \ID\ = 1, i.e., only one domain master key matched the received pseudo ID, the matching ID, IDD, may be used by Mp for completing the network connection establishment.

[00250] In step 6, if \ID\ > 1, i.e., several domain master keys matched the received pseudo ID, the Mp may attempt to complete the network registration by testing, one by one, the domain IDs in the set ID, i.e., by authenticating the connecting unit u. Depending on the choices for the function F and the function G, it may or may not be possible for more than one valid match to occur (i.e., by some choices of these functions only one valid match is possible).

[00251] The function G may be chosen as follows:

[00252] Let ID = 0 and let Ns' be the most significant bits of IDD', and let IDD" be the least significant bits of IDD' ; and

[00253] V ID _D E IDD , O(MKDD, IDD") = SD (where IDD denotes the complete set of domain ID values and D denotes decryption of IDD" using NV as the IV), add IDD to the set ID.

[00254] One advantage of the systems and methods set forth herein may be that at least some embodiments are fully interoperable with the LoRa LPWAN industry standards, while offering device and/or IoT domain privacy. If a very high degree of privacy is required by the system, the disclosed systems and methods offer both anonymity with respect to which individual IoT unit is attached to the network, as well as to which application domain it belongs. This prevents, for instance, advanced business analysis of an IoT system offering as it prevents IoT WAN tracking. Exemplary systems and methods only use symmetric key operations, which are very lightweight and may be implemented on very resource constrained IoT units.

[00255] Below is set forth an exemplary use case of the systems and methods disclosed herein. Considered is a scenario where a LoRa network provider offers LPWAN to several different application providers in a city. In the example, considered is a public city surveillance system that jointly utilizes the offered network together with a Food Basket Delivery Company. [00256] The public city surveillance provider system utilizes the LPWAN to measure traffic flows including all type of transport such as motor vehicles, bikes and pedestrians through sensors locate all over the city. The sensors communicate with the city surveillance system using the LoRa LPWAN infrastructure.

[00257] The food basket delivery company offers home delivery of food to its city customers through "intelligent food baskets" (manually placed baskets or mobile robot baskets for instance). The intelligent food baskets report back to the food delivery company their status, such as current position, as well as information regarding if the customer has picked-up the ordered food from the basket or not. This allows the food delivery company to keep detailed track of customer delivery status, as well as achieve more efficient logistic management of the baskets, which are assumed be re-used by the food delivery company. The scenario is depicted in FIG. 18.

[00258] The food basket delivery company worries about competing companies being able to gather information regarding the company customers and food deliveries, which might be used by the competitor for customized advertisements of competing offers (this may especially be possible if no domain privacy is applied in the system). The competitor might, for instance, install radio equipment that intercepts LPWAN communication in certain areas in the city, and by identifying communications from the food basket company obtain detailed information on areas where the baskets are located, how many of them are deployed in those areas, etc. Thus, the food basket delivery company may request the identity privacy protections addressed by the systems and methods of the present disclosure. Below is an example of how the systems and methods may be used by a single food basket.

[00259] In step 1, a food basket, B, is delivered to a customer and the customer picks up the food, which is noticed by the food basket, which tries to create a new LPWAN

networking session.

[00260] In step 2, B generates a random number Ni, two bytes long.

[00261] In step 3, B uses the internally stored key, MKID, with Ni as the IV to encrypt its internal device address (8 bytes long): E(MKID, ID _U ).

[00262] In step 4, B generates a random number N3 (4 bytes). [00263] In step 5, B uses the internally stored key, MKDD, with N3 as the IV to encrypt its domain "magic word", SD (4 bytes): E(MKID, SD) and calculates a pseudo domain ID as IDD'

[00264] In step 6, B sends a LoRa "Join-Request" message [1] to the network provider server: [AppEUI, DevEUI, DevNonce] where AppEUI = IDD', DevEUI = E(MKID, ID _U ) and DevNonce = Ni.

[00265] In step 7, the network provider server receives the "Join Request" message previously sent by B.

[00266] In step 8, the network provider server forwards the Join Request message to the provider network back-end manager system, Μΐοτ.

[00267] In step 9, Μΐοτ takes the four most significant bits of AppEUI, AppEUI M and tries to decrypt using the four least significant bits of AppEU, AppEUI L, as the IV. It tries all internal domain keys it possesses, one by one. After checking a number of different keys, it determines that only for the key MKDD does O(MKDD, AppEUI L) = SD.

[00268] In step 10, Μΐοτ looks up the key MKID, and uses the received Ni as the IV to obtain identity ID _U of the connecting device as ID _U = O(MKID, DevEUI).

[00269] In step λ λ, Μΐοτ uses ID _U to calculate the device access key (LoRa Appkey), KAU = PRF(MKD DU).

[00270] In step 12, Mp uses a random source to generate a wireless access domain device unique random temporary identity: TID _U .

[00271] In step 13, Mp returns TIDu together with KA _U to Sp.

[00272] In step 14, Sp uses KA _U to calculate a LoRa session key, NwSKey, and to calculate a LoRa "Join Accept" message, am, which contains among other parameters TIDu (in encrypted form). During session establishment, TIDu is sent to B.

[00273] In step 15, B uses TIDu as its identifier when obtaining network access in order to send the status information "basket empty" to the food provider back-end system. As TIDu is sent in the clear via the over-the-air interface, it can be observed by an external observer.

However, as this value only is temporary and chosen at random, it will not provide the external observer any information about which entity actually connects to the network.

[00274] The systems and methods disclosed herein offer a good level of identity protection with very low overhead and with LoRa interoperability. Alternative techniques may operate to encrypt the identity values during network establishment with a suitable public key or public keys. Such an approach may make use of public key operation capabilities at the device side. However, even if that would be feasible to implement on many IoT devices, even if elliptic curve cryptography is used, such approaches would imply an at least five-times increase of the join message size during network establishment, creating a non-negligible bandwidth increase of the whole system. Furthermore, such approaches would not be interoperable with the current LoRa specification.

[00275] In one embodiment, a method of preventing an external attacker from discovering a device ID of an Internet of Things (IoT) device during network-access request and grant in a low power wide area network (LPWAN) may comprise: receiving, at a domain server, from a network server an encrypted device ID and a domain ID associated with a network-access request sent by a first IoT device to the network server; retrieving, based on the domain ID, a preconfigured domain key; decrypting, based on the domain key, the device ID; generating a session device key equivalent to a device key preconfigured in the device, based on the domain key and the device ID; generating a pseudo-random temporary ID for the first IoT device; and transmitting to the network server the temporary ID and the generated session device key.

[00276] In another embodiment, a method of preventing an external attacker from discovering a device ID of an IoT device during network-access request and grant in LPWAN may comprise: receiving, at a network server, from a first IoT device an encrypted device ID and a domain ID associated with a network-access request; transmitting from the network server to a domain server the encrypted device ID and domain ID; receiving, from the domain server, a temporary ID and a session device key, each associated with the first IoT device; and associating and addressing the network-access grant, and future messages from the network server to the first IoT device, with the temporary ID.

[00277] In another embodiment, a method may comprise: receiving, at a provider access server, an access request from a first Internet of Things (IoT) device, the access request comprising an encrypted device ID, a domain ID associated with the first IoT device, and a first nonce value; retrieving a preconfigured domain key based on the received domain ID; decrypting the received encrypted device ID using the retrieved domain key and received first nonce value; deriving a device unique access key associated with the first IoT device, based at least in part on the decrypted device ID and a domain wide master key associated with the first IoT device; generating a pseudorandom temporary ID for the first IoT device; and establishing a secure session from the provider access server to the first IoT device, wherein the temporary ID for the first IoT device is communicated from the provider access server to the first IoT device during session establishment.

[00278] In another embodiment, a method may comprise: receiving, at an IoT application access server, a forwarded access request from a first Internet of Things (IoT) device, the access request comprising an encrypted device ID, a domain ID associated with the first IoT device, and a first nonce value; decrypting the received encrypted device ID using the retrieved domain key and received first nonce value; identifying a device unique access key associated with the first IoT device, based at least in part on the decrypted device ID and a domain wide master key associated with the first IoT device; calculating a session access key; generating a pseudorandom temporary ID for the first IoT device; generating a Joint Accept message, wherein the Join Accept message comprises at least the second nonce value and the temporary ID; and communicating the Join Accept message from the IoT application access server to the first IoT device.

[00279] In another embodiment, a method may comprise: communicating, from an IoT device, a network request, wherein the network request comprises an encrypted device ID, a domain ID, and a first nonce value; receiving a Join Accept message at the IoT device, wherein the Join Accept message comprises, in an encrypted form, a second nonce value and a temporary ID assigned to the IoT device; decrypting the Join Accept message and verifying its integrity using an access key associated with the IoT device; calculating, at the IoT device, a session access key based on the device's access key, the first nonce value, and the second nonce value; and using the temporary ID as an identifier for the IoT device in a subsequent network access request, wherein the subsequent network access request is secured using the session access key.

[00280] In another embodiment, a method may comprise: generating, at an IoT device, a random nonce; generating, at the IoT device based on the random nonce and a domain ID protection master key, a pseudo domain ID; and communicating, from the IoT device, a network request, wherein the network request comprises the pseudo domain ID.

[00281] In another embodiment, a method may comprise: receiving, at a provider server during a network establishment, a network request from a first IoT device, the network request comprising a pseudo domain ID; determining, based on the received pseudo domain ID and a domain ID protection master key, a domain ID candidate set; and responsive to a determination that the domain ID candidate set is a null set, communicating an error message to the first IoT device; or responsive to a determination that the domain ID candidate set comprises at least one candidate domain ID, completing the network establishment using a matching domain ID of the domain ID candidate set.

[00282] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity. FIG. 19 is a system diagram of an exemplary WTRU 102, which may be employed as an IoT device or server in embodiments described herein. As shown in FIG. 19, the WTRU 102 may include a processor 118, a communication interface 119 including a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a

display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and sensors 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[00283] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 19 depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[00284] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[00285] In addition, although the transmit/receive element 122 is depicted in FIG. 19 as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[00286] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[00287] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[00288] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. As examples, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), and the like), solar cells, fuel cells, and the like. [00289] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[00290] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[00291] FIG. 20 depicts an exemplary network entity 190 that may be used in embodiments of the present disclosure. As depicted in FIG. 20, network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.

[00292] Communication interface 192 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 192 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 192 may include components such as one or more antennae, one or more

transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 192 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 192 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.

[00293] Processor 194 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.

[00294] Data storage 196 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non-transitory data storage deemed suitable by those of skill in the relevant art could be used. As depicted in FIG. 20, data storage 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.

[00295] It is understood that the processes and instrumentalities described herein may apply in any combination and may apply to other networks and wireless technologies. Although features and elements (including procedural steps) described herein in various examples may be shown or described in particular combinations and/or orders, each feature and element may be used alone or in any combination and in any order with and without other features and elements. Although examples provided herein may pertain to New Radio (NR) or 5G-specific protocols, subject matter described herein is not limited to provided examples or referenced communication technologies. Subject matter herein is applicable to a wider variety of examples and

implementations, including in other wireless systems.

[00296] The processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as CD-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.

[00297] The various features and processes described herein may be used

independently of one another, or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. In addition, certain methods or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto may be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically described, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the described example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the described example embodiments.

[00298] While the methods and systems have been described in connection with preferred embodiments and specific examples, it is not intended that the scope be limited to the particular embodiments set forth, as the embodiments herein are intended in all respects to be illustrative rather than restrictive.

[00299] Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its operations be performed in a specific order.

Accordingly, where a method claim does not actually recite an order to be followed by its operations or it is not otherwise specifically stated in the claims or descriptions that the operations are to be limited to a specific order, it is no way intended that an order be inferred, in any respect. This holds for any possible non-express basis for interpretation, including: matters of logic with respect to arrangement of steps or operational flow; plain meaning derived from grammatical organization or punctuation; and the number or type of embodiments described in the specification.

[00300] It will be apparent to those skilled in the art that various modifications and variations may be made without departing from the scope or spirit of the present disclosure. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practices described herein. It is intended that the specification and example figures be considered as exemplary only, with a true scope and spirit being indicated by the following claims.