CN117728942A - Mutual trust code generation method, equipment verification method and electronic equipment - Google Patents

Abstract

The application discloses a mutual trust code generation method, a device verification method and electronic equipment, wherein the mutual trust code generation method comprises the following steps: acquiring the current mutual trust code corresponding to the user account and the actual expiration time and pre-expiration time corresponding to the current mutual trust code; responding to the pre-expiration time reaching the current mutual-trust code, and acquiring a standby mutual-trust code corresponding to the user account; and sending the current mutual trust code to the Internet of things equipment bound with the user account, and if the standby mutual trust code exists, sending the standby mutual trust code to the Internet of things equipment at the same time so as to perform mutual trust verification between all the Internet of things equipment bound with the user account through the current mutual trust code or the standby mutual trust code. When the current mutual trust code is about to expire, the updated standby mutual trust code is issued to the Internet of things equipment under the same user account, so that the situation that the Internet of things equipment cannot timely acquire the updated mutual trust code due to the fact that the Internet of things equipment is offline can be avoided on the premise of ensuring communication safety between the Internet of things equipment.

Description

Mutual trust code generation method, equipment verification method and electronic equipment

Technical Field

The present invention relates to the field of data transmission technologies, and in particular, to a method for generating a mutual trust code, a method for verifying a device, and an electronic device.

Background

With the rapid development of the internet of things technology, massive intelligent devices or terminals are accessed to the internet, and along with popularization and convenience of the mobile internet, application (APP) of the intelligent devices becomes a mainstream Application scene gradually, and a user can add a binding intelligent device in an APP account of the user, and through operation on the APP, interaction with the intelligent device is realized through a server forwarding mode.

The internet of things is increasingly valued as an emerging industry in the information age, the number of internet of things equipment is also increased in a sustained manner, the number of equipment is exponentially increased, the possibility that confidential information is illegally obtained and an information sending end is impersonated is increased, and the safety of the internet of things environment is reduced.

Disclosure of Invention

The application provides at least a mutual trust code generation method, a device verification method and electronic equipment.

The first aspect of the present application provides a method for generating a mutually trusted code, where the method includes: acquiring a current mutual trust code corresponding to a user account and validity period information corresponding to the current mutual trust code, wherein the validity period information comprises actual expiration time and pre-expiration time, and the pre-expiration time is earlier than the actual expiration time; in response to reaching the pre-expiration time of the current mutual-trust code, acquiring a standby mutual-trust code corresponding to the user account, wherein the actual expiration time of the standby mutual-trust code is later than the actual expiration time of the current mutual-trust code; and sending the current mutual trust code to the Internet of things equipment bound with the user account, and if the standby mutual trust code exists, sending the standby mutual trust code to the Internet of things equipment at the same time so that mutual trust verification is carried out between all the Internet of things equipment bound with the user account through the current mutual trust code or the standby mutual trust code.

In an embodiment, the validity period information also contains an effective time, the effective time of the alternate mutually trusted code being equal to an actual expiration time of the current mutually trusted code.

In an embodiment, further comprising: and deleting the current mutual-trust code and taking the standby mutual-trust code as a new current mutual-trust code in response to reaching the actual expiration time of the current mutual-trust code.

A second aspect of the present application provides a device authentication method, applied to a request initiating device, including: storing current mutually-trusted codes or standby mutually-trusted codes sent by a server to obtain an initiating mutually-trusted code set corresponding to the request initiating equipment, wherein the current mutually-trusted codes or the standby mutually-trusted codes are obtained by the mutually-trusted code generating method; obtaining a first timestamp by obtaining the current time, and selecting a first initiating mutual-trust code corresponding to the request initiating device from the initiating mutual-trust code set by utilizing the first timestamp; generating an initiation identity sequence corresponding to the request initiation device based on the first timestamp and the first initiation mutual trust code; sending a verification request carrying the initiation identity sequence to a request response device, so that the request response device performs first verification processing on the request initiation device based on the initiation identity sequence; the first verification process is implemented based on a first response mutual trust code corresponding to the first timestamp by the request response device.

In an embodiment, after the sending, to the request response device, the authentication request carrying the initiation identity sequence, the method further includes: receiving verification passing information sent by the request response device, wherein the verification passing information is generated after the request response device passes the verification of the request initiating device, the verification passing information carries a response identity sequence corresponding to the request response device, and the response identity sequence is generated based on a second timestamp and a second response mutual-trust code corresponding to the request response device at the second timestamp; selecting a second initiating mutual-trust code corresponding to the request initiating device from the initiating mutual-trust code set by utilizing the second timestamp; and performing second verification processing on the response identity sequence based on the second initiating mutual trust code.

In an embodiment, the performing, based on the second initiation mutually trusted code, a second verification process on the response identity sequence includes: detecting whether a second response mutual-trust code in the response identity sequence is consistent with the second initiation mutual-trust code; and if the two types of information are consistent, establishing a mutually trusted relation with the request response equipment.

A third aspect of the present application provides another device authentication method, applied to a request response device, the method comprising: storing current mutually-trusted codes or standby mutually-trusted codes sent by a server to obtain a response mutually-trusted code set corresponding to the request response equipment, wherein the current mutually-trusted codes or the standby mutually-trusted codes are obtained by the mutually-trusted code generation method; receiving a verification request sent by request initiating equipment, wherein the verification request carries an initiating identity sequence of the request initiating equipment, and the initiating identity sequence is generated by the request initiating equipment based on a first time stamp and a first initiating mutual trust code corresponding to the first time stamp by the request initiating equipment; selecting a first response mutual-trust code corresponding to the request response device from the response mutual-trust code set by utilizing the first timestamp; and performing first verification processing on the initiation identity sequence based on the first response mutual trust code.

In an embodiment, performing a first verification process on the initiation identity sequence based on the first response mutual trust code includes: detecting whether a first initiating mutually trusted code in the initiating identity sequence is consistent with the first responding mutually trusted code; and if the request is consistent, judging that the request initiating equipment passes the verification.

In an embodiment, after the determining that the request initiating device passes the verification, the method further includes: obtaining a second time stamp by obtaining the current time, and selecting a second response mutual-trust code corresponding to the request response device from the response mutual-trust code set by utilizing the second time stamp; generating a response identity sequence corresponding to the request response device based on the second timestamp and the second response mutual-trust code; transmitting verification passing information carrying the response identity sequence to request initiating equipment so that the request initiating equipment carries out second verification processing on the request responding equipment based on the response identity sequence; the second verification process is implemented based on a second initiation mutual trust code corresponding to the second timestamp by the request initiating device.

A fourth aspect of the present application provides an electronic device, including a memory and a processor, where the processor is configured to execute program instructions stored in the memory, so as to implement the foregoing mutual trust code generating method or device verification method.

A fifth aspect of the present application provides a computer-readable storage medium having stored thereon program instructions which, when executed by a processor, implement the above-described mutual trust code generation method or device verification method.

According to the scheme, the current mutual trust code corresponding to the user account and the actual expiration time and the pre-expiration time corresponding to the current mutual trust code are obtained; in response to reaching the pre-expiration time of the current mutual-trust code, acquiring a standby mutual-trust code corresponding to the user account, wherein the actual expiration time of the standby mutual-trust code is later than the actual expiration time of the current mutual-trust code; the method comprises the steps that the current mutual trust code is sent to the Internet of things equipment bound with the user account, and if the standby mutual trust code exists, the standby mutual trust code is sent to the Internet of things equipment, so that mutual trust verification is conducted among all the Internet of things equipment bound with the user account through the current mutual trust code or the standby mutual trust code, when the current mutual trust code is about to expire, the updated standby mutual trust code is issued to the Internet of things equipment under the same user account, and on the premise that communication safety between the Internet of things equipment is guaranteed, the situation that the Internet of things equipment cannot timely learn the updated mutual trust code due to the fact that the Internet of things equipment is offline is avoided, and stability of verification operation of the equipment is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the technical aspects of the application.

FIG. 1 is a schematic diagram of an implementation environment involved in a mutually trusted code generation method as illustrated in an exemplary embodiment of the present application;

FIG. 2 is a flow chart illustrating a method of mutually trusted code generation in accordance with an exemplary embodiment of the present application;

FIG. 3 is a schematic diagram of an issued mutually trusted code shown in an exemplary embodiment of the present application;

FIG. 4 is a schematic diagram illustrating communication between devices of the Internet of things according to an exemplary embodiment of the present application;

FIG. 5 is a flow chart of a device authentication method shown in an exemplary embodiment of the present application;

FIG. 6 is a flow chart of a device authentication method shown in another exemplary embodiment of the present application;

FIG. 7 is an interaction diagram illustrating authentication of an Internet of things device according to an exemplary embodiment of the present application;

FIG. 8 is a block diagram of a mutually trusted code generating apparatus shown in an exemplary embodiment of the present application;

FIG. 9 is a block diagram of a device authentication apparatus shown in an exemplary embodiment of the present application;

FIG. 10 is a block diagram of a device authentication apparatus shown in another exemplary embodiment of the present application;

FIG. 11 is a schematic diagram of an electronic device shown in an exemplary embodiment of the present application;

fig. 12 is a schematic structural view of a computer-readable storage medium shown in an exemplary embodiment of the present application.

Detailed Description

The following describes the embodiments of the present application in detail with reference to the drawings.

In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, interfaces, techniques, etc., in order to provide a thorough understanding of the present application.

The term "and/or" is herein merely an association information describing an associated object, meaning that three relationships may exist, e.g., a and/or B may represent: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship. Further, "a plurality" herein means two or more than two. In addition, the term "at least one" herein means any one of a plurality or any combination of at least two of a plurality, for example, including at least one of A, B, C, and may mean including any one or more elements selected from the group consisting of A, B and C.

The following describes a mutual trust code generating method provided in the embodiment of the present application.

Referring to fig. 1, a schematic diagram of an implementation environment of an embodiment of the present application is shown. The implementation environment of the scheme may include a server 110, an internet of things device 120 and a user terminal 130, where the server 110 is respectively connected with the internet of things device 120 and the user terminal 130 in a communication manner.

The server 110 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, a content delivery network (Content Delivery Network, CDN), basic cloud computing services such as big data and an artificial intelligent platform.

The number of the internet of things devices 120 may be one or more, and each internet of things device 120 may be the same type of device or different types of devices. For example, the first internet of things device is an internet of things gateway device such as a router and a relay, and the second internet of things device is a common internet of things device such as a monitoring camera and an intelligent household appliance; or the first internet of things device and the second internet of things device are common internet of things devices. The application does not limit the device types and the number of the devices of the internet of things.

The user terminal 130 may be a smart phone, a computer, or the like.

Illustratively, a client running a target application program is installed in the user terminal 130, the target application program may manage the internet of things device 120, and the server 110 may be a background server of the target application program, for providing a background service for the client of the target application program.

For example, the user account is logged in a target application program corresponding to the user terminal 130, where the user account is bound with the first internet of things device and the second internet of things device, and the working states of the first internet of things device and the second internet of things device can be checked through the target application program, and a control instruction can also be issued to the first internet of things device and the second internet of things device.

However, not only the user terminal 130 and the server 110 need to communicate with the internet of things device 120, but also the plurality of internet of things devices 120 need to share their own data in order to realize the cooperative work between the plurality of internet of things devices 120, for example, when one sensor detects a certain event, the sensor may send a message to other devices to trigger a corresponding operation.

Therefore, in order to ensure the communication security between the plurality of internet of things devices 120, the method and the device send the mutually trusted codes to the internet of things devices 120 bound under the same user account, so that the internet of things devices 120 can perform identity verification and authorization through the mutually trusted codes.

Further, the applicant also discovers that in an actual application scenario, since the mutual trust code is provided with the validity period information, and the internet of things device 120 is often offline due to network failure, power failure and other reasons, if the offline time is at the boundary time of expiration of the mutual trust code, the offline internet of things device is easy to cause that the offline internet of things device cannot timely acquire the updated mutual trust code, thereby affecting data transmission between the offline internet of things device and other internet of things devices, and reducing user experience.

In view of the above problem, when the current mutual trust code is about to expire, the method and the device issue updated standby mutual trust codes to the internet of things equipment under the same user account, so that the situation that the internet of things equipment cannot timely acquire the updated mutual trust codes due to the fact that the internet of things equipment is offline is avoided on the premise of guaranteeing communication safety between the internet of things equipment.

It can be appreciated that, in the specific embodiments of the present application, related data such as user account numbers, user information, etc. are related, when the embodiments of the present application are applied to specific products or technologies, user permissions or agreements need to be obtained, and the collection, use and processing of related data needs to keep on related laws and regulations and standards of related countries and regions.

Referring to fig. 2, fig. 2 is a flowchart illustrating a method for generating mutually trusted codes according to an exemplary embodiment of the present application. The mutually trusted code generation method can be applied to the implementation environment shown in fig. 1 and is specifically executed by a server in the implementation environment.

As shown in fig. 2, the method for generating the mutual code at least includes steps S210 to S230, which are described in detail as follows:

step S210: acquiring a current mutual trust code corresponding to a user account and validity period information corresponding to the current mutual trust code, wherein the validity period information comprises actual expiration time and pre-expiration time, and the pre-expiration time is earlier than the actual expiration time.

The present mutual trust code and the relevant validity period information corresponding to the user account may be generated by the server, or the present mutual trust code and the relevant validity period information corresponding to the user account may be generated by the user terminal (as shown in fig. 1), which is not limited in this application.

The server acquires the current mutual trust code corresponding to the user account and acquires validity period information corresponding to the current mutual trust code.

The actual expiration time refers to the expiration time of the current mutual trust code, and the pre-expiration time refers to the time when the current mutual trust code is about to expire, and is earlier than the actual expiration time.

In some embodiments, the pre-expiration time is obtained according to a protection time length, for example, the protection time length is 1 month, and if the actual expiration time corresponding to the user account a is 2023, 12, 31, then the pre-expiration time is 1 month before the actual expiration time, that is, 2023, 11, 30.

The protection time length can be preset or flexibly calculated.

The method includes the steps that an offline record of each piece of internet of things equipment bound under the user account is obtained, offline time length corresponding to the offline fault of the equipment is stored in the offline record, the offline time length in the offline record is counted, and the protection time length is set according to a counting result.

Illustrating:

in example 1, the longest offline time length in the offline record is counted to obtain the longest time length, and the protection time length is obtained according to the longest time length. For example, the longest time length may be directly used as the guard time length, or the longest time length may be calculated, such as addition calculation or subtraction calculation, to obtain the final guard time length.

In example 2, the total offline time length and total offline times in the offline record are calculated, the average time length is calculated according to the total offline time length and the total offline times, and the protection time length is obtained according to the average time length. For example, the average time length may be directly used as the guard time length, or the average time length may be calculated, such as addition calculation or multiple multiplication calculation, to obtain the final guard time length.

Example 3, an initial time length corresponding to the current mutual code is obtained, and the initial time length may be preset; or the initial time length can be obtained according to the total validity period length corresponding to the current mutually trusted code, if the total validity period length is multiplied by a preset coefficient, the initial time length is 1 month if the total validity period length is 12 months and the preset coefficient is 1/12. And meanwhile, counting the offline time length in the offline record, and adjusting the initial time length according to the counting result to obtain the final protection time length. The statistical result may be the longest time length in example 1 or the average time length in example 2, or may be a statistical result obtained by other statistical methods, which is not limited in this application.

And 4, acquiring an initial time length corresponding to the current mutual-communication code, respectively counting the offline time lengths (such as the longest time length and the average time length) of different devices, and respectively calculating the protection time length corresponding to each device according to the initial time length and the counting result of the different devices. For example, the longest time length of the device 1 is 1 day, the longest time length of the device 2 is 10 days, and the initial time length is 20 days, and according to the initial time length and the statistics result of different devices, the protection time length of the device 1 is 21 days, and the protection time length of the device 2 is 30 days.

Also, for example, the device importance degree of each device bound under the user account may be obtained, where the device importance degree may be determined according to the type of the device, the frequency of data interaction with other devices, the frequency of use of the user, and the like, and the protection time length is obtained according to the device importance degree.

In example 5, the device importance level obtains a reference time length, if the device importance level is greater than the threshold value, the reference time length is 30 days, otherwise, the reference time length is 10 days. Then, a guard time length is obtained from the reference time length. For example, the reference time length may be directly used as the guard time length, or the reference time length may be calculated, such as addition calculation or multiple multiplication calculation, to obtain the final guard time length.

Specifically, for the above examples 4 and 5, the protection time lengths corresponding to the different internet of things devices may be different, so that the pre-expiration time of the same current mutually trusted code for the different internet of things devices may be different, and the pre-expiration time setting may be performed for the different internet of things devices in a targeted manner, so that the flexibility and accuracy of setting the pre-expiration time are improved.

It should be noted that, the above manner of setting the protection time length is merely an exemplary illustration, and in an actual application scenario, other manners may be flexibly selected to set the protection time length according to an actual situation, for example, the protection time length may be flexibly set according to a device communication reliability level and user information of a user account (such as a user level, a device usage habit of a user, etc.), which is not limited in this application.

The protection time length is flexibly calculated according to the offline record of each device, the importance degree of the device and the like, so that the pre-expiration time is obtained according to the protection time length and the actual expiration time, and the accuracy of the calculated pre-expiration time is improved.

Step S220: and responding to the pre-expiration time of the current mutual-trust code, acquiring a standby mutual-trust code corresponding to the user account, wherein the actual expiration time of the standby mutual-trust code is later than the actual expiration time of the current mutual-trust code.

And if the pre-expiration time of the current mutual-trust code is reached, acquiring or generating the mutual-trust code of the next period as a standby mutual-trust code, and simultaneously, the standby mutual-trust code also corresponds to the validity period information. It is apparent that the actual expiration time of the spare mutually trusted code is later than the actual expiration time of the current mutually trusted code.

Step S230: and sending the current mutual trust code to the Internet of things equipment bound with the user account, and if the standby mutual trust code exists, sending the standby mutual trust code to the Internet of things equipment at the same time so as to perform mutual trust verification between all the Internet of things equipment bound with the user account through the current mutual trust code or the standby mutual trust code.

It should be noted that, the device bound to the user account may be a device that has already had a binding relationship with the user account, or may be a device that is requesting to bind to the user account.

For example, in response to a request for binding the internet of things device to the user account, a current mutual trust code of the user account is obtained, the current mutual trust code is sent to the internet of things device, and if a standby mutual trust code exists, the standby mutual trust code is sent to the internet of things device at the same time, and a binding relationship between the internet of things device and the user account is established.

For another example, referring to fig. 3, fig. 3 is a schematic diagram of issuing a mutually trusted code according to an exemplary embodiment of the present application, and as shown in fig. 3, a mutually trusted code acquisition request sent by an internet of things device is received, where the mutually trusted code acquisition request may be generated when the internet of things device has authorization behaviors and detects that the mutually trusted code is space. The server inquires whether the binding user account exists in the Internet of things equipment, if not, the server does not respond to the mutual-trust code acquisition request; if so, generating or acquiring current mutually-trusted codes and/or standby mutually-trusted codes and validity period information of the corresponding user account, and further transmitting the current mutually-trusted codes and/or standby mutually-trusted codes and validity period information to the Internet of things equipment.

In some embodiments, the validity period information further comprises an effective time, the effective time of the alternate mutually trusted code being equal to an actual expiration time of the current mutually trusted code.

In some embodiments, further comprising: and deleting the current mutual-trust code and taking the standby mutual-trust code as a new current mutual-trust code in response to reaching the actual expiration time of the current mutual-trust code.

Illustrating: if the current mutually trusted code uniquest 1 of the designated user account expires on the day of 12 months of 2023 and the corresponding pre-expiration time of uniquest 1 is 2023, namely, the day of 11 months of 30 years of 11 months of 2023, if equipment binding occurs, the uniquest 1 is issued through a server, and meanwhile, the standby mutually trusted code uniquest 2 with the expiration time of 2024, namely, the day of 31 months of 12 months of 31 is issued, and meanwhile, the uniquest 1 which is about to expire is still preferentially used among the equipment of the internet of things. It follows that there are at most 2 unique str data on the device side.

By the method, the same current mutual trust code and/or standby mutual trust code can be issued to the internet of things equipment bound to the same user account, so that the internet of things equipment can be verified by taking the current mutual trust code or the standby mutual trust code as the certificate of identity verification. And when the current mutual trust code is about to expire, the updated standby mutual trust code is issued to the Internet of things equipment under the same user account, so that the situation that the Internet of things equipment cannot timely acquire the updated mutual trust code due to the fact that the Internet of things equipment is offline is avoided on the premise of ensuring the communication safety between the Internet of things equipment, and the stability of the equipment in executing verification operation is improved.

Referring to fig. 4, a schematic diagram of communication between internet of things devices is shown in an exemplary embodiment of fig. 4, where a request initiating device and a request responding device are both internet of things devices, and the request initiating device initiates a communication request to the request responding device to request to establish a communication connection with the request responding device, and after identity authentication is performed between the request initiating device and the request responding device and the request initiating device passes, communication connection is established between the request initiating device and the request responding device.

Referring to fig. 5, fig. 5 is a flowchart illustrating a device authentication method according to an exemplary embodiment of the present application. The device authentication method may be applied to the implementation environment shown in fig. 4 and specifically executed by the request initiating device in the implementation environment.

As shown in fig. 5, the device verification method at least includes steps S510 to S540, and is described in detail as follows:

step S510: storing the current mutual-trust code or the standby mutual-trust code sent by the server to obtain an initiating mutual-trust code set corresponding to the request initiating equipment, wherein the current mutual-trust code or the standby mutual-trust code is obtained by the mutual-trust code generating method.

It should be noted that the initiating mutually trusted code set may only include one mutually trusted code, or may include a plurality of mutually trusted codes, for example, between the pre-expiration time and the actual expiration time of the current mutually trusted code, the initiating mutually trusted code set may include both the current mutually trusted code and the standby mutually trusted code.

Optionally, after the current mutually trusted code expires, the current mutually trusted code is deleted from the originating mutually trusted code set, and if a standby mutually trusted code exists in the originating mutually trusted code set, the standby mutually trusted code is re-used as the current mutually trusted code, that is, at most two mutually trusted codes exist in the originating mutually trusted code set.

Step S520: obtaining a first timestamp by obtaining the current time, and selecting a first initiating mutual-trust code corresponding to the request initiating device from the initiating mutual-trust code set by utilizing the first timestamp.

For example, if the set of originating mutually trusted codes only contains the current mutually trusted code, detecting whether the current mutually trusted code is expired, specifically, detecting whether the actual expiration time corresponding to the current mutually trusted code is later than the first timestamp, if the actual expiration time corresponding to the current mutually trusted code is later than the first timestamp, the current mutually trusted code is not expired, and taking the current mutually trusted code as the first originating mutually trusted code. If the actual expiration time corresponding to the current mutual-trust code is not later than the first time stamp, the current mutual-trust code is expired, the mutual-trust code acquisition result is null, and if the request initiating equipment is in an offline state at the moment, a mutual-trust code acquisition request is sent to a server so that the server can issue the available mutual-trust code; if the request initiating device is in an offline state at this time, the current device verification process fails to be executed.

Also, for example, if the set of originating mutually trusted codes contains both the current mutually trusted code and the spare mutually trusted code, then it is detected whether the current mutually trusted code is expired, and if the current mutually trusted code is not expired, then the current mutually trusted code is used as the first originating mutually trusted code. If the current mutual-trust code is expired, detecting whether the standby mutual-trust code is expired, and if the standby mutual-trust code is not expired, taking the standby mutual-trust code as a first originating mutual-trust code. If the standby mutual-trust code is also expired, the mutual-trust code acquisition result is empty, and if the request initiating equipment is in an offline state, a mutual-trust code acquisition request is sent to the server so that the server can issue the available mutual-trust code; if the request initiating device is in an offline state at this time, the current device verification process fails to be executed.

Step S530: based on the first timestamp and the first initiation mutual trust code, an initiation identity sequence corresponding to the request initiation device is generated.

After the first initiation mutual-trust code is obtained, an initiation identity sequence corresponding to the request initiation equipment is generated according to the first timestamp and the first initiation mutual-trust code.

That is, the initiation identity sequence at least contains the first timestamp and the information corresponding to the first initiation mutual trust code.

Illustratively, to protect the confidentiality and integrity of data, all communication of the internet of things device is accomplished using suitable encryption protocols and algorithms, ensuring that the data is not obtained or tampered with by unauthorized persons during transmission. For example, a preset encryption algorithm is adopted to encrypt the first timestamp and the first initiation mutual trust code, and the encryption result is used as an initiation identity sequence corresponding to the request initiation device.

For example, a hash function is used to encrypt the first timestamp and the first originating mutual code to obtain an originating identity sequence. Among them, hash functions include, but are not limited to, MD5 (Message Digest Algorithm 5), SHA-1 (Secure Hash Algorithm 1), SHA-256 (Secure Hash Algorithm 256), and the like.

It should be noted that, in addition to generating the initiation identity sequence according to the first timestamp and the first initiation mutual trust code, the initiation identity sequence may also contain more information, so as to generate the initiation identity sequence in combination with the device identifier of the request initiation device, the first timestamp and the first initiation mutual trust code.

Step S540: sending a verification request carrying an initiation identity sequence to a request response device, so that the request response device performs first verification processing on the request initiation device based on the initiation identity sequence; the first verification process is implemented based on a first response mutual trust code corresponding to the first time stamp by the request response device.

The verification request at least carries an initiating identity sequence, and the verification request is used for requesting the request response device to verify the request initiating device.

The request response device performs first verification processing on the request initiation device based on the initiation identity sequence, wherein the first verification processing is a process of verifying the request initiation device by the request response device, and the first verification processing is realized based on a first response mutual trust code corresponding to the request response device at a first time stamp.

Next, a specific execution procedure of the first authentication process will be described from the request response device side.

Referring to fig. 6, fig. 6 is a flowchart illustrating a device authentication method according to another exemplary embodiment of the present application. The device authentication method can be applied to the implementation environment shown in fig. 4 and specifically executed by a request response device in the implementation environment.

As shown in fig. 6, the device verification method at least includes steps S610 to S640, and is described in detail as follows:

step S610: storing the current mutual-trust code or the standby mutual-trust code sent by the server to obtain a response mutual-trust code set corresponding to the request response equipment, wherein the current mutual-trust code or the standby mutual-trust code is obtained by the mutual-trust code generating method.

The response mutually trusted code set is similar to the initiation mutually trusted code set and will not be described in detail here.

Step S620: and receiving a verification request sent by the request initiating device, wherein the verification request carries an initiating identity sequence of the request initiating device, and the initiating identity sequence is generated by the request initiating device based on the first time stamp and a first initiating mutual trust code corresponding to the first time stamp by the request initiating device.

Step S630: and selecting a first response mutual-trust code corresponding to the request response device from the response mutual-trust code set by using the first time stamp.

Illustratively, the first timestamp corresponding to the authentication request may be obtained from the initiating identity sequence. For example, if the initiation identity sequence is encrypted data, a corresponding decryption algorithm is adopted to decrypt the initiation identity sequence, so as to obtain a first timestamp and a first initiation mutual trust code corresponding to the first timestamp by the request initiation device.

Also by way of example, it may be that the authentication request carries both the initiating identity sequence and the first timestamp, the first timestamp being obtained directly from the authentication request.

In some embodiments, after obtaining the first timestamp, the request response device may further detect whether the first timestamp is within the response validity period, if the time when the request response device receives the verification request is taken as a judgment time, detect whether an interval between the first timestamp and the judgment time exceeds a preset interval threshold, and if the interval exceeds the preset interval threshold, judge that the first timestamp is not within the response validity period, and not respond to the verification request; if the preset interval threshold is not exceeded, the response to the verification request is judged to be in the response validity period, and the subsequent verification step is carried out.

And selecting a first response mutual-trust code corresponding to the request response device from the response mutual-trust code set by using the first time stamp. The method for acquiring the first response mutually-trusted code is similar to the method for acquiring the first originating mutually-trusted code in step S520, and will not be described here.

In some embodiments, after obtaining the first timestamp, the request response device may further detect whether the first timestamp is within the response validity period, if the time when the request response device receives the verification request is taken as a judgment time, detect whether an interval between the first timestamp and the judgment time exceeds a preset interval threshold, and if the interval exceeds the preset interval threshold, judge that the first timestamp is not within the response validity period, and not respond to the verification request; if the preset interval threshold is not exceeded, the response to the verification request is judged to be in the response validity period, and the subsequent verification step is carried out.

Step S640: and performing first verification processing on the initiated identity sequence based on the first response mutual trust code.

And verifying the initiating identity sequence through the first response mutual trust code to obtain a verification result.

Illustratively, performing a first verification process on the initiation identity sequence based on the first response mutually trusted code includes: detecting whether a first initiating mutually trusted code in the initiating identity sequence is consistent with a first responding mutually trusted code; if the request is consistent, judging that the request initiating equipment passes the verification.

If the request response device and the request initiating device are the internet of things devices under the same user account, the request response device judges that the request initiating device is credible.

Specifically, referring to fig. 7, fig. 7 is an interaction diagram of verification performed by an internet of things device according to an exemplary embodiment of the present application, as shown in fig. 7, device a is a request initiating device, device B is a request responding device, device a and device B are bound to the same user account, and a server periodically sends current mutually trusted codes and/or standby mutually trusted codes to device a and device B, respectively. The device A discovers the device B in the local area network, the device A encrypts the SHA256 according to the device identification, the first time stamp and the first initiation mutual code to generate an initiation identity sequence snA, and then sends snA and the first time stamp to the device B together to request the device B to perform identity verification. After receiving the information sent by the equipment A, the equipment B firstly detects whether the first timestamp is in the response validity period, and if so, verifies whether the equipment A is credible according to the initiation identity sequence, wherein the verification process is as follows: adopting a corresponding decryption algorithm to perform decryption calculation on snA to obtain a decrypted result, wherein the decrypted result contains a first originating mutual trust code; meanwhile, a first time stamp is utilized to select a first response mutual-trust code corresponding to the request response device from the response mutual-trust code set; and if the first initiation mutual trust code is detected to be consistent with the first response mutual trust code, the equipment A is considered to be trusted.

In the foregoing embodiment, in the actual application process, in order to further improve the reliability of data transmission, the request initiating device needs to verify the request responding device, where the verification process is similar to the process that the request responding device verifies the request initiating device, and see the following embodiment specifically.

Next, a process of the request initiating device authenticating the request responding device will be described in detail in connection with authentication processing steps between the request initiating device and the request responding device.

In some embodiments, after determining that the request initiating device is authenticated, the request responding device further comprises: obtaining a second time stamp by the current time, and selecting a second response mutual-trust code corresponding to the request response device from the response mutual-trust code set by using the second time stamp; generating a response identity sequence corresponding to the request response device based on the second timestamp and the second response mutual-trust code; transmitting verification passing information carrying a response identity sequence to the request initiating device so that the request initiating device performs second verification processing on the request responding device based on the response identity sequence; the second verification process is implemented based on a second initiation mutual trust code corresponding to the second timestamp by the request initiation device.

The request initiating device receives verification passing information sent by the request responding device; selecting a second initiating mutual-trust code corresponding to the request initiating device from the initiating mutual-trust code set by using the second timestamp; and performing second verification processing on the response identity sequence based on the second initiating mutual-trust code.

And performing second verification processing on the response identity sequence based on the second initiating mutual-trust code, wherein the second verification processing comprises the following steps: detecting whether a second response mutual-trust code in the response identity sequence is consistent with a second initiation mutual-trust code; if the two types of information are consistent, establishing a mutually trusted relation with the request response equipment.

Specifically, with continued reference to fig. 7, after device a is authenticated, device B encrypts device a256 according to its own device identifier, a second timestamp, and a second response mutual trust code, generates a response identity sequence snB, and sends snB to device a together with the second timestamp. After receiving the information sent by the equipment B, the equipment A detects whether the second timestamp is in the response validity period, and if so, verifies whether the equipment B is credible according to the response identity sequence, wherein the verification process is as follows: adopting a corresponding decryption algorithm to perform decryption calculation on snB to obtain a decrypted decryption result, wherein the decryption result contains a second response mutual trust code; meanwhile, a second initiating mutual-trust code corresponding to the requesting initiating device is selected from the initiating mutual-trust code set by using a second timestamp; and if the second initiation mutual trust code is detected to be consistent with the second response mutual trust code, the device B is considered to be trusted.

Further, the device a and the device B establish a mutual trust relationship, and the device a and the device B can perform data transmission.

Optionally, when data transmission is performed, data transmitted in the data transmission process is still encrypted.

For example, after the data to be transmitted is encrypted by adopting a preset data encryption algorithm, the encrypted data is transmitted. Illustrating: carrying out SHA256 coding by using an identity sequence (such as an initiating identity sequence or a responding identity sequence), and converting the identity sequence into a 32-bit length byte array to be used as a key; SHA256 coding is carried out by using the mutually trusted code, and the byte array with the length of the first 16 bits is intercepted as iv; data encryption transmission is performed by encrypting data to be transmitted using AES256 based on key and iv.

By the method, access control among the devices of the Internet of things can be realized, and the fact that only the devices passing verification can communicate with other devices is ensured. The unverified device may refuse to access through firewall, network isolation, etc.

Fig. 8 is a block diagram of a mutually trusted code generating apparatus deployed at a server, as shown in an exemplary embodiment of the present application. As shown in fig. 8, the exemplary mutually trusted code generating apparatus 800 includes: a code acquisition module 810 and a code issuing module 820. Specifically:

The code obtaining module 810 is configured to obtain a current mutually trusted code corresponding to the user account and validity period information corresponding to the current mutually trusted code, where the validity period information includes an actual expiration time and a pre-expiration time, and the pre-expiration time is earlier than the actual expiration time; the standby mutual-trust code corresponding to the user account is obtained in response to the pre-expiration time of the current mutual-trust code, and the actual expiration time of the standby mutual-trust code is later than the actual expiration time of the current mutual-trust code;

the code issuing module 820 is configured to send a current mutually trusted code to the internet of things device bound to the user account, and if a standby mutually trusted code exists, send the standby mutually trusted code to the internet of things device at the same time, so that mutual trust verification is performed between each internet of things device bound to the user account through the current mutually trusted code or the standby mutually trusted code.

Fig. 9 is a block diagram of a device authentication apparatus deployed at a request initiating device, as shown in an exemplary embodiment of the present application. As shown in fig. 9, the exemplary device authentication apparatus 900 includes: a first code storage module 910, a first code selection module 920, a sequence generation module 930, and a request transmission module 940. Specifically:

a first code storage module 910, configured to store a current mutually trusted code or a standby mutually trusted code sent by the server, to obtain an initiating mutually trusted code set corresponding to the request initiating device, where the current mutually trusted code or the standby mutually trusted code is obtained by the mutually trusted code generating method described above;

A first code selection module 920, configured to obtain a first timestamp from the current time, and select, using the first timestamp, a first originating mutual-trust code corresponding to the request originating device from the originating mutual-trust code set;

a sequence generating module 930, configured to generate an initiation identity sequence corresponding to the request initiating device based on the first timestamp and the first initiation mutual code;

a request sending module 940, configured to send a verification request carrying an initiation identity sequence to a request response device, so that the request response device performs a first verification process on the request initiation device based on the initiation identity sequence; the first verification process is implemented based on a first response mutual trust code corresponding to the first time stamp by the request response device.

Fig. 10 is a block diagram of a device authentication apparatus deployed at a request response device, as shown in another exemplary embodiment of the present application. As shown in fig. 10, the exemplary device authentication apparatus 1000 includes: the second code storage module 1010, the request receiving module 1020, the second code selection module 1030, and the verification module 1040. Specifically:

a second code storage module 1010, configured to store a current mutually trusted code or a standby mutually trusted code sent by the server, to obtain a response mutually trusted code set corresponding to the request response device, where the current mutually trusted code or the standby mutually trusted code is obtained by the mutually trusted code generating method described above;

The request receiving module 1020 is configured to receive a verification request sent by a request initiating device, where the verification request carries an initiating identity sequence of the request initiating device, and the initiating identity sequence is generated by the request initiating device based on a first timestamp and a first initiating mutual trust code corresponding to the first timestamp by the request initiating device;

a second code selection module 1030, configured to select, using the first timestamp, a first response mutual-trust code corresponding to the request response device from the response mutual-trust code set;

and the verification module 1040 is configured to perform a first verification process on the initiation identity sequence based on the first response mutual trust code.

Referring to fig. 11, fig. 11 is a schematic structural diagram of an embodiment of an electronic device of the present application. The electronic device 1100 comprises a memory 1101 and a processor 1102, the processor 1102 being adapted to execute program instructions stored in the memory 1101 to implement the steps of any of the mutual trust code generation method or device verification method embodiments described above. In one particular implementation scenario, electronic device 1100 may include, but is not limited to: the microcomputer, server, and the electronic device 1100 may also include a mobile device such as a notebook computer, a tablet computer, and the like, which is not limited herein.

In particular, the processor 1102 is operable to control itself and the memory 1101 to implement the steps of any of the mutually trusted code generation method or device verification method embodiments described above. The processor 1102 may also be referred to as a central processing unit (Central Processing Unit, CPU). The processor 1102 may be an integrated circuit chip with signal processing capabilities. The processor 1102 may also be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a Field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. In addition, the processor 1102 may be commonly implemented by an integrated circuit chip.

Referring to fig. 12, fig. 12 is a schematic structural diagram of an embodiment of a computer readable storage medium of the present application. The computer readable storage medium 1200 stores program instructions 1210 executable by a processor, the program instructions 1210 for implementing the steps in any of the mutual code generation method or device authentication method embodiments described above.

In some embodiments, functions or modules included in an apparatus provided by the embodiments of the present disclosure may be used to perform a method described in the foregoing method embodiments, and specific implementations thereof may refer to descriptions of the foregoing method embodiments, which are not repeated herein for brevity.

The foregoing description of various embodiments is intended to highlight differences between the various embodiments, which may be the same or similar to each other by reference, and is not repeated herein for the sake of brevity.

In the several embodiments provided in the present application, it should be understood that the disclosed methods and apparatus may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of modules or units is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical, or other forms.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units. The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all or part of the technical solution contributing to the prior art or in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Claims (10)

1. The mutual trust code generating method is characterized by being applied to a server and comprising the following steps:

acquiring a current mutual trust code corresponding to a user account and validity period information corresponding to the current mutual trust code, wherein the validity period information comprises actual expiration time and pre-expiration time, and the pre-expiration time is earlier than the actual expiration time;

in response to reaching the pre-expiration time of the current mutual-trust code, acquiring a standby mutual-trust code corresponding to the user account, wherein the actual expiration time of the standby mutual-trust code is later than the actual expiration time of the current mutual-trust code;

and sending the current mutual trust code to the Internet of things equipment bound with the user account, and if the standby mutual trust code exists, sending the standby mutual trust code to the Internet of things equipment at the same time so that mutual trust verification is carried out between all the Internet of things equipment bound with the user account through the current mutual trust code or the standby mutual trust code.

2. The method of claim 1, wherein the validity period information further comprises an effective time, and wherein the effective time of the alternate mutually trusted code is equal to an actual expiration time of the current mutually trusted code.

3. The method as recited in claim 1, further comprising:

And deleting the current mutual-trust code and taking the standby mutual-trust code as a new current mutual-trust code in response to reaching the actual expiration time of the current mutual-trust code.

4. A device authentication method, applied to a request originating device, comprising:

storing current mutually-trusted codes or standby mutually-trusted codes sent by a server to obtain an initiating mutually-trusted code set corresponding to the request initiating equipment, wherein the current mutually-trusted codes or the standby mutually-trusted codes are obtained by the mutually-trusted code generating method of any one of claims 1 to 3;

obtaining a first timestamp by obtaining the current time, and selecting a first initiating mutual-trust code corresponding to the request initiating device from the initiating mutual-trust code set by utilizing the first timestamp;

generating an initiation identity sequence corresponding to the request initiation device based on the first timestamp and the first initiation mutual trust code;

sending a verification request carrying the initiation identity sequence to a request response device, so that the request response device performs first verification processing on the request initiation device based on the initiation identity sequence; the first verification process is implemented based on a first response mutual trust code corresponding to the first timestamp by the request response device.

5. The method of claim 4, further comprising, after said sending a verification request carrying said initiation identity sequence to a request response device:

receiving verification passing information sent by the request response device, wherein the verification passing information is generated after the request response device passes the verification of the request initiating device, the verification passing information carries a response identity sequence corresponding to the request response device, and the response identity sequence is generated based on a second timestamp and a second response mutual-trust code corresponding to the request response device at the second timestamp;

selecting a second initiating mutual-trust code corresponding to the request initiating device from the initiating mutual-trust code set by utilizing the second timestamp;

and performing second verification processing on the response identity sequence based on the second initiating mutual trust code.

6. The method of claim 5, wherein said performing a second authentication process on said response identity sequence based on said second originating mutual trust code comprises:

detecting whether a second response mutual-trust code in the response identity sequence is consistent with the second initiation mutual-trust code;

And if the two types of information are consistent, establishing a mutually trusted relation with the request response equipment.

7. A device authentication method, applied to a request response device, comprising:

storing current mutually-trusted codes or standby mutually-trusted codes sent by a server to obtain a response mutually-trusted code set corresponding to the request response equipment, wherein the current mutually-trusted codes or the standby mutually-trusted codes are obtained by the mutually-trusted code generation method of any one of claims 1 to 3;

receiving a verification request sent by request initiating equipment, wherein the verification request carries an initiating identity sequence of the request initiating equipment, and the initiating identity sequence is generated by the request initiating equipment based on a first time stamp and a first initiating mutual trust code corresponding to the first time stamp by the request initiating equipment;

selecting a first response mutual-trust code corresponding to the request response device from the response mutual-trust code set by utilizing the first timestamp;

and performing first verification processing on the initiation identity sequence based on the first response mutual trust code.

8. The method of claim 7, wherein said performing a first authentication process on said initiation identity sequence based on said first response mutual trust code comprises:

Detecting whether a first initiating mutually trusted code in the initiating identity sequence is consistent with the first responding mutually trusted code;

and if the request is consistent, judging that the request initiating equipment passes the verification.

9. The method of claim 8, further comprising, after the determining that the request initiating device is authenticated:

obtaining a second time stamp by obtaining the current time, and selecting a second response mutual-trust code corresponding to the request response device from the response mutual-trust code set by utilizing the second time stamp;

generating a response identity sequence corresponding to the request response device based on the second timestamp and the second response mutual-trust code;

transmitting verification passing information carrying the response identity sequence to request initiating equipment so that the request initiating equipment carries out second verification processing on the request responding equipment based on the response identity sequence; the second verification process is implemented based on a second initiation mutual trust code corresponding to the second timestamp by the request initiating device.

10. An electronic device comprising a memory and a processor for executing program instructions stored in the memory to implement the steps of the method according to any of claims 1-9.