Communication method, system and storage medium for shared key

Abstract

The present application provides a communication method, system and storage medium for a shared key, wherein the communication method for a shared key includes: the IoT trust anchor device establishes a trust relationship with the restricted IoT device; the server communicates and connects with the IoT trust anchor device, and obtains a first temporary shared key and a link random number for accessing the restricted IoT device through the IoT trust anchor device; the server establishes a communication connection with the restricted IoT device based on the first temporary shared key, the link random number and the PSK_DTLS protocol. The present application can reduce the memory and ROM occupancy rate of the restricted IoT device, improve the security of the key, and reduce the performance requirements of the restricted IoT device in the process of achieving end-to-end secure connection based on symmetric keys.

Description

Technical Field

[0001] The present application relates to the field of Internet of Things communication technology, and in particular to a communication method, system and storage medium for sharing a key. Background Art

[0002] The development of 5G networks, low-power local / wide area wireless network technologies and corresponding IP technologies has rapidly promoted the emergence of a new type of application network - the Internet of Things. In the Internet of Things, a new type of networked devices with highly limited computing power, memory resources, and power supply capabilities have emerged. These devices can be connected to the Internet of Things (IoT) based on the IP protocol, but IoT devices with limited resources are limited IoT devices.

[0003] Specifically, in resource-constrained IoT, constrained IoT devices have the following characteristics: low computing / storage resources, battery-powered and low-power short-range wireless network connections, IP network technology, and deployment in an open environment without physical protection; a group of IoT devices deployed in the same area to achieve specific tasks constitute an IoT LAN; IoT gateways are used to connect different networks or heterogeneous networks, and the IoT LAN is connected to the enterprise LAN or servers on the Internet; servers and enterprise LANs are in a protected environment with physical protection. The use of IP technology enables constrained IoT devices to communicate with other constrained IoT devices or services located in remote network domains in an end-to-end manner. For example, IP-enabled sensor devices built into the body can transparently send the medical data of patients they collect to the electronic health server without any application layer interaction at the IoT gateway.

[0004] However, in this case, the transmitted information may be routed through untrusted network infrastructure (e.g., the Internet) or wireless local area networks (e.g., Bluetooth networks). Therefore, in resource-constrained IoT, providing peer authentication and end-to-end data protection are key requirements to prevent eavesdropping on sensitive information or malicious triggering of harmful execution tasks.

[0005] In order to provide end-to-end secure connections in the Internet of Things (IoT), variants of traditional end-to-end IP security protocols, such as DTLS, minimal IKEv2, etc., have been proposed for use in constrained IoT. All of these protocol variants consider public key cryptography in their protocol design. The use of public key cryptography in constrained IoT environments has the following disadvantages: it generates a lot of processing and transmission overhead, requires a large amount of RAM and ROM for implementation, and consumes a lot of energy. Therefore, constrained IoT devices mostly use symmetric key technology to provide end-to-end secure connections.

[0006] Currently, there are two ways to provide end-to-end secure connections using symmetric key technology, namely DTLS (Datagram Transport Layer Security), Kerberos, and Kerberos-like methods. However, the DTLS method has the following defects: (1) The communicating parties need to securely deploy symmetric key information on the communication endpoints before establishing a DTLS connection; (2) The restricted IoT device needs to know all the clients that may communicate with it and share keys with them before deployment. In particular, when the clients that communicate with the restricted IoT device cannot be determined in advance, it is a very unsafe method to disclose the pre-shared password of the restricted IoT device to all potential clients that may communicate with it.

[0007] On the other hand, Kerberos and Kerberos-like methods have the following disadvantages: (1) The Kerberos client protocol needs to be implemented on the restricted IoT device, which is complex to implement and will still occupy a large amount of memory and ROM of the restricted IoT device; (2) The number of transmitted messages is large and the messages are long, which consumes a lot of IoT network bandwidth and power. Summary of the invention

[0008] The purpose of the embodiments of the present application is to provide a communication method, system and storage medium for sharing a key, which are used to reduce the memory and ROM occupancy rate of restricted IoT devices, improve the security of keys, and reduce the performance requirements of restricted IoT devices in the process of achieving end-to-end secure connection based on symmetric keys.

[0009] To this end, the first aspect of the present application discloses a communication method based on a shared key, the method applies the communication system based on a shared key, the system includes a restricted IoT device, an IoT trust anchor device, and a server, and the method includes:

[0010] The IoT trust anchor device establishes a trust relationship with the restricted IoT device;

[0011] The server is in communication connection with the IoT trust anchor device, and obtains a first temporary shared key and a link random number for accessing the restricted IoT device through the IoT trust anchor device;

[0012] The server establishes a communication connection with the restricted IoT device based on the first temporary shared key, the link random number, and the PSK_DTLS protocol.

[0013] In the first aspect, as an optional implementation manner, the IoT trust anchor device establishes a trust relationship with the restricted IoT device, including:

[0014] The restricted IoT device stores a master symmetric key;

[0015] The IoT trust anchor device generates a first data table for storing information of the restricted IoT device, where the information of the restricted IoT device includes a master symmetric key, an ID of the restricted IoT device, and an IP address of the restricted IoT device;

[0016] The IoT trust anchor device responds to the certificate deployment instruction to store the certificate information;

[0017] The IoT trust anchor device generates a second data table, where the second data table is used to store server permission information that allows access to the restricted IoT device.

[0018] In the first aspect, as an optional implementation, the server permission information includes the ID of the accessible server, the access account, the access password, and the ID of the restricted IoT device that the server is allowed to access.

[0019] In the first aspect, as an optional implementation, the server is communicatively connected with the IoT trust anchor device, and obtains a first temporary shared key and a link random number for accessing the restricted IoT device through the IoT trust anchor device, including:

[0020] The server establishes a TLS secure connection with the IoT trust anchor device;

[0021] The server and the IoT trust anchor device perform mutual authentication based on the certificate information and the certificate mechanism;

[0022] When the server authentication is passed and the IoT trust anchor device authentication is passed, the server sends a key acquisition request to the IoT trust anchor device, where the key acquisition request carries the ID of the server and the ID of the restricted IoT device;

[0023] The IoT trust anchor device determines, based on the ID of the server and the second data table, whether the server has permission to access the restricted IoT device;

[0024] When the server has permission to access the restricted IoT device, the IoT trust anchor device reads the serial number of the restricted IoT device based on the first data table;

[0025] The IoT trust anchor device generates the first temporary shared key and the link random number based on the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device and the preset key length;

[0026] The IoT trust anchor device sends the first temporary shared key and the link random number to the server;

[0027] The server saves the first temporary shared key and the link random number based on the ID of the restricted IoT device.

[0028] In the first aspect, as an optional implementation, the initial value of the serial number of the restricted IoT device is 0;

[0029] And, after the IoT trust anchor device sends the first temporary shared key and the link random number to the server, the method further includes:

[0030] The IoT trust anchor device updates the serial number of the restricted IoT device.

[0031] In the first aspect, as an optional implementation, the IoT trust anchor device generates the first temporary shared key and the link random number based on the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device and the preset key length, including: encoding the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device and the preset key length based on a BASE64 encoder to generate the link random number;

[0032] Decoding the link random number based on a BASE64 decoder to obtain an ID of the first temporary shared key;

[0033] The Internet of Things trust anchor device uses the ID of the first temporary shared key and the master symmetric key as input parameters of the SHA256 algorithm, and obtains the first temporary shared key through the SHA256 algorithm.

[0034] In the first aspect, as an optional implementation, the server establishes a communication connection with the restricted IoT device based on the first temporary shared key, the link random number, and the PSK_DTLS protocol, including:

[0035] The server sends an authentication request to the restricted IoT device, where the authentication request carries the link random number;

[0036] The restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key, where the second temporary shared key and the first temporary shared key are symmetric keys;

[0037] The method further comprises establishing a communication connection with the restricted Internet of Things device based on the second temporary shared key and the first temporary shared key.

[0038] In the first aspect, as an optional implementation, after the server sends an authentication request to the restricted IoT device and before the restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key, the method further includes:

[0039] The restricted IoT device verifies whether the length of the link random number is within a preset length range;

[0040] When the length of the link random number is within a preset length range, the restricted IoT device decodes the link random number based on a Base64 decoder and obtains decoding information;

[0041] The restricted IoT device determines whether the length of the decoded information is equal to a preset length threshold;

[0042] When the length of the decoded information is equal to the preset length threshold, the restricted IoT device compares the decoded information with the information of the restricted IoT device to verify whether the decoded information is correct;

[0043] When the decoded information is verified to be correct, the restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key.

[0044] The second aspect of the present application discloses a communication system based on a shared key, the communication system based on a shared key, the system comprising a restricted Internet of Things device, an Internet of Things trust anchor device, and a server, wherein the server establishes a communication connection with the restricted Internet of Things device through the method of the first aspect of the present application.

[0045] The third aspect of the present application discloses a storage medium, which stores computer instructions. When the computer instructions are called, they are used to execute the communication method based on a shared key of the first aspect of the present application.

[0046] Compared with the prior art, the beneficial technical effects of this application are:

[0047] The embodiment of the present application can share keys only between the restricted IoT device Di and the IoT trust anchor device TA it trusts through the trust relationship between the IoT trust anchor device and the restricted IoT device. The restricted IoT device Di can achieve end-to-end secure communication based on PSK-DTLS between the restricted IoT device Di and any server S without sharing the password with the server S. The shared key is only used to generate a temporary shared key and is not transmitted on the network. In this way, the security of the shared key can be improved. On the other hand, the present application makes little modification to the original PSK-DTLS protocol, which can reduce the protocol complexity of the communication process.

[0048] On the other hand, the present application completes the key acquisition process through the computing performance of the IoT trust anchor device TA, and the restricted IoT device Di can only be used to communicate with the server S. In this way, it is possible to avoid increasing the number of restricted IoT devices D. i The CPU and memory / ROM requirements are reduced, and the power consumption of the limited IoT device will not be increased. On the other hand, the present application has good scalability and can be used in large-scale IoT application environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0050] Figure 1 It is a flow chart of a communication method based on a shared key disclosed in an embodiment of the present application;

[0051] Figure 2 It is a structural diagram of a shared key communication system disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0052] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0053] Embodiment 1

[0054] See also Figure 1 , Figure 1 1 is a flow chart of a communication method based on a shared key disclosed in an embodiment of the present application, wherein the communication method based on a shared key in an embodiment of the present application is applied to a communication system with a shared key. Figure 1 As shown, the communication method based on the shared key in the embodiment of the present application includes the following steps:

[0055] 101. The IoT trust anchor device establishes a trust relationship with the restricted IoT device;

[0056] 102. The server is connected to the IoT trust anchor device through communication, and obtains a first temporary shared key and a link random number for accessing the restricted IoT device through the IoT trust anchor device;

[0057] 103. The server establishes a communication connection with the restricted IoT device based on the first temporary shared key and the link random number and the PSK_DTLS protocol.

[0058] The communication method based on shared keys in the embodiment of the present application can share keys only between the restricted IoT device Di and the IoT trust anchor device TA it trusts through the trust relationship between the IoT trust anchor device and the restricted IoT device. The restricted IoT device Di can achieve PSK-DTLS-based end-to-end secure communication between the restricted IoT device Di and any server S without sharing a password with the server S. The shared keys are only used to generate temporary shared keys and are not transmitted on the network, which can improve the security of the shared keys. On the other hand, the method in the embodiment of the present application makes little modification to the original PSK-DTLS protocol, which can reduce the protocol complexity of the communication process.

[0059] On the other hand, the embodiment of the present application completes the key acquisition process through the computing performance of the IoT trust anchor device TA, and the restricted IoT device Di can only be used to communicate with the server S. In this way, it is possible to avoid increasing the number of restricted IoT devices D. i The CPU and memory / ROM requirements are reduced, and the power consumption of the restricted IoT device is not increased. On the other hand, the method of the embodiment of the present application has good scalability and can be used in the environment of large-scale IoT applications.

[0060] In the embodiment of the present application, as an optional implementation, step 101: the IoT trust anchor device establishes a trust relationship with the restricted IoT device, including the following sub-steps:

[0061] The restricted IoT device stores the master symmetric key;

[0062] The IoT trust anchor device generates a first data table for storing information of a restricted IoT device, where the restricted IoT information includes a master symmetric key, an ID of the restricted IoT device, and an IP address of the restricted IoT device;

[0063] The IoT trust anchor device responds to the certificate deployment instruction to store the certificate information;

[0064] The IoT trust anchor device generates a second data table, where the second data table is used to store server permission information that allows access to restricted IoT devices.

[0065] In an embodiment of the present application, as an optional implementation, the server permission information includes the ID of the accessible server, the access account, the access password, and the ID of the restricted IoT device that the server is allowed to access.

[0066] In this optional implementation, optionally, the user can use a preset key generation algorithm to generate a master symmetric key, wherein the preset key generation algorithm is not limited in the present application embodiment. Further optionally, after the master symmetric key is generated, the user can send the master symmetric key to the device manufacturer to entrust the device manufacturer to burn the master symmetric key into the restricted IoT device.

[0067] In this optional implementation, optionally, the master symmetric key can also be securely generated by the manufacturer using a preset key generation algorithm, and the manufacturer burns the master symmetric key into the restricted IoT device, and then informs the user using secure means such as encrypted email.

[0068] In this optional implementation, the certificate information is used to implement mutual authentication between the server and the IoT trust anchor device based on the certificate mechanism. For this process, please refer to the prior art, and this embodiment of the present application will not be elaborated on.

[0069] In this optional implementation, the first data table includes the IP address of the restricted IoT device, the master symmetric key and the ID of the restricted IoT device as the primary key association. In this optional implementation, in the communication process between the restricted IoT device and the server, the complete parameters required for access are matched based on a certain parameter, so as to realize the communication process between the restricted IoT device and the server based on the complete parameters. For example, when the ID of the restricted IoT device is input, the IP address of the restricted IoT device can be matched through the first data table, and then the server can initiate a request to the restricted IoT device through the IP address of the restricted IoT device.

[0070] In this optional implementation, as an example of a first data table, as shown in Table 1, DevIP represents the IP address of the restricted IoT device, DevID represents the ID of the restricted IoT device, DevKey represents the master symmetric key, and SN represents the serial number of the restricted IoT device (the serial number of the restricted IoT device is used in the generation process of the link random number below).

[0071]

[0072] Table 1

[0073] In this optional implementation, the second data table is used to determine whether the server and the account currently logged in to the server have permission to access the restricted IoT device when the server requests a connection with the restricted IoT device. For example, when user A logs in to the server, it can be determined that user A has access rights based on the information currently input by user A and the second data table, and when user B logs in to the server, it can be determined that user B does not have access rights based on the information currently input by user B and the second data table.

[0074] In this optional implementation, as an example of the second data table, as shown in Table 2, ClientID represents the ID of the server, Account represents the access account, PW represents the access password, and PermitID represents the ID of the restricted IoT device that the server allows to access.

[0075] ClientID Account PW PermitIDS D1 xxxx xxx {D1, Dn} .. xxxx xxx {D1, Dn} Dn xxxx xxx {D1, Dn}

[0076] Table 2

[0077] In the embodiment of the present application, as an optional implementation, Figure 2 As shown, step 102: the server communicates with the IoT trust anchor device and obtains a first temporary shared key and a link random number for accessing a restricted IoT device through the IoT trust anchor device, including the following sub-steps:

[0078] The server establishes a TLS secure connection with the IoT trust anchor device;

[0079] The server and IoT trust anchor device perform mutual authentication based on certificate information and certificate mechanism;

[0080] When the server authentication and IoT trust anchor device authentication are passed, the server sends a key acquisition request to the IoT trust anchor device. The key acquisition request carries the server ID and the restricted IoT device ID.

[0081] The IoT trust anchor device determines whether the server has permission to access the restricted IoT device based on the server ID and the second data table;

[0082] When the server has permission to access the restricted IoT device, the IoT trust anchor device reads the serial number of the restricted IoT device based on the first data table;

[0083] The IoT trust anchor device generates a first temporary shared key and a link random number based on the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device and the preset key length;

[0084] The IoT trust anchor device sends the first temporary shared key and the link random number to the server;

[0085] The server saves the first temporary shared key and the link random number based on the ID of the restricted IoT device.

[0086] In this optional implementation, the server and the IoT trust anchor device establish a TLS secure connection based on the IP protocol. For the specific process, please refer to the prior art, and the present application embodiment will not elaborate on this. In this optional implementation, for the specific process of mutual authentication between the server and the IoT trust anchor device based on certificate information and certificate mechanism, please refer to the prior art, and the present application embodiment will not elaborate on this.

[0087] In this optional implementation, optionally, step 102 further includes the following sub-steps:

[0088] When the server does not have permission to access the restricted IoT device, the IoT trust anchor device returns access denial information to the server.

[0089] In this optional implementation, the preset key derivation algorithm is a secure hash algorithm. For example, the preset key derivation algorithm may be one of SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. Accordingly, the number of the preset key derivation algorithm represents the number corresponding to the secure hash algorithm. For example, when the preset key derivation algorithm is SHA-1, the number of the preset key derivation algorithm is {0x0C, 0x44, 0x4A}, that is, the number of the preset key derivation algorithm is a 3-byte constant.

[0090] In this optional implementation, optionally, the length of the serial number of the restricted IoT device is 8 bytes, the length of the ID of the IoT trust anchor device is 1 byte, the length of the identity information of the server is 12 bytes, the length of the ID of the restricted IoT device is 12 bytes, and the length of the preset key is one byte. It should be noted that the preset key length indicates the length of the preset first temporary shared key. For example, the length of the pre-prepared first temporary shared key is 37.

[0091] In the embodiment of the present application, as an optional implementation, the initial value of the serial number of the restricted IoT device is 0. Accordingly, after the IoT trust anchor device sends the first temporary shared key and the link random number to the server, the method of the embodiment of the present application further includes the following steps:

[0092] The IoT trust anchor device updates the serial number of the restricted IoT device.

[0093] In this optional implementation, the IoT trust anchor device updates the serial number of the restricted IoT device after each generation of the first temporary shared key and the link random number. In this way, each generation of the first temporary shared key and the link random number can be based on different serial numbers, so that each generation of the first temporary shared key is different, thereby further improving the security of the first temporary shared key.

[0094] In this optional implementation, optionally, the specific manner in which the IoT trust anchor device updates the serial number of the restricted IoT device is:

[0095] After the IoT trust anchor device generates the first temporary shared key and link random number each time, the serial number of the restricted IoT device is incremented by 1.

[0096] Exemplarily, assuming that SN represents the serial number of the restricted IoT device, the IoT trust anchor device executes SN+1 after each generation of the first temporary shared key and the link random number.

[0097] In an embodiment of the present application, as an optional implementation, the IoT trust anchor device generates a first temporary shared key and a link random number based on the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device and the preset key length, including:

[0098] Encode the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device and the preset key length based on the BASE64 encoder to generate a link random number;

[0099] Decode the link random number based on the BASE64 decoder to obtain the ID of the first temporary shared key;

[0100] The IoT trust anchor device uses the ID of the first temporary shared key and the master symmetric key as input parameters of the SHA256 algorithm, and obtains the first temporary shared key through the SHA256 algorithm.

[0101] In this optional implementation, please refer to the prior art for the specific working process of the BASE64 encoder and the BASE64 decoder, and the embodiment of the present application will not elaborate on this.

[0102] In this optional implementation, please refer to the prior art for the specific working process of the SHA256 algorithm, and the embodiments of the present application will not elaborate on this.

[0103] In the embodiment of the present application, as an optional implementation, step 103: the server establishes a communication connection with the restricted IoT device based on the first temporary shared key and the link random number and the PSK_DTLS protocol, including the following sub-steps:

[0104] The server sends an authentication request to the restricted IoT device, and the authentication request carries a link random number;

[0105] The restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key, where the second temporary shared key and the first temporary shared key are symmetric keys;

[0106] The server establishes a communication connection with the restricted IoT device based on the second temporary shared key, the first temporary shared key, and the PSK_DTLS protocol.

[0107] In the embodiment of the present application, based on the second temporary shared key and the first temporary shared key, and the PSK_DTLS protocol, the specific process of establishing a communication connection with the restricted IoT device is as follows:

[0108] Based on the PSK_DTLS protocol, it is determined whether the second temporary shared key is consistent with the first temporary shared key. If the second temporary shared key is consistent with the first temporary shared key, the server establishes a communication connection with the restricted IoT device.

[0109] In this optional implementation, please refer to the prior art for the specific process of the PSK_DTLS protocol, and the embodiments of the present application will not go into details.

[0110] In an embodiment, as an optional implementation, after the server sends an authentication request to the restricted IoT device, before the restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key, the method of the embodiment of the present application further includes the following sub-steps:

[0111] The restricted IoT device verifies whether the length of the link random number is within the preset length range;

[0112] When the length of the link random number is within a preset length range, the restricted IoT device decodes the link random number based on a Base64 decoder and obtains decoding information;

[0113] The restricted IoT device determines whether the length of the decoded information is equal to a preset length threshold;

[0114] When the length of the decoded information is equal to the preset length threshold, the restricted IoT device compares the decoded information with the information of the restricted IoT device to verify whether the decoded information is correct;

[0115] When the decoded information is verified to be correct, the execution-restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key.

[0116] In this optional implementation, by judging the length of the link random number and the length of the decoding information, the server can be refused to connect with the restricted IoT device if the length of the link random number and the length of the decoding information do not meet the requirements, thereby further improving the security of the restricted IoT device.

[0117] In this optional implementation, the preset length range is 37-60 bytes. Accordingly, as an example, if the length of the random number of the restricted IoT device verification link is 35 bytes, it is not within the preset length range. At this time, the second temporary shared key is NULL, that is, the restricted IoT device does not generate the second temporary shared key, so that the restricted IoT device cannot communicate with the server based on the symmetric first temporary shared key and the second temporary shared key.

[0118] In this optional implementation, the preset length threshold is 37. Accordingly, when the restricted IoT device determines that the length of the decoded information is 36, it is not equal to 37, and the second temporary shared key is NULL, that is, the restricted IoT device does not generate the second temporary shared key, and thus the restricted IoT device cannot communicate with the server based on the symmetric first temporary shared key and the second temporary shared key.

[0119] Embodiment 2

[0120] See also Figure 2 , Figure 2 Schematic diagram of a communication system for sharing a key disclosed in an embodiment of the present application. Figure 2 As shown, the communication system based on shared key of the embodiment of the present application includes: a restricted Internet of Things device and a server, wherein the server establishes a communication connection with the restricted Internet of Things device through the communication method based on shared key of the first embodiment of the present application.

[0121] Furthermore, if Figure 2 As shown, the structural diagram of the communication system for sharing keys also includes a TA for the IoT trust anchor device.

[0122] Specifically, in the embodiments of the present application, Figure 2 As shown, the communication system based on shared keys includes n restricted IoT devices, a server located on a local area network or on the Internet, and an IoT trust anchor device, wherein the server is represented by S, the IoT trust anchor device is represented by TA, and the restricted IoT device is represented by Di, wherein i = (0, 1, 2…n), and n is the total number of restricted IoT devices.

[0123] More specifically, Figure 2 As shown, n restricted IoT devices Di can be communicatively connected with the IoT trust anchor device TA, wherein the IoT trust anchor device TA and the managed restricted IoT devices Di are in the same management domain, and the IoT trust anchor device TA can be a resource-rich device with strong computing, storage and communication capabilities. For example, the IoT trust anchor device TA can be a server or a dedicated device. Optionally, the IoT trust anchor device TA can also be embedded in other network devices in a modular manner. For example, the IoT trust anchor device TA can be embedded in the IoT gateway GW.

[0124] In an embodiment of the present application, the IoT trust anchor device TA is deployed in an environment with physical protection measures, such as an office building of an enterprise. In this way, the master symmetric key stored in the IoT trust anchor device TA can be prevented from being leaked based on physical protection measures.

[0125] In the embodiments of the present application, Figure 2 As shown, the system of the embodiment of the present application may also include an Internet of Things gateway GW, wherein the Internet of Things gateway GW is communicatively connected with the restricted Internet of Things device Di of the specified network domain, and the Internet of Things gateway GW acts as an IP data packet forwarder and connects the restricted Internet of Things to the local IP network infrastructure or the Internet through conventional wired or wireless connections.

[0126] In an embodiment of the present application, optionally, the restricted IoT device Di can communicate with the IoT gateway GW through restricted link layer technologies such as 6LoWPAN, IEEE802.15.4, Bluetooth, LoWAN, etc., and communicate and connect with the IoT trust anchor device TA or server S through the IoT gateway GW.

[0127] In the embodiment of the present application, the IoT trust anchor device TA communicates with the server S via the IP protocol. On the other hand, the restricted IoT device Di communicates with the server S via the PSK-DTLS protocol.

[0128] It should be noted that a restricted IoT device is an IoT device located in a resource-restricted domain, where the network resources accessible to the restricted network domain are limited. Furthermore, the restricted IoT device may be a smart home device, an industrial sensor, a smart camera, or other electronic device that relies on IoT technology. On the other hand, in an embodiment of the present application, the IoT trust anchor device may be a host, and the server may also be a host.

[0129] The system of the embodiment of the present application can share keys only between the restricted IoT device Di and the IoT trust anchor device TA it trusts by executing a communication method based on a shared key. The restricted IoT device Di can achieve end-to-end secure communication based on PSK-DTLS between the restricted IoT device Di and any server S without sharing a password with the server S. The shared key is only used to generate a temporary shared key and is not transmitted on the network, which can improve the security of the shared key. On the other hand, the method of the embodiment of the present application makes little modification to the original PSK-DTLS protocol, which can reduce the protocol complexity of the communication process.

[0130] On the other hand, the embodiment of the present application completes the key acquisition process through the computing performance of the IoT trust anchor device TA, and the restricted IoT device Di can only be used to communicate with the server S. In this way, it is possible to avoid increasing the number of restricted IoT devices D. i The CPU and memory / ROM requirements are reduced, and the power consumption of the restricted IoT device is not increased. On the other hand, the system of the embodiment of the present application has good scalability and can be used in a large-scale IoT application environment.

[0131] Embodiment 3

[0132] An embodiment of the present application discloses a storage medium, which stores computer instructions. When the computer instructions are called, they are used to execute the communication method based on a shared key in the first embodiment of the present application.

[0133] The storage medium of the embodiment of the present application can share keys only between the restricted IoT device Di and the IoT trust anchor device TA it trusts through the trust relationship between the IoT trust anchor device and the restricted IoT device. The restricted IoT device Di can achieve end-to-end secure communication based on PSK-DTLS between the restricted IoT device Di and any server S without sharing the password with the server S. The shared key is only used to generate a temporary shared key and is not transmitted on the network, which can improve the security of the shared key. On the other hand, the method of the embodiment of the present application makes little modification to the original PSK-DTLS protocol, which can reduce the protocol complexity of the communication process.

[0134] On the other hand, the embodiment of the present application completes the key acquisition process through the computing performance of the IoT trust anchor device TA, and the restricted IoT device Di can only be used to communicate with the server S. In this way, it is possible to avoid increasing the number of restricted IoT devices D. i The CPU and memory / ROM requirements are reduced, and the power consumption of the restricted IoT device is not increased. On the other hand, the storage medium of the embodiment of the present application has good scalability and can be used in the environment of large-scale IoT applications.

[0135] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0136] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0137] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0138] It should be noted that if the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of a software product, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM) random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0139] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0140] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A communication method based on a shared key, It is characterized in that The method is applied to a communication system based on a shared key, the system comprising a restricted IoT device, an IoT trust anchor device, and a server, and the method comprises: The IoT trust anchor device establishes a trust relationship with the restricted IoT device; The server is in communication connection with the IoT trust anchor device, and obtains a first temporary shared key and a link random number for accessing the restricted IoT device through the IoT trust anchor device; The server establishes a communication connection with the restricted IoT device based on the first temporary shared key, the link random number, and the PSK_DTLS protocol; And, the IoT trust anchor device establishes a trust relationship with the restricted IoT device, including: The restricted IoT device stores a master symmetric key; The IoT trust anchor device generates a first data table for storing information of the restricted IoT device, where the information of the restricted IoT device includes a master symmetric key, an ID of the restricted IoT device, and an IP address of the restricted IoT device; The IoT trust anchor device responds to the certificate deployment instruction to store the certificate information; The IoT trust anchor device generates a second data table, where the second data table is used to store server permission information that allows access to the restricted IoT device; And, the server is in communication connection with the IoT trust anchor device, and obtains a first temporary shared key and a link random number for accessing the restricted IoT device through the IoT trust anchor device, including: The server establishes a TLS secure connection with the IoT trust anchor device; The server and the IoT trust anchor device perform mutual authentication based on the certificate information and the certificate mechanism; When the server authentication is passed and the IoT trust anchor device authentication is passed, the server sends a key acquisition request to the IoT trust anchor device, where the key acquisition request carries the ID of the server and the ID of the restricted IoT device; The IoT trust anchor device determines, based on the ID of the server and the second data table, whether the server has permission to access the restricted IoT device; When the server has permission to access the restricted IoT device, the IoT trust anchor device reads the serial number of the restricted IoT device based on the first data table; The IoT trust anchor device generates the first temporary shared key and the link random number based on the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device and the preset key length; The IoT trust anchor device sends the first temporary shared key and the link random number to the server; The server saves the first temporary shared key and the link random number based on the ID of the restricted IoT device.

2. The method according to claim 1, It is characterized in that The server permission information includes the ID of the accessible server, the access account, the access password, and the ID of the restricted IoT device that the server is allowed to access.

3. The method according to claim 2, It is characterized in that The initial value of the serial number of a restricted IoT device is 0; And, after the IoT trust anchor device sends the first temporary shared key and the link random number to the server, the method further includes: The IoT trust anchor device updates the serial number of the restricted IoT device.

4. The method according to claim 3, It is characterized in that The IoT trust anchor device generates the first temporary shared key and the link random number based on the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device, and the preset key length, including: encoding the serial number of the restricted IoT device, the number of the preset key derivation algorithm, the ID of the IoT trust anchor device, the identity information of the server, the ID of the restricted IoT device, and the preset key length based on a BASE64 encoder to generate the link random number; Decoding the link random number based on a BASE64 decoder to obtain an ID of the first temporary shared key; The Internet of Things trust anchor device uses the ID of the first temporary shared key and the master symmetric key as input parameters of the SHA256 algorithm, and obtains the first temporary shared key through the SHA256 algorithm.

5. The method according to claim 4, It is characterized in that The server establishes a communication connection with the restricted IoT device based on the first temporary shared key, the link random number, and the PSK_DTLS protocol, including: The server sends an authentication request to the restricted IoT device, where the authentication request carries the link random number; The restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key, where the second temporary shared key and the first temporary shared key are symmetric keys; A communication connection with the restricted Internet of Things device is established based on the second temporary shared key and the first temporary shared key.

6. The method according to claim 5, It is characterized in that After the server sends an authentication request to the restricted IoT device and before the restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key, the method further includes: The restricted IoT device verifies whether the length of the link random number is within a preset length range; When the length of the link random number is within a preset length range, the restricted IoT device decodes the link random number based on a Base64 decoder and obtains decoding information; The restricted IoT device determines whether the length of the decoded information is equal to a preset length threshold; When the length of the decoded information is equal to the preset length threshold, the restricted IoT device compares the decoded information with the information of the restricted IoT device to verify whether the decoded information is correct; When the decoded information is verified to be correct, the restricted IoT device generates a second temporary shared key based on the link random number and the master symmetric key.

7. A communication system based on a shared key, It is characterized in that The shared key-based communication system includes a restricted IoT device, an IoT trust anchor device, and a server, wherein the server establishes a communication connection with the restricted IoT device through the method according to any one of claims 1 to 6.

8. A storage medium, It is characterized in that The storage medium stores computer instructions, which, when called, are used to execute the communication method based on a shared key as described in any one of claims 1 to 6.

Images