Method for establishing trust relationship between devices and electronic device

Abstract

The invention discloses a method for establishing a trust relationship between devices and an electronic device. Belongs to the technical field of communication. The method comprises the following steps: under the condition that a first device logs in an account and the first device is a first login device of the account, sending first device information of the first device to a server; a verification request for the second device is received, the verification request is sent to the first device by the second device through the server side under the condition that the second device logs in the account and it is determined that the first device information is stored in the server side, and the verification request comprises identity information of the second device; verifying the second equipment based on the identity information; and establishing a trust relationship with the second equipment under the condition that the verification of the second equipment is passed.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of communication technology, and specifically to a method for establishing a trust relationship between devices and an electronic device. Background Art

[0002] With the development of terminal technology, the demand for information transmission between devices is increasing. Establishing a trust relationship between two devices can ensure that a secure communication link can be built between the two devices for data transmission.

[0003] In the prior art, different devices of the same brand can establish a trust relationship between devices through a local area network when logging in to the same account. Once a device is far away and out of the local area network environment, the trust relationship between devices cannot be established. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide a method for establishing a trust relationship between devices and an electronic device, which can establish a trust relationship with a device logged in to the same account at any distance, avoid the distance limitation of establishing a trust relationship between devices, and enrich the applicable scenarios of establishing a trust relationship between devices.

[0005] In a first aspect, an embodiment of the present application provides a method for establishing a trust relationship between devices, which is executed by a first device, and the method includes: when the first device logs in to an account and the first device is the first login device of the account, sending the first device information of the first device to a server; receiving a verification request for a second device, the verification request is sent by the second device to the first device via the server when the second device logs in to the account and determines that the first device information is stored in the server, and the verification request includes the identity information of the second device; based on the identity information, verifying the second device; and establishing a trust relationship with the second device when the second device passes the verification.

[0006] In a second aspect, an embodiment of the present application provides a device for establishing a trust relationship between devices, the device comprising: a first sending unit, for sending first device information of the first device to a server when the first device logs in to an account and the first device is the first device to log in to the account; a receiving unit, for receiving a verification request for a second device, the verification request being sent by the second device to the first device via the server when the second device logs in to the account and determines that the first device information is stored in the server, the verification request including the identity information of the second device; a verification unit, for verifying the second device based on the identity information; and an establishing unit, for establishing a trust relationship with the second device when the second device passes the verification.

[0007] In a third aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.

[0008] In a fourth aspect, an embodiment of the present application provides a readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method described in the first aspect above are implemented.

[0009] In a fifth aspect, an embodiment of the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method described in the first aspect.

[0010] In a sixth aspect, an embodiment of the present application provides a computer program product, which is stored in a storage medium and is executed by at least one processor to implement the method described in the first aspect.

[0011] In an embodiment of the present application, when the first device logs in to the account and the first device is the first device to log in to the account, the first device information of the first device is sent to the server; when a verification request for the second device is received, the second device is verified based on the identity information of the second device in the verification request; when the second device passes the verification, a trust relationship is established with the second device. Since the verification request for the second device is sent from the second device to the first device via the server when the second device logs in to the same account and determines that the first device information is stored in the server, in the process of building a trust relationship with the second device, the server is used for information transmission, so that a trust relationship can be established with a device that logs in to the same account at any distance, without limiting the devices to be in the same local area network environment, avoiding the distance limit for building a trust relationship between devices, and enriching the applicable scenarios for building a trust relationship between devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a flow chart of a method for establishing a trust relationship between devices provided in an embodiment of the present application;

[0013] Figure 2 is a flowchart of a second device verification process in a method for establishing a trust relationship between devices provided in an embodiment of the present application;

[0014] Figure 3 is a flowchart of a second device verification process in a method for establishing a trust relationship between devices provided in an embodiment of the present application;

[0015] Figure 4 It is a structural diagram of an apparatus for establishing a trust relationship between devices provided in an embodiment of the present application;

[0016] Figure 5 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0017] Figure 6 It is a schematic diagram of the hardware structure of an electronic device suitable for implementing the embodiments of the present application. DETAILED DESCRIPTION

[0018] The following will be combined with the drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of this application.

[0019] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0020] The following is a detailed description of the method and apparatus for establishing a trust relationship between devices provided in the embodiments of the present application through specific embodiments and their application scenarios in conjunction with the accompanying drawings.

[0021] Please refer to Figure 1 , which shows one of the flow charts of the method for establishing a trust relationship between devices provided in an embodiment of the present application. The method for establishing a trust relationship between devices provided in an embodiment of the present application can be executed by a first device. The device in the embodiment of the present application can be various electronic devices such as a smart phone, a tablet computer, a laptop, a wearable device, etc.

[0022] The process of the method for establishing a trust relationship between devices provided in the embodiment of the present application includes the following steps:

[0023] Step 101, when a first device logs into an account and the first device is the first device to log into the account, the first device information of the first device is sent to the server.

[0024] In this embodiment, the account may refer to an account of the brand's account management system, for example, it may be an account for logging into a certain brand of electronic devices such as mobile phones and tablets. Generally, devices produced by different brands may have different account management systems. For a certain brand's account management system, the same user usually has only one account in the account management system. If a user owns multiple devices produced by the brand, the user can use the same account to log in to the multiple devices.

[0025] In this embodiment, the server can be implemented as a single server or a server cluster. The above server can be an account server used by the device brand to manage and maintain the account.

[0026] In the application scenario of this embodiment, the first device and the second device may be owned by the same user. The first device and the second device may be different devices produced by the same brand. The first device and the second device can log in to the same account. When the first device logs in to the account and the second device does not log in to the account, the first device is the first login device for the account. At this time, the first device information of the first device can be obtained and sent to the server. The first device information may include but is not limited to the device identification of the first device, the public key used for communicating with other devices, and the digital signature and other information. It should be noted that the embodiment of the present application does not limit the number of second devices, that is, there may be one or more second devices.

[0027] In practice, after receiving the first device information, the server can verify the first device to ensure the validity of the first device information. After the verification is passed, the first device information can be stored so that the second device can obtain valid and secure first device information when logging in to ensure the secure transmission of the verification request. If the verification fails, the first device information will not be stored to ensure the security of communication.

[0028] In some optional implementations of this example, step 101 may include the following steps:

[0029] Step S1: When a first device logs in to an account and the first device is the first device to log in to the account, a first terminal-side trusted device list is created, wherein the first terminal-side trusted device list includes first device information of the first device. The first terminal-side trusted device list can be used to store device information of trusted devices with a trust relationship.

[0030] Step S2, sending the first terminal side trusted device list to the server, so that the server creates a server side trusted device list based on the first terminal side trusted device list after verifying the first terminal side trusted device list, and the server side trusted device list includes the first device information.

[0031] By creating a first terminal-side trusted device list, it is possible to clearly and accurately record the device information of trusted devices having a trust relationship, and to facilitate subsequent transmission and verification of the device information.

[0032] In some optional implementations of this example, the above step S1 may further include the following sub-steps:

[0033] Sub-step S11, when the first device logs in to the account and the first device is the first login device of the account, obtain the first key pair, the second key pair, and the third key pair. Here, the first key pair includes a first private key and a first public key, the second key pair includes a second private key and a second public key, and the third key pair includes a third private key and a third public key. The above-mentioned first key pair can be used to sign the subsequently generated first terminal-side trusted device list to ensure that the first terminal-side trusted device list is credible. The above-mentioned second key pair can be used to perform key negotiation with other devices to complete communication encryption. The above-mentioned third key pair can be used to sign the second public key to ensure that the second public key is credible. For different accounts, the third key pair of their login devices is different. The contents of the first key pair, the second key pair, and the third key pair are different.

[0034] Optionally, the first device may run two systems, one of which is an operating system, such as an Android operating system. The other system is a TEE (Trusted execution environment) system, which is used to provide a trusted execution environment. A trusted execution environment is a secure area built by software and hardware methods on a computing platform, which can ensure that the code and data loaded in the secure area are protected in terms of confidentiality and integrity. The first key pair, the second key pair, and the third key pair can be generated in the TEE. Conventional key generation tools or key generation instructions can be used to randomly generate the first key pair, the second key pair, and the third key pair. As an example, the first key pair can be recorded as {account_A_pri, account_A_pub}, where the first private key is account_A_pri and the first public key is account_A_pub. The second key pair can be recorded as {device_A_trust_pri, device_A_trust_pub}, where the second private key is device_A_trust_pri and the second public key is device_A_trust_pub. The third key pair can be recorded as {account_device_pri, account_device_pub}, where the third private key is account_device_pri and the third public key is account_device_pub. The first key pair, the second key pair and the third key pair are randomly generated by the first device, so that the process of establishing a trusted device does not depend on the key pair built into the chip of the first device when it leaves the factory, and the trust relationship between devices can be established more flexibly and conveniently.

[0035] Optionally, the first key pair and the third key pair can be generated in the TEE. Conventional key generation tools or key generation instructions can be used to randomly generate the first key pair and the third key pair. The second key pair can use the key pair built into the chip when the first device leaves the factory. In this case, for easy distinction, the second key pair can be recorded as {device_A_pri, device_A_pub}, where the second private key is device_A_pri and the second public key is device_A_pub. By using the key pair built into the chip when the first device leaves the factory as the second key pair for key negotiation with other devices to complete communication encryption, the process of generating the second key pair can be omitted to improve the efficiency of establishing a trust relationship between devices. At the same time, the key pair resources built into the chip when the first device leaves the factory can be fully utilized to reduce the occupancy of some storage space.

[0036] Sub-step S12, using the third private key to sign the first device identifier and the second private key of the first device to obtain a first digital signature. As an example, the first device identifier can be recorded as uid_1, the second private key is device_A_trust_pub, and the third private key account_device_pri can be used to sign {uid_1, device_A_trust_pub} to obtain a first digital signature, which is recorded as account_device_sign_1. account_device_sign_1 = Sign(account_device_pri, Hash(uid_1|device_A_trust_pub). Among them, Hash() represents a hash function, and Sign() represents a signature algorithm, which can be RSA (Ron Rivest, Adi Shamir, Leonard Adleman) encryption algorithm, ECC (Elliptic Curve Cryptography), etc., which are not specifically limited here.

[0037] Sub-step S13, creating a first terminal side trusted device list, the first terminal side trusted device list includes the first device information of the first device, the first device information includes the first device identification, the second public key and the first digital signature. Continuing with the above example, the first terminal side trusted device list can be recorded as device_table1, see the following table for details:

[0038] device_uid device_pub account_device_sign uid_1 device_A_trust_pub account_device_sign_1

[0039] Among them, device_uid, device_pub, account_device_sign are fields in the table structure, which represent device identification, device public key, and device signature respectively. The first terminal side trusted device list includes a record, which includes the first device identification uid_1, the second public key device_A_trust_pub and the first digital signature account_device_sign_1.

[0040] By creating a first terminal-side trusted device list, it is possible to clearly and accurately record the device information of trusted devices having a trust relationship, and to facilitate subsequent transmission and verification of the device information.

[0041] In some optional implementations of this example, the above step S2 may further include the following sub-steps:

[0042] Sub-step S21, sending the first public key to the server, and obtaining the first certificate of the first public key returned by the server. Here, the server may have a CA (Certificate Authority). The CA is a third-party trust organization that specializes in providing network identity authentication services. The CA is responsible for issuing and managing digital certificates to ensure the security of network communications and the integrity of data. Its main functions include issuing, updating, revoking and verifying certificates, and managing the binding of public keys and private keys to ensure the security of network transactions and the confidentiality of data. Here, the first public key can be sent to the server, and the first certificate of the first public key returned by the server can be obtained. The first certificate can be recorded as account_A_cert.

[0043] Sub-step S22, the first terminal side trusted device list is signed by the first private key to obtain a second digital signature. Continuing the above example, the first terminal side trusted device list device_table1 is signed by the first private key account_A_pri, and the obtained second digital signature can be recorded as account_sign_1. Wherein, account_sign_1 = Sign(account_A_pri, Hash(device_table1)).

[0044] Sub-step S23, sends the first terminal side trusted device list, the second digital signature, the first certificate and the third public key to the server, so that the server verifies the first certificate through the root certificate public key. If the first certificate is verified successfully, the server obtains the first public key from the first certificate and verifies the second digital signature through the first public key. If the second digital signature is verified successfully, the server verifies the first device information in the first terminal side trusted device list through the third public key, and creates the server side trusted device list if the first device information is verified successfully. It should be noted that the third public key can also be sent to the server in advance, for example, immediately after creation.

[0045] Continuing with the above example, the first terminal-side trusted device list device_table1, the second digital signature account_sign_1, the first certificate account_A_cert and the third public key account_device_pub may be sent to the server.

[0046] The server can store the root certificate public key. The root certificate public key is the public key used to verify all certificates issued by the above CA organization. Since the first certificate is issued by the above CA organization, the validity of the first certificate can be verified by the root certificate public key. The root certificate public key can be recorded as device_root_pub. After receiving the above information, the server can first use the root certificate public key device_root_pub to verify the first certificate account_A_cert to determine its validity.

[0047] If the first certificate account_A_cert fails to be verified, the server may discard the first terminal-side trusted device list device_table1, the second digital signature account_sign_1, and the first certificate account_A_cert. If the first certificate account_A_cert passes the verification, the first public key account_A_pub may be obtained from the first certificate account_A_cert, and the second digital signature account_sign_1 may be verified by the first public key account_A_pub to determine the validity of the second digital signature account_sign_1. The first certificate account_A_cert may include but is not limited to the first public key account_A_pub, the certificate issuer, the certificate holder, the certificate validity period, and other information.

[0048] Among them, when verifying the second digital signature account_sign_1 through the first public key account_A_pub, the first public key account_A_pub and the second digital signature account_sign_1 can be input into the function Verify() for signature verification to obtain the function value Verify(account_A_pub, account_sign_1). If the function value is equal to Hash(device_table1), it is determined that the second digital signature account_sign_1 is verified, and the second digital signature account_sign_1 can be considered valid at this time. Since the second digital signature account_sign_1 is obtained by signing the first terminal side trusted device list, if the second digital signature account_sign_1 is valid, it means that the first terminal side trusted device list device_table1 has not been tampered with or forged. On the contrary, if the function value is not equal to Hash(device_table1), it is determined that the second digital signature account_sign_1 has not been verified. At this time, the second digital signature account_sign_1 can be considered invalid, and its corresponding first terminal side trusted device list device_table1 may be tampered with or forged. In this case, the server can discard the first terminal side trusted device list device_table1, the second digital signature account_sign_1 and the first certificate account_A_cert.

[0049] When the second digital signature account_sign_1 is verified, the first device information in the first terminal side trusted device list device_table1 can be verified through the third public key account_device_pub to determine the validity of the first device information. Here, the first digital signature account_device_sign_1 in the first device information can be verified. If the first digital signature account_device_sign_1 is verified, it can be considered that the first device information is verified, that is, the first device information is valid and has not been tampered with or forged. Conversely, if the first digital signature account_device_sign_1 is not verified, it can be considered that the first device information is not verified, that is, the first device information is invalid and may be tampered with or forged. Specifically, the third public key and the first digital signature account_device_sign_1 are first input into the function Verify() for signature verification to obtain the function value Verify(account_device_pub, account_device_sign_1). If the function value is not equal to Hash(uid_1|device_A_trust_pub), it is determined that the first digital signature account_device_sign_1 has not been verified, and the server can discard the first terminal side trusted device list device_table1, the second digital signature account_sign_1 and the first certificate account_A_cert. If the function value is equal to Hash(uid_1|device_A_trust_pub), it is determined that the first digital signature account_device_sign_1 has been verified, that is, the first device information has been verified. At this time, a server side trusted device list can be created. The server side trusted device list can be recorded as server_table1, and the details can be seen in the following table:

[0050] device_uid device_pub account_device_sign account_sign account_cert uid_1 device_A_trust_pub account_device_sign_1 account_sign_1 account_A_cert

[0051] Among them, device_uid, device_pub, account_device_sign, account_sign, and account_cert are all fields in the table structure, which represent device identification, device public key, device signature, account signature, and account certificate respectively. The server-side trusted device list includes a record, which includes the first device identification uid_1, the second public key device_A_trust_pub, the first digital signature account_device_sign_1, the second digital signature account_sign_1, and the first certificate account_A_cert.

[0052] By sending the first terminal side trusted device list, the second digital signature, the first certificate and the third public key to the server, the server can verify the validity of the first certificate, the second digital signature and the first device information in the first terminal side trusted device list in turn, and ensure that the first public key, the first terminal side trusted device list and the first device information in the first terminal side trusted device list have not been tampered with or forged. In this way, the security of the first device that logs into the above account for the first time can be guaranteed, and it is avoided that other devices will send verification requests to unsafe devices when logging into the same account, thereby ensuring the security of communication.

[0053] Step 102, receiving a verification request for the second device. The verification request is sent from the second device to the first device via the server when the second device logs in to the account and determines that the first device information is stored in the server. The verification request includes the identity information of the second device.

[0054] In this embodiment, after receiving the first device information, the server can verify the first device, store the first device information if the verification is successful, and discard the first device information if the verification fails. Therefore, when the second device logs in to the same account, if it is detected that the first device information exists on the server, it means that the first trusted device has logged in to the account. At this time, a verification request can be sent to the first device via the server, and the first device verifies the second device. The verification request may include the identity information of the second device. The identity information can be used to help the first device verify whether the second device is a trusted device. For example, it may include but is not limited to the certificate, public key and other information of the second device.

[0055] Step 103: Verify the second device based on the identity information.

[0056] In this embodiment, the first device may verify the second device based on the identity information in the verification request to determine whether the second device is a trusted device.

[0057] In some optional implementations of the present embodiment, the second device may store a fourth key pair and a fifth key pair, the fourth key pair including a fourth private key and a fourth public key, and the fifth key pair including a fifth private key and a fifth public key. The identity information includes a second device identifier of the second device, a fifth public key, a second certificate of the fourth public key, and a third digital signature obtained by signing the second device identifier and the fifth public key with the fourth private key. The fourth key pair can be used to sign the subsequently generated list of trusted devices on the second terminal side to ensure that the list of trusted devices on the second terminal side is credible. The fifth key pair can be used to complete communication encryption through key negotiation with other devices. Similar to the first certificate, the second certificate can also be generated by the CA organization on the server side after authenticating the fourth public key. The third digital signature can be generated in a similar manner to the first digital signature. To avoid repetition, it will not be repeated here.

[0058] Similar to the first device, the second device may also run two systems, one of which is an operating system, such as an Android operating system. The other system is a TEE system, which is used to provide a trusted execution environment. The fourth key pair and the fifth key pair may be generated in the TEE. Conventional key generation tools or key generation instructions may be used to randomly generate the fourth key pair and the fifth key pair. As an example, the fourth key pair may be recorded as {account_B_pri, account_B_pub}, wherein the fourth private key is account_B_pri and the fourth public key is account_B_pub. The fifth key pair may be recorded as {device_B_trust_pri, device_B_trust_pub}, wherein the fifth private key is device_B_trust_pri and the fifth public key is device_B_trust_pub. By randomly generating the fourth key pair and the fifth key pair by the second device, the process of establishing a trusted device does not depend on the key pair built into the chip when the second device leaves the factory, and the trust relationship between devices can be established more flexibly and conveniently.

[0059] Similar to the first device, the fifth key pair can also use the key pair built into the chip of the second device when it leaves the factory. In this case, for easy distinction, the fifth key pair can be recorded as {device_B_pri, device_B_pub}, where the fifth private key is device_B_pri and the fifth public key is device_B_pub. By using the key pair built into the chip of the second device when it leaves the factory as the fifth key pair for key negotiation with other devices to complete communication encryption, the process of generating the fifth key pair can be omitted to improve the efficiency of establishing a trust relationship between devices, and at the same time, the key pair resources built into the chip of the fifth device when it leaves the factory can be fully utilized to reduce the occupation of some storage space.

[0060] On this basis, see Figure 2 , step 103 may include the following sub-steps:

[0061] Sub-step S301, displaying a first prompt message. The first prompt message can be used to prompt the user to confirm to perform trusted device verification on the second device. The first prompt message can be displayed in a pop-up window or other manner.

[0062] Sub-step S302, in response to the first input of the first prompt information, the second certificate is verified by the root certificate public key. The first input can be a touch input, or a voice command, or a specific gesture input by the user, or other feasible input, which can be determined according to actual use requirements, and is not limited in the embodiments of the present application. The specific gesture in the embodiments of the present application can be any one of a single-click gesture, a sliding gesture, a drag gesture, a pressure recognition gesture, a long press gesture, an area change gesture, a double-press gesture, and a double-click gesture. The click input in the embodiments of the present application can be a single-click input, a double-click input, or any number of click inputs, etc., and can also be a long press input or a short press input.

[0063] As an example, the second certificate can be recorded as account_B_cert. The root certificate public key stored in the first device is the same as the root certificate public key device_root_pub in the server, which can be pre-acquired from the server. Since the second certificate is issued by the CA organization of the server, the root certificate public key device_root_pub can be used to verify the validity of the second certificate account_B_cert.

[0064] Sub-step S303, when the second certificate is verified successfully, obtain the fourth public key from the second certificate, and verify the third digital signature by using the fourth public key.

[0065] Continuing with the above example, the third digital signature can be recorded as req_sign. The second certificate account_B_cert may include, but is not limited to, the fourth public key account_B_pub, the certificate issuer, the certificate holder, the certificate validity period, and other information. Since the second certificate account_B_cert is the certificate of the fourth public key account_B_pub, if the second certificate account_B_cert is verified, it can be considered that the fourth public key account_B_pub in the second certificate account_B_cert has not been tampered with or forged. The fourth public key account_B_pub can be obtained from the second certificate account_B_cert, and the third digital signature req_sign can be verified by the fourth public key account_B_pub to determine the validity of the third digital signature req_sign.

[0066] The second device identifier can be recorded as uid_2. Taking the fifth key pair as {device_B_trust_pri, device_B_trust_pub} as an example, when the third digital signature req_sign is verified by the fourth public key account_B_pub, the fourth public key account_B_pub and the third digital signature req_sign can be input into the function Verify() for signature verification to obtain the function value Verify(account_B_pub, req_sign). If the function value is equal to Hash(uid_2|device_B_trust_pub), it is determined that the third digital signature req_sign has been verified. Conversely, if the function value is not equal to Hash(uid_2|device_B_trust_pub), it is determined that the third digital signature req_sign has not been verified.

[0067] Sub-step S304, when the third digital signature is verified, it is determined that the second device is verified. Here, if the third digital signature req_sign is verified, it can be considered that the third digital signature req_sign is valid. Since the third digital signature is obtained by signing the second device identifier uid_2 and the fifth public key device_B_trust_pub with the fourth private key, if the third digital signature req_sign is valid, it can be considered that the second device identifier uid_2 and the fifth public key device_B_trust_pub have not been tampered with or forged. Therefore, it can be determined that the second device is verified.

[0068] By responding to the first input of the first prompt information, and verifying the second certificate and the third digital signature of the second device in sequence, and confirming that the verification of the second device has passed when all verifications have passed, it can be ensured that the verification request of the second device has not been tampered with or forged during the transmission process, and that the second device is a safe and trustworthy device, thereby improving the security of communication.

[0069] In some optional implementations of this embodiment, the first device may store a third certificate of the second public key. The second device may store a fifth key pair. The fifth key pair includes a fifth private key and a fifth public key. When the second device logs in to the account and chooses to have the first device provide the verification code, it may send a verification request to the first device. The identity information carried in the verification request may include a fourth certificate of the fifth public key.

[0070] As an example, the key pair {device_A_pri, device_A_pub} built into the first device when it leaves the factory can be used as the second key pair, and the key pair {device_B_pri, device_B_pub} built into the second device when it leaves the factory can be used as the fifth key pair. Thus, the second private key is device_A_pri, the second public key is device_A_pub, the fifth private key is device_B_pri, and the fifth public key is device_B_pub. The third certificate is a certificate obtained after the second public key device_A_pub is authenticated by the CA organization, which can be recorded as device_A_cert. The third certificate can be built into the first device when the first device leaves the factory. The fourth certificate is a certificate obtained after the fifth public key device_B_pub is authenticated by the CA organization, which can be recorded as device_B_cert. The fourth certificate can be built into the second device when the first device leaves the factory.

[0071] On this basis, see Figure 3 , step 103 may include the following sub-steps:

[0072] Sub-step S401, verifying the fourth certificate by using the root certificate public key. Continuing the above example, the root certificate public key device_root_pub may be used to verify the fourth certificate device_B_cert to determine the validity of the fourth certificate device_B_cert.

[0073] Sub-step S402, when the fourth certificate is verified, the fifth public key is obtained from the fourth certificate, and the second prompt information is displayed. The above second prompt information can be used to prompt the user to trigger the calculation and display of the verification code. The second prompt information can be displayed in a pop-up window or the like. Continuing with the above example, the fourth certificate device_B_cert may include but is not limited to the fifth public key device_B_pub, the certificate issuer, the certificate holder, the certificate validity period and other information. Since the fourth certificate device_B_cert is the certificate of the fifth public key device_B_pub, when the fourth certificate device_B_cert is verified, it can be considered that the fifth public key device_B_pub in the fourth certificate device_B_cert has not been tampered with or forged, and the fifth public key device_B_pub can be obtained from the fourth certificate device_B_cert.

[0074] Sub-step S403, upon receiving the second input of the user to the second prompt information, a random number is generated, and a one-time password is obtained locally. As an example, a six-digit random number can be generated and recorded as rand_Num. The above-mentioned first password can also be a six-digit password, which can be recorded as OTP_Num. In practice, OTP_Num can be built into the server and the logged-in device, and the server can verify whether it has been approved by the device of the logged-in account by verifying OTP_Num.

[0075] Sub-step S404, based on the random number and the one-time password, generate a verification code. Continuing the above example, the verification code can be recorded as show_Num, which can be calculated according to a predefined rule. For example, show_Num = ((rand_Num + OTP_Num) mod 1000000). Wherein, mod is a modulo function.

[0076] Sub-step S405: Generate a first negotiated key based on the fifth public key and the second private key. Continuing with the above example, the first negotiated key can be recorded as shared_AB_key. shared_AB_key=SHARE(device_B_pub, device_A_pri).

[0077] Sub-step S406: Generate a second negotiated key based on the fifth public key, the second private key and the verification code. Continuing with the above example, the second negotiated key can be recorded as shared_AB_password_key. shared_AB_password_key=SHARE(device_B_pub, device_A_pri, show_Num).

[0078] Sub-step S407, encrypt the random number using the first negotiated key to obtain a second ciphertext. Continuing with the above example, the second ciphertext can be recorded as cipher_num. cipher_num = Enc (shared_AB_key, rand_Num).

[0079] Sub-step S408, encrypt the third key pair with the second negotiated key to obtain a third ciphertext. Continuing with the above example, the third ciphertext can be recorded as cipher_key. cipher_key = Enc (shared_AB_password_key, {account_device_pri, account_device_pub}).

[0080] Sub-step S409: sending the third certificate, the second ciphertext and the third ciphertext to the second device via the server, so that the second device decrypts the second ciphertext and the third ciphertext based on the verification code to obtain a random number and a third key pair.

[0081] Continuing with the above example, the first device may send the third certificate device_A_cert, the second ciphertext cipher_num and the third ciphertext cipher_key to the second device via the server.

[0082] Here, the second device can also use the root certificate public key device_root_pub to verify the third certificate device_A_cert. After the verification is passed, the second public key device_A_pub can be obtained from the third certificate device_A_cert, and key negotiation can be performed based on the second public key device_A_pub and its own fifth private key device_B_pub to obtain the first negotiated key shared_AB_key. shared_AB_key=SHARE(device_A_pub, device_B_pri). Similarly, key negotiation can be performed using the second public key device_A_pub, its own fifth private key device_B_pub and the verification code show_Num to obtain the second negotiated key shared_AB_password_key. shared_AB_password_key=SHARE(device_A_pub, device_B_pri, show_Num).

[0083] Next, the second device may decrypt the second ciphertext cipher_num based on the first negotiated key shared_AB_key to obtain a random number rand_Num. rand_Num = Dec (shared_AB_key, cipher_num). And, the third ciphertext cipher_key may be decrypted based on the second negotiated key shared_AB_password_key to obtain a third key pair {account_device_pri, account_device_pub}. {account_device_pri, account_device_pub} = Dec (shared_AB_password_key, cipher_key).

[0084] Sub-step S410, displaying the verification code so that the user inputs the verification code into the second device, and the second device determines the one-time password based on the verification code and the random number. Here, after completing the data transmission of sub-step S409, the first device can display the verification code.

[0085] Continuing with the above example, the first device can display the verification code show_Num. After the user enters the verification code show_Num displayed in the first device on the second device, the second device can calculate the one-time password OTP_Num based on the verification code show_Num using the same rule. For example, OTP_Num = ((show_Num – rand_Num) mod 1000000). Then, the second device can complete the account login verification based on the one-time password OTP_Num.

[0086] Sub-step S411, when the one-time password generated by the second device is verified successfully, determining that the second device verification is successful.

[0087] When the second device successfully logs into the account, the first device that has logged into the same account provides a verification code, and the user enters the verification code into the second device to verify the second device, which can further improve the accuracy of the verification of the second device.

[0088] In practice, after the second device successfully logs in to the account, the second device can generate a fourth key pair {account_B_pri, account_B_pub} in its TEE environment, where account_B_pri is the fourth private key and account_B_pub is the fourth public key. The fourth public key account_B_pub can then be sent to the server to obtain the second certificate account_B_cert of the fourth public key through the CA organization of the server. Afterwards, the second device can download the server-side trusted device list server_table3 from the server, as shown in the following table:

[0089] device_uid device_pub account_device_sign account_sign account_cert uid_1 device_A_pub account_device_sign_1 account_sign_1 account_A_cert

[0090] Next, the second device can use the root certificate public key account_root_pub to verify the first certificate account_A_cert in the server-side trusted device list server_table3. After the verification is passed, the trusted first public key account_A_pub is obtained from the first certificate.

[0091] Next, the second device can verify the second digital signature account_sign_1 in the server-side trusted device list server_table3 through the first public key account_A_pub. That is, determine whether Verify(account_A_pub, account_sign_1) is equal to Hash(device_table1). If so, it indicates that the server-side trusted device list server_table3 has not been tampered with.

[0092] Next, the second device can use the third public key account_device_pub to verify the device information in the server-side trusted device list server_table3 line by line, specifically verifying the digital certificate in the device information to determine whether Verify(account_device_pub, account_device_sign_n) is equal to Hash(uid_n|device_X_trust_pub). After that, create a second terminal-side trusted device list, and write the verified device information into the second terminal-side trusted device list device_table4. For details, see the following table:

[0093] device_uid device_pub account_device_sign uid_1 device_A_pub account_device_sign_1

[0094] Next, the second device signs the second device identifier uid_2 and the fifth public key device_B_pub with the third private key to obtain the fourth digital signature account_device_sign_2. account_device_sign_2 = Sign(account_device_pri, Hash(uid_2|device_B_pub)). Afterwards, the second device information including the second device identifier uid_2, the fifth public key device_B_pub and the fourth digital signature account_device_sign_2 is added as a record to the second terminal side trusted device list to obtain device_table5. For details, see the following table:

[0095] device_uid device_pub account_device_sign uid_1 device_A_pub account_device_sign_1 uid_2 device_B_pub account_device_sign_2

[0096] Next, the second device may use the first public key account_A_pub to sign the updated second terminal side trusted device list device_table5 to obtain the fifth digital signature account_sign_2. account_sign_2=Sign(account_B_pri, Hash(device_table5)), and send the second terminal side trusted device list device_table5, the fifth digital signature account_sign_2 and the second certificate account_B_cert to the server.

[0097] Next, the server can first use the root certificate public key account_root_pub to verify the second certificate account_A_cert. After the verification is passed, the fourth public key account_B_pub is obtained from the second certificate account_B_cert. After that, the fifth digital signature account_sign_2 is verified using the fourth public key account_B_pub. For example, determine whether Verify(account_B_pub, account_sign_2) is equal to Hash(device_table5). If the fifth digital signature account_sign_2 is verified, the server can use the third public key account_device_pub to verify each device information in the second terminal side trusted device list device_table5 line by line. For example, whether Verify(account_device_pub, account_device_sign_n) is equal to Hash(uid_n|device_X_trust_pub). After all verifications are completed, the server side trusted device list will be updated to obtain server_table4. For details, please refer to the table below:

[0098]

[0099] Step 104: When the second device passes the verification, a trust relationship is established with the second device.

[0100] In this embodiment, if the second device passes the verification, a trust relationship can be established with the second device. After establishing the trust relationship, the first device and the second device can generate a negotiation key with the help of their own private keys and the other party's public key, encrypt the data through the negotiation key, forward the encrypted ciphertext to the other party via the server, and decrypt the ciphertext from the other party forwarded via the server through the negotiation key to obtain the original data. Since the private key of the device is only built into the device locally, a third-party device or the server cannot generate the same negotiation key, and therefore cannot decrypt the ciphertext to obtain the original data, thereby enabling secure communication between trusted devices.

[0101] In addition, since the data can be encrypted and transferred to the other party through the server during the communication process with the second device, the first device and the second device logged in to the same account can communicate securely at any distance, without relying on the local area network environment, enriching the applicable scenarios of communication between devices.

[0102] In some optional implementations of this embodiment, based on the first implementation in step 103, the first device may establish a trust relationship with the second device through the following steps:

[0103] Sub-step S305, the fifth public key is signed by the third private key to obtain a fourth digital signature. Continuing the above example, the fifth public key device_B_trust_pub is signed by the third private key account_device_pri, and the obtained fourth digital signature can be recorded as account_device_sign_2. account_device_sign_2 = Sign (account_device_pri, Hash (uid_2 | device_B_trust_pub)).

[0104] Sub-step S306, add the second device information of the second device to the first terminal side trusted device list, the second device information includes the second device identification, the fifth public key and the fourth digital signature. Continuing with the above example, the first terminal side trusted device list after adding the second device information can be recorded as device_table2, and the details can be seen in the following table:

[0105] device_uid device_pub account_device_sign uid_1 device_A_trust_pub account_device_sign_1 uid_2 device_B_trust_pub account_device_sign_2

[0106] Among them, the devices in the above-mentioned first terminal-side trusted device list have a trust relationship.

[0107] By using the third private key to sign the fifth public key to obtain a fourth digital signature when the above-mentioned second device verification is passed, and adding the second device information including the second device identifier, the fifth public key and the fourth digital signature to the first terminal side trusted device list, the first terminal side trusted device list in the first device is automatically updated when the second device is confirmed to be a trusted device, thereby facilitating the maintenance of the trust relationship.

[0108] By adding the second device information to the trusted device list on the first terminal side, a trust relationship can be established with the second device based on the second device information, so that the first device and the second device can communicate securely. In addition, by updating the trusted device list on the first terminal side, it is also convenient to synchronize the trusted devices to the server side in the future, so that the server side can obtain more accurate information about the trusted devices.

[0109] Furthermore, in some optional implementations of this embodiment, after establishing a trust relationship with the second device, the first device may also perform the following steps:

[0110] Sub-step S307, using the first private key to sign the first terminal side trusted device list after adding the second device information, to obtain a fifth digital signature. Continuing the above example, using the first private key account_A_pri to sign the first terminal side trusted device list device_table2 after adding the second device information, the obtained fifth digital signature can be recorded as account_sign_2. account_sign_2 = Sign (account_A_pri, Hash (device_table2)).

[0111] In sub-step S308, the first terminal side trusted device list after adding the second device information, the fifth digital signature and the first certificate are sent to the server, so that the server verifies the first certificate through the root certificate public key. If the first certificate is verified successfully, the server obtains the first public key from the first certificate and verifies the fifth digital signature through the first public key. If the fifth digital signature is verified successfully, the server verifies each device information in the first terminal side trusted device list after adding the second device information through the third public key, and updates the server side trusted device list based on the verification results of each device information.

[0112] Continuing the above example, the first device can send the first terminal side trusted device list device_table2, the fifth digital signature account_sign_2 and the first certificate account_A_cert after adding the second device information to the server. After receiving the above information, the server can first use the root certificate public key device_root_pub to verify the first certificate account_A_cert to determine its validity.

[0113] If the first certificate account_A_cert fails to be verified, the server may discard the first terminal-side trusted device list device_table2, the fifth digital signature account_sign_2, and the first certificate account_A_cert after adding the second device information. If the first certificate account_A_cert passes the verification, the first public key account_A_pub may be obtained from the first certificate account_A_cert, and the fifth digital signature account_sign_2 may be verified by the first public key account_A_pub to determine the validity of the fifth digital signature account_sign_2.

[0114] Among them, when the fifth digital signature account_sign_2 is verified by the first public key account_A_pub, the first public key account_A_pub and the fifth digital signature account_sign_2 can be input into the function Verify() for signature verification to obtain the function value Verify(account_A_pub, account_sign_2). If the function value is equal to Hash(device_table2), it is determined that the fifth digital signature account_sign_2 is verified, and the fifth digital signature account_sign_2 can be considered valid at this time. Since the fifth digital signature account_sign_2 is obtained after signing device_table2, if the fifth digital signature account_sign_2 is valid, it means that device_table2 has not been tampered with or forged. On the contrary, if the function value is not equal to Hash(device_table2), it is determined that the fifth digital signature account_sign_2 is not verified, and the fifth digital signature account_sign_2 can be considered invalid at this time, and device_table2 may be tampered with or forged. In this case, the server may discard the first terminal-side trusted device list device_table2, the fifth digital signature account_sign_2, and the first certificate account_A_cert after adding the second device information.

[0115] When the fifth digital signature account_sign_2 is verified, the device information in device_table2 can be verified by the third public key account_device_pub to determine the validity of each device information. The device information in device_table2 may include the first device information and the second device information. In practice, the device information is verified by verifying the digital signature in the device information. Specifically, the digital signature in each device information in device_table2 can be verified line by line using the third public key account_device_pub. Determine whether the function value of Verify(account_device_pub, account_device_sign_n) is equal to Hash(uid_n|device_X_trust_pub). n is 1, 2,…. X=A, B…. For the digital signature account_device_sign_n, if the function value Verify(account_device_pub, account_device_sign_n) is equal to Hash(uid_n|device_X_trust_pub), it is determined that the digital signature account_device_sign_n has been verified, and it can be considered that the device information containing the digital signature account_device_sign_n has been verified, and the device information is valid and has not been tampered with or forged. On the contrary, if the function value Verify(account_device_pub, account_device_sign_n) is not equal to Hash(uid_n|device_X_trust_pub), it is determined that the digital signature account_device_sign_n has not been verified, and it can be considered that the device information containing the digital signature account_device_sign_n has not been verified, and the device information may have been tampered with or forged.

[0116] After verifying the device information in device_table2, the server-side trusted device list server_table1 can be updated based on the verification results of each device information to obtain server_table2. Continuing with the above example, if both the first device information and the second device information are verified, the obtained server_table2 can be specifically referred to in the following table:

[0117]

[0118] By sending the updated first terminal side trusted device list, the fifth digital signature and the first certificate to the server, the server can verify the validity of the first certificate, the fifth digital signature and the updated first terminal side trusted device list, and ensure that the first public key, the updated first terminal side trusted device list and the device information of each device in the list have not been tampered with or forged. In this way, the security of each trusted device can be guaranteed, and the security of communication can be guaranteed.

[0119] Furthermore, in some optional implementations of this embodiment, after establishing a trust relationship with the second device, the first device may also perform the following steps:

[0120] Sub-step S309, based on the fifth public key and the second private key, generate a first negotiated key. In practice, key agreement refers to the process in which two parties who need to communicate confidentially reach a shared secret key through public channel communication, and the key is called a negotiated key. Through key agreement, each participant can generate the same negotiated key without directly exchanging keys, and then encrypt the data with the negotiated key for secure communication. Key agreement can be implemented through specific encryption algorithms and protocols, such as RSA encryption algorithm, ECC encryption algorithm, etc. The design of these algorithms and protocols ensures that even without sharing keys in advance, the communicating parties can generate the same session key by exchanging information, thereby achieving secure communication. As an example, the first negotiated key can be recorded as shared_AB_key. shared_AB_key=SHARE(device_B_trust_pub, device_A_trust_pri). Among them, SHARE() can represent a key agreement function, for example, the function of the above-mentioned RSA encryption algorithm and ECC encryption algorithm.

[0121] Sub-step S310, encrypt the third key pair with the first negotiated key to obtain a first ciphertext. Continuing the above example, the first ciphertext can be recorded as account_device_key_cipher. account_device_key_cipher = Enc(shared_AB_key, {account_device_pri, account_device_pub}). Wherein, Enc() represents an encryption function.

[0122] Sub-step S311, sending the first ciphertext to the second device via the server, so that the second device generates a first negotiated key based on the second public key and the fifth private key, and decrypts the first ciphertext based on the first negotiated key to obtain a third key pair. Upon receiving the updated server-side trusted device list issued by the server, the second device verifies the first certificate through the root certificate public key. Upon successful verification of the first certificate, the second device obtains the first public key from the first certificate and verifies the fifth digital signature through the first public key. Upon successful verification of the fifth digital signature, the second device verifies each device information in the updated server-side trusted device list through the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

[0123] Continuing with the above example, the first device may send the first ciphertext account_device_key_cipher to the second device via the server. After receiving the first ciphertext account_device_key_cipher, the second device may first generate the first negotiated key shared_AB_key based on the second public key device_A_trust_pub and the fifth private key device_B_trust_pub. shared_AB_key=SHARE(device_A_trust_pub,device_B_trust_pub). Then, the second device may decrypt the first ciphertext account_device_key_cipher based on the first negotiated key shared_AB_key to obtain the third key pair {account_device_pri,account_device_pub}. {account_device_pri,account_device_pub}=Dec(shared_AB_key,account_device_key_cipher). Wherein, Dec() represents the decryption function.

[0124] After updating the server-side trusted device list, the server may send the updated server-side trusted device list server_table2 to the second device. When the second device receives the updated server-side trusted device list server_table2 sent by the server, it may first use the root certificate public key device_root_pub to verify the first certificate account_A_cert to determine its validity. When the first certificate account_A_cert passes the verification, the first public key account_A_pub may be obtained from the first certificate account_A_cert, and the fifth digital signature account_sign_2 may be verified by the first public key account_A_pub to determine the validity of the fifth digital signature account_sign_2. When the fifth digital signature account_sign_2 passes the verification, the device information in device_table2 may be verified by the third public key account_device_pub to determine the validity of the device information. The device information in device_table2 may include the first device information and the second device information. After verifying the device information in device_table2, a second terminal side trusted device list device_table3 may be created based on the verification results of the device information. For details, see the following table:

[0125] device_uid device_pub account_device_sign uid_1 device_A_trust_pub account_device_sign_1 uid_2 device_B_trust_pub account_device_sign_2

[0126] It should be noted that the verification process of the first certificate, the fifth digital signature, and each device information by the second device is the same as the verification process of the server in the above implementation method. To avoid repetition, it will not be repeated here.

[0127] By generating the first negotiated key based on the fifth public key of the second device and the second private key of the first device when the second device passes the verification, and then encrypting the third key pair based on the first negotiated key to obtain the first ciphertext, and sending it to the second device via the server, the second device can receive the first ciphertext regardless of whether it is in the same local area network as the first device. Since the first ciphertext needs to be decrypted using the first negotiated key, and the first negotiated key needs to be generated using the private key of the device, and the private key is only stored locally on the device, the server cannot obtain the plaintext data in the first ciphertext when transferring it, thus ensuring the security of communication.

[0128] The second device obtains the same first negotiation key through key negotiation, and then uses the first negotiation key to decrypt the first ciphertext to obtain the third key pair, and then verifies each information device in the server-side trusted device list issued by the server-side based on the third public key, and finally synchronizes the verification results based on each device information, so as to achieve synchronization of the terminal-side trusted device list. Since the trusted devices in the trusted device list have a trust relationship, it is convenient for the second device to maintain the trust relationship between devices.

[0129] In some optional implementations of this embodiment, based on the second implementation in step 103, the first device may establish a trust relationship with the second device through the following steps:

[0130] Sub-step S412, when the second device is verified and the server-side trusted device list in the server is updated, the updated server-side trusted device list is downloaded from the server. The server-side trusted device list is updated based on the second terminal-side trusted device list sent by the second device, and the second terminal-side trusted device list includes the first device information and the second device information, and the second device information includes the second device identifier of the second device, the fifth public key, and the fourth digital signature obtained by signing the fifth public key with the third private key. Continuing with the above example, the updated server-side trusted device list downloaded from the server is server_table4. Server_table4 includes the first device information, the second device information, the fifth digital signature account_sign_2, and the second certificate account_B_cert. The first device information includes the first device identifier uid_1, the second public key device_A_pub, and the first digital signature account_device_sign_1. The second device information includes the second device identifier uid_1, the fifth public key device_B_pub, and the fourth digital signature account_device_sign_2.

[0131] Sub-step S413, verifying the device information in the updated server-side trusted device list. The verification process here can refer to the verification process of the device information in the server-side trusted device list in the above implementation, or can refer to the verification process of the device information in the first terminal-side trusted device list or the second terminal-side trusted device list in the above implementation. To avoid repetition, it will not be repeated here.

[0132] Sub-step S414: based on the verification results of each device information, update the first terminal side trusted device list. Here, the verified device information can be added to the first terminal side trusted device list to update the first terminal side trusted device list.

[0133] By adding the second device information to the trusted device list on the first terminal side, a trust relationship can be established with the second device based on the second device information, so that the first device and the second device can communicate securely.

[0134] The method provided by the above-mentioned embodiment of the present application sends the first device information of the first device to the server when the first device logs in to the account and the first device is the first device to log in to the account; when receiving a verification request for the second device, the second device is verified based on the identity information of the second device in the verification request; when the second device passes the verification, a trust relationship is established with the second device. Since the verification request for the second device is sent from the second device to the first device via the server when the second device logs in to the same account and determines that the first device information is stored in the server, in the process of building a trust relationship with the second device, the server is used for information transmission, so that a trust relationship can be established with a device that logs in to the same account at any distance, without limiting the devices to be in the same local area network environment, avoiding the distance limit for building a trust relationship between devices, and enriching the applicable scenarios for building a trust relationship between devices.

[0135] It should be noted that the execution subject of the method for establishing a trust relationship between devices provided in the embodiment of the present application can be a device for establishing a trust relationship between devices. In the embodiment of the present application, the device for establishing a trust relationship between devices executing the method for establishing a trust relationship between devices is taken as an example to illustrate the device for establishing a trust relationship between devices provided in the embodiment of the present application.

[0136] like Figure 4 As shown, the device 400 for establishing a trust relationship between devices in this embodiment includes: a first sending unit 401, used to send the first device information of the first device to the server when the first device logs in to the account and the first device is the first login device of the account; a receiving unit 402, used to receive a verification request for the second device, the verification request is sent by the second device to the first device via the server when the second device logs in to the account and determines that the first device information is stored in the server, and the verification request includes the identity information of the second device; a verification unit 403, used to verify the second device based on the identity information; an establishing unit 404, used to establish a trust relationship with the second device when the second device passes the verification.

[0137] In some optional implementations of the present embodiment, the first sending unit 401 is further used to: create a first terminal-side trusted device list when the first device logs in to an account and the first device is the first login device of the account, the first terminal-side trusted device list including first device information of the first device; send the first terminal-side trusted device list to the server, so that the server creates a server-side trusted device list based on the first terminal-side trusted device list after verifying the first terminal-side trusted device list, and the server-side trusted device list includes the first device information.

[0138] In some optional implementations of the present embodiment, the first sending unit 401 is also used to: when the first device logs in to an account and the first device is the first login device of the account, obtain a first key pair, a second key pair, and a third key pair, the first key pair including a first private key and a first public key, the second key pair including a second private key and a second public key, and the third key pair including a third private key and a third public key; sign the first device identifier of the first device and the second private key with the third private key to obtain a first digital signature; create a first terminal-side trusted device list, the first terminal-side trusted device list including first device information of the first device, and the first device information including the first device identifier, the second public key and the first digital signature.

[0139] In some optional implementations of the present embodiment, the first sending unit 401 is further used to: send the first public key to the server to obtain the first certificate of the first public key returned by the server; sign the first terminal side trusted device list by the first private key to obtain a second digital signature; send the first terminal side trusted device list, the second digital signature, the first certificate and the third public key to the server, so that the server verifies the first certificate by the root certificate public key, and when the first certificate is verified successfully, the server obtains the first public key from the first certificate and verifies the second digital signature by the first public key, and when the second digital signature is verified successfully, the server verifies the first device information in the first terminal side trusted device list by the third public key, and when the first device information is verified successfully, creates a server side trusted device list.

[0140] In some optional implementations of this embodiment, the second device stores a fourth key pair and a fifth key pair, the fourth key pair includes a fourth private key and a fourth public key, and the fifth key pair includes a fifth private key and a fifth public key; the identity information includes the second device identification of the second device, the fifth public key, the second certificate of the fourth public key, and the third digital signature obtained by signing the second device identification and the fifth public key with the fourth private key; the verification unit 403 is also used to: display a first prompt message; in response to a first input of the first prompt message, verify the second certificate with the root certificate public key; when the second certificate is verified successfully, obtain the fourth public key from the second certificate, and verify the third digital signature with the fourth public key; when the third digital signature is verified successfully, determine that the second device is verified successfully.

[0141] In some optional implementations of this embodiment, the establishing unit 404 is also used to: sign the fifth public key through the third private key to obtain a fourth digital signature; add the second device information of the second device to the first terminal side trusted device list, the second device information including the second device identifier, the fifth public key and the fourth digital signature, wherein the devices in the first terminal side trusted device list have a trust relationship.

[0142] In some optional implementations of this embodiment, the device also includes a second sending unit, which is used to: when the second device is verified, sign the first terminal side trusted device list after adding the second device information through the first private key to obtain a fifth digital signature; send the first terminal side trusted device list after adding the second device information, the fifth digital signature and the first certificate to the server, so that the server verifies the first certificate through the root certificate public key, and when the first certificate is verified, the server obtains the first public key from the first certificate and verifies the fifth digital signature through the first public key, and when the fifth digital signature is verified, the server verifies each device information in the first terminal side trusted device list after adding the second device information through the third public key, and updates the server side trusted device list based on the verification results of each device information.

[0143] In some optional implementations of this embodiment, the device also includes a third sending unit, which is used to: generate a first negotiation key based on the fifth public key and the second private key; encrypt the third key pair by using the first negotiation key to obtain a first ciphertext; send the first ciphertext to the second device via the server, so that the second device generates the first negotiation key based on the second public key and the fifth private key, and decrypts the first ciphertext based on the first negotiation key to obtain the third key pair. When the second device receives the updated server-side trusted device list issued by the server, the first certificate is verified by the root certificate public key. When the first certificate is verified successfully, the second device obtains the first public key from the first certificate and verifies the fifth digital signature by using the first public key. When the fifth digital signature is verified successfully, the second device verifies each device information in the updated server-side trusted device list by using the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

[0144] In some optional implementations of this embodiment, the first device stores a third certificate of the second public key, the second device stores a fifth key pair, the fifth key pair includes a fifth private key and a fifth public key, and the identity information includes a fourth certificate of the fifth public key; the verification unit 403 is further used to: verify the fourth certificate through the root certificate public key; if the fourth certificate verification passes, obtain the fifth public key from the fourth certificate and display a second prompt message; when receiving the second input of the user to the second prompt message, generate a random number and obtain a one-time password locally; based on the random number and the one-time password, generate a verification code; based on the fifth public key and the second private key, generate a first negotiated key; based on the fifth public key and the second private key, generate a first negotiated key; based on the fifth public key The server comprises a server and a server. The server comprises a first certificate, a second certificate and a second ciphertext. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device. The server comprises a server and a second device.

[0145] In some optional implementations of this embodiment, the establishing unit 404 is also used to: when the second device verification is passed, when the second device verification is passed and there is an update to the server-side trusted device list in the server, download the updated server-side trusted device list from the server, wherein the server-side trusted device list is updated based on the second terminal-side trusted device list sent by the second device, the second terminal-side trusted device list includes the first device information and the second device information, the second device information includes the second device identifier of the second device, the fifth public key, and the fourth digital signature obtained by signing the fifth public key with the third private key; verify each device information in the updated server-side trusted device list; and update the first terminal-side trusted device list based on the verification results of each device information.

[0146] The device provided by the above-mentioned embodiment of the present application sends the first device information of the first device to the server when the first device logs in to the account and the first device is the first device to log in to the account; when receiving a verification request for the second device, the second device is verified based on the identity information of the second device in the verification request; when the second device passes the verification, a trust relationship is established with the second device. Since the verification request for the second device is sent from the second device to the first device via the server when the second device logs in to the same account and determines that the first device information is stored in the server, in the process of building a trust relationship with the second device, the server is used for information transmission, so that a trust relationship can be established with a device that logs in to the same account at any distance, without limiting the devices to be in the same local area network environment, avoiding the distance limit for building a trust relationship between devices, and enriching the applicable scenarios for building a trust relationship between devices.

[0147] The device for establishing a trust relationship between devices in the embodiment of the present application can be an electronic device, or a component in an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal, or it can be other devices other than a terminal. Exemplarily, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a PDA, a vehicle-mounted electronic device, a mobile Internet device (Mobile Internet Device, MID), an augmented reality (Augmented Reality, AR) / virtual reality (Virtual Reality, VR) device, a robot, a wearable device, a super mobile personal computer (Ultra-Mobile Personal Computer, UMPC), a netbook or a personal digital assistant (Personal Digital Assistant, PDA), etc., and can also be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (Personal Computer, PC), a television (Television, TV), a teller machine or a self-service machine, etc., and the embodiment of the present application is not specifically limited.

[0148] The device for establishing a trust relationship between devices in the embodiment of the present application may be a device having an operating system. The operating system may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0149] The device for establishing a trust relationship between devices provided in the embodiment of the present application can achieve Figure 1 To avoid repetition, the various processes implemented by the method embodiment are not described here.

[0150] Alternatively, if Figure 5 As shown, an embodiment of the present application also provides an electronic device 500, including a processor 501 and a memory 502, wherein the memory 502 stores programs or instructions that can be executed on the processor 501, and when the program or instructions are executed by the processor 501, the various steps of the above-mentioned embodiment of the method for establishing a trust relationship between devices are implemented, and the same technical effect can be achieved. To avoid repetition, they are not described here.

[0151] It should be noted that the electronic devices in the embodiments of the present application include the above-mentioned mobile electronic devices and non-mobile electronic devices.

[0152] Figure 6 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of the present application.

[0153] The electronic device 600 includes but is not limited to: a radio frequency unit 601, a network module 602, an audio output unit 603, an input unit 604, a sensor 605, a display unit 606, a user input unit 607, an interface unit 608, a memory 609, and a processor 610.

[0154] Those skilled in the art will appreciate that the electronic device 600 may also include a power source (such as a battery) for supplying power to each component, and the power source may be logically connected to the processor 610 through a power management system, thereby implementing functions such as managing charging, discharging, and power consumption management through the power management system. Figure 6 The electronic device structure shown in the figure does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently, which will not be described in detail here.

[0155] Among them, the processor 610 is used to send the first device information of the first device to the server when the first device logs in to the account and the first device is the first login device of the account; receive a verification request for the second device, the verification request is sent by the second device to the first device via the server when the second device logs in to the account and determines that the first device information is stored in the server, and the verification request includes the identity information of the second device; based on the identity information, verify the second device; if the second device passes the verification, establish a trust relationship with the second device.

[0156] Since the verification request for the second device is sent by the second device to the first device via the server when the second device logs in to the same account and determines that the first device information is stored in the server, in the process of building a trust relationship with the second device, the server is used for information transmission, so that a trust relationship can be established with a device logged in to the same account at any distance, without restricting the devices to be in the same local area network environment, avoiding distance limitations on building trust relationships between devices, and enriching the applicable scenarios for building trust relationships between devices.

[0157] In some optional implementations, the processor 610 is further used to create a first terminal-side trusted device list when the first device logs in to an account and the first device is the first login device of the account, the first terminal-side trusted device list including first device information of the first device; and send the first terminal-side trusted device list to the server, so that the server creates a server-side trusted device list based on the first terminal-side trusted device list after verifying the first terminal-side trusted device list, the server-side trusted device list including the first device information.

[0158] In some optional implementations, the processor 610 is also used to obtain a first key pair, a second key pair, and a third key pair when the first device logs in to an account and the first device is the first login device for the account, the first key pair including a first private key and a first public key, the second key pair including a second private key and a second public key, and the third key pair including a third private key and a third public key; sign the first device identifier of the first device and the second private key with the third private key to obtain a first digital signature; create a first terminal-side trusted device list, the first terminal-side trusted device list including first device information of the first device, and the first device information including the first device identifier, the second public key and the first digital signature.

[0159] In some optional implementations, the processor 610 is also used to send the first public key to the server to obtain the first certificate of the first public key returned by the server; sign the first terminal side trusted device list with the first private key to obtain a second digital signature; send the first terminal side trusted device list, the second digital signature, the first certificate and the third public key to the server, so that the server verifies the first certificate through the root certificate public key, and if the first certificate is verified, obtain the first public key from the first certificate and verify the second digital signature through the first public key; if the second digital signature is verified, verify the first device information in the first terminal side trusted device list through the third public key, and if the first device information is verified, create a server side trusted device list.

[0160] In some optional implementations, the second device stores a fourth key pair and a fifth key pair, the fourth key pair includes a fourth private key and a fourth public key, and the fifth key pair includes a fifth private key and a fifth public key; the identity information includes a second device identifier of the second device, the fifth public key, a second certificate of the fourth public key, and a third digital signature obtained by signing the second device identifier and the fifth public key with the fourth private key; the processor 610 is also used to display a first prompt message through the display unit 606; in response to a first input of the first prompt message, verify the second certificate through the root certificate public key; when the second certificate is verified successfully, obtain the fourth public key from the second certificate, and verify the third digital signature through the fourth public key; when the third digital signature is verified successfully, determine that the second device is verified successfully.

[0161] In some optional implementations, the processor 610 is further used to sign the fifth public key with the third private key to obtain a fourth digital signature; add the second device information of the second device to the first terminal side trusted device list, the second device information including the second device identifier, the fifth public key and the fourth digital signature, wherein the devices in the first terminal side trusted device list have a trust relationship.

[0162] In some optional implementations, the processor 610 is further used to sign the first terminal-side trusted device list after adding the second device information through the first private key to obtain a fifth digital signature; send the first terminal-side trusted device list after adding the second device information, the fifth digital signature and the first certificate to the server, so that the server verifies the first certificate through the root certificate public key, and if the first certificate is verified successfully, obtain the first public key from the first certificate and verify the fifth digital signature through the first public key; if the fifth digital signature is verified successfully, verify each device information in the first terminal-side trusted device list after adding the second device information through the third public key, and update the server-side trusted device list based on the verification results of each device information.

[0163] In some optional implementations, the processor 610 is further used to generate a first negotiation key based on the fifth public key and the second private key; encrypt the third key pair by using the first negotiation key to obtain a first ciphertext; send the first ciphertext to the second device via the server, so that the second device generates the first negotiation key based on the second public key and the fifth private key, and decrypts the first ciphertext based on the first negotiation key to obtain the third key pair. When the second device receives the updated server-side trusted device list issued by the server, the first certificate is verified by using the root certificate public key. When the first certificate is verified successfully, the second device obtains the first public key from the first certificate and verifies the fifth digital signature by using the first public key. When the fifth digital signature is verified successfully, the second device verifies each device information in the updated server-side trusted device list by using the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

[0164] In some optional implementations, the first device stores a third certificate of the second public key, the second device stores a fifth key pair, the fifth key pair includes a fifth private key and a fifth public key, and the identity information includes a fourth certificate of the fifth public key; the processor 610 is further used to verify the fourth certificate through the root certificate public key; when the fourth certificate is verified, the fifth public key is obtained from the fourth certificate, and the second prompt information is displayed through the display unit 606; when the user input unit 607 receives a second input of the second prompt information from the user, a random number is generated, and a one-time password is obtained locally; based on the random number and the one-time password, a verification code is generated; based on the fifth public key and the second private key, a first negotiated key is generated; based on the fifth public key, the second private key and the verification code, generate a second negotiated key; encrypt the random number by the first negotiated key to obtain a second ciphertext; encrypt the third key pair by the second negotiated key to obtain a third ciphertext; send the third certificate, the second ciphertext and the third ciphertext to the second device via the server, so that the second device decrypts the second ciphertext and the third ciphertext based on the verification code to obtain the random number and the third key pair; display the verification code by the display unit 606, so that the user inputs the verification code to the second device, and the second device determines the one-time password based on the verification code and the random number; when the one-time password generated by the second device is verified, it is determined that the second device is verified.

[0165] In some optional implementations, the processor 610 is further used to download an updated server-side trusted device list from the server when the second device is verified and there is an update to the server-side trusted device list in the server, wherein the server-side trusted device list is updated based on the second terminal-side trusted device list sent by the second device, the second terminal-side trusted device list including the first device information and the second device information, the second device information including the second device identifier of the second device, the fifth public key, and the fourth digital signature obtained by signing the fifth public key with the third private key; verifying each device information in the updated server-side trusted device list; and updating the first terminal-side trusted device list based on the verification results of each device information.

[0166] It should be understood that in the embodiment of the present application, the input unit 604 may include a graphics processor (GPU) 6041 and a microphone 6042, and the graphics processor 6041 processes the image data of a static picture or video obtained by an image capture device (such as a camera) in a video capture mode or an image capture mode. The display unit 606 may include a display panel 6061, and the display panel 6061 may be configured in the form of a liquid crystal display, an organic light emitting diode, etc. The user input unit 607 includes a touch panel 6071 and at least one of other input devices 6072. The touch panel 6071 is also called a touch screen. The touch panel 6071 may include two parts: a touch detection device and a touch controller. Other input devices 6072 may include, but are not limited to, a physical keyboard, function keys (such as a volume control button, a switch button, etc.), a trackball, a mouse, and a joystick, which will not be repeated here.

[0167] The memory 609 can be used to store software programs and various data. The memory 609 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, an application program or instructions required for at least one function (such as a sound playback function, an image playback function, etc.), etc. In addition, the memory 609 may include a volatile memory or a non-volatile memory, or the memory 609 may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synchronous link dynamic random access memory (SLDRAM) and a direct memory bus random access memory (DRRAM). The memory 609 in the embodiment of the present application includes but is not limited to these and any other suitable types of memory.

[0168] The processor 610 may include one or more processing units; optionally, the processor 610 integrates an application processor and a modem processor, wherein the application processor mainly processes operations related to an operating system, a user interface, and application programs, and the modem processor mainly processes wireless communication signals, such as a baseband processor. It is understandable that the modem processor may not be integrated into the processor 610.

[0169] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, each process of the above-mentioned embodiment of the method for establishing a trust relationship between devices is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0170] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0171] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned embodiment of the method for establishing a trust relationship between devices, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0172] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0173] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned embodiment of the method for establishing a trust relationship between devices, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0174] It should be noted that, in this article, the term "comprises", "includes" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "including one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the method and device in the embodiment of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0175] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0176] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A method for establishing a trust relationship between devices, characterized in that: Executed by a first device, the method includes: When the first device logs in to the account and the first device is the first device to log in to the account, sending the first device information of the first device to the server; receiving a verification request for a second device, wherein the verification request is sent by the second device to the first device via the server when the second device logs in to the account and determines that the server stores the information of the first device, and the verification request includes the identity information of the second device; Based on the identity information, verify the second device; When the second device passes the verification, a trust relationship is established with the second device.

2. The method according to claim 1, characterized in that The sending, when the first device logs in to the account and the first device is the first device to log in to the account, the first device information of the first device to the server includes: When the first device logs in to the account and the first device is the first login device of the account, creating a first terminal-side trusted device list, wherein the first terminal-side trusted device list includes first device information of the first device; The first terminal side trusted device list is sent to the server, so that the server creates a server side trusted device list based on the first terminal side trusted device list after verifying the first terminal side trusted device list, and the server side trusted device list includes the first device information.

3. The method according to claim 2, characterized in that The step of creating a first terminal-side trusted device list when the first device logs in to the account and the first device is the first login device of the account includes: When the first device logs in to the account and the first device is the first login device of the account, obtain a first key pair, a second key pair, and a third key pair, the first key pair includes a first private key and a first public key, the second key pair includes a second private key and a second public key, and the third key pair includes a third private key and a third public key; Sign the first device identification of the first device and the second private key by using the third private key to obtain a first digital signature; A first terminal-side trusted device list is created, wherein the first terminal-side trusted device list includes first device information of the first device, wherein the first device information includes the first device identifier, the second public key, and the first digital signature.

4. The method according to claim 3, characterized in that The sending the first terminal-side trusted device list to the server so that the server creates a server-side trusted device list based on the first terminal-side trusted device list after verifying the first terminal-side trusted device list, includes: Sending the first public key to the server, and obtaining a first certificate of the first public key returned by the server; Sign the first terminal-side trusted device list using the first private key to obtain a second digital signature; The first terminal side trusted device list, the second digital signature, the first certificate and the third public key are sent to the server, so that the server verifies the first certificate through the root certificate public key. If the first certificate is verified successfully, the server obtains the first public key from the first certificate and verifies the second digital signature through the first public key. If the second digital signature is verified successfully, the server verifies the first device information in the first terminal side trusted device list through the third public key, and creates a server side trusted device list if the first device information is verified successfully.

5. The method according to claim 4, characterized in that The second device stores a fourth key pair and a fifth key pair, the fourth key pair includes a fourth private key and a fourth public key, and the fifth key pair includes a fifth private key and a fifth public key; the identity information includes a second device identifier of the second device, the fifth public key, a second certificate of the fourth public key, and a third digital signature, and the third digital signature is obtained by signing the second device identifier and the fifth public key with the fourth private key; The verifying the second device based on the identity information includes: Display the first prompt information; In response to a first input of the first prompt information, verifying the second certificate by using the root certificate public key; When the second certificate is verified successfully, obtaining the fourth public key from the second certificate, and verifying the third digital signature by using the fourth public key; When the third digital signature is verified successfully, it is determined that the second device is verified successfully.

6. The method according to claim 5, characterized in that The establishing a trust relationship with the second device includes: Sign the fifth public key using the third private key to obtain a fourth digital signature; Add the second device information of the second device to the first terminal side trusted device list, wherein the second device information includes the second device identifier, the fifth public key and the fourth digital signature, wherein the devices in the first terminal side trusted device list have a trust relationship.

7. The method according to claim 6, characterized in that After establishing a trust relationship with the second device, the method further includes: Sign the first terminal-side trusted device list after adding the second device information by using the first private key to obtain a fifth digital signature; The first terminal-side trusted device list after adding the second device information, the fifth digital signature and the first certificate are sent to the server, so that the server verifies the first certificate through the root certificate public key. If the first certificate is verified successfully, the server obtains the first public key from the first certificate and verifies the fifth digital signature through the first public key. If the fifth digital signature is verified successfully, the server verifies each device information in the first terminal-side trusted device list after adding the second device information through the third public key, and updates the server-side trusted device list based on the verification results of each device information.

8. The method according to claim 7, characterized in that After establishing a trust relationship with the second device, the method further includes: Generate a first negotiated key based on the fifth public key and the second private key; Encrypting the third key pair by using the first negotiated key to obtain a first ciphertext; The first ciphertext is sent to the second device via the server, so that the second device generates the first negotiated key based on the second public key and the fifth private key, and decrypts the first ciphertext based on the first negotiated key to obtain the third key pair. When the second device receives the updated server-side trusted device list issued by the server, the first certificate is verified by the root certificate public key. When the first certificate is verified successfully, the second device obtains the first public key from the first certificate and verifies the fifth digital signature by the first public key. When the fifth digital signature is verified successfully, the second device verifies each device information in the updated server-side trusted device list by the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

9. The method according to claim 4, characterized in that The first device stores a third certificate of the second public key, the second device stores a fifth key pair, the fifth key pair includes a fifth private key and a fifth public key, and the identity information includes a fourth certificate of the fifth public key; The verifying the second device based on the identity information includes: Verifying the fourth certificate by using the root certificate public key; When the fourth certificate is verified successfully, obtaining the fifth public key from the fourth certificate and displaying the second prompt information; Upon receiving a second input of the second prompt information from the user, generating a random number and obtaining a one-time password locally; Generate a verification code based on the random number and the one-time password; Generate a first negotiated key based on the fifth public key and the second private key; Generate a second negotiated key based on the fifth public key, the second private key and the verification code; Encrypting the random number using the first negotiated key to obtain a second ciphertext; Encrypting the third key pair by using the second negotiated key to obtain a third ciphertext; Sending the third certificate, the second ciphertext and the third ciphertext to the second device via the server, so that the second device decrypts the second ciphertext and the third ciphertext based on the verification code to obtain the random number and the third key pair; displaying the verification code so that the user inputs the verification code into the second device, and the second device determines the one-time password based on the verification code and the random number; If the one-time password generated by the second device is successfully verified, it is determined that the second device is successfully verified.

10. The method according to claim 9, characterized in that The establishing a trust relationship with the second device includes: If the second device passes verification and there is an update to the server-side trusted device list in the server, download the updated server-side trusted device list from the server, wherein the server-side trusted device list is updated based on the second terminal-side trusted device list sent by the second device, the second terminal-side trusted device list includes the first device information and the second device information, and the second device information includes the second device identifier of the second device, the fifth public key, and a fourth digital signature obtained by signing the fifth public key with the third private key; Verifying the updated device information of each device in the server-side trusted device list; Based on the verification results of each device information, update the first terminal side trusted device list.

11. A device for establishing a trust relationship between devices, characterized in that: The device comprises: A first sending unit, configured to send first device information of the first device to a server when a first device logs in to an account and the first device is the first device to log in to the account; a receiving unit, configured to receive a verification request for a second device, wherein the verification request is sent by the second device to the first device via the server when the second device logs in to the account and determines that the server stores the information of the first device, and the verification request includes the identity information of the second device; a verification unit, configured to verify the second device based on the identity information; An establishing unit is used to establish a trust relationship with the second device when the second device passes the verification.

12. An electronic device, characterized in that: It comprises a processor and a memory, wherein the memory stores a program or instruction that can be run on the processor, and when the program or instruction is executed by the processor, the steps of the method for establishing a trust relationship between devices as described in any one of claims 1-10 are implemented.

13. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by the processor, the steps of the method for establishing a trust relationship between devices as described in any one of claims 1-10 are implemented.

Images