System and method for delegating ticket authentication to a star network in the internet of things and services

Abstract

A star topology network comprises a user device, a central gateway, and one or more sensor nodes added to the existing network. A communication between the user device and the central gateway is secured either based on public-key cryptography, symmetric-key cryptography, or by the use of a secure channel such as a wired communication. A request from the user device to the central gateway can be transmitted over the internet.

Claims

1. A star topology network comprising: a plurality of sensor nodes, each sensor node in the plurality of sensor nodes having a respective ID; a user device; and an internet-enabled central gateway in public-key cryptographic communication with the user device, wherein the user device is configured to: read the respective ID from a first sensor node in the plurality of sensor nodes; and generate a ticket by signing a first message with a private key and encrypting the first message with a public key of the central gateway, the first message including the respective ID of the first sensor node; wherein the first sensor node is configured to: generate a first random number; encrypt the first random number with a secret shared key that was exchanged with the central gateway; and transmit, to the central gateway, a second message including a concatenation of the ticket, the encrypted first random number, and a message authentication code, wherein the central gateway is configured to: decrypt the second message using the secret shared key that was exchanged with the first sensor node; and validate the ticket based on the decrypted second message, and wherein the central gateway is configured to: recover the first random number from the decrypted second message; generate a second random number; determine a first hash of the first random number concatenated with the respective ID of the first sensor node; encrypt a concatenation of the second random number with the first hash; and transmit, to the first sensor node, a third message including a concatenation of (i) the encrypted concatenation of the second random number with the first hash and (ii) a message authentication code.

2. The star topology network of claim 1, wherein the user device is configured to: broadcast the ticket to the plurality of sensor nodes.

3. The star topology network of claim 1, wherein the first sensor node is configured to: exchange a secret shared key with the central gateway after receiving the ticket from the user device.

4. The start topology network of claim 1, wherein the first sensor device is configured to: determine a second hash of the first random number concatenated with the respective ID of the first sensor node; decrypt the third message using the secret shared key that was exchanged with the central gateway; recover the second random number and the first hash from the decrypted third message; and validate the third message by comparing the recovered first hash with the determined second hash.

5. The start topology network of claim 4, wherein the first sensor device is configured to: determine a third hash of the second random number concatenated with the respective ID of the first sensor node; encrypt a concatenation of the first random number with the third hash; and transmit, to the central gateway, a fourth message including a concatenation of (i) the encrypted concatenation of the first random number with the third hash and (ii) a message authentication code.

6. The star topology network of claim 5, wherein the central gateway is configured to: determine a fourth hash of the second random number concatenated with the respective ID of the first sensor node; decrypt the fourth message using the secret shared key that was exchanged with the first sensor node; recover the third hash from the decrypted fourth message; and validate the fourth message by comparing the recovered third hash with the determined fourth hash.

7. The star topology network of claim 1, wherein the user device is configured to: request a nonce from the central gateway; and receive the nonce from the central gateway, wherein the first message used to generate the ticket includes the nonce and the respective ID of the first sensor node.

8. A star topology network comprising: a plurality of sensor nodes, each sensor node in the plurality of sensor nodes having a respective ID; a user device; and an internet-enabled central gateway in public-key cryptographic communication with the user device; wherein the user device is configured to (i) read the respective ID from a first sensor node in the plurality of sensor nodes and (ii) generate a ticket by signing a first message with a private key and encrypting the first message with a public key of the central gateway, the first message including the respective ID of the first sensor node, wherein the first sensor node is configured to (i) encrypt a first random number with a secret shared key that was exchanged with the central gateway and (ii) transmit, to the central gateway, a second message including a concatenation of the ticket and the encrypted first random number, and wherein the central gateway is configured to (i) recover the first random number from the second message, (ii) determine a first hash of the first random number concatenated with the respective ID of the first sensor node, (iii) encrypt a concatenation of a second random number with the first hash, and (iv) transmit, to the first sensor node, a third message including the encrypted concatenation of the second random number with the first hash.

9. The star topology network of claim 8, wherein the user device is configured to: broadcast the ticket to the plurality of sensor nodes.

10. The star topology network of claim 8, wherein the first sensor node is configured to: exchange the secret shared key with the central gateway after receiving the ticket from the user device.

11. The start topology network of claim 8, wherein the first sensor node is configured to: generate the first random number; and transmit, to the central gateway, the second message including a concatenation of the ticket, the encrypted first random number, and a message authentication code.

12. The star topology network of claim 8, wherein the central gateway is configured to: decrypt the second message using the secret shared key that was exchanged with the first sensor node; and validate the ticket based on the decrypted second message.

13. The star topology network of claim 8, wherein the central gateway is configured to: generate the second random number; and transmit, to the first sensor node, a third message including a concatenation of (i) the encrypted concatenation of the second random number with the first hash and (ii) a message authentication code.

14. The start topology network of claim 13, wherein the first sensor device is configured to: determine a second hash of the first random number concatenated with the respective ID of the first sensor node; decrypt the third message using the secret shared key that was exchanged with the central gateway; recover the second random number and the first hash from the decrypted third message; and validate the third message by comparing the recovered first hash with the determined second hash.

15. The start topology network of claim 14, wherein the first sensor device is configured to: determine a third hash of the second random number concatenated with the respective ID of the first sensor node; encrypt a concatenation of the first random number with the third hash; and transmit, to the central gateway, a fourth message including a concatenation of (i) the encrypted concatenation of the first random number with the third hash and (ii) a message authentication code.

16. The star topology network of claim 15, wherein the central gateway is configured to: determine a fourth hash of the second random number concatenated with the respective ID of the first sensor node; decrypt the fourth message using the secret shared key that was exchanged with the first sensor node; recover the third hash from the decrypted fourth message; and validate the fourth message by comparing the recovered third hash with the determined fourth hash.

17. The star topology network of claim 8, wherein the user device is configured to: request a nonce from the central gateway; and receive the nonce from the central gateway, wherein the first message used to generate the ticket includes the nonce and the respective ID of the first sensor node.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) These and other features, aspects, and advantages of this disclosure will become better understood when the following detailed description of certain exemplary embodiments is read with reference to the accompanying drawings in which like characters represent like arts throughout the drawings, wherein:

(2) FIG. 1 is a flow diagram of a network comprising a user device and an internet-enabled central gateway; and

(3) FIG. 2 is a flow diagraph of another network comprising a sensor node coupled to the user device and the internet-enabled central gateway.

DETAILED DESCRIPTION

(4) The following description is presented to enable any person skilled in the art to make and use the described embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the described embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the described embodiments. Thus, the described embodiments are not limited to the embodiments shown, but are to be accorded the widest scope consistent with the principles and features disclosed herein.

(5) Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed and/or described operations may be omitted in additional embodiments.

(6) FIG. 1 is a flow diagram illustrating a network 100 comprises a user device D and a central gateway C communicating with the user device D. During an initialization phase 100, both the user device D and the central gateway C generate an unique public-private key pairs. The user device D may be a thin client, a thick client, a mobile phone, a tablet, a phablet, a laptop, a personal digital assistant (PDA), a personal computer (PC), or any suitable electronic devices. The central gateway C is an internet-enabled central gateway. The user device D issues a Certificate Signing Request (CSR) and sends the CSR to the central gateway C. The CSR includes a public key of the user device D. The central gateway C upon receiving the request generates a certificate. The communication between the user device D and the central gateway C is secured either based on public-key cryptography, symmetric-key cryptography, or by the use of a secure channel such as a wired communication.

(7) FIG. 2 is a flow diagram illustrating a network 200 comprises a user device D, a central gateway C, and at least one new sensor node S.sub.1 added to the existing network 200. Although one sensor node S.sub.1 is illustrated, more than one sensor node may be added to the network 200. For instance, in a home automation, more than 10 sensor nodes are connected to the network 200 for a relatively long period of time between several months and several years. The sensor node S.sub.1 may be actuators, sensing elements, or any suitable components that can connected to a star topology network. The initialization phase set up between the user device D and the central gateway C in FIG. 2 is similar to the initialization phase as illustrated in FIG. 1. In one embodiment, the user device D may be function as a ticket machine for emitting certified tickets which are personalized to individual sensor nodes. After the initialization phase is completed, the user device D sends a request for receiving a nonce n.sub.1 to the central gateway C. In some embodiments, the user device D may send a request for receiving a timestamps instead of random nonces n. Upon receiving the request, the central device C checks if the request was issued by a legitimate device, e.g. the user device D. If the request is valid or authenticated, the central gateway C replies to the user device D with nonce n.sub.1. Although one nonce n.sub.1 is generated, the central gateway C may generate a set of nonce n and then set the set of nonce n to the user device D once a secure communication link becomes available. Afterwards, a secure communication between the user device D and the central gateway C is no longer required. Consequently, the user device D holds a set of already certified tickets for adding new nodes n to the network 200 at any time. After some individual amount of time, but below a chosen expiration of n.sub.1, the user device D reads an ID of the node S.sub.1 to be added to the network 200. In one embodiment, the ID can be read directly from the node S.sub.1 via a secure communication interface. In some embodiments, the IDS can be read from the node S.sub.1 by scanning a barcode or a Quick Response (QR) code located either on the node S.sub.1 or on the node S.sub.1 accessory such as owner's manual, packages, any materials accompanying with the node S.sub.1 and so forth. In another embodiment, the user may receive the ID of the node S.sub.1 over an internet when the node S.sub.1 is purchased via an online store. In yet another embodiment, the sensor node with a specific ID can be added to an existing network wherein the ID is read off of a smart tag such as a RFID tag. In further yet another embodiment, the ID can be read from a Physically Unclonable Function (PUF) located on the sensor node. Once the ID of the node S.sub.1 is registered, the user device D generates a ticket y by signing a message (n.sub.1, ID(S.sub.1) with its private key PrK.sub.D and encrypting it with C′s public key PK.sub.C. Thereafter, the user device D broadcasts the ticket y or sends the ticket y to S.sub.1. After receiving y, the central gateway C and the node S.sub.1 start the key agreement procedure to exchange a secret shared key K.sub.CS=(K.sub.CS1∥K.sub.CS2). The key agreement can be done either by a public-key cryptography such as Diffic-Hellman key exchange protocol or any suitable physical layer security.

(8) After the shared key K.sub.CS has been exchanged between the node S.sub.1 and the central gateway C, the node S.sub.1 generates a random number r.sub.S1. Subsequently, the node S.sub.1 encrypts r.sub.S1 with K.sub.CS1 and sends a concatenation of y, E.sub.KCS1(r.sub.S1) and a message authentication code (MAC) to the central gateway C. Since the central gateway C can decrypt y, the central gateway C checks the validity of nonce n.sub.1 and if the ticket has been signed by the trusted device D. If the central gateway C is a legitimate gateway, the central gateway C receives acknowledgement of ID(S.sub.1). Using the established key K.sub.CS1, the central gateway C decrypts y.sub.2 thereby obtaining the random number r.sub.S1. Then, the central gateway C concatenates r.sub.S1 and the ID of the node S.sub.1 to be added to the existing network 200, i.e. ID(S.sub.1), and computes a hash h(r.sub.S1, ID(S.sub.1)) of the concatenated value. The central gateway C then generates a random number r.sub.C, concatenates the random number r.sub.C with a hash value and sends the message y.sub.3=E.sub.KCS1(r.sub.S1(r.sub.S1,ID(S.sub.1)))∥MAC.sub.KCS2 (y.sub.3) to the node S.sub.1. Upon receiving the message y.sub.3, node S.sub.1 decrypts the message y.sub.3, thereby obtaining the random number r.sub.C and the hash value h(r.sub.S1,ID(S.sub.1)). Since node S.sub.1 knows the random number r.sub.S1, node S.sub.1 can compute the hash value and compare it to the received has value. If the values are identical, the response of the central gateway C to the challenge r.sub.S1 is valid.

(9) Next, the node S.sub.1 takes the random number r.sub.C generated by the central gateway C and computes the hash h(r.sub.c,ID(S.sub.1)). The node S.sub.1 concatenates the hash value with the random number r.sub.S1 and sends the message y.sub.3=E.sub.k(r.sub.C,h(r.sub.c,ID(S.sub.1)), r.sub.S1)∥MAC.sub.KCS2 (y.sub.4) to the central gateway C. Upon receiving the message, the central gateway C decrypts the message and verifies that the hash value h(r.sub.c,ID(S.sub.1) returned by the node S.sub.1 for the challenge re is equal to the hash value locally computed by the central gateway C. Finally, if the received and the computed hash values are identical, the central gateway C sends a message to the user device D indicating that the new node S.sub.1 is successfully added to the network 200. In one embodiment, the time between the request to add a new sensor node S.sub.1 to an existing network 200 and the start of the key agreement can be limited by an upper bound t.sub.max such that the new node S.sub.1 can only be added within a small period of time.

(10) In some embodiments, the hash function h can be replaced by some function ƒ that takes a random number and the Id of the node S.sub.1 as an input. For instance, ƒ can be a function that takes an n-bit random number and the first half of an 2n-bit ID(S) and returns an XOR of these.

(11) According to another aspect of the disclosure, if the communication between the user device D and the central gateway C is a symmetric-key cryptography, instead of signing the message with its private key, the user device D can calculate a MAC on the nonce n using a shared key between the user device D and the central gateway C, i.e. K.sub.DC.

(12) The embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling with the sprit and scope of this disclosure.

(13) Embodiments within the scope of the disclosure may also include non-transitory computer-readable storage media or machine-readable medium for carrying or having computer-executable instructions or data structures stored thereon. Such non-transitory computer-readable storage media or machine-readable medium may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such non-transitory computer-readable storage media or machine-readable medium can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. Combinations of the above should also be included within the scope of the non-transitory computer-readable storage media or machine-readable medium.

(14) Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network.

(15) Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

(16) While the patent has been described with reference to various embodiments, it will be understood that these embodiments are illustrative and that the scope of the disclosure is not limited to them. Many variations, modifications, additions, and improvements are possible. More generally, embodiments in accordance with the patent have been described in the context or particular embodiments. Functionality may be separated or combined in blocks differently in various embodiments of the disclosure or described with different terminology. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure as defined in the claims that follow.