Privacy preserving message blinding
阅读说明：本技术 隐私保护消息盲化 (Privacy preserving message blinding ) 是由 约瑟夫·阿方索·克纳普 托马斯·艾里奇 迈克尔·彼得·库珀-哈蒙德 亚历山大·米尔西亚·加拉加 于 2017-10-11 设计创作，主要内容包括：一种用于发送消息帧的方法,包括：通过包括处理器的终端设备生成包括第一明文头的第一消息帧部分；获得设备标识DevEUI和头盲化密钥HdrBKey；使用DevEUI和HdrBKey生成第一头掩码；通过将第一头掩码应用到第一明文头获得第一盲化头；通过使用第一盲化头更新第一消息部分获得第一更新消息帧部分；生成包括第一更新消息帧部分的第一盲化消息帧；以及将第一盲化消息帧发送到网络网关。(A method for transmitting a message frame, comprising: generating, by a terminal device comprising a processor, a first message frame portion comprising a first plaintext header; acquiring a device identifier DevEUI and a head blinding key HdrBKey; generating a first bitmask using DevEUI and HdrBKey; obtaining a first blinded header by applying a first header mask to the first plaintext header; obtaining a first update message frame portion by updating the first message portion using the first blinding header; generating a first blinded message frame comprising a first update message frame portion; and sending the first blinded message frame to a network gateway.)
1. A method for transmitting a message frame, comprising:
generating, by a terminal device comprising a processor, a first message frame portion comprising a first clear header;
obtaining a device identifier (DevEUI) and a header blinding key (HdrBKey);
generating a first bitmask using the DevEUI and the HdrBKey;
obtaining a first blinded head by applying the first head mask to the first clear header;
obtaining a first updated message frame portion by updating the first message portion using the first blinding header;
generating a first blinded message frame comprising the first update message frame portion; and
and sending the first blinded message frame to a network gateway.
2. The method of claim 1, wherein each of the DevEUI and the HdrBKey is specific to the terminal device.
3. The method of claim 1, wherein generating the first bitmask includes performing a cryptographic operation on the DevEUI using the HdrBKey.
4. The method of claim 3, wherein the cryptographic operation requires a symmetric cipher.
5. The method of claim 1, wherein obtaining a first blinding head comprises: performing a bitwise exclusive-OR (XOR) operation between the first header mask and the first plaintext header.
6. The method of claim 1, wherein obtaining the first update message frame portion comprises: replacing the first plaintext header of the first message frame portion with the first blinded header.
7. The method of claim 1, further comprising:
prior to generating the first message frame portion:
receiving, by the terminal device, the DevEUI during a manufacturing process of the terminal device.
8. The method of claim 7, further comprising:
receiving, by the terminal device, the HdrBKey during a manufacturing process of the terminal device.
9. The method of claim 7, further comprising:
generating, by the terminal device, a join request message including the DevEUI;
sending the join request message to a network host;
receiving an encrypted join accept message including a network identifier (NetID) from the network host;
extracting the NetID by decrypting the encrypted join accept message; and
the HdrBKey is derived using at least an application key (AppKey) and the NetID.
10. The method of claim 9, wherein decrypting the encrypted join accept message comprises performing a cryptographic operation using the AppKey, wherein the cryptographic operation requires a symmetric cipher.
11. The method of claim 9, wherein deriving the HdrBKey comprises performing a cryptographic operation on at least the NetID using the AppKey, wherein the cryptographic operation requires a symmetric cipher.
12. The method of claim 1, further comprising:
generating, by the terminal device, a second message frame portion including a second plaintext header;
generating a second header mask using the first header mask and the HdrBKey;
obtaining a second blinded header by applying the second header mask to the second plaintext header;
obtaining a second updated message frame portion by updating the second message frame portion using the second blinding header;
generating a second blinded message frame comprising the second update message frame portion; and
and sending the second blinded message frame to a network gateway.
13. The method of claim 12, wherein generating the second header mask comprises performing a cryptographic operation on the first header mask using the HdrBKey.
14. The method of claim 13, wherein the cryptographic operation requires a symmetric cipher.
15. The method of claim 12, wherein obtaining the second blinded header comprises performing a bitwise exclusive-or (XOR) operation between the second header mask and the second plaintext header.
16. The method of claim 12, wherein obtaining a second update message frame comprises replacing the second plaintext header for the second message frame portion with the second blinded header.
17. The method of claim 1, further comprising:
receiving, by the terminal device, a second blinding message frame including a second blinding header from the network gateway;
generating a second header mask using the first header mask and the HdrBKey;
obtaining a second plaintext header by applying the second header mask to the second blinded header; and
obtaining a second message frame by updating the second blinded message frame using the second plaintext header.
18. The method of claim 17, wherein generating a second header mask comprises performing a cryptographic operation on the first header mask using the HdrBKey, wherein the cryptographic operation requires a symmetric cipher.
19. The method according to claim 17, wherein obtaining the second plaintext header comprises performing a bitwise exclusive-or (XOR) operation between the second header mask and the second blinded header.
20. The method of claim 17, wherein obtaining a second message frame comprises replacing the second blinding header of the second blinding message frame with the second plaintext header.
21. The method of claim 17, further comprising:
extracting, by the terminal device, a ciphered frame payload and a first Message Integrity Code (MIC) from the second message frame;
generating a second MIC using the second plaintext header, the encrypted frame payload, and a network session key (NwkSKey);
authenticating the second message frame using the first MIC and the second MIC;
based on the authentication, obtaining a frame payload by decrypting the encrypted frame payload using at least an application session key (AppSKey); and
executing a set of instructions to reconfigure the terminal device, wherein the frame payload includes the set of instructions.
22. The method of claim 21, wherein generating the second MIC comprises: performing a cryptographic operation on the second plaintext header and the encrypted frame payload using the NwkSKey, wherein the cryptographic operation requires a symmetric cipher.
23. The method of claim 21, wherein authenticating the second message frame comprises: determining that the first MIC matches the second MIC.
24. The method of claim 21, wherein reconfiguring the terminal device comprises: and adjusting at least one terminal equipment configuration parameter through the terminal equipment.
25. The method of claim 1, further comprising:
monitoring, by the terminal device, a set of terminal device operating parameters;
checking the terminal equipment operation parameter set by contrasting a set standard;
based on the checking, determining that the set of terminal device operating parameters meets the set criteria; and
based on the determination, adjusting a terminal device configuration parameter set.
26. The method of claim 25, wherein the set of terminal device operating parameters comprises physical characteristics measured by sensors on the terminal device.
27. The method of claim 26, wherein the set of terminal device operating parameters further comprises a metric derived from at least the physical characteristic.
28. The method of claim 25, wherein the setting criteria comprises a static condition preset during a manufacturing process of the terminal device.
29. The method of claim 28, wherein the set of criteria further comprises a dynamic condition.
30. A method for transmitting a message frame, comprising:
obtaining, by a network host, a device identifier (DevEUI), a header blinding key (HdrBKey), and a device address (DevAddr) for each terminal device in a device group;
generating a first head mask by using the DevEUI and the HdrBKey for each terminal device of the device group, obtaining a first head mask set;
generating a first candidate clear header (CPH) including the DevAddr for each terminal device of the device group;
obtaining a first set of Candidate Blinded Heads (CBHs) by applying the first head mask to the first CPH for each terminal device of the device group;
obtaining a first message frame including a first blinded header from a network gateway;
comparing the first blinding head to each of the first CBH's in the first set of CBH's;
based on the comparison, identifying a first fixed bit-matching CBH of the first set of CBHs that includes a first set of fixed bits that matches a second set of fixed bits included in the first blinding head;
obtaining a first plaintext header by applying one first header mask of the first set of header masks to the first blinded header, wherein the one first header mask corresponds to the first fixed-bit-matching CBH;
obtaining a first un-blinded message frame by updating the first message frame using the first plaintext header; and
sending the first un-blinded message frame to an application system.
31. The method of claim 30, wherein the device group comprises a set of end devices managed by the network host.
32. The method of claim 30, wherein generating the first bitmask for each end device of the group of devices comprises: performing a cryptographic operation on the DevEUI using the HdrBKey.
33. The method of claim 32, wherein the cryptographic operation requires a symmetric cipher.
34. The method of claim 30, wherein obtaining the first set of CBHs by applying the first head mask to the first CPH for each end device of the device group comprises: performing a bitwise exclusive-OR (XOR) operation between the first bitmask and the first CPH.
35. The method of claim 30, wherein obtaining the first message frame comprises:
receiving, by the network host, a Media Access Control (MAC) frame encapsulating the first message frame from the network gateway; and
and extracting the first message frame by de-encapsulating the MAC frame.
36. The method of claim 30, wherein each of the first and second sets of fixed bits comprises a subset of fixed bits representing the DevAddr.
37. The method of claim 30, wherein obtaining the first plaintext header by applying the one first header mask to the first blinded header comprises: performing a bitwise exclusive-OR (XOR) operation between the one first header mask and the first blinding header.
38. The method of claim 30, wherein obtaining the first unblinded message frame by updating the first message frame using the first plaintext header comprises: replacing the first blinded header of the first message frame with the first clear header.
39. The method of claim 30, further comprising:
generating, by the network host, a second header mask by using the first header mask and the HdrBKey for each terminal device of the device group, to obtain a second header mask set;
generating a second CPH including the DevAddr for each terminal device of the device group;
obtaining a second CBH set by applying the second head mask to the second CPH for each terminal device of a device group;
obtaining a second message frame comprising a second blinded header from the network gateway;
comparing the second blinding head to each second CBH of the second set of CBHs;
based on the comparison, identifying a second fixed bit-matched CBH of the second set of CBHs that includes a third set of fixed bits that matches a fourth set of fixed bits included in the second blinding head;
obtaining a second plaintext header by applying one second header mask of the second set of header masks to the second blinded header, wherein the one second header mask corresponds to the second fixed-bit-matching CBH;
obtaining a second un-blinded message frame by updating the second message frame using the second plaintext header; and
sending the second un-blinded message frame to the application system.
40. The method of claim 39, wherein generating the second head mask for each end device of the device group comprises: performing a cryptographic operation on the first bitmask using the HdrBKey.
41. The method of claim 40, wherein the cryptographic operation requires a symmetric cipher.
42. The method of claim 39, wherein obtaining the second set of CBHs by applying the second head mask to the second CPH for each end device of the device group comprises: performing a bitwise exclusive-OR (XOR) operation between the second head mask and the second CPH.
43. The method of claim 39 wherein each of the third and fourth sets of fixed bits comprises a subset of fixed bits representing the DevAddr.
44. The method according to claim 39, wherein obtaining the second plaintext header by applying the one second header mask to the second blinded header comprises: performing a bitwise exclusive-OR (XOR) operation between the one second header mask and the second blinding header.
45. The method according to claim 39, wherein obtaining the second unblinded message frame by updating the second message frame using the second clear header comprises: replacing the second blinded header of the second message frame with the second plaintext header.
46. The method of claim 30, further comprising:
monitoring, by the network host, a set of network operating parameters;
checking the set of network operating parameters against a set criterion;
based on the checking, determining that the set of network operating parameters meets the set criteria; and
based on the determination, a set of network configuration parameters is adjusted.
47. The method of claim 46, wherein the set of network operating parameters includes at least one network performance metric.
48. The method of claim 46, further comprising:
generating a configuration update message through the network host, wherein the configuration update message comprises at least one terminal device configuration parameter and at least one corresponding set value; and
sending the configuration update message to a terminal device via the network gateway.
49. The method of claim 48, wherein the configuration update message reconfigures the terminal device, wherein reconfiguring the terminal device is associated with adjustment of the set of network configuration parameters.
50. A terminal device, comprising:
a communication interface; and
a processor operatively connected to the communication interface, on which a blinding filter is executed, wherein the processor is configured to:
generating a first message frame portion comprising a first plaintext header;
obtaining a device identifier (DevEUI) and a header blinding key (HdrBKey);
generating a first bitmask using the DevEUI and the HdrBKey using the blinding filter;
obtaining a first blinded head by applying the first head mask to the first clear text head using the blinding filter;
obtaining a first updated message frame portion by updating the first message portion using the first blinding header;
generating a first blinded message frame comprising the first update message frame portion; and
sending the first blinded message frame to a network gateway using the communication interface.
51. A network host, comprising:
a communication interface; and
a processor operatively connected to the communication interface, on which a blinding filter is executed, wherein the processor is configured to:
obtaining a device identifier (DevEUI), a header blinding key (HdrBKey) and a device address (DevAddr) for each terminal device of the device group;
using the blinding filter, obtaining a first set of bitmasks by generating a first bitmask using the DevEUI and the HdrBKey for each terminal device of the device group;
generating a first candidate clear header (CPH) including the DevAddr for each terminal device of the device group;
obtaining a first set of Candidate Blinded Heads (CBHs) by applying the first head mask to the first CPH for each terminal device of the device group using the blinding filter;
obtaining, using the communication interface, a first message frame comprising a first blinding header from a network gateway operatively connected to the network host;
comparing the first blinding head to each of the first CBH's in the first set of CBH's;
based on the comparison, identifying a first fixed bit-matching CBH of the first set of CBHs that includes a first set of fixed bits that matches a second set of fixed bits included in the first blinding head;
obtaining a first plaintext header by applying one first header mask of the first set of header masks to the first blinded header, wherein the one first header mask corresponds to the first fixed-bit-matching CBH;
obtaining a first un-blinded message frame by updating the first message frame using the first plaintext header; and
sending the first unblinded message frame to an application system using the communication interface.
52. A system, comprising:
a network gateway; and
a terminal device comprising a first communication interface and a first processor on which a first blinding filter is executed, wherein the terminal device is operatively connected to the network gateway, wherein the first processor is configured to:
generating a first message frame portion comprising a first plaintext header;
obtaining a device identifier (DevEUI) and a header blinding key (HdrBKey);
generating a first bitmask using the DevEUI and the HdrBKey using the first blinding filter;
obtaining a first blinded head by applying the first head mask to the first clear text head using a first blinding filter;
obtaining a first updated message frame portion by updating the first message portion using the first blinding header;
generating a first blinded message frame comprising the first update message frame portion; and
sending the first blinded message frame to the network gateway using the first communication interface.
53. The system of claim 52, further comprising:
an application system; and
a network host comprising a second communication interface and a second processor on which a second blinding filter is executed, wherein the network host is operatively connected to the network gateway and the application system, wherein the second processor is configured to:
obtaining the DevEUI, the HdrBKey and a device address (DevAddr) aiming at each terminal device of a device group;
using the second blinding filter, obtaining a second set of head masks by generating a second head mask for each terminal device of the device group using the DevEUI and the HdrBKey;
generating a first candidate clear header (CPH) including the DevAddr for each terminal device of the device group;
obtaining a first set of Candidate Blinded Headers (CBHs) by applying the second header mask to the first CPH for each end device of the device group using the second blinding filter;
obtaining a message frame including a second blinding header from the network gateway using the second communication interface;
comparing the second blinding head to each of the first CBHs in the first set of CBHs;
based on the comparison, identifying a first fixed bit-matching CBH of the first set of CBHs that includes a first set of fixed bits that matches a second set of fixed bits included in the second blinding header;
obtaining a second plaintext header by applying one second header mask of the second set of header masks to the second blinded header, wherein the one second header mask corresponds to the first fixed-bit-matching CBH;
obtaining an unblinded message frame by updating the message frame using the second plaintext header; and
sending the un-blinded message frame to the application system using the second communication interface.
54. A non-transitory Computer Readable Medium (CRM) comprising computer readable program code which, when executed by a processor, enables the processor to:
generating a first message frame portion comprising a first plaintext header;
obtaining a device identifier (DevEUI) and a header blinding key (HdrBKey);
generating a first bitmask using the DevEUI and the HdrBKey;
obtaining a first blinded head by applying the first head mask to the first clear header;
obtaining a first updated message frame portion by updating the first message portion using the first blinding header;
generating a first blinded message frame comprising the first update message frame portion; and
and sending the first blinded message frame to a network gateway.
55. A non-transitory Computer Readable Medium (CRM) comprising computer readable program code which, when executed by a processor, enables the processor to:
obtaining a device identifier (DevEUI), a header blinding key (HdrBKey) and a device address (DevAddr) for each terminal device of the device group;
generating a first head mask by using the DevEUI and the HdrBKey for each terminal device of the device group, obtaining a first head mask set;
generating a first candidate clear header (CPH) including the DevAddr for each terminal device of the device group;
obtaining a first set of Candidate Blinded Heads (CBHs) by applying the first head mask to the first CPH for each terminal device of the device group;
obtaining a first message frame including a first blinded header from a network gateway;
comparing the first blinding head to each of the first CBH's in the first set of CBH's;
based on the comparison, identifying a first fixed bit-matching CBH of the first set of CBHs that includes a first set of fixed bits that matches a second set of fixed bits included in the second blinding header;
obtaining a first plaintext header by applying one first header mask of the first set of header masks to the first blinded header, wherein the one first header mask corresponds to the first fixed-bit-matching CBH;
obtaining a first un-blinded message frame by updating the first message frame using the first plaintext header; and
sending the first un-blinded message frame to an application system.
Background
The present invention is directed to addressing privacy vulnerabilities in existing radio architectures such as Low Power Wide Area Networks (LPWANs). Accordingly, embodiments of the present invention provide an apparatus and method for encrypting and decrypting a transmitted message based on the LoRaWAN protocol specification.
Disclosure of Invention
A method for transmitting a message frame includes generating, by a terminal device including a processor, a first message frame portion including a first clear header. The method obtains a device identifier (DevEUI) and a header blinding key (HdrBKey). The method generates a first bitmask using the DevEUI and the HdrBKey, and obtains a first blinded header by applying the first bitmask to the first plaintext header. The method obtains a first update message frame portion by updating a first message portion using a first blinding header, generates a first blinding message frame including the first update message frame portion, and sends the first blinding message frame to a network gateway.
A method for transmitting a message frame, comprising: a device identifier (DevEUI), a header blinding key (HdrBKey), and a device address (DevAddr) are obtained by a network host for each terminal device in a device group (device placement). The method generates a first head mask by using DevEUI and HdrBKey aiming at each terminal device of a device group to obtain a first head mask set; and generating a first candidate clear header (CPH) including the DevAddr for each terminal device of the device group. The method obtains a first set of Candidate Blinding Headers (CBHs) by applying a first header mask to a first CPH for each terminal device of the device group, and obtains a first message frame including the first blinding header from the network gateway. The method compares a first blinding header to each of a first CBH set of CBHs and matches a CBH based on comparing a first fixed bit set of the first CBH set that includes a first fixed bit set that matches a second fixed bit set included in the first blinding header. The method obtains a first plaintext header by applying one first head mask of a first set of head masks to a first blinded header, wherein the one first head mask corresponds to a first fixed-bit-matching CBH. The method obtains a first non-blinded message frame by updating the first message frame with a first clear header and sends the first non-blinded message frame to an application system.
A terminal device, comprising: a communication interface and a processor operatively connected to the communication interface and executing a blinding filter thereon, wherein the processor is configured to generate a first message frame portion comprising a first clear header. The processor is configured to obtain a device identifier (DevEUI) and a header blinding key (HdrBKey). The processor is configured to generate a first bitmask using the DevEUI and the HdrBKey by using a blinding filter. The processor is configured to generate a first blinded message frame comprising a first update message frame portion by using a blinding filter to obtain a first blinding header by applying a first header mask to a first plaintext header and by updating the first message portion using the first blinding header to obtain a first update message frame portion. The processor is configured to transmit the first blinded message frame to a network gateway using the communication interface.
A network host includes a communication interface. It also includes a processor operatively connected to the communication interface and executing the blinding filter thereon, wherein the processor is configured to obtain, for each end device of the device group, a device identifier (DevEUI) and a header blinding key (HdrBKey) and a device address (DevAddr). The processor is configured to obtain a first set of bitmasks by generating a first bitmask using DevEUI and HdrBKey for each end device of the device group using a blinding filter. The processor is configured to generate a first candidate clear header (CPH) comprising the DevAddr for each end device in the device group. The processor is configured to obtain a first set of Candidate Blinded Heads (CBHs) by applying a first head mask to the first CPH for each end device of the device group using a blinding filter. The processor is configured to obtain, using the communication interface, a first message frame including a first blinding header from a network gateway operatively connected to the network host. The processor is configured to compare the first blinding header to each of the first CBHs in the first set of CBHs, and identify a first fixed-bit-matching CBH in the first set of CBHs that includes a first set of fixed bits that matches a second set of fixed bits included in the first blinding header based on the comparison. The processor is configured to obtain a first plaintext header by applying one first header mask of a first set of header masks to a first blinded header, wherein the one first header mask corresponds to a first fixed-bit-matching CBH. The processor is configured to obtain a first non-blinded message frame by updating the first message frame using the first clear header, and to send the first non-blinded message frame to the application system using the communication interface.
A system includes a network gateway and a terminal device. The terminal device comprises a first communication interface and a first processor on which a first blinding filter is executed, wherein the terminal device is operatively connected to a network gateway, wherein the first processor is configured to generate a first message frame portion comprising a first clear header. The first processor also obtains a device identifier (DevEUI) and a header blinding key (HdrBKey), and generates a first header mask using the DevEUI and HdrBKey by using a first blinding filter. The first processor also obtains a first blinded header by applying the first header mask to the first plaintext header using the first blinding filter, and obtains a first updated message frame portion by updating the first message portion using the first blinding header. The first processor generates a first blinded message frame including a first update message frame portion and transmits the first blinded message frame to the network gateway by using the first communication interface.
A non-transitory Computer Readable Medium (CRM) comprising computer readable program code which, when executed by a processor, enables the processor to generate a first message frame portion comprising a first clear header and obtain a device identifier (DevEUI) and a header blinding key (HdrBKey). The processor also generates a first bitmask using the DevEUI and the HdrBKey, and obtains a first blinded header by applying the first bitmask to the first plaintext header. The processor also obtains a first update message frame portion by updating the first message portion using the first blinding header, generates a first blinding message frame including the first update message frame portion, and sends the first blinding message frame to the network gateway.
A non-transitory Computer Readable Medium (CRM) comprising computer readable program code which, when executed by a processor, enables the processor to: a device identifier (DevEUI), a header blinding key (HdrBKey) and a device address (DevAddr) are obtained for each terminal device of the device group. The processor obtains a first set of bitmasks by generating a first bitmask using DevEUI and HdrBKey for each end device of the device group, and generates a first candidate clear header (CPH) including DevAddr for each end device of the device group. The processor is configured to obtain a first set of Candidate Blinding Headers (CBHs) by applying a first header mask to the first CPH for each end device of the device group, and obtain a first message frame including the first blinding header from the network gateway. The processor is configured to compare the first blinding header to each of the first CBHs in the first set of CBHs, and identify a first fixed-bit-matching CBH in the first set of CBHs that includes a first set of fixed bits that matches a second set of fixed bits included in the second blinding header based on the comparison. The processor is configured to obtain a first plaintext header by applying one first header mask of a first set of header masks to a first blinded header, wherein the one first header mask corresponds to a first fixed-bit-matching CBH. The processor is configured to obtain a first non-blinded message frame by updating the first message frame with a first clear header, and to send the first non-blinded message frame to the application system.
Drawings
Fig. 1A illustrates a system in accordance with one or more embodiments disclosed herein.
Fig. 1B illustrates a system in accordance with one or more embodiments disclosed herein.
Fig. 2A illustrates a terminal device in accordance with one or more embodiments disclosed herein.
Fig. 2B illustrates a network gateway in accordance with one or more embodiments disclosed herein.
Fig. 2C illustrates a network host in accordance with one or more embodiments disclosed herein.
Fig. 3 illustrates a LoRaWAN message frame in accordance with one or more embodiments disclosed herein.
Fig. 4A shows a diagram illustrating a LoRaWAN security procedure in accordance with one or more embodiments disclosed herein.
Fig. 4B shows a diagram illustrating an enhanced LoRaWAN security process in accordance with one or more embodiments disclosed herein.
Fig. 5A and 5B show a flow chart describing a method for activating a terminal device according to one or more embodiments disclosed herein.
Fig. 6A and 6B show a flow chart describing a method for blinding a plaintext header in accordance with one or more embodiments disclosed herein.
Fig. 7A and 7B show a flow chart describing a method for blinding a blinding head in accordance with one or more embodiments disclosed herein.
Fig. 8 shows a flowchart depicting a method for optimizing terminal device operation according to one or more embodiments disclosed herein.
Fig. 9 shows a flow diagram depicting a method for optimizing network operation in accordance with one or more embodiments disclosed herein.
Fig. 10A and 10B each illustrate a computing system in accordance with one or more embodiments disclosed herein.
Fig. 11 illustrates a high-level view of a general network architecture with one or more embodiments disclosed herein.
Fig. 12 illustrates some components of a message having one or more embodiments disclosed herein.
Fig. 13 illustrates a message blinding process utilizing one or more embodiments disclosed herein.
Detailed Description
Specific embodiments disclosed herein will now be described in detail with reference to the accompanying drawings. In the following detailed description of the embodiments disclosed herein, numerous specific details are set forth in order to provide a more thorough understanding of the embodiments disclosed herein. However, it will be apparent to one of ordinary skill in the art that the embodiments disclosed herein may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.
In the following description of fig. 1A-10B, in various embodiments disclosed herein, any component described with respect to a figure may be equivalent to one or more similarly-named components described with respect to any other figure. For the sake of brevity, the description of these components will not be repeated for each figure. Thus, each embodiment of a component of each figure is incorporated by reference and assumed to be optionally present in each other figure having one or more similarly named components. Additionally, in accordance with various embodiments disclosed herein, any description of components of a figure will be construed as an alternative embodiment, which may be implemented in addition to, in combination with, or instead of the embodiments described with respect to the corresponding named components in any other figure.
Throughout this application, ordinal numbers (e.g., first, second, third, etc.) may be used as adjectives for elements (i.e., any noun in the application). The use of ordinal numbers does not necessarily imply or generate any particular order of elements nor does it necessarily limit any elements to only a single element unless explicitly disclosed, for example, by the use of the terms "before", "after", "single", and other such terms. Rather, ordinal numbers are used to distinguish between elements. As an example, the first element is different from the second element, and the first element may include more than one element and be subsequent (or prior) to the second element in the ordering of the elements.
Embodiments disclosed herein relate generally to privacy protection. In particular, one or more embodiments of the present disclosure require blinding of header information associated with radio transmissions, which is typically susceptible to eavesdropping and/or interception. More specifically, the blinding (or encryption) and the final blinding (or decryption) of the header information are performed using a device-specific header blinding key (HdrBKey) that is known only to the terminal device and the network host that manages the terminal device. In one or more other embodiments disclosed herein, the end device (i.e., the network-enabled physical object) may include the ability to monitor and adjust its own parameters to optimize the end device operation. Similarly, the network host may include the ability to monitor and adjust network-wide parameters to optimize network operation.
In one or more embodiments disclosed herein, protecting privacy through message blinding utilizes, at least in part, the LoRaWAN protocol. A version of the LoRaWAN protocol is defined in a document entitled version 1.0.2 of the loran alliance LoRaWAN specification dated 7 months 2016. The LoRaWAN protocol is incorporated herein by reference in its entirety. Furthermore, embodiments disclosed herein are not limited to a particular version of the LoRaWAN protocol. Based on the exemplary embodiments discussed herein, it will be apparent to those of ordinary skill in the art that the use of message blinding is not necessarily limited to the LoRaWAN protocol, and that other protocols may also benefit from combinations of the concepts, methods, systems, and devices discussed herein.
In one or more embodiments disclosed herein, privacy protection through message blinding utilizes, at least in part, the Institute of Electrical and Electronics Engineers (IEEE)802.15.4 standard, which defines the operation of low-rate wireless personal area networks (LR-WPANs). One of the IEEE802.15.4 standardsVersion is entitled "IEEE standard for local and metropolitan area networks" part 15.4 at 9 months 2011: low Rate Wireless personal area network (LR-WPAN) "version IEEE Std802.15.4-2011Is defined in the document of (1). The IEEE802.15.4 standard is hereby incorporated by reference in its entirety. Furthermore, embodiments disclosed herein are not limited to a particular version of the IEEE802.15.4 standard.
Fig. 1A illustrates a system in accordance with one or more embodiments disclosed herein. The system (100A) includes a terminal device (102), a network gateway (104A), a network host (106), and an application system (108). Each of these components is described below.
In one or more embodiments disclosed herein, the end device (102) may be any network-enabled physical object (including software and/or firmware) that includes at least one sensor. In one or more embodiments disclosed herein, the term "network-enabled" may refer to a device that includes functionality to collect and exchange information over a network, such as a Local Area Network (LAN) or a Wide Area Network (WAN). In one or more embodiments disclosed herein, the end device (102) may be an internet of things (IoT) -enabled physical object. Examples of terminal devices (102) may include, but are not limited to, motes, appliances, vehicles, wearable or implantable devices, and urban or rural buildings.
In one or more embodiments disclosed herein, the terminal device (102) may include functionality to use one or more onboard (or operatively connected) sensors to collect sensor information. The terminal device (102) may include further functionality to send the aforementioned sensor information to the network gateway (104A). In one or more embodiments disclosed herein, the terminal device (102) and the network gateway (104A) may be capable of two-way, low power, and long distance communicationThe wireless communication link is operatively connected. In one or more embodiments disclosed herein,
In one or more embodiments disclosed herein, the terminal device (102) may include further functionality to generate and send a join request message, and subsequently receive a join accept message (e.g., see fig. 5). Additionally, the terminal device (102) may include functionality to receive configuration update messages (e.g., see FIG. 9) and/or software and firmware updates. In one or more embodiments disclosed herein, the terminal device (102) may include further functionality to monitor, analyze, and optimize itself to improve operational management (see, e.g., fig. 8). In one or more embodiments disclosed herein, the terminal device (102) may include functionality to perform blinding and unblinding operations (e.g., see fig. 6A-7B). The terminal device (102) will be described in further detail below with reference to fig. 2A.
In one or more embodiments disclosed herein, the network gateway (104A) may be any network interconnect, physical device (including software and/or firmware). In one or more embodiments disclosed herein, the term "internetworking" may refer to a process that includes the function of connecting together at least two networks that use different underlying protocols. Thus, in one embodiment disclosed herein, the network gateway (104A) may include functionality to converge and/or mediate between the LoRaWAN protocol and the transmission control protocol/internet protocol (TCP/IP). TCP/IP may be employed by the backhaul network where the network host (106) and the application system (108) reside. In another embodiment disclosed herein, the network gateway (104A) may include functionality to converge and/or mediate between any other existing or future developed wireless protocol and TCP/IP (or any other existing or future developed network protocol). Examples of network gateways (104A) include, but are not limited to, bridges, protocol converters, routers, network switches, multi-layer switches, wireless access points, hubs, and network repeaters.
In one or more embodiments disclosed herein, the above-described backhaul network can be the medium through which the network gateway (104A), the network host (106), and the application system (108) are operatively (or communicatively) connected. The connections between these various components of the system (100A) may be wired and/or wireless, direct or indirect, temporary, permanent, and/or intermittent. Further, the backhaul network may be implemented using a Local Area Network (LAN) or a Wide Area Network (WAN), such as the internet. Further, the backhaul network can employ any existing or future-developed wired and/or wireless communication protocol that includes functionality to facilitate the exchange of information between at least the various components of the system (100A).
In one or more embodiments disclosed herein, the network gateway (104A) may include further functionality to obtain and forward information to or from the end device (102) and/or the network host (106). Specifically, in one or more embodiments disclosed herein, the network gateway (104A) may include functionality to receive LoRaWAN message frames from the end device (102). In one or more embodiments disclosed herein, the received LoRaWAN message frame may include a blinded header (discussed below). Subsequently, the network gateway (104A) may include functionality to encapsulate the received LoRaWAN message frame into a Media Access Control (MAC) frame used by TCP/IP and to send the generated MAC frame to the network host (106). In one or more embodiments disclosed herein, the network gateway (104A) may also include functionality to receive MAC frames from the network host (106). The network gateway (104A) may then include functionality to decapsulate the received MAC frame to obtain the payload residing therein (i.e., the content that the network host (106) may attempt to send to the end device (102)). The network gateway (104A) may then include functionality to encapsulate the obtained payload into a LoRaWAN message frame used by the LoRaWAN protocol, and to transmit the generated LoRaWAN message frame to the terminal device (102). Those of ordinary skill in the art will appreciate that the network gateway (104A) may include other functionality without departing from the scope of the embodiments disclosed herein. The network gateway (104A) will be discussed in further detail below with reference to fig. 2B.
In one or more embodiments disclosed herein, the network host (106) may be any computing system (including software and/or firmware) that may be configured to generate, transmit, receive, and/or process MAC frames. In one embodiment disclosed herein, the network hosts (106) may be implemented on one or more physical servers (e.g., in a data center). In another embodiment disclosed herein, the network host (106) may be implemented on one or more virtual servers, which may be cloud-based. In another embodiment disclosed herein, the network host (106) may be implemented on a combination of one or more physical and/or virtual servers. In another embodiment disclosed herein, the network host (106) may be implemented on any one or more computing systems similar to the exemplary computing system shown in fig. 10A and 10B.
In one or more embodiments disclosed herein, the network host (106) may include the functionality of the management system (100A). Specifically, to manage the system (100A), the network host (106) may include functionality to eliminate duplicate packets (e.g., MAC frames and LoRaWAN message frames), schedule acknowledgements, and adapt data rates. To further adapt the data rate, in one or more embodiments disclosed herein, the network host (106) may include further functionality to manage the data rate and Radio Frequency (RF) output of each end device (102) individually by employing an Adaptive Data Rate (ADR) scheme. The network host (106) may include further functionality to enable packet routing, intelligent dynamic network gateway selection (for optimized traffic routing), and device authentication. In one or more embodiments disclosed herein, the network host (106) may include functionality to generate and send configuration update messages (e.g., see fig. 9). In one or more embodiments disclosed herein, the network host (106) may include functionality to provide provisioning, administration, and reporting services to the application system (108).
In one or more embodiments disclosed herein, the network host (106) may include functionality to receive MAC frames from the network gateway (104A). As described above, the received MAC frame may encapsulate the LoRaWAN message frame from the end device (102). In one embodiment disclosed herein, the received LoRaWAN message frame may include a blinded header (see, e.g., fig. 4B). In such embodiments, the received LoRaWAN message frame may also include sensor information collected and/or measured, for example, by the headend device (102). In another embodiment disclosed herein, the received LoRaWAN message frame may be a join request message (e.g., see fig. 5). The network host (106) may include further functionality to obtain the LoRaWAN message frame by decapsulating the received MAC frame. In one or more embodiments disclosed herein, a network host (106) similar to the terminal device (102) may include functionality to perform blinding and unblinding operations (see, e.g., fig. 6A-7B). Further, the network host (106) may include functionality to encapsulate the LoRaWAN message frame (including the unblinded header) into a MAC frame, and then send the generated MAC frame to the application system (108).
In one or more embodiments disclosed herein, the network host (106) may include additional functionality to dynamically allocate a device address (DevAddr) for one or more end devices (102). The assigning may be performed in response to receiving a join request message from the terminal device(s) (102) (e.g., see fig. 5). In one or more embodiments disclosed herein, the DevAddr may be a unique 32-bit hexadecimal number that specifies a device address for an end device in the network/system (100A). In response to receiving the join request message, the network host (106) may include further functionality to generate and send a join accept message to the terminal device (102). In one or more embodiments disclosed herein, the join accept message may include relevant information (e.g., dynamic device address, session key, and header blinding key (discussed below)) necessary to activate the terminal device (102) and thereby enable the terminal device (102) to securely communicate with various other components of the system (100A).
Further, in one or more embodiments disclosed herein, the network host (106) may include functionality to receive MAC frames from the application system (108). In one embodiment disclosed herein, these received MAC frames may include instructions to control the actions of the end device (102) or software and/or firmware updates. The network host (106) may then include functionality to forward these received MAC frames to the end device (102) via the network gateway (104A). Further, the network host (106) may include functionality to evaluate and optimize network operation by monitoring network operation parameters and adjusting network configuration parameters (see, e.g., fig. 9). In optimizing network operation, the network host (106) may also include functionality to affect terminal device operation by generating and sending configuration update messages. Those of ordinary skill in the art will now appreciate that the network host (106) may include other functionality without departing from the scope of the embodiments disclosed herein. The network host (108) will be discussed in further detail below with reference to fig. 2C.
In one or more embodiments disclosed herein, the application system (108) may be any computing system that may be configured to acquire sensor information from the terminal device (102) and then control the actions of the terminal device (102) (e.g., see fig. 10A and 10B). In one embodiment disclosed herein, the application system (108) may be implemented using one or more physical machines (e.g., in a data center). In another embodiment disclosed herein, the application system (108) may be implemented using one or more virtual machines, which may be cloud-based. In yet another embodiment disclosed herein, the application system (108) may be implemented using a combination of one or more physical and virtual machines. Examples of application systems (108) include, but are not limited to, desktop computers, laptops, tablets, servers, smart phones, game consoles, and workstations.
In one or more embodiments disclosed herein, the application system (108) may include functionality to receive MAC frames from the network host (106). The received MAC frame may include, for example, sensor information from the terminal device (102). The application system (108) may include further functionality to perform analysis of information received from the terminal device (102). In one or more embodiments disclosed herein, the application system (108) may also include functionality to generate instructions, commands, and/or software/firmware updates that may then be transmitted to one or more terminal devices (102). Those of ordinary skill in the art will now appreciate that the application system (108) may include additional or alternative functionality without departing from the scope of the embodiments disclosed herein.
Although fig. 1A illustrates a configuration of components, system configurations other than the system configuration illustrated in fig. 1A may be used without departing from the scope of embodiments disclosed herein. For example, as optionally shown in fig. 1A, the system (100A) may include an additional network gateway (104B) that may serve as a network forwarder that resides between the network gateway (104A) and the network host (106). As another example, as shown in FIG. 1B, the system (100B) may include a plurality of end devices (102A-102C, 102J-102L, 102S-102U), where each set is operatively connected to a designated network gateway (104D-104F). The plurality of network gateways (104D-104F) may then be operatively connected to a network host (106), which in turn may be operatively connected to a plurality of application systems (108X-108Z) by the network host (106).
Fig. 2A illustrates a terminal device in accordance with one or more embodiments disclosed herein. The terminal device (200) includes a power source (202), one or more sensors (204), zero or more actuators (206), one or more processors (208), and a communication interface (214). Each of these components is described below.
In one or more embodiments disclosed herein, the power source (202) may be any power supply device. In one or more embodiments disclosed herein, the power source (202) may be any electrical storage device. In one embodiment disclosed herein, the power supply (202) may store and provide Direct Current (DC) power. In another embodiment disclosed herein, the power supply (202) may store and provide Alternating Current (AC) power. In yet another embodiment disclosed herein, the power source (202) may store and provide a combination of DC and AC power. In one or more embodiments disclosed herein, the power source (202) may include functionality to provide power to various other components of the terminal device (200), such as sensors (204), actuators (206), if any, a processor (208), and a communication interface (214). The power supply (202) may include additional rechargeable functionality, such as, for example, a battery. In one or more embodiments disclosed herein, the power supply (202) may include an integrated management system that may monitor the charging and discharging of power to and from the power supply (202). In such embodiments, the management system may also monitor measurements related to the operation and regulation of the power supply (202). The monitored measurements or properties may include, but are not limited to, temperature, pressure, leakage, capacitance, resistance, inductance, and rate of energy consumption. In one or more embodiments disclosed herein, the power source (202) may be operatively connected to an external power source (not shown) from which the power source (202) may draw power for recharging. Those of ordinary skill in the art will now appreciate that the power supply (202) may include additional circuits or devices (e.g., voltage regulators, converters, transformers, etc.) for enabling the aforementioned functions and other functions without departing from the scope of the embodiments disclosed herein.
In one or more embodiments disclosed herein, the sensor (204) may be a physical device that includes software. In one or more embodiments disclosed herein, the sensor (204) may be a physical device that includes firmware. In any of the above examples, software or firmware is provided to convert measurable physical characteristics (i.e., characteristics that may describe the state of a physical system) into electrical signals or data. Examples of physical characteristics may include, but are not limited to, charge, flow rate, frequency, intensity, position, momentum, pressure, intensity, temperature, velocity, and volume. Those of ordinary skill in the art will now appreciate that the sensors may detect and measure other physical characteristics depending on the application, environment, or both with which the terminal device (200) is associated without departing from the scope of the embodiments disclosed herein. Examples of sensors (204) may include, but are not limited to, accelerometers, Global Positioning System (GPS) devices, pressure sensors, temperature sensors, microphones, cameras, electroencephalographs (EEG) (i.e., bio-electric sensors), and photo-ionization detectors (PIDs) (e.g., gas or organic compound sensors). In one or more embodiments disclosed herein, the one or more sensors (204) may be operatively connected to the power source (202) and the one or more processors (208).
In one or more embodiments disclosed herein, the actuator (206) may be a physical device that includes software. In one or more embodiments disclosed herein, the actuator (206) may be a physical device that includes firmware. In either case, software or firmware is provided to the sensor to enable conversion of the electrical signal or data to a stimulus. In one or more embodiments disclosed herein, the nature of the stimuli can be kinetic, sensory, thermal, chemical, auditory, visual, any other type of stimuli, or a combination thereof. Examples of actuators (206) may include, but are not limited to, motors, fluid pumps, piezoelectric elements, speakers, and displays. Those of ordinary skill in the art will now appreciate that the actuator may generate other stimuli depending on the application, environment, or both with which the terminal device (200) is associated without departing from the scope of the embodiments disclosed herein. Further, in one or more embodiments disclosed herein, zero or more actuators (206) are operatively connected to the power source (202) and the one or more processors (208).
In one or more embodiments disclosed herein, the processor (208) may be a collection of integrated circuits including software for executing instructions. In one or more embodiments disclosed herein, the processor (208) may be a collection of integrated circuits including firmware for executing instructions. The above-described instructions may correspond to computer-readable program code that, when executed by one or more processors (208), enables the one or more processors (208) to perform the embodiments disclosed herein as shown in fig. 5-8. Those of ordinary skill in the art will now appreciate that the computer readable program code may enable the one or more processors (208) to perform additional operations without departing from the scope of the embodiments disclosed herein. Examples of the processor (208) may include, but are not limited to, a discrete processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a microcontroller, a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), a single board computer, and any combination thereof.
In one or more embodiments disclosed herein, the blinding filter (210) may be executed on one or more processors (208) of the terminal device (200). In one embodiment disclosed herein, the blinding filter (210) may be at least a portion of a computer program or a set of computer readable program code. When executed by the one or more processors (208), the blinding filter (210) may enable the one or more processors (208) to perform blinding or de-blinding operations in accordance with embodiments disclosed herein (e.g., see fig. 6A-7B).
In one or more embodiments disclosed herein, the decision logic (212) may be executed on one or more processors (208) of the terminal device (200). In one embodiment disclosed herein, the decision logic (212) may be at least a portion of a computer program or a set of computer readable program code. When executed by the one or more processors (208), the decision logic (212) may provide the one or more processors (208) with the functionality to monitor and optimize terminal device operation in accordance with embodiments disclosed herein (see, e.g., fig. 8).
In one or more embodiments disclosed herein, the communication interface (214) may be a physical device including software for receiving and transmitting LoRaWAN message frames. In one or more embodiments disclosed herein, the communication interface (214) may be a physical device, including firmware, for receiving and transmitting the LoRaWAN message frames. The communication interface (214) may communicatively connect the terminal device (200) to one or more network gateways (see, e.g., fig. 1A). In at least one embodiment disclosed herein, the communication interface (214) may employ LoRa wireless modulation to receive and transmit information. In at least one embodiment disclosed herein, the communication interface (214) may employ the LoRaWAN protocol to receive and transmit information. In another embodiment disclosed herein, the communication interface (214) may employ any other existing or future developed modulation, protocol, or combination thereof to receive and transmit information.
In one or more embodiments disclosed herein, the communication interface (214) may include functionality to receive a join accept message (from a network host) (e.g., see fig. 5). The communication interface (214) may include additional functionality to receive configuration update messages (e.g., see fig. 9) and software/firmware updates (from a network host). In one or more embodiments disclosed herein, the communication interface (214) may include further functionality to send sensor information (obtained from the one or more sensors (204)) to the network host via the network gateway. Examples of the communication interface (214) include, but are not limited to, a network interface controller, a network interface device, a network socket, and an antenna.
Although fig. 2A illustrates a configuration of components, terminal device configurations other than the configuration illustrated in fig. 2A may be used without departing from the scope of the embodiments disclosed herein.
Fig. 2B illustrates a network gateway in accordance with one or more embodiments disclosed herein. The network gateway (220) includes a power supply (222), a memory (224), one or more processors (226), and a communication interface (228). Each of these components is described below.
In one or more embodiments disclosed herein, the power supply (222) may be substantially similar to the power supply (202) described above with respect to the terminal device in fig. 2A. In one or more embodiments disclosed herein, memory (224) may be any non-persistent or volatile memory, such as, for example, Random Access Memory (RAM) and cache memory. The memory (224) may be operatively connected to the power source (222) and the one or more processors (226). In one or more embodiments disclosed herein, the one or more processors (226) may be substantially similar to the processor (208) described above in fig. 2A.
In one or more embodiments disclosed herein, the communication interface (228) may be a physical device including software for receiving and transmitting LoRaWAN message frames, MAC frames, or a combination thereof. In one or more embodiments disclosed herein, the communication interface (228) may be a physical device including firmware for receiving and transmitting LoRaWAN message frames, MAC frames, or a combination thereof. The communication interface (228) may communicatively connect the network gateway (220) to one or more end devices and a network host (see, e.g., fig. 1A). In one embodiment disclosed herein, the communication interface (228) may employ LoRa wireless modulation, LoRaWAN protocol, or a combination thereof to receive and transmit information. The communication interface (228) may additionally or alternatively employ a TCP/IP stack and protocols to receive and transmit information from/to systems residing in the backhaul network (as described above). In another embodiment disclosed herein, the communication interface (228) may employ any other existing or future developed modulation, stack, protocol, or combination thereof to receive and transmit information. Examples of communication interfaces (228) include, but are not limited to, network interface controllers, network interface devices, network sockets, ethernet ports, and antennas.
Although fig. 2B illustrates a configuration of components, a network gateway configuration other than that shown in fig. 2B may be used without departing from the scope of the embodiments disclosed herein.
Fig. 2C illustrates a network host in accordance with one or more embodiments disclosed herein. The network host (240) includes a data store (242), one or more processors (244), and a communication interface (250). Each of these components is described below.
In one or more embodiments disclosed herein, the data store (242) may be any type of storage unit, data structure, device, or combination thereof (e.g., a file system, a database, a collection of tables, or any other storage mechanism). The data repository (242) may include functionality to incorporate any information relevant to embodiments disclosed herein, including, but not limited to, routing tables to track which network gateway may be operatively connected to which end device, one or more network session keys, one or more application session keys, one or more header blinding keys, and monitored data rates and RF outputs associated with each end device operatively connected to the network host (240). In one or more embodiments disclosed herein, the data store (242) may be implemented using multiple storage units, data structures, or devices, which may or may not be of the same type or located at the same physical site. Examples of data store (242) include, but are not limited to, solid state drives, optical drives, magnetic storage, cloud-based storage systems, and any other persistent and non-volatile storage media.
In one or more embodiments disclosed herein, the one or more processors (244) of the network host (240) may be substantially similar to the processors described with respect to the terminal device or network gateway in fig. 2A or 2B, respectively. Further, in one or more embodiments disclosed herein, the blinding filter (246) may be executed on one or more processors (224) of the network host (240). In one embodiment disclosed herein, the blinding filter (246) may be at least a portion of a computer program or a set of computer readable program code. When executed by the one or more processors (244), the blinding filter (246) may enable the one or more processors (244) to perform blinding or de-blinding operations in accordance with embodiments disclosed herein (e.g., see fig. 6A-7B).
In one or more embodiments disclosed herein, the decision logic (248) may be executed on one or more processors (244) of the terminal device (240). In one embodiment disclosed herein, the decision logic (248) may be at least a portion of a computer program or a set of computer readable program code. When executed by the one or more processors (244), the decision logic (248) may provide the one or more processors (244) with functionality to monitor and optimize network operations in accordance with embodiments disclosed herein (e.g., see fig. 9).
In one or more embodiments disclosed herein, the communication interface (250) may be a physical device including software for receiving and transmitting MAC frames. In one or more embodiments disclosed herein, the communication interface (250) may be a physical device including firmware for receiving and transmitting MAC frames. The communication interface (250) may communicatively connect the network host (240) to one or more network gateways and one or more application systems (see, e.g., fig. 1B). In one embodiment disclosed herein, the communication interface (250) may employ a TCP/IP stack and protocols to receive and transmit information. In another embodiment disclosed herein, the communication interface (250) may employ any other existing or future developed networking stack, protocol, or combination thereof to receive and transmit information. Examples of communication interfaces (250) include, but are not limited to, ethernet ports, network interface controllers, network interface devices, network sockets, and antennas.
Although fig. 2C illustrates a configuration of components, a network host configuration other than that shown in fig. 2C may be used without departing from the scope of the embodiments disclosed herein.
Fig. 3 illustrates a LoRaWAN message frame in accordance with one or more embodiments disclosed herein. The LoRaWAN message frame (300) includes a preamble (302), a Physical Header (PHDR) (304), a PHDR Cyclic Redundancy Check (CRC) (306), and a Physical (PHY) payload (308). These aforementioned components may be present in an uplink message frame that may be sent by the terminal device to the network host. In one embodiment disclosed herein, the LoRaWAN message frame (300) may also include a CRC (310) when considering a downlink message frame that may be sent by the network host to the terminal device. Each of these components is described below.
In one or more embodiments disclosed herein, the preamble (302), PHDR (304), PHDR CRC (306), PHY payload (308), and CRC (310) may be comprised of
In one or more embodiments disclosed herein, the PHY payload (308) may be a data structure that includes a Media Access Control (MAC) header (MHDR) (320). The MHDR (320) may specify information including, but not limited to, the message type of the LoRaWAN message frame (300) and the version of the message frame format of the LoRaWAN layer specification with which the LoRaWAN message frame (300) is encoded. The PHY payload (308) may also include a MAC payload (322) (described below) and a Message Integrity Code (MIC) (324). In one or more embodiments disclosed herein, the MIC (324) may be a hexadecimal number that is computed and verified over several components of the LoRaWAN message frame (300) (see, e.g., fig. 4A and 4B) to ensure data integrity of the MAC payload (322).
In one or more embodiments disclosed herein, the MAC payload (322) may be a data structure that includes a Frame Header (FHDR) (340). The FHDR (340) can be further decomposed and thus includes a device address (DevAddr) (360), a frame control (FCtrl) (362), a frame count (FCnt) (364), and frame options (FOpts) (366). The DevAddr (360) may represent a network address of the end device, which may be dynamically assigned by the network host during activation of the end device (see, e.g., fig. 5). FCtrl (362) may include information including, but not limited to, a set data rate, transmission power, repetition rate, and frequency channel of a radio transceiver (i.e., communication interface). The FCnt (364) may track the number of uplink and downlink messages that have been exchanged. Additionally, FOpts (366) may be used to transmit MAC commands that enable the network host to issue instructions to the end device. The issued instruction may, for example, instruct the terminal device to adjust one or more terminal device configuration parameters (see, e.g., fig. 9).
In one or more embodiments disclosed herein, the MAC payload (322) may also include a frame port (FPort) (342) and a frame payload (344). The FPort (342) may indicate which session key (e.g., network session key (NwkSKey) or application session key (AppSKey)) to use to encrypt the frame payload (344). Finally, the frame payload (344) may represent content that the terminal device or network host may attempt to send to each other. Those of ordinary skill in the art will now appreciate that the LoRaWAN message frame (300) may include other components without departing from the embodiments disclosed herein.
Although fig. 3 illustrates a configuration of components, message frame configurations other than those illustrated in fig. 3, which are related to the LoRaWAN specification, may be used without departing from the scope of the embodiments disclosed herein. For example, message frames (e.g., Media Access Control (MAC) frames) compliant with the ieee802.15.4 standard may be employed instead.
Fig. 4A shows a diagram illustrating a LoRaWAN security procedure in accordance with one or more embodiments disclosed herein. The process (400A) may begin by obtaining a frame payload (402) that may represent content that a source device may attempt to transmit to a destination device. From there, a cryptographic operation (406) may be applied to the frame payload (402) using at least one application session key (AppSKey) (404). In one or more embodiments disclosed herein, AppSKey (404) can be a unique hexadecimal number that is specific to the terminal device and known only to the terminal device and the application system. In one or more embodiments disclosed herein, the terminal device and application system may encrypt and decrypt the frame payload using AppSKey (402). In one embodiment disclosed herein, the cryptographic operation (406) performed may require an Advanced Encryption Standard (AES) algorithm. In another embodiment disclosed herein, the cryptographic operation (406) may require any other existing or future developed symmetric cipher. The result of the cryptographic operation (406) may generate an encrypted frame payload (414).
In one or more embodiments disclosed herein, a symmetric cipher may be a cryptographic algorithm that uses the same cryptographic key to encrypt unencrypted information and to decrypt encrypted information. In the present disclosure, for example, the cryptographic key may be a header blinding key (HdrBKey) that may be used to blind (or encrypt) a plaintext header (i.e., unencrypted information) and to unblind (or decrypt) a blinded header (i.e., encrypted information). In addition to the AES algorithm described above, examples of other symmetric ciphers that may be used in one or more embodiments disclosed herein include, but are not limited to, the Twofish algorithm, Serpent algorithm, Blowfish algorithm, CAST5 algorithm, Kuznyechik algorithm, Rivest Cipher (RC)4 algorithm, triple data encryption standard (3DES) algorithm, Skipjack algorithm, and International Data Encryption Algorithm (IDEA).
In one or more embodiments disclosed herein, the process (400A) may be performed by generation of a MAC payload (408). The MAC payload (408) may be obtained by a connection header (FHDR) (410), a frame port (FPort) (412), and an encrypted frame payload (414). The FHDR (410) may include a device address (418), a frame control (FCtrl) (420), a frame count (FCnt) (422), and a frame options (FOpts) (424). In one embodiment disclosed herein, FHDR (410), along with MAC Header (MHDR) (416) and FPort (412), may be collectively referred to as a clear header (428). In another embodiment disclosed herein, the clear header (428) may include at least the device address (418) and the FCnt (422). In one or more embodiments disclosed herein, the term "plaintext" may refer to a state that exhibits an exposure, unencrypted or vulnerable state, which may be susceptible to eavesdropping or interception.
Proceeding to process (400A), the plaintext header (428) may then be appended with the ciphered frame payload (414) and the Message Integrity Code (MIC) (430) to obtain a Physical (PHY) payload (426). The MIC (430) may be generated by: another cryptographic operation (434) is applied jointly to the clear header (428) and the encrypted frame payload (414), using at least the network session key (NwkSKey) (432). In one or more embodiments disclosed herein, NwkSKey (432) may be a unique hexadecimal number specific to the terminal device and known only to the terminal device and the network host. In one or more embodiments disclosed herein, NwkSKey (432) may be used by the end device and the network host to compute and verify a MIC (430) to ensure data integrity. In one embodiment disclosed herein, the cryptographic operation (434) performed may require an AES algorithm. In another embodiment disclosed herein, the cryptographic operation (434) performed may require any other existing or future developed symmetric cipher.
Fig. 4B shows a diagram illustrating an enhanced LoRaWAN security process in accordance with one or more embodiments disclosed herein. The enhanced process (400B) is substantially similar to the process (400A) depicted in fig. 4A, except for the blinding operation (442). In one or more embodiments disclosed herein, the introduction of this blinding operation (442) can minimize, if not eliminate, the possibility of eavesdropping or intercepting header information sent within the LoRaWAN message frame. Further, a blinding operation (442) may be applied to the clear header (428) using at least one header blinding key (HdrBKey) (440). As described above, clear header (428) may refer to an unencrypted header (including MHDR (416), device address (DevAddr) (418), FCtrl (420), FCnt (422), FOpts (424), and FPort (412)) that may be susceptible to eavesdropping or interception. In one or more embodiments disclosed herein, the enhanced process (400B) addresses this vulnerability by generating a blinded (or otherwise encrypted) header (444). In one or more embodiments disclosed herein, the HdrBKey (440) can be a unique hexadecimal number specific to the end device and known only to the end device and the network host. In one or more embodiments disclosed herein, the HdrBKey (440) can be used by the end device and the network host to blindly/encrypt the clear header and to unblind/decrypt the blinded header. In one embodiment disclosed herein, the performed blinding operation (434) may require an AES algorithm. In another embodiment disclosed herein, the performed blinding operation (434) may require any other existing or future developed symmetric cipher.
Fig. 5-9 illustrate flow diagrams in accordance with one or more embodiments disclosed herein. Although the various steps in the flow diagrams are presented and described sequentially, those skilled in the art will appreciate that some or all of the steps may be performed in a different order, some or all of the steps may be combined or omitted, and some or all of the steps may be performed in parallel. In one embodiment disclosed herein, the steps shown in fig. 5-9 may be performed in parallel with any other steps shown in fig. 5-9 without departing from the scope of embodiments disclosed herein.
Fig. 5A and 5B show a flow chart describing a method for activating a terminal device according to one or more embodiments disclosed herein. Specifically, fig. 5A and 5B describe a method of Over The Air Activation (OTAA). OTAA may be a way to enable end devices to join a network and participate in secure information exchange with a network host. Further, the OTAA procedure described below may be performed when the end device is initially deployed or whenever the end device is reset.
In step 500, the terminal device generates a join request message. In one or more embodiments disclosed herein, the join request message may be a LoRaWAN message frame (see, e.g., fig. 3) that includes a unique identifier as a Media Access Control (MAC) header (MHDR), thereby making the LoRaWAN message frame of the join request message type. In one or more embodiments disclosed herein, the join request message may also include an application identifier (AppEUI), a device identifier (DevEUI), and an application key (AppKey). AppEUI may be a globally unique hexadecimal number that uniquely identifies a particular application system (i.e., the application system that owns or controls the terminal device). Further, DevEUI may be a globally unique hexadecimal number that uniquely identifies a particular terminal device (i.e., the terminal device that generated the join request message). Additionally, the AppKey may be a unique hexadecimal number specific to the terminal device. The end device may use the AppKey to derive the session key and blinded key (see, e.g., step 526), which is necessary to enable the end device to participate in secure information exchange with the network host. The AppKey may be pre-provisioned (or stored) to the terminal device during the manufacturing process. In one or more embodiments disclosed herein, AppEUI, DevEUI, and AppKey may be pre-specified (or stored) to the terminal device during the manufacturing process. One of ordinary skill in the art will appreciate that the join request message may include additional components without departing from the scope of the embodiments disclosed herein.
In step 502, the terminal device sends a join request message (generated in step 500) to the network host. In step 504, the network host receives the join request message (sent by the terminal device in step 502). Specifically, in one or more embodiments disclosed herein, a network host may receive a MAC frame encapsulating a join request message. The received MAC frame may be generated by the network gateway upon receiving the join request message from the terminal device. The network host may then decapsulate the MAC frame to access various components of the join request message (e.g., AppEUI, DevEUI, and AppKey).
In step 506, the network host determines whether the end device is allowed to join or participate in the network. In one or more embodiments disclosed herein, this determination may require authentication of the join request message, or more specifically, authentication of a Message Integrity Code (MIC) of the join request message using at least AppEUI, DevEUI, and AppKey (see, e.g., fig. 3). If the terminal device is allowed to join or participate in the network (i.e., the MIC authentication is successful), the process proceeds to step 508. On the other hand, if the terminal apparatus is not allowed to join or participate in the network (e.g., MIC authentication fails), the process ends.
In step 508, upon determining that the end device is allowed to join or participate in the network, the network host generates a join accept message. In one or more embodiments disclosed herein, the join accept message may be a LoRaWAN message frame (see, e.g., fig. 3) that includes a unique identifier as the MHDR, thereby making the LoRaWAN message frame of the join accept type. In one or more embodiments disclosed herein, the join accept message may further include a device address (DevAddr) and a network identifier (NetID). The DevAddr may be a unique hexadecimal number that uniquely identifies the network address of the terminal device in the network. The DevAddr may be dynamically allocated by the network host in response to receiving and authenticating the join request message. Further, the NetID can be a globally unique hexadecimal number that uniquely identifies a particular network (i.e., at least the network in which the network host resides). Those of ordinary skill in the art will now appreciate that the join accept message may include additional components without departing from the scope of the embodiments disclosed herein.
Turning to fig. 5B, in step 520, the network host sends a join accept message to the end device. In particular, in one or more embodiments disclosed herein, after generating the join accept message, the network host may encrypt the join accept message using the AppKey, in conjunction with, for example, an Advanced Encryption Standard (AES) encryption algorithm. Alternatively, the network host may encrypt the join accept message using the AppKey in conjunction with any other existing or future developed symmetric cipher. The network host may then encapsulate the encrypted join accept message within a MAC frame, wherein the MAC frame is transmitted to the end device. In one or more embodiments disclosed herein, upon reaching a network gateway, which may be a single-hop (single-hop) away from the end device, the network gateway may decapsulate the MAC frame before sending the encrypted join accept message to the end device.
At step 522, the end device receives the join accept message (sent by the network host at step 520). As described above, in one or more embodiments disclosed herein, a received join accept message may be encrypted. In step 524, the terminal device then decrypts the join accept message (received in step 522). In one or more embodiments disclosed herein, the end device can decrypt the join accept message using the AppKey to access various components of the join accept message (e.g., DevAddr and NetID).
In step 526, the terminal device derives a network session key (NwkSKey), an application session key (AppSKey), and a header blinding key (HdrBKey). In one or more embodiments disclosed herein, each of the above-described keys can be derived using at least an AppKey and a NetID. Those of ordinary skill in the art will now appreciate that the terminal device may derive the above-described keys using additional or alternative components. NwkSKey may be a unique hexadecimal number which is specific to the terminal device and known only to the terminal device and the network host. In one or more embodiments disclosed herein, NwkSKey may be used by the end device and the network host to calculate and verify the MICs of all LoRaWAN message frames to ensure data integrity (see, e.g., fig. 3, 4A, and 4B). Furthermore, AppSKey may be a unique hexadecimal number specific to the terminal device and known only to the terminal device and the application system. In one or more embodiments disclosed herein, AppSKey may be used by terminal devices and application systems to encrypt and decrypt the frame payload of a LoRaWAN message frame (see, e.g., fig. 3, 4A, and 4B). Further, HdrBKey may be a unique hexadecimal number specific to the terminal device and known only to the terminal device and the network host. In one or more embodiments disclosed herein, the HdrBKey may be used by the terminal device and the network host to blinde/encrypt the clear header of the LoRaWAN message frame, and to unblind/decrypt the blinded header (see, e.g., fig. 4B and 6A-7B).
Although fig. 5A and 5B describe a method for activating a terminal device, activation methods other than those shown in fig. 5A and 5B may be used without departing from the scope of the embodiments disclosed herein. For example, a personalized Activation (ABP) method may be used. In ABP, during the manufacturing process, the above-described process is not performed, but DevAddr, NwkSKey, AppSKey, and HdrBKey are previously specified (or hard-coded) to a terminal device. In one or more embodiments of the apparatus, systems, and methods described herein, the individual portions may be hard-coded. For example, in one or more embodiments, the DevAddr may be provided to the terminal device during manufacturing. In another embodiment, NwkSKey may be provided to the terminal device during manufacture. In another embodiment, AppSKey may be provided to the terminal device during manufacture. In another embodiment, HdrBKey may be provided to the terminal device during manufacture. Subsequently, using these pre-specified components, the end device can immediately begin participating in the secure information exchange with the network host upon deployment or reset of the end device.
Fig. 6A and 6B show a flow chart describing a method for blinding a plaintext header in accordance with one or more embodiments disclosed herein. In particular, fig. 6A describes a method for blinding the clear headers of any first LoRaWAN message frames exchanged between the terminal device and the network host. Fig. 6B describes a method for blinding the clear header of any subsequent (i.e., second or later) LoRaWAN message frames exchanged between the terminal device and the network host.
Turning to fig. 6A, in step 600, a portion of a first LoRaWAN message frame is generated. In one or more embodiments disclosed herein, the portion may include a first clear header and a first encrypted frame payload. As described above with reference to fig. 3, the clear header may include the following components: MAC Header (MHDR), device address (DevAddr), frame control (FCtrl), frame count (FCnt), frame options (FOpts), and frame port (FPort). In one or more embodiments disclosed herein, the first clear header and the first encrypted frame payload may together represent a portion of a Physical (PHY) payload of the first LoRaWAN message frame. In one embodiment disclosed herein, step 600 may be performed by a terminal device, wherein the first LoRaWAN message frame may be an uplink message. In another embodiment disclosed herein, step 600 may be performed by the network host, wherein the first LoRaWAN message frame may be a downlink message.
In step 602, a device identifier (DevEUI) and a header blinding key (HdrBKey) are obtained. In one or more embodiments disclosed herein, the DevEUI and HdrBKey may be retrieved from local storage or memory residing on the end device or network host. Further, in one embodiment disclosed herein, DevEUI and HdrBKey may be stored locally on the terminal device or network host by pre-provisioning (i.e., in an individualized Activation (ABP) manner) (as described above). In another embodiment disclosed herein, DevEUI and HdrBKey may be stored locally on the terminal device or network host after performing the methods described above with respect to fig. 5A and 5B.
In step 604, a first bitmask is generated. In one or more embodiments disclosed herein, the first bitmask may be generated by performing a cryptographic operation on DevEUI using HdrBKey. Furthermore, cryptographic operations may require any existing or future developed symmetric cipher. As an example, in one embodiment disclosed herein, the cryptographic operation may employ an AES encryption algorithm.
In step 606, the first header mask (generated in step 604) is applied to the first plaintext header. In one or more embodiments disclosed herein, applying the first bitmask to the first plaintext header may entail performing a bitwise exclusive-or (i.e., XOR) operation involving the first bitmask and the first plaintext header. In one or more embodiments disclosed herein, the first blinding header may be generated by the bitwise XOR operation described above.
In step 608, the portion of the first LoRaWAN message frame (generated in step 600) is updated. In one or more embodiments disclosed herein, the update may entail replacing the first plaintext header with the first blinded header (obtained in step 606). In step 610, a remaining portion of the first LoRaWAN message frame may be generated in accordance with the LoRaWAN specification to generate a first blinded LoRaWAN message frame. In one or more embodiments disclosed herein, the first blinded LoRaWAN message frame includes at least a first blinded header (obtained in step 608). In step 612, a first blinded LoRaWAN message frame (generated in step 610) is then transmitted. In one or more embodiments disclosed herein, the first blinded LoRaWAN message frame may be transmitted to the network gateway regardless of whether the transmitting entity is a terminal device or a network host.
Turning to fig. 6B, in step 620, a portion of a second (or subsequent) LoRaWAN message frame is generated. In one or more embodiments disclosed herein, the portion of the second (or subsequent) LoRaWAN message frame may include a second (or subsequent) clear header and a second (or subsequent) encrypted frame payload.
In step 622, a second (or subsequent) header mask is generated. In one or more embodiments disclosed herein, the second (or subsequent) header mask may be generated by performing a cryptographic operation on the first (or previously generated) header mask using the HdrBKey. Furthermore, the cryptographic operation may require any existing or future developed symmetric cipher. As an example, in one embodiment disclosed herein, the cryptographic operation may employ an AES encryption algorithm.
In step 624, the second (or subsequent) header mask (generated in step 622) is applied to the second (or subsequent) plaintext header. In one or more embodiments disclosed herein, applying the second (or subsequent) header mask to the second (or subsequent) plaintext header may entail performing a bitwise exclusive-or (i.e., XOR) operation involving the second (or subsequent) header mask and the second (or subsequent) plaintext header. In one or more embodiments disclosed herein, the second (or subsequent) blinding header may be generated by the bitwise XOR operation described above.
In step 626, the portion of the second (or subsequent) LoRaWAN message frame (generated in step 620) is updated. In one or more embodiments disclosed herein, the update may entail replacing the second (or subsequent) plaintext header with the second (or subsequent) blinded header (obtained in step 624). From here, the remainder of the second (or subsequent) LoRaWAN message frame may be generated according to the LoRaWAN specification. The result is a second (or subsequent) blinded LoRaWAN message frame. In step 628, a second (or subsequent) blinded LoRaWAN message frame is then sent. In one or more embodiments disclosed herein, the second (or subsequent) blinded LoRaWAN message frame may be transmitted to the network gateway, regardless of whether the transmitting entity is a terminal device or a network host.
Fig. 7A and 7B show a flow chart describing a method for blinding a blinding head in accordance with one or more embodiments disclosed herein. In one embodiment disclosed herein, the following unblinding method may be performed exclusively by the network host. In another embodiment disclosed herein, the following blinding-free method (or more precisely, steps 700 to 724) may additionally be performed on the terminal device. In the latter embodiment, the terminology relating to "for each terminal device in the device group" (hereinafter introduced from the perspective of the network host performing the method) may be replaced to reflect the terminology relating to "for the terminal device" (i.e., the terminal device performing the blinding method).
In step 700, for each terminal device in the device group, a device identifier (DevEUI), a header blinding key (HdrBKey), and a device address (DevAddr) are obtained. In one or more embodiments disclosed herein, a device group may refer to a collection of end devices to which a network host is operatively (or communicatively) connected. Referring to FIG. 1B, the device group managed by the network host (106) may include end devices A-C (102A-102C), J-L (102J-102L), and S-U (102S-102U). Furthermore, as described above, DevEUI, HdrBKey, and DevAddr are each specific to an end device. Thus, in one or more embodiments disclosed herein, a unique DevEUI set, a unique HdrBKey set, and a DevAddr set may be obtained for the group of devices. Further, in one or more embodiments disclosed herein, the DevEUI set, HdrBKey set, and DevAddr set may be retrieved from local storage or memory residing on a network host. In one embodiment disclosed herein, the above-described information sets may be stored locally on the network host by Preprovisioning (i.e., in an individualized Activation (ABP) manner), as described above. In another embodiment disclosed herein, the above-described set of information may be stored locally on the network host after performing the method described above with respect to fig. 5A and 5B.
In step 702, for each terminal device in the device group, a head mask is generated, thereby obtaining a set of head masks. In one embodiment disclosed herein, when a first LoRaWAN message frame is expected, a first bitmask may be generated by performing a cryptographic operation on DevEUI using HdrBKey. In other embodiments disclosed herein, when a second (or subsequent) LoRaWAN message frame is expected, the second (or subsequent) header mask may be generated by performing a cryptographic operation on the first (or previously generated) header mask using the HdrBKey. Furthermore, cryptographic operations may require any existing or future developed symmetric cipher. As an example, in one embodiment disclosed herein, the cryptographic operation may employ an AES encryption algorithm.
In step 704, for each terminal device in the device group, a candidate clear header (CPH) for the next expected LoRaWAN message frame is generated, thereby obtaining a CPH set. In one or more embodiments disclosed herein, the generation of the CPH may require instantiation (or initialization) of a random hexadecimal number, where the length of the random hexadecimal number is equal to the length of the plaintext header. Subsequently, at a known bit position (bit location) of the clear header designated for the DevAddr (see, e.g., fig. 3, 4A, and 4B) and other fixed data, the DevAddr and other fixed data can be replaced into a corresponding bit position of the random hexadecimal number. The above replacement results in a CPH that may include a portion of the valid bits (delineated by the DevAddr and other fixed data at their designated bit positions) and a portion of the non-valid (or don't care) bits.
In step 706, for each end device in the device group, a header mask is applied to the CPH of the next expected LoRaWAN message frame. Thus, as a result, for each terminal device in the device group, a Candidate Blinding Header (CBH) is obtained, thereby obtaining a CBH set. In one or more embodiments disclosed herein, applying the head mask to the CPH may entail performing a bitwise exclusive-or (i.e., XOR) operation involving the head mask and the CPH.
In step 708, a LoRaWAN message frame is received. In one or more embodiments disclosed herein, the received LoRaWAN message frame may include a blinded header (i.e., an encrypted clear header) (see, e.g., fig. 4B). Further, the received LoRaWAN message frame may be sent by a network gateway. In one embodiment disclosed herein, the received LoRaWAN message frame may arrive as a Media Access Control (MAC) frame encapsulating the LoRaWAN message frame when it is considered that the network host is performing the blinding method. In another embodiment disclosed herein, the received LoRaWAN message frame may arrive as it is (i.e., without MAC encapsulation) when it is considered that the end device is performing the de-blinding method.
Turning to fig. 7B, in step 720, the fixed (or valid) bits of the blinded header (of the LoRaWAN message frame received in step 708) are compared to the fixed (or valid) bits of each CBH in the CBH set (obtained in step 706). In one or more embodiments disclosed herein, based on the comparison, at least one fixed-bit matching CBH is identified. In one or more embodiments disclosed herein, the fixed-bit-matching CBH refers to a CBH in the CBH set that includes fixed (or valid) bits that exactly match the fixed (or valid) bits included in the aforementioned blinding header. Although there is a possibility of identifying a plurality of fixed bit matching CBHs, the probability is considered to be infinitesimal small. Then, in all possibilities, only a single fixed bit matching CBH can be identified as a result of the above comparison.
In step 722, the identified header mask is applied to the blinded header (of the LoRaWAN message frame received in step 708). In one or more embodiments disclosed herein, the identified head mask may be one of the set of head masks (generated in step 702) corresponding to the fixed-bit-matching CBH (identified in step 720). As described above with respect to step 706, the CBH (for the particular terminal device) may be obtained by applying the head mask (for the particular terminal device) to the CPH (for the particular terminal device) for the next expected LoRaWAN message frame. Thus, in one or more embodiments disclosed herein, the identified head mask may be the head mask (for the particular end device) that is applied to the CPH (for the particular end device) to obtain the fixed-bit-matching CBH (associated with the particular end device). Further, in one or more embodiments disclosed herein, a clear text (i.e., decrypted/unencrypted) header is obtained when the identified header mask is applied to the blinded header. In one or more embodiments disclosed herein, applying the identified header mask to the blinded header results in a clear header, which may require performing a bitwise exclusive-or (i.e., XOR) operation involving the identified header mask and the blinded header.
In step 724, the LoRaWAN message frame (received in step 708) is updated with the clear header (obtained in step 722). Specifically, in one or more embodiments disclosed herein, a clear header (obtained in step 722) may be utilized in place of the blinded header residing in the received LoRaWAN message frame. The result is a blinded LoRaWAN message frame.
In step 726, the sender device (of the device group) corresponding to the fixed bit matching CBH is identified. In one or more embodiments disclosed herein, because the header mask, CPH, and CBH are terminal device specific (as described above), one or more of the aforementioned information may be tracked back to the sending end device. In one embodiment disclosed herein, the association between the terminal device and the aforementioned information may be tracked or consolidated locally on the network host. In such embodiments, identification of the sending end device may entail finding a locally stored record or entry that includes a fixed bit matching CBH. Upon identifying a particular record or entry, the sender device associated with the particular record or entry may be found.
In step 728, the application system with which the transmitting terminal device (identified in step 726) is registered is identified. In one or more embodiments disclosed herein, the network host may include functionality to track or consolidate the following associations: the association details which set of terminal devices is likely to be owned/controlled by which application system. Using these associations, the application system that owns or controls the sender device (identified in step 726) may then be identified. In step 730, the blinded LoRaWAN message frame (obtained in step 724) is sent to the application system (identified in step 728). In one or more embodiments disclosed herein, as the backhaul network where the network hosts and application systems reside, TCP/IP may be employed, and the blinded LoRaWAN message frames may be encapsulated in MAC frames before transmission.
Fig. 8 shows a flow diagram depicting a method for optimizing terminal device operational management according to one or more embodiments disclosed herein. In one or more embodiments disclosed herein, the following method may be exclusively performed by a terminal device.
In step 800, one or more terminal device operating parameters are monitored. In one embodiment disclosed herein, the terminal device operating parameter can be any observable physical characteristic, measurable physical characteristic, or combination thereof. In such embodiments, one or more of the above characteristics may be estimated by one or more sensors resident on (or operatively connected to) the terminal device. Examples of terminal device operating parameters that are observable and measurable physical properties include, but are not limited to, electrical properties (e.g., charge, capacitance, electric field, electrical impedance, power, magnetic flux), temperature, location, radioactive mass, intensity, frequency, pressure, and velocity. In another embodiment disclosed herein, the terminal device operating parameter may be a metric derived from one or more observable/measurable physical characteristics. The metrics may describe qualitative information such as, for example, thresholds, constraints, ranges, durations, maxima, minima, and averages. Examples of terminal device operating parameters as metrics include, but are not limited to, data rate, processor usage, hardware temperature, sensor tolerance, latency, message frame loss, incident response, and vulnerability mitigation.
In step 802, one or more terminal device operating parameters (monitored in step 800) are checked against set criteria. In one embodiment disclosed herein, the set-up criteria may include static conditions or specifications, which may be provided during the manufacturing process. In another embodiment disclosed herein, the set-up criteria may include dynamic conditions or specifications that may change with, for example, software/firmware updates, configuration update messages (e.g., see fig. 9), and self-improvement/learning schemes. As an example, the dynamically set criteria for observable/measurable physical characteristics of a location (as terminal device operating parameters) may be constraints provided by geo-fencing (i.e., a virtual geographic boundary that may trigger a response when a terminal device enters or leaves a particular area, or is within or beyond a specified range from a reference). As another example, the statically-set criteria (as a terminal device operating parameter) for a measure of lifetime energy throughput of a power supply may be a preset hard top or maximum value that specifies the total amount of energy (in watt-hours) that may be charged into and discharged from the power supply over all cycles of its lifetime. In one or more embodiments disclosed herein, the set-up criteria may be consistent with global end-device objectives, such as energy conservation, message frame transmission success, sustained privacy and security, and other performance-related objectives.
In step 804, it is determined whether a set criterion is met (against which one or more terminal device operating parameters are checked). If the set criteria are met, processing proceeds to step 806. On the other hand, if the setting criterion is not satisfied, the process ends.
In step 806, one or more terminal device configuration parameters are adjusted when it is determined (in step 804) that the one or more terminal device operating parameters meet the set criteria. In one or more embodiments disclosed herein, a terminal device configuration parameter may be a control variable that may affect the operation of the terminal device. Further, in one or more embodiments disclosed herein, one or more configuration parameters may be adjusted to keep terminal device operation consistent with global terminal device goals (as described above). Examples of terminal device configuration parameters include, but are not limited to, radio frequency channel and data rate (which may affect communication range, message duration, and battery life). In one or more other embodiments disclosed herein, one or more dynamic setting criteria may be adjusted in response to the determination (of step 804). The above adjustments to the configuration parameters or set criteria may be used to optimize terminal device operation.
Fig. 9 shows a flow diagram depicting a method for optimizing network operation management according to one or more embodiments disclosed herein. In one or more embodiments disclosed herein, the following method may be performed exclusively by a network host.
In step 900, one or more network operating parameters are monitored. In one embodiment disclosed herein, the network operating parameter may be any performance metric derived from one or more observable/measurable physical characteristics (as described above). The metrics may describe qualitative information such as thresholds, constraints, ranges, durations, maxima, minima, and averages. Examples of network operating parameters as performance metrics include, but are not limited to, bandwidth availability, traffic level, packet loss, relative link load, latency, throughput, end-to-end delay, jitter, and other existing network performance measurements/metrics.
In step 902, one or more network operating parameters (monitored in step 900) are checked against set criteria. In one embodiment disclosed herein, the set-up criteria may include static conditions or specifications that may have been provided during initial deployment of the network. In another embodiment disclosed herein, the set criteria may include dynamic conditions or criteria, which may change with, for example, software/firmware updates, and self-improvement/learning schemes. In one or more embodiments disclosed herein, the set-up criteria may be in accordance with global network objectives, such as maximizing runtime and throughput, minimizing latency and error rates, and other network performance related objectives.
In step 904, it is determined whether set criteria (against which one or more network operating parameters are checked) are met. If the set criteria are met, processing proceeds to step 906. On the other hand, if the setting criterion is not satisfied, the process ends.
In step 906, one or more network configuration parameters are adjusted when it is determined (in step 904) that the one or more network operating parameters meet the set criteria. In one or more embodiments disclosed herein, a network configuration parameter may be a control variable that may affect network operation. Further, in one or more embodiments disclosed herein, one or more network configuration parameters may be adjusted to keep network operations consistent with global network objectives (as described above). In one or more other embodiments disclosed herein, one or more dynamic setting criteria may be adjusted in response to the determination (of step 904). The above adjustments to network configuration parameters or set criteria may be used to optimize network operation.
In step 908, adjustments to network configuration parameters or set criteria may be translated into instructions/commands that require terminal device compliance. For example, a network host may adjust some set of network configuration parameters or set criteria to set an upper limit on the amount of load that the network may experience at any given time. In one embodiment disclosed herein, adjustments may be performed to prevent network capacity overload, which may result in data collisions and frame loss. Subsequently, when applying these countermeasures, the network host may formulate instructions that require the end device to comply in order to maintain the load on the network within tolerances. In an example, the instructions may include instructing the terminal devices to adjust their data rates, transmit powers, repetition rates, radio frequency channels, or a combination thereof.
In performing step 908, one or more configuration update messages are generated. In one or more embodiments disclosed herein, the configuration update message may be at least a portion of a set of instructions or computer readable program code executable by the terminal device. In one embodiment disclosed herein, the configuration update message may target a subset of the device group (i.e., a set of end devices operatively (or communicatively) connected to the network host). In another embodiment disclosed herein, the configuration update message may target an entire device cluster. Further, in one embodiment disclosed herein, the configuration update messages may each include the same global instructions. In another embodiment disclosed herein, the configuration update messages may each include unique instructions specific to the following terminal devices: the configuration update message is targeting the terminal device. Further, in one or more embodiments disclosed herein, the configuration update message may include an identifier for one or more terminal device configuration parameters, and one or more corresponding settings associated with the terminal device configuration parameters.
In step 910, a configuration update message (generated in step 908) is sent to one or more terminal devices. In one embodiment disclosed herein, a configuration update message may be sent to one or more terminal devices as necessary to achieve optimization of network operation. The network host may include the following functions: the determination of which terminal devices to target is based on being able to track or consolidate the current state of each terminal device in the device group.
Embodiments of the present disclosure may be implemented on a computing system. Any combination of mobile devices, desktop computers, servers, routers, switches, embedded devices, or other types of hardware may be used. For example, as shown in fig. 10A, a computing system (1000) may include one or more computer processors (1002), non-persistent storage (1004) (e.g., volatile storage such as Random Access Memory (RAM), cache memory), persistent storage (1006) (e.g., a hard disk, an optical drive such as a Compact Disc (CD) drive or Digital Versatile Disc (DVD) drive, flash memory, etc.), a communication interface (1012) (e.g., a bluetooth interface, an infrared interface, a network interface, an optical interface, etc.), and many other elements and functions.
The computer processor (1002) may be an integrated circuit for processing instructions. For example, a computer processor may be one or more cores or micro-cores of a processor. Computing system 4) may also include one or more input devices (1010), such as a touch screen, keyboard, mouse, microphone, touch pad, electronic pen, or any other type of input device.
Communication interface (1012) may include integrated circuitry for connecting computing system (1000) to a network (not shown), e.g., a Local Area Network (LAN), a Wide Area Network (WAN) such as the internet, a mobile network, or any other type of network, or another device, such as another computing device.
Further, the computing system (1000) may include one or more output devices (1008), such as a screen (e.g., a Liquid Crystal Display (LCD), a plasma display, a touch screen, a Cathode Ray Tube (CRT) monitor, a projector, or other display device), a printer, an external storage device, or any other output device. The one or more output devices may be the same or different from the input devices. The input and output devices may be connected locally or remotely to the computer processor (1002), non-persistent storage (1004), and persistent storage (1006). Many different types of computing systems exist, and the aforementioned input and output devices may take other forms.
Software instructions in the form of computer-readable program code for performing embodiments of the present disclosure may be stored, in whole or in part, temporarily or permanently on a non-transitory computer-readable medium, such as a CD, DVD, storage device, diskette, tape, flash memory, physical memory, or any other computer-readable storage medium. In particular, the software instructions may correspond to computer readable program code which, when executed by a processor, is configured to perform one or more embodiments of the present disclosure.
The computing system (1000) in fig. 10A may be connected to or part of a network. For example, as shown in fig. 10B, the network (1020) may include a plurality of nodes (e.g., node X (1022), node Y (1024)). Each node may correspond to a computing system such as that shown in fig. 10A, or a combined set of nodes may correspond to the computing system shown in fig. 10A. By way of example, embodiments of the present disclosure may be implemented on a node of a distributed system connected to other nodes. As another example, embodiments of the present disclosure may be implemented on a distributed computing system having multiple nodes, where each portion of the present disclosure may be located on a different node within the distributed computing system. Further, one or more elements of the computing system (1000) described above may be located at a remote location and connected to the other elements over a network.
Although not shown in fig. 10B, the nodes may correspond to blades in a server chassis, the blades being connected to other nodes via a backplane. As another example, a node may correspond to a server in a data center. As another example, a node may correspond to a computer processor or a micro-core of a computer processor having shared memory or resources.
Nodes (e.g., node X (1022), node Y (1024)) in the network (1020) may be configured to provide services to the client device (1026). For example, the node may be part of a cloud computing system. The node may include functionality to receive requests from client devices (1026) and to send responses to client devices (1026). The client device (1026) may be a computing system, such as the computing system shown in FIG. 10A. Further, client device (1026) may include or perform all or a portion of one or more embodiments of the present disclosure.
The computing system or group of computing systems described in fig. 10A and 10B may include functionality to perform various operations disclosed herein. For example, the computing system(s) may perform communication between processes on the same or different systems. Various mechanisms that employ some form of active or passive communication may facilitate the exchange of data between processes on the same device. Examples of communication among these processes include, but are not limited to, the implementation of files, signals, sockets, message queues, pipelines, semaphores, shared memory, message passing, and memory mapped files. Further details regarding a few of these non-limiting examples are provided below.
Based on the client-server networking model, sockets can serve as interfaces or communication channel endpoints that enable bi-directional data transfer between processes on the same device. First, after the client-server networking model, a server process (e.g., a process that provides data) may create a first socket object. The server process then binds the first socket object, thereby associating the first socket object with a unique name or address. After creating and binding the first socket object, the server process then waits and listens for incoming connection requests from one or more client processes (e.g., processes that look up data). At this point, the client process begins by creating a second socket object when the client process wishes to obtain data from the server process. The client process then proceeds to generate a connection request that includes at least the second socket object and the unique name or address associated with the first socket object. The client process then transmits a connection request to the server process. Depending on availability, the server process may accept the connection request, establishing a communication channel with the client process, or the server process may be busy handling other operations, the connection request may be queued in a buffer until the server process is ready. The established connection informs the client process that communication can begin. In response, the client process may generate a data request specifying that the client process wishes to obtain. The data request is then transmitted to the server process. Upon receiving a data request, the server process analyzes the request and collects the requested data. Finally, the server process then generates a reply that includes at least the requested data and sends the reply to the client process. More generally, data may be transmitted as datagrams or character streams (e.g., bytes).
Shared memory refers to a mechanism for allocation of virtual memory space in order to verify that multiple processes can transfer or access data. When implementing shared memory, the initialization process first creates shareable segments in persistent or non-persistent memory. After creation, the initialization process then installs the shareable segment, which is then mapped into the address space associated with the initialization process. After installation, the initialization process continues to identify and grant access to one or more authorization processes that may also write data to and read data from the shareable segment. Changes made by one process to data in a shareable segment may immediately affect other processes that are also linked to the shareable segment. Further, when one of the authorized processes accesses the shareable segment, the shareable segment maps to the address space of the authorized process. In general, at any given time, only one authorization process may install shareable segments in addition to the initialization process.
Other techniques may be used to share data between processes, such as the various data described in this application, without departing from the scope of this disclosure. These processes may be part of the same or different application programs and may execute on the same or different computing systems.
In addition to, or instead of, sharing data between processes, a computing system performing one or more embodiments of the present disclosure may include functionality to receive data from a user. For example, in one or more embodiments, a user may submit data via a Graphical User Interface (GUI) on a user device. Data may be submitted via the GUI by a user selecting one or more GUI widgets or inserting text and other data into the GUI widgets using a touchpad, keyboard, mouse, or any other input device. In response to selecting a particular item, information about the particular item may be obtained by the computer processor from persistent or non-persistent storage. After the user selects an item, the content of the obtained data about the particular item may be displayed on the user device in response to the user's selection.
As another example, a request to obtain data about a particular item may be sent to a server operatively connected to the user device over a network. For example, a user may select a Uniform Resource Locator (URL) link within a web client of a user device to initiate a hypertext transfer protocol (HTTP) or other protocol request that is sent to a network host associated with the URL. In response to the request, the server may extract data about the particular selected item and send the data to the device that initiated the request. Once the user device has received data about a particular item, the content of the received data about the particular item may be displayed on the user device in response to a selection by the user. Further to the above example, the data received from the server after selection of the URL link may provide a web page in hypertext markup language (HTML) form that may be rendered by a web client and displayed on the user device.
Once the data is obtained, such as by using the techniques described above or from a storage device, the computing system may extract one or more data items from the obtained data when performing one or more embodiments of the present disclosure. For example, the extraction may be performed by the computing system in FIG. 10A as follows. First, an organization scheme (e.g., syntax, schema, layout) of the data is determined, which may be based on one or more of the following: location (e.g., bit or column location, nth token in a data stream, etc.), attribute (where an attribute is associated with one or more values), or hierarchical/tree structure (consisting of different levels of detail of a level of nodes, such as in nested packet headers or nested document portions). The original, unprocessed stream of data symbols is then parsed into a stream of tokens (or hierarchy) (where each token may have an associated token "type") in the context of an organizational schema.
Next, one or more data items are extracted from the token stream or structure using extraction criteria, where the extraction criteria are processed according to an organizational schema to extract one or more tokens (or nodes from the hierarchy). For location-based data, a token is extracted at a location identified by the extraction criteria. For attribute/value based data, tokens or nodes associated with attributes that satisfy the extraction criteria are extracted. For hierarchical/layered data, tokens associated with nodes matching the extraction criteria are extracted. The extraction criteria may be as simple as an identifier string, or may be a query presented to a structured data warehouse (where the data warehouse may be organized according to a database schema or data format, such as XML).
The extracted data is available for further processing by the computing system. For example, the computing system of fig. 10A may perform the data comparison while performing one or more embodiments of the present disclosure. The data comparison may be used to compare two or more data values (e.g., A, B). For example, one or more embodiments may determine that A > B, A B, A! B, a < B, etc. The comparison may be performed by submitting A, B, and an opcode specifying an operation related to the comparison, into an Arithmetic Logic Unit (ALU), i.e., a circuit that performs an arithmetic or bitwise logical operation on the two data values. The ALU outputs a numeric result of an operation or one or more status flags associated with the numeric result. For example, the status flag may indicate whether the numeric result is a positive number, a negative number, zero, or the like. The comparison may be performed by selecting the appropriate opcode and then reading the numeric result or status flag. For example, to determine A > B, B may be subtracted from A (i.e., A-B), and the status flag may be read to determine if the result is positive (i.e., if A > B, A-B > 0). In one or more embodiments, B may be considered a threshold, and if a ═ B or if a > B, a is deemed to satisfy the threshold, as determined using an ALU. In one or more embodiments of the present disclosure, a and B may be vectors, and comparing a to B requires comparing a first element of vector a to a first element of vector B, comparing a second element of vector a to a second element of vector B, and so on. In one or more embodiments, if A and B are strings, the binary values of the strings may be compared.
The computing system in FIG. 10A may be implemented or connected to a data store. For example, one type of data store is a database. A database is a collection of information configured to facilitate data retrieval, modification, reorganization, and deletion. A database management system (DBMS) is a software application that provides a user with an interface to define, create, query, update, or manage a database.
A user or software application may submit a statement or query to the DBMS. The DBMS then interprets the statement. The statement may be a select statement, an update statement, a create statement, a delete statement, etc. requesting information. Further, a statement may include a specification of data or data containers (databases, tables, records, columns, views, etc.), identifiers, conditions (comparison operators), functions (e.g., join, full join, count, average, etc.), orderings (e.g., rise, fall), or other parameters. The DBMS may execute the statement. For example, the DBMS may access a memory buffer, a reference or index to a file for reading, writing, deleting, or any combination thereof, in response to the statement. The DBMS may load data from persistent or non-persistent memory and perform computations in response to queries. The DBMS may return the results to the user or software application.
The computing system of FIG. 10A may include functionality to present raw or processed data, such as results of comparisons and other processing. For example, presenting data may be accomplished through various presentation methods. In particular, the data may be presented through a user interface provided by the computing device. The user interface may include a GUI that displays information on a display device, such as a computer monitor or a touch screen on a handheld computer device. The GUI may include various GUI widgets that organize what data is shown and how the data is presented to the user. Further, the GUI may present the data directly to the user, e.g., through text as the actual data value, or by the computing device as a visual representation of the data, e.g., through a visual data model.
For example, the GUI may first obtain a notification from a software application requesting that a particular data object be presented within the GUI. Next, the GUI may determine the data object type associated with a particular data object, for example, by retrieving data from a data attribute within the data object that identifies the data object type. The GUI may then determine any rules that are specified for displaying the data object type, for example, rules specified by the software framework for the data object class, or rules specified according to any local parameters defined by the GUI for rendering the data object type. Finally, the GUI may obtain data values from particular data objects and present visual representations of the data values within the display device according to specified rules for the type of data object.
Data may also be presented by various audio methods. In particular, the data may be presented in an audio format and as sound through one or more speakers operatively connected to the computing device.
Data may also be presented to the user by tactile methods. For example, haptic methods may include vibrations or other physical signals generated by a computing system. For example, a vibration generated by the handheld computer device having a predefined vibration duration and intensity may be used to present data to the user for transmission of the data.
The above description of functions presents only a few examples of functions performed by the computing system of fig. 10A and the nodes and/or client devices in fig. 10B. Other functions may be performed using one or more embodiments of the present disclosure.
While the present disclosure has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will now appreciate that other embodiments can be devised which do not depart from the scope of the disclosure as disclosed herein. Accordingly, the scope of the present disclosure should be limited only by the attached claims.
Mobile devices with radio communication typically send messages upstream periodically and aperiodically in order to send data to some application backend service using some network infrastructure (shortly, network) operated by some network operator for message forwarding (see, e.g., fig. 11). In some cases, the communication is unidirectional, i.e., the device never receives messages downstream from the application backend service, but only sends different types of data upstream to the application backend service. In other cases, the device and application backend exchange upstream and downstream messages. Thus, the data sent upstream may be, for example, sensor readings such as temperature, humidity, acceleration, or GPS location. The downstream data may be actuator commands or device settings.
In order for the backend application to correctly associate the device as the source of the received data, the upstream message may typically contain (in close proximity to the actual application payload) some unique device address, often referred to as a header, possibly in combination with some unique network address and metadata (e.g., sequence counter and flag). It should be noted that the values of some fields of the header are fixed, while the values of other fields may vary according to some algorithm (e.g., simple increment) or based on some device or environment state. For integrity checking, the message may also include some cryptographic Message Integrity Code (MIC), commonly referred to as a trailer.
In a radio infrastructure, such as a Low Power Wide Area Network (LPWAN) based on the LoRaWAN protocol specification, the header and trailer are typically sent in clear (unencrypted), so that the radio infrastructure can forward upstream messages to intended receivers based on unique device addresses and certain owner relationships between the device and certain application back-ends set forth during the provisioning of the device. It should be noted that the network operator controlling the network infrastructure may thus be an entity different from the application owner, as is often the case for a large-scale multi-tenant radio infrastructure operated by a single network operator and used by many application owners.
For example, in LoRaWAN, a device sends an upstream message that most of its code is as follows (see fig. 12):
the integrity of the entire header and payload is protected by the MIC as a trailer, but only the frame payload is encrypted. The MIC is computed cryptographically by the sending device and verified by the network with a device-specific network key known only to the device and the network. The frame payload is encrypted by the device with a device-specific application key known only to the device and the application owner, i.e. only the application owner can decrypt the application data received from the device.
Now, since the radio transmission can usually be listened to by an eavesdropper while in the air, the unencrypted header and trailer must be considered as public information. Thus, a mobile device can be tracked and geo-located with some accuracy by simply listening to its upstream messages and checking transmission metadata, such as the wireless signal strength indicator (RSSI) or signal-to-noise ratio (SNR) of the transmitted message. If the device is attached to a person or some item, the person or item may be involuntarily tracked by some third party.
Note that: the present disclosure uses the LoRaWAN protocol only for illustration and clarification of the problems solved and the solutions proposed. The present disclosure itself is in no way limited to the LoRaWAN protocol or LoRaWAN LPWAN infrastructure.
As a countermeasure, the header must be replaced with a constantly changing pseudo-randomly masked header, which can only be associated by the network infrastructure with the actual device and not with any eavesdropper. If the tail only includes pseudo-random data like the MIC, it may not need further pseudo-randomization; otherwise, the same scheme as described below for the head can also be applied to the tail.
For head pseudo-randomization, the devices are personalized during production with an additional device-specific blinding key, which may also be set to be known to the network together with the device address and the device-specific network key. Now, instead of sending the header in clear, the device uses the blinded key pair Mask/i-iA pseudo-random blinding Mask/i is calculated for each message i using cryptographic operations, whereby Mask/o is the initial header of the device. Therefore, the minimum length of the blinding mask is equal to the length of the header. The header of message i is then exclusive-ored with Mask/i and the currently masked header replaces the header of the message (see fig. 13). As a specific example, the blinding key may be an AES key,and by using Mask/i with blinded key pair-iThe AES cipher operation performed to derive Mask/i.
In order to correctly identify the device sending the upstream message with the masked header, the network does the same and pre-computes the candidate header for the next expected message for its overall device group. If the conflicting changes are negligible for all practical purposes, the network may identify the sending device by comparing the fixed field of the received masked header with the fixed field of the pre-computed candidate header. The network then replaces the masked header with the unmasked header by again xoring the masked header with the mask of the correctly identified candidate header before forwarding the message to the application owner. In this way, the blinding is transparent to the application owner.
In general, with very low probability, it may happen that the fixed field of the masked header is equal to the fixed field of the candidate headers of multiple devices. In this case, the headers must be unmasked one by one for all those devices, and the MIC is verified. The device is uniquely identified if one and only one MIC is verified. If this is a very low probability beyond the MIC verification, the message cannot be reconstructed and will be discarded. Since the radio scheme already operates assuming sporadic message loss, there is no real implication of discarding a single message if it is limited to a very rare occasion. It should also be noted that the MIC must always be verified to ensure the integrity of the message, even if only a single candidate header is identified.
For some applications, the device may also choose to send any upstream message multiple times, possibly even on different channels, to increase the likelihood of at least one successful transmission. In this case, the blinding mask is also pushed for each retransmission, which again significantly reduces the probability of upstream messages being unrecoverable due to the blinding key.
As mentioned above, radio communications are prone to message loss due to interference or collisions in the radio spectrum. While some network infrastructures ensure message delivery by using acknowledgements and retransmissions, this is not practical for most LPWAN environments such as LoRaWAN. To compensate for the missing uplink message, the network will pre-compute not only the next blinded header, but also the range of n next blinded header candidates. Thus, it can handle up to n-1 messages that are lost in succession. Even after that, it may attempt resynchronization by calculating additional masked head candidates based on historical message upstream pattern recognition by considering that most devices send periodically and identifying the most likely device, although this operation may become very expensive and the device will then be considered lost.
To prevent a device from being lost in the case of n + m (m ≧ 0) consecutive lost messages, the network can periodically resynchronize its blinded state to the blinded state of the device. To do so, the device will have to periodically send a separate message with an unmasked header. When the network receives such an unmasked header, it may resynchronize its state with the device blinded state and mask the future header again. Thus, ideally, the unmasked header should be transmitted at intervals that make it highly unlikely that an eavesdropper will receive multiple unmasked headers per device.
Note that: it is not possible to simply encrypt the header because it typically includes some variable fields that, although being changed or included only occasionally, may still allow an eavesdropper to infer the identity of the sending device. Generally, for encryption, a single flipped bit in the plaintext tends to flip about 50% of the bits in the encrypted text that is spread over the encrypted text as a whole. Thus, the device address of the mask as part of the header can no longer be pre-computed by the network, since the network is generally unable to predict the value of the variable field.
Although the scheme derived above works for upstream-only devices, it can be applied to devices capable of two-way communication and downstream messages that also have some reservations.
First, if a device requests the network infrastructure to acknowledge receipt of an upstream message, such an acknowledgement may only be sent after the MIC has been successfully verified. Otherwise, in rare cases, an acknowledgement will be sent even if the message is not recoverable due to the mask. The retransmission again pushes the mask.
Secondly, the scheme may also be applied to downstream messages using the same or a second blinding key. Although the computational load on the device is a bit higher for two reasons: (1) the device must try a set of potential candidate headers for de-masking and verifying the MIC; (2) a device can only discard messages of other devices after trying all candidates. In the case of LoRaWAN, reason (2) does not occur often because the device only listens to downstream messages very sporadically, but depending on the radio scheme used and the particular application constraints (e.g., battery life), this may be a problem.
Third, depending on the number of upstream messages, it may be advisable to replace the blinding key from time to time. This may be done when the device and/or the network decides to renegotiate its device-specific session key, or independently. This will also prevent a device from being lost due to n + m consecutive missing upstream messages if the renegotiation is done in such a way that the masked state of the device is also renegotiated after the device specific session key. In LoRaWAN, a device can simply rejoin the network over the air.
As mentioned above, in order to properly unmask upstream messages, in principle the network must pre-compute a possible number of candidate headers for each device for its entire device population. For devices that transmit in some predictable pattern, and as these patterns are either made known to the network in advance or learned over time by the network itself, the network may limit its search for the transmitting device to a possible set of candidates. If no devices can be identified within the candidate set, or the MIC does not verify the identified candidates (possibly due to highly unlikely but still possible collisions as previously described), the network must broaden its search.
The full blinding header clearly prevents the device from roaming unless the blinded state of the device is to be shared with the roaming network infrastructure. Alternatively, if the header, as in LoRaWAN, includes the network identifier of the home network, the network identifier may remain in the clear (not blinded) so that the roaming network may simply forward the message to the home network based on the network identifier. Privacy is still maintained unless the number of roaming devices from the same network is small.
Although the blinded header eliminates the most obvious source for identifying messages sent by the same device, the sending behavior of the device may still reveal its identity with some probability due to other (almost) unique patterns in the device's communication. Messages may be sent strictly periodically, with the same data rate, with the same transmit power, and with the same length throughout the same radio channel. To further increase the security, the device may compromise all these parameters pseudo-randomly by changing the transmission time by some pseudo-random positive or negative delay, adding some payload padding of pseudo-random length, pseudo-randomly hopping the channel, changing the data rate and adjusting the transmission power. The device may even disseminate purely randomized messages to be filtered at the application level, albeit at the cost of reduced battery life.
Finally, in addition to protecting privacy, the blinding header has the advantage of blinding the actual group of devices in the network or within a given area, since each device effectively acts as a different device for each upstream message. This may be a significant side effect for network operators who for various reasons do not want to reveal the number of devices within their networks to their competition.
- 上一篇：一种医用注射器针头装配设备
- 下一篇：芯片的访问方法、微芯片、智能卡以及调试设备