Method for establishing trust relationship between devices and electronic device

Abstract

The present application relates to the technical field of communications, and discloses a method for establishing a trust relationship between devices and an electronic device. Embodiments of the method comprises: when a first device logs in to an account and the first device is the first login device of the account, sending first device information of the first device to a server (101); receiving a verification request for a second device, the verification request being sent by the second device to the server and forwarded by the server to the first device after the second device logs in to the account and it is determined that first device information is stored in the server, the verification request comprising identity information of the second device (102); on the basis of the identity information, verifying the second device (103); and after the second device passes the verification, establishing a trust relationship with the second device (104).

Description

Methods for establishing trust relationships between devices and electronic devices

[0001] This application claims priority to Chinese Patent Application No. 202411493010.3, filed on October 24, 2024, entitled “Method for Establishing Trust Relationship Between Devices and Electronic Device”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, specifically to a method for establishing trust relationships between devices and an electronic device. Background Technology

[0003] 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 them for data transmission.

[0004] In existing technologies, different devices of the same brand can establish trust relationships through a local area network (LAN) when logged into the same account. However, if a device is located far away and leaves the LAN environment, establishing trust relationships between devices becomes impossible. Summary of the Invention

[0005] The purpose of this application is to provide a method for establishing trust relationships between devices and an electronic device that can build trust relationships with devices logged in with the same account at any distance, avoiding the distance limitation of establishing trust relationships between devices and enriching the applicable scenarios for establishing trust relationships between devices.

[0006] In a first aspect, embodiments of this application provide a method for establishing a trust relationship between devices, executed by a first device. The method includes: when the first device logs into an account and is the first device to log in to the account, sending first device information of the first device to a 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 into the account and it is determined that the server stores the first device information, and the verification request includes the identity information of the second device; verifying the second device based on the identity information; and establishing a trust relationship with the second device if the verification of the second device is successful.

[0007] Secondly, embodiments of this application provide an inter-device trust relationship establishment apparatus, comprising: a first sending unit, configured to send first device information of the first device to a server when the first device logs into an account and the first device is the first device to log into 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 into the account and it is determined that the server stores the first device information, 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; and an establishment unit, configured to establish a trust relationship with the second device when the second device passes the verification.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, the memory storing programs or instructions executable on the processor, the programs or instructions, when executed by the processor, implementing the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a computer program is stored, and when executed by a processor, the computer program implements the steps of the method described in the first aspect above.

[0010] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method described in the first aspect.

[0011] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method described in the first aspect.

[0012] In this embodiment, when the first device logs into an account and is the first device to log in to the account, the first device information of the first device is sent to the server. Upon receiving a verification request for the second device, the second device is verified based on its identity information in the verification request. If 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 after the second device logs into the same account and it is determined that the server stores the first device information, the server is used for information transmission during the process of establishing a trust relationship with the second device. This allows trust relationships to be established with devices logged into the same account at any distance, without requiring the devices to be in the same local area network environment. This avoids the distance limitation of establishing trust relationships between devices and enriches the applicable scenarios for establishing trust relationships between devices. Attached Figure Description

[0013] Figure 1 is a flowchart of the method for establishing trust relationships between devices provided in an embodiment of this application;

[0014] Figure 2 is a flowchart of the verification process of the second device in the device trust relationship establishment method provided in the embodiment of this application;

[0015] Figure 3 is a flowchart of the verification process of the second device in the device trust relationship establishment method provided in the embodiment of this application;

[0016] Figure 4 is a schematic diagram of the device for establishing trust relationships between devices provided in an embodiment of this application;

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

[0018] Figure 6 is a schematic diagram of the hardware structure of an electronic device suitable for implementing the embodiments of this application. Specific Implementation

[0019] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0020] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0021] The method and apparatus for establishing inter-device trust relationships provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0022] Please refer to Figure 1, which shows one of the flowcharts of the method for establishing trust relationships between devices provided in this application embodiment. The method for establishing trust relationships between devices provided in this application embodiment can be executed by a first device. The device in this application embodiment can be various electronic devices such as smartphones, tablets, laptops, and wearable devices.

[0023] The process of establishing inter-device trust relationships provided in this application embodiment includes the following steps:

[0024] Step 101: If the first device is logged into the account and is the first device logged into the account, the first device information of the first device is sent to the server.

[0025] In this embodiment, the account can refer to an account in the brand's account management system, such as an account for logging into a brand's mobile phone, tablet, or other electronic devices. Typically, devices manufactured by different brands may have different account management systems. For a given brand's account management system, the same user usually only has one account within that system. If a user owns multiple devices manufactured by that brand, they can log in using the same account across all of those devices.

[0026] In this embodiment, the server can be implemented as a single server or a server cluster. The aforementioned server can be an account server used by the device brand for account management and maintenance.

[0027] In the application scenario of this embodiment, the first device and the second device can be owned by the same user. The first device and the second device can be different devices manufactured by the same brand. The first device and the second device can log in to the same account. When the first device is logged in to the account and the second device is not logged in to the account, the first device is the first device to log in to 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 identifier of the first device, the public key used for communication with other devices, and digital signatures. It should be noted that this application embodiment does not limit the number of second devices, that is, there can be one or more second devices.

[0028] In practice, after receiving the first device information, the server can verify the first device to ensure its validity. If verification is successful, the first device information can be stored so that the second device can obtain valid and secure first device information when logging in, ensuring the secure transmission of verification requests. If verification fails, the first device information is not stored to ensure communication security.

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

[0030] Step S1: If the first device is logged into an account and is the first device logged into the account, a first terminal-side trusted device list is created. The first terminal-side trusted device list includes the 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 trust relationships.

[0031] Step S2: The first terminal-side trusted device list is sent to the server so that after the server verifies the first terminal-side trusted device list, it creates a server-side trusted device list based on the first terminal-side trusted device list. The server-side trusted device list includes the first device information.

[0032] By creating a first terminal-side trusted device list, it is easy to clearly and accurately record the device information of trusted devices with trust relationships, and to facilitate the subsequent transmission and verification of device information.

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

[0034] Sub-step S11: If the first device is the first device logged into the account, and the first device is the first login device for 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 first key pair can be used to sign the subsequently generated first terminal-side trusted device list to ensure the trustworthiness of the first terminal-side trusted device list. The second key pair can be used to perform key negotiation with other devices to complete communication encryption. The third key pair can be used to sign the second public key to ensure the trustworthiness of the second public key. For different accounts, the third key pair of the login device is different. The contents of the first key pair, the second key pair, and the third key pair are different.

[0035] Optionally, the first device can run two systems. One system is an operating system, such as Android. The other system is a TEE (Trusted Execution Environment) system, used to provide a trusted execution environment. The trusted execution environment is a secure area built on a computing platform using hardware and software methods, ensuring the confidentiality and integrity of code and data loaded within this secure area. The first key pair, second key pair, and third key pair can be generated in the TEE. Conventional key generation tools or instructions can be used to randomly generate the first, second, and third key pairs. As an example, the first key pair can be denoted 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 denoted 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 denoted 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. By randomly generating the first, second, and third key pairs on the first device, the establishment of trust between devices can be made independent of the key pairs built into the chip of the first device at the factory, enabling more flexible and convenient establishment of trust relationships between devices.

[0036] Optionally, the first and third key pairs mentioned above can be generated in the TEE. Conventional key generation tools or instructions can be used to randomly generate the first and third key pairs. The second key pair mentioned above can be the key pair embedded in the chip of the first device at the factory. In this case, for ease of distinction, the second key pair can be denoted 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 embedded in the chip of the first device at 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 eliminated, thereby improving the efficiency of establishing trust relationships between devices. Simultaneously, the key pair resources embedded in the chip of the first device at the factory can be fully utilized, reducing the occupation of some storage space.

[0037] Sub-step S12 involves signing the first device identifier and the second private key of the first device using the third private key to obtain the first digital signature. For example, the first device identifier can be denoted as uid_1, and the second private key as device_A_trust_pub. The third private key, account_device_pri, can be used to sign {uid_1, device_A_trust_pub} to obtain the first digital signature, which is then denoted as account_device_sign_1. account_device_sign_1 = Sign(account_device_pri, Hash(uid_1|device_A_trust_pub). Here, Hash() represents the hash function, and Sign() represents the signature algorithm, which can be RSA (Ron Rivest, Adi Shamir, Leonard Adleman) encryption algorithm, ECC (Elliptic Curve Cryptography), etc., without specific limitations here.

[0038] Sub-step S13: Create a first terminal-side trusted device list. This list includes the first device information, which includes the first device identifier, the second public key, and the first digital signature. Continuing the example above, the first terminal-side trusted device list can be denoted as device_table1, as shown in the table below:

[0039] device_uid device_pub account_device_sign

[0040] uid_1device_A_trust_pub account_device_sign_1

[0041] In this table, device_uid, device_pub, and account_device_sign are fields representing the device identifier, device public key, and device signature, respectively. The first terminal-side trusted device list includes one record containing the first device identifier uid_1, the second public key device_A_trust_pub, and the first digital signature account_device_sign_1.

[0042] By creating a first terminal-side trusted device list, it is easy to clearly and accurately record the device information of trusted devices with trust relationships, and to facilitate the subsequent transmission and verification of device information.

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

[0044] Sub-step S21 involves sending the first public key to the server and receiving the first certificate of the first public key returned by the server. Here, the server may be a CA (Certificate Authority). A CA is a trusted third-party organization that provides network identity authentication services. CAs are responsible for issuing and managing digital certificates to ensure the security of network communication and the integrity of data. Their main functions include certificate issuance, renewal, revocation, and verification, as well as managing the binding of public 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 server will return the first certificate of the first public key, which can be denoted as account_A_cert.

[0045] Sub-step S22: Sign the first terminal-side trusted device list using the first private key to obtain a second digital signature. Continuing the example above, sign the first terminal-side trusted device list device_table1 using the first private key account_A_pri. The resulting second digital signature can be denoted as account_sign_1. Where, account_sign_1 = Sign(account_A_pri, Hash(device_table1)).

[0046] Sub-step S23 involves sending the first terminal-side trusted device list, the second digital signature, the first certificate, and the third public key to the server. This allows the server to verify the first certificate using the root certificate public key. If the first certificate verification is successful, the server retrieves the first public key from the first certificate and verifies the second digital signature using the first public key. If the second digital signature verification is successful, the server verifies the first device information in the first terminal-side trusted device list using the third public key. If the first device information verification is successful, the server-side trusted device list is created. It should be noted that the third public key can also be sent to the server in advance, for example, immediately after creation.

[0047] Continuing with the example above, 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 can be sent to the server.

[0048] The server can store the root certificate public key. The root certificate public key is used to verify all certificates issued by the aforementioned CAs. Since the first certificate was issued by one of the aforementioned CAs, its validity can be verified using the root certificate public key. The root certificate public key can be denoted 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.

[0049] If the verification of the first certificate `account_A_cert` fails, the server can discard the aforementioned first terminal-side trusted device list `device_table1`, the second digital signature `account_sign_1`, and the first certificate `account_A_cert`. If the verification of the first certificate `account_A_cert` succeeds, the server can obtain the first public key `account_A_pub` from the first certificate `account_A_cert`, and use the first public key `account_A_pub` to verify the second digital signature `account_sign_1` to determine its validity. The first certificate `account_A_cert` may contain information including, but not limited to, the first public key `account_A_pub`, the certificate issuer, the certificate holder, and the certificate validity period.

[0050] Specifically, when verifying the second digital signature `account_sign_1` using 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 signature verification function `Verify()`, resulting in the function value `Verify(account_A_pub, account_sign_1)`. If this function value equals `Hash(device_table1)`, then the second digital signature `account_sign_1` is considered valid, having passed verification. Since the second digital signature `account_sign_1` is obtained by signing the first terminal-side trusted device list, its validity indicates that the first terminal-side trusted device list `device_table1` has not been tampered with or forged. Conversely, if the function value is not equal to Hash(device_table1), then the verification of the second digital signature account_sign_1 has failed. In this case, the second digital signature account_sign_1 can be considered invalid, and its corresponding first terminal-side trusted device list device_table1 may have been tampered with or forged. In this situation, the server can discard the aforementioned first terminal-side trusted device list device_table1, the second digital signature account_sign_1, and the first certificate account_A_cert.

[0051] If the second digital signature `account_sign_1` passes verification, the first device information in the trusted device list `device_table1` on the first terminal side can be verified using 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` passes verification, the first device information is considered valid and has not been tampered with or forged. Conversely, if the first digital signature `account_device_sign_1` fails verification, the first device information is considered invalid and may have been 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()` used for signature verification, resulting in 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), then the verification of the first digital signature account_device_sign_1 is determined to have failed, and the server can discard the aforementioned 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), then the verification of the first digital signature account_device_sign_1 is determined to have passed, i.e., the verification of the first device information is successful. At this time, a server-side trusted device list can be created. The server-side trusted device list can be denoted as server_table1, as shown in the table below:

[0052] In this table, `device_uid`, `device_pub`, `account_device_sign`, `account_sign`, and `account_cert` are fields representing the device identifier, device public key, device signature, account signature, and account certificate, respectively. The server-side trusted device list includes one record containing the first device identifier `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`.

[0053] By sending the first list of trusted devices on the terminal side, the second digital signature, the first certificate, and the third public key to the server, the server can sequentially verify the validity of the first certificate, the second digital signature, and the first device information in the first list of trusted devices on the terminal side. This ensures that the first public key, the first list of trusted devices on the terminal side, and the first device information in the first list of trusted devices on the terminal side have not been tampered with or forged. Therefore, the security of the first device logging into the aforementioned account can be guaranteed, preventing other devices from sending verification requests to insecure devices when logging into the same account, thus ensuring communication security.

[0054] Step 102: Receive a verification request for the second device. The verification request is sent from the second device to the first device via the server after the second device has logged into its account and confirmed that the server stores the information of the first device. The verification request includes the identity information of the second device.

[0055] In this embodiment, after receiving the first device information, the server can verify the first device. If the verification is successful, the server stores the first device information; otherwise, it discards the first device information. Therefore, when a second device logs into the same account, if the server detects the existence of the first device information, it means that a trusted device has already logged into that account. At this time, the server can send a verification request to the first device, which then verifies the second device. The verification request may include the second device's identity information. This 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 second device's certificate, public key, etc.

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

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

[0058] In some optional implementations of this embodiment, the second device may store 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 identifier, the fifth public key, a second certificate for 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 the trustworthiness of the list. The fifth key pair can be used to perform key negotiation with other devices to complete communication encryption. Similar to the first certificate, the second certificate can also be generated by the server-side CA authority 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 described further here.

[0059] Similar to the first device, the second device can also run two systems: one is an operating system, such as Android, and the other is a TEE system to provide a trusted execution environment. The fourth and fifth key pairs can be generated within the TEE. These can be randomly generated using conventional key generation tools or instructions. For example, the fourth key pair can be denoted as {account_B_pri, account_B_pub}, where the fourth private key is account_B_pri and the fourth public key is account_B_pub. The fifth key pair can be denoted as {device_B_trust_pri, device_B_trust_pub}, where the fifth private key is device_B_trust_pri and the fifth public key is device_B_trust_pub. By randomly generating the fourth and fifth key pairs using the second device, the establishment of trust between devices becomes independent of the key pairs embedded in the chip at the factory, enabling more flexible and convenient establishment of trust relationships between devices.

[0060] Similar to the first device, the fifth key pair can also be the key pair embedded in the chip of the second device at the factory. In this case, for ease of distinction, the fifth key pair can be denoted 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 embedded in the chip of the second device at 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 eliminated, thereby improving the efficiency of establishing trust relationships between devices. At the same time, the key pair resources embedded in the chip of the fifth device at the factory can be fully utilized, reducing the occupation of some storage space.

[0061] Based on this, referring to Figure 2, step 103 may include the following sub-steps:

[0062] Sub-step S301: Display the first prompt message. The first prompt message can be used to prompt the user to confirm the trusted device verification for the second device. The first prompt message can be displayed through pop-up windows or other means.

[0063] Sub-step S302, in response to the first input of the first prompt information, verifies the second certificate using the root certificate public key. The first input can be touch input, voice command, a specific gesture input by the user, or other feasible inputs, which can be determined according to actual usage needs and are not limited in this embodiment. The specific gesture in this embodiment can be any one of the following: single-click gesture, swipe gesture, drag gesture, pressure recognition gesture, long-press gesture, area change gesture, double-press gesture, and double-tap gesture. The click input in this embodiment can be single-click input, double-click input, or any number of clicks, and can also be long-press input or short-press input.

[0064] As an example, the second certificate can be denoted 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, and can be obtained in advance from the server. Since the second certificate is issued by the CA authority of the server, the validity of the second certificate account_B_cert can be verified using the root certificate public key device_root_pub.

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

[0066] Continuing the example above, the third digital signature can be denoted as `req_sign`. The second certificate, `account_B_cert`, may contain information including, but not limited to, the fourth public key `account_B_pub`, the certificate issuer, the certificate holder, and the certificate validity period. 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 successfully, the fourth public key `account_B_pub` in the second certificate `account_B_cert` can be considered tamper-proof and unforged. 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 using the fourth public key `account_B_pub` to determine the validity of the third digital signature `req_sign`.

[0067] The second device identifier can be denoted as uid_2. Taking the fifth key pair as {device_B_trust_pri, device_B_trust_pub} as an example, when verifying the third digital signature req_sign using 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() used for signature verification, resulting in the function value Verify(account_B_pub, req_sign). If the function value equals Hash(uid_2|device_B_trust_pub), then the verification of the third digital signature req_sign is successful. Conversely, if the function value is not equal to Hash(uid_2|device_B_trust_pub), then the verification of the third digital signature req_sign is unsuccessful.

[0068] Sub-step S304: If the third digital signature verification passes, determine that the second device verification passes. Here, if the third digital signature `req_sign` verification passes, the third digital signature `req_sign` is considered 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, the second device identifier `uid_2` and the fifth public key `device_B_trust_pub` can be considered tamper-proof and unforged. Therefore, it can be determined that the second device verification passes.

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

[0070] 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 logging into an account and selecting to have the first device provide a verification code, the second device 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.

[0071] As an example, the key pair {device_A_pri, device_A_pub} pre-installed on the first device can be used as the second key pair, and the key pair {device_B_pri, device_B_pub} pre-installed on the second device can be used as the fifth key pair. Therefore, 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 the certificate obtained by a CA (Certificate Authority) after authenticating the second public key device_A_pub, and can be denoted as device_A_cert. The third certificate can be pre-installed on the first device at the factory. The fourth certificate is the certificate obtained by a CA after authenticating the fifth public key device_B_pub, and can be denoted as device_B_cert. The fourth certificate can be pre-installed on the second device at the factory.

[0072] Based on this, referring to Figure 3, step 103 may include the following sub-steps:

[0073] Sub-step S401 verifies the fourth certificate using the root certificate public key. Continuing the example above, the root certificate public key device_root_pub can be used to verify the fourth certificate device_B_cert to determine its validity.

[0074] Sub-step S402: If the fourth certificate verification is successful, obtain the fifth public key from the fourth certificate and display the second prompt information. This 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 the form of a pop-up window, etc. Continuing the example above, the fourth certificate device_B_cert may contain information including, but not limited to, the fifth public key device_B_pub, the certificate issuer, the certificate holder, and the certificate validity period. Since the fourth certificate device_B_cert is the certificate of the fifth public key device_B_pub, if the fourth certificate device_B_cert is verified successfully, it can be assumed 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.

[0075] In sub-step S403, upon receiving the user's second input regarding the second prompt information, a random number is generated, and a one-time password is retrieved locally. As an example, a six-digit random number can be generated and denoted as rand_Num. The initial password can also be a six-digit password, denoted as OTP_Num. In practice, OTP_Num can be built into both the server and the logged-in device. The server can verify whether the logged-in account's device has given its consent by verifying OTP_Num.

[0076] Sub-step S404 generates a verification code based on a random number and a one-time password. Continuing the example above, the verification code can be denoted as show_Num, and can be calculated using predefined rules. For example, show_Num = ((rand_Num + OTP_Num) mod 1000000). Here, mod is the modulo function.

[0077] Sub-step S405: Based on the fifth public key and the second private key, generate the first negotiation key. Continuing the example above, the first negotiation key can be denoted as shared_AB_key. shared_AB_key = SHARE(device_B_pub, device_A_pri).

[0078] Sub-step S406: Based on the fifth public key, the second private key, and the verification code, generate the second negotiation key. Continuing the example above, the second negotiation key can be denoted as shared_AB_password_key. shared_AB_password_key = SHARE(device_B_pub, device_A_pri, show_Num).

[0079] Sub-step S407: Encrypt the random number using the first negotiated key to obtain the second ciphertext. Continuing the example above, the second ciphertext can be denoted as cipher_num. cipher_num = Enc(shared_AB_key, rand_Num).

[0080] Sub-step S408: Encrypt the third key pair using the second negotiated key to obtain the third ciphertext. Continuing the example above, the third ciphertext can be denoted as cipher_key. cipher_key = Enc(shared_AB_password_key, {account_device_pri, account_device_pub}).

[0081] Sub-step S409: The third certificate, the second ciphertext, and the third ciphertext are sent to the second device via the server, so that the second device can decrypt the second ciphertext and the third ciphertext based on the verification code to obtain a random number and a third key pair.

[0082] Continuing with the example above, the first device can 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.

[0083] Here, the second device can also use the root certificate public key `device_root_pub` to verify the third certificate `device_A_cert`. After successful verification, it can obtain the second public key `device_A_pub` from the third certificate `device_A_cert`, and perform key negotiation based on the second public key `device_A_pub` and its own fifth private key `device_B_pub` to obtain the first negotiation key `shared_AB_key`. `shared_AB_key = SHARE(device_A_pub, device_B_pri)`. Similarly, it can perform key negotiation 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 negotiation key `shared_AB_password_key`. `shared_AB_password_key = SHARE(device_A_pub, device_B_pri, show_Num)`.

[0084] Next, the second device can decrypt the second ciphertext cipher_num based on the first negotiation key shared_AB_key to obtain a random number rand_Num. rand_Num = Dec(shared_AB_key, cipher_num). And, it can decrypt the third ciphertext cipher_key based on the second negotiation key shared_AB_password_key to obtain the third key pair {account_device_pri, account_device_pub}. {account_device_pri, account_device_pub} = Dec(shared_AB_password_key, cipher_key).

[0085] In sub-step S410, a verification code is displayed so that the user can input the verification code into the second device, which then determines a one-time password based on the verification code and a random number. Here, after the data transmission in sub-step S409 is completed, the first device can display the verification code.

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

[0087] Sub-step S411: If the one-time password generated by the second device passes the verification, determine that the verification by the second device has passed.

[0088] By having the first device, which is already logged into the same account, provide a verification code when the second device successfully logs into the account, and then having the user enter this verification code into the second device for verification, the accuracy of the verification of the second device can be further improved.

[0089] In practice, after the second device successfully logs in to its account, it can generate a fourth key pair {account_B_pri, account_B_pub} within 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 a second certificate, account_B_cert, from the server's CA authority. Afterward, the second device can download the server-side trusted device list, server_table3, from the server. See the table below for details:

[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 successful verification, it obtains the trusted first public key `account_A_pub` 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 using the first public key, account_A_pub. That is, it determines whether Verify(account_A_pub, account_sign_1) equals Hash(device_table1). If they do, 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, it verifies the digital certificate in the device information to determine whether `Verify(account_device_pub, account_device_sign_n)` equals `Hash(uid_n|device_X_trust_pub)`. Afterward, a second terminal-side trusted device list is created, and the verified device information is written to the second terminal-side trusted device list `device_table4`, as shown in the table below:

[0093] Next, the second device signs its second device identifier uid_2 and fifth public key device_B_pub using the third private key, obtaining a fourth digital signature account_device_sign_2. account_device_sign_2 = Sign(account_device_pri, Hash(uid_2|device_B_pub)). Then, the second device information, including the aforementioned second device identifier uid_2, the aforementioned fifth public key device_B_pub, and the aforementioned fourth digital signature account_device_sign_2, is added as a record to the trusted device list on the second terminal side, resulting in device_table5, as shown in the table below:

[0094] Next, the second device can 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.

[0095] Next, the server can first verify the second certificate, account_A_cert, using the root certificate public key, account_root_pub. After successful verification, it obtains the fourth public key, account_B_pub, from the second certificate, account_B_cert. Then, it uses the fourth public key, account_B_pub, to verify the fifth digital signature, account_sign_2. For example, it checks whether Verify(account_B_pub, account_sign_2) equals Hash(device_table5). If the fifth digital signature, account_sign_2, is verified successfully, the server can then verify each device in the second terminal-side trusted device list, device_table5, row by row using the third public key, account_device_pub. For example, it checks whether Verify(account_device_pub, account_device_sign_n) equals Hash(uid_n|device_X_trust_pub). After completing all verifications, the server-side trusted device list is updated, resulting in server_table4, as shown in the table below:

[0096] Step 104: If the second device passes the verification, establish a trust relationship with the second device.

[0097] In this embodiment, a trust relationship can be established with the second device after successful verification. After establishing the trust relationship, the first and second devices can generate a negotiation key using their own private keys and the other's public key. They then encrypt data using the negotiation key and forward the encrypted ciphertext to the other device via the server. Furthermore, they can decrypt the ciphertext forwarded from the other device via the server using the negotiation key to obtain the original data. Since the device's private key is only stored locally, third-party devices or servers cannot generate the same negotiation key and therefore cannot decrypt the ciphertext to obtain the original data, thus enabling secure communication between trusted devices.

[0098] Furthermore, since data can be encrypted and relayed to the second device via the server during communication, the first and second devices logged into the same account can communicate securely at any distance, without relying on a local area network environment, thus enriching the applicable scenarios for inter-device communication.

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

[0100] Sub-step S305: Sign the fifth public key with the third private key to obtain the fourth digital signature. Continuing the example above, sign the fifth public key device_B_trust_pub with the third private key account_device_pri. The resulting fourth digital signature can be denoted as account_device_sign_2. account_device_sign_2 = Sign(account_device_pri, Hash(uid_2|device_B_trust_pub)).

[0101] Sub-step S306: Add the second device's information to the first terminal-side trusted device list. The second device information includes the second device identifier, the fifth public key, and the fourth digital signature. Continuing the example above, the first terminal-side trusted device list after adding the second device information can be denoted as device_table2, as shown in the table below:

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

[0103] If the second device is verified, the third private key is used to sign the fifth public key to obtain a fourth digital signature. The second device information, which includes the second device identifier, the fifth public key and the fourth digital signature, is added to the first terminal-side trusted device list. This enables automatic updating of the first terminal-side trusted device list in the first device when the second device is confirmed as a trusted device, thereby facilitating the maintenance of trust relationships.

[0104] By adding the second device's information to the trusted device list on the first terminal side, a trust relationship can be established between the first and second devices, enabling secure communication between them. Furthermore, updating the trusted device list on the first terminal side facilitates subsequent synchronization of trusted devices with the server, providing the server with more accurate information about the trusted devices.

[0105] 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:

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

[0107] 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 can verify the first certificate using 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 using the first public key. If the fifth digital signature is verified successfully, the server verifies the information of each device in the first terminal-side trusted device list after adding the second device information using the third public key, and updates the server-side trusted device list based on the verification results of each device information.

[0108] Continuing the example above, the first device can send the first terminal-side trusted device list (device_table2) after adding the second device information, the fifth digital signature (account_sign_2), and the first certificate (account_A_cert) to the server. Upon receiving this information, the server can first verify the first certificate (account_A_cert) using the root certificate public key (device_root_pub) to determine its validity.

[0109] If the first certificate `account_A_cert` fails verification, the server can discard the first terminal-side trusted device list `device_table2` (after adding the second device information), the fifth digital signature `account_sign_2`, and the first certificate `account_A_cert`. If the first certificate `account_A_cert` passes verification, the server can obtain the first public key `account_A_pub` from the first certificate `account_A_cert` and use the first public key `account_A_pub` to verify the fifth digital signature `account_sign_2` to determine its validity.

[0110] When verifying the fifth digital signature `account_sign_2` using the first public key `account_A_pub`, both `account_A_pub` and `account_sign_2` are input into the signature verification function `Verify()`, resulting in the function value `Verify(account_A_pub, account_sign_2)`. If this function value equals `Hash(device_table2)`, the fifth digital signature `account_sign_2` is considered valid. Since `account_sign_2` is obtained by signing `device_table2`, its validity indicates that `device_table2` has not been tampered with or forged. Conversely, if the function value does not equal `Hash(device_table2)`, the verification of the fifth digital signature `account_sign_2` fails, and it is considered invalid, suggesting that `device_table2` may have been tampered with or forged. In this case, the server can 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.

[0111] If the fifth digital signature, `account_sign_2`, passes verification, the third public key, `account_device_pub`, can be used to verify the device information in `device_table2` to determine the validity of each device information. The device information in `device_table2` may include first device information and second device information. In practice, verifying device information can involve verifying the digital signature within the device information. Specifically, the third public key, `account_device_pub`, can be used to verify the digital signature in each device information in `device_table2` row by row. The function value of `Verify(account_device_pub, account_device_sign_n)` is then determined to be equal to `Hash(uid_n|device_X_trust_pub)`, where n is 1, 2, ..., and X = A, B, ... For the digital signature `account_device_sign_n`, if the function value `Verify(account_device_pub, account_device_sign_n)` equals `Hash(uid_n|device_X_trust_pub)`, then the digital signature `account_device_sign_n` has been verified successfully, and the device information containing this signature is considered valid and has not been tampered with or forged. Conversely, if the function value `Verify(account_device_pub, account_device_sign_n)` does not equal `Hash(uid_n|device_X_trust_pub)`, then the digital signature `account_device_sign_n` has failed verification, and the device information containing this signature is considered to have failed verification, potentially indicating tampering or forgery.

[0112] After verifying the device information in device_table2, the server-side trusted device list server_table1 can be updated based on the verification results, resulting in server_table2. Continuing the example above, if both the first and second device information pass verification, the resulting server_table2 can be seen in the table below:

[0113] By sending the updated first terminal-side trusted device list, the fifth digital signature, and the first certificate to the server, the server can sequentially verify the validity of the first certificate, the fifth digital signature, and the device information in the updated first terminal-side trusted device list. This ensures 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. Therefore, the security of each trusted device is guaranteed, thus ensuring the security of communication.

[0114] 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:

[0115] Sub-step S309 generates a first negotiation key based on the fifth public key and the second private key. In practice, key agreement refers to the process by which two parties requiring secure communication reach a shared secret key through communication over a public channel; this key is called the negotiation key. Through key agreement, each participant can generate the same negotiation key without directly exchanging keys. Data is then encrypted using the negotiation key for secure communication. Key agreement can be implemented using specific encryption algorithms and protocols, such as RSA encryption and ECC encryption. The design of these algorithms and protocols ensures that even without prior key sharing, the communicating parties can generate the same session key by exchanging information, thereby achieving secure communication. As an example, the first negotiation key can be denoted as shared_AB_key. shared_AB_key = SHARE(device_B_trust_pub, device_A_trust_pri). Here, SHARE() can represent a key agreement function, such as the function of the aforementioned RSA encryption algorithm or ECC encryption algorithm.

[0116] Sub-step S310 involves encrypting the third key pair using the first negotiated key to obtain the first ciphertext. Continuing the example above, the first ciphertext can be denoted as account_device_key_cipher. account_device_key_cipher = Enc(shared_AB_key, {account_device_pri, account_device_pub}). Here, Enc() represents the encryption function.

[0117] In sub-step S311, the first ciphertext is sent to the second device via the server, so that the second device generates a 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 a third key pair. When the second device receives the updated server-side trusted device list sent by the server, it verifies the first certificate using the root certificate public key. If the first certificate is verified successfully, the second device obtains the first public key from the first certificate and verifies the fifth digital signature using the first public key. If the fifth digital signature is verified successfully, the second device verifies the information of each device in the updated server-side trusted device list using the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

[0118] Continuing the example above, the first device can 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 can first generate a first negotiation 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 can decrypt the first ciphertext `account_device_key_cipher` using the first negotiation key `shared_AB_key` to obtain a third key pair `{account_device_pri, account_device_pub}`. `{account_device_pri, account_device_pub} = Dec(shared_AB_key, account_device_key_cipher)`. Here, `Dec()` represents the decryption function.

[0119] After updating the server-side trusted device list, the server can send the updated server-side trusted device list `server_table2` to the second device. Upon receiving the updated server-side trusted device list `server_table2`, the second device first uses the root certificate public key `device_root_pub` to verify the first certificate `account_A_cert` to determine its validity. If the first certificate `account_A_cert` is verified successfully, the first public key `account_A_pub` can be obtained from the first certificate `account_A_cert`, and used to verify the fifth digital signature `account_sign_2` to determine its validity. If the fifth digital signature `account_sign_2` is verified successfully, the third public key `account_device_pub` can be used to verify the device information in `device_table2` to determine the validity of each device information. The device information in `device_table2` may include information from the first device and the second device. After verifying the device information in device_table2, a second terminal-side trusted device list device_table3 can be created based on the verification results. See the table below for details:

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

[0121] If the verification on the second device is successful, a first negotiation key is generated based on the fifth public key of the second device and the second private key of the first device. Then, the third key pair is encrypted using the first negotiation key to obtain the first ciphertext, which is sent to the second device via the server. This ensures that the second device can receive the first ciphertext regardless of whether it is on the same local area network as the first device. Since the first ciphertext requires decryption using the first negotiation key, and the first negotiation key is generated using the device's private key, which is stored only locally on the device, the server cannot obtain the plaintext data during the relay of the first ciphertext, thus ensuring communication security.

[0122] By having the second device obtain the same first negotiated key through key negotiation, and then using this first negotiated key to decrypt the first ciphertext to obtain a third key pair, the second device can then verify each information device in the server-side trusted device list issued by the server side based on the third public key. Finally, by synchronizing the verification results of each device, the terminal-side trusted device list can be synchronized. Since the trusted devices in the trusted device list have trust relationships, it is convenient for the second device to maintain the trust relationships between devices.

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

[0124] Sub-step S412: If the second device is verified and the server-side trusted device list in the server is updated, download the updated server-side trusted device list 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. The second terminal-side trusted device list includes first device information and 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. Continuing the example above, the updated server-side trusted device list downloaded from the server is server_table4. server_table4 includes first device information, 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.

[0125] Sub-step S413 verifies the information of each device in the updated server-side trusted device list. The verification process here can refer to the verification process for device information in the server-side trusted device list described above, or the verification process for device information in the first terminal-side trusted device list or the second terminal-side trusted device list described above. To avoid repetition, it will not be elaborated further here.

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

[0127] 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, enabling the first device and the second device to communicate securely.

[0128] The method provided in the above embodiments of this application, when a first device logs into an account and is the first device to log in to the account, sends the first device information of the first device to the server; upon receiving a verification request for a second device, verifies the second device based on the identity information of the second device in the verification request; and establishes a trust relationship with the second device if the verification of the second device is successful. Since the verification request for the second device is sent from the second device to the first device via the server after the second device logs into the same account and it is determined that the server stores the first device information, the server facilitates information transmission during the establishment of a trust relationship with the second device. This allows for the establishment of a trust relationship with devices logged into the same account at any distance, without requiring the devices to be in the same local area network environment, thus avoiding distance limitations in establishing trust relationships between devices and enriching the applicable scenarios for establishing trust relationships between devices.

[0129] It should be noted that the device trust relationship establishment method provided in this application embodiment can be executed by a device trust relationship establishment device. This application embodiment uses the device trust relationship establishment device executing the device trust relationship establishment method as an example to illustrate the device trust relationship establishment device provided in this application embodiment.

[0130] As shown in Figure 4, the device trust relationship establishment apparatus 400 of this embodiment includes: a first sending unit 401, used to send first device information of the first device to the server when the first device logs in to an account and the first device is the first login device of the account; a receiving unit 402, used 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 it is determined that the server stores the first device information, 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; and an establishment unit 404, used to establish a trust relationship with the second device when the second device passes the verification.

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

[0132] In some optional implementations of this embodiment, the first sending unit 401 is further configured to: when the first device logs into an account and the first device is the first login device for the account, obtain a first key pair, a second key pair, and a third key pair, wherein 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 identifier and the second private key of the first device using the third private key to obtain a first digital signature; and create a first terminal-side trusted device list, wherein the first terminal-side trusted device list includes first device information of the first device, and the first device information includes the first device identifier, the second public key, and the first digital signature.

[0133] In some optional implementations of this embodiment, the first sending unit 401 is further configured to: send the first public key to the server to obtain 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; 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 using 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 using 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 using the third public key; and if the first device information is verified successfully, create a server-side trusted device list.

[0134] In some optional implementations of this embodiment, the second device stores 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, 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 verification unit 403 is further configured to: display a first prompt message; in response to a first input to the first prompt message, verify the second certificate with the root certificate public key; if 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; if the third digital signature is verified successfully, determine that the second device has been verified successfully.

[0135] In some optional implementations of this embodiment, the establishment unit 404 is further configured 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, wherein the second device information includes the second device identifier, the fifth public key and the fourth digital signature, and wherein the devices in the first terminal-side trusted device list have a trust relationship.

[0136] In some optional implementations of this embodiment, the apparatus further includes a second sending unit, configured to: when the second device verification is successful, sign the first terminal-side trusted device list after adding the second device information using 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 using the root certificate public key; when the first certificate verification is successful, the server obtains the first public key from the first certificate and verifies the fifth digital signature using the first public key; when the fifth digital signature verification is successful, the server verifies each device information in the first terminal-side trusted device list after adding the second device information using the third public key, and updates the server-side trusted device list based on the verification results of each device information.

[0137] In some optional implementations of this embodiment, the device further includes a third sending unit, configured to: generate a first negotiation key based on the fifth public key and the second private key; encrypt the third key pair 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, it verifies the first certificate using the root certificate public key; when the first certificate verification is successful, the second device obtains the first public key from the first certificate and verifies the fifth digital signature using the first public key; when the fifth digital signature verification is successful, the second device verifies the device information in the updated server-side trusted device list using the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

[0138] 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 including 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 configured to: verify the fourth certificate using the root certificate public key; if the fourth certificate is verified successfully, obtain the fifth public key from the fourth certificate and display a second prompt message; if a second input from the user to the second prompt message is received, generate a random number and obtain a one-time password from the local machine; generate a verification code based on the random number and the one-time password; generate a first negotiation key based on the fifth public key and the second private key; and generate a verification code based on the fifth public key and the second private key. The server generates a second negotiation key using the first private key and the first private key; it encrypts the random number using the first negotiation key to obtain a second ciphertext; it encrypts the third key pair using the second negotiation key to obtain a third ciphertext; it sends 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; it displays the verification code so that the user can input 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 verified successfully, it is determined that the second device has passed the verification.

[0139] In some optional implementations of this embodiment, the establishment unit 404 is further configured to: download the updated server-side trusted device list from the server when the second device is verified and the server-side trusted device list in the server is updated, 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 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; 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.

[0140] The apparatus provided in the above embodiments of this application, when a first device logs into an account and is the first device to log in to the account, sends the first device information of the first device to the server; upon receiving a verification request for a second device, it verifies the second device based on the identity information of the second device in the verification request; and if the second device passes the verification, it establishes a trust relationship 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 after the second device logs into the same account and it is determined that the server stores the first device information, the information transmission is facilitated by the server during the establishment of a trust relationship with the second device. This allows for the establishment of a trust relationship with devices logged into the same account at any distance, without requiring the devices to be in the same local area network environment, thus avoiding distance limitations in establishing trust relationships between devices and enriching the applicable scenarios for establishing trust relationships between devices.

[0141] The device trust relationship establishment device in this application embodiment 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 other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. The embodiments of this application do not specifically limit it.

[0142] The device trust relationship establishment apparatus in this application embodiment can be a device with an operating system. The operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0143] The device trust relationship establishment apparatus provided in this application embodiment can implement the various processes implemented in the method embodiment of FIG1. ​​To avoid repetition, it will not be described again here.

[0144] Optionally, as shown in FIG5, this application embodiment also provides an electronic device 500, including a processor 501 and a memory 502. The memory 502 stores a program or instructions that can run on the processor 501. When the program or instructions are executed by the processor 501, they implement the various steps of the above-described method embodiment for establishing trust relationships between devices and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0145] It should be noted that the electronic devices in the embodiments of this application include the aforementioned mobile electronic devices and non-mobile electronic devices.

[0146] Figure 6 is a schematic diagram of the hardware structure of an electronic device that implements an embodiment of this application.

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

[0148] Those skilled in the art will understand that the electronic device 600 may also include a power supply (such as a battery) for powering various components. The power supply can be logically connected to the processor 610 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The electronic device structure shown in Figure 6 does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0149] The processor 610 is configured to: send first device information of the first device to the server when the first device logs into the account and the first device is the first device to log into the account; 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 into the account and it is determined that the server stores the first device information, and the verification request includes the identity information of the second device; verify the second device based on the identity information; and establish a trust relationship with the second device if the verification of the second device is successful.

[0150] Since the verification request for the second device is sent from the second device to the first device via the server after the second device is logged into the same account and the server has confirmed that the first device's information is stored in the server, the server is used to transmit information during the process of establishing a trust relationship with the second device. This allows a trust relationship to be established with devices logged into the same account at any distance, without requiring the devices to be in the same local area network environment. This avoids the distance limitation of establishing trust relationships between devices and enriches the applicable scenarios for establishing trust relationships between devices.

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

[0152] In some optional implementations, the processor 610 is further configured to, when the first device logs into an account and the first device is the first login device for the account, obtain a first key pair, a second key pair, and a third key pair, wherein 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 identifier of the first device and the second private key using the third private key to obtain a first digital signature; and create a first terminal-side trusted device list, wherein the first terminal-side trusted device list includes first device information of the first device, and the first device information includes the first device identifier, the second public key, and the first digital signature.

[0153] In some optional implementations, the processor 610 is further configured to send the first public key to the server to obtain 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; 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 using 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 using 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 using the third public key; and if the first device information is verified successfully, the server-side trusted device list is created.

[0154] In some optional implementations, the second device stores 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, 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 further configured to display a first prompt message through a display unit 606; in response to a first input to the first prompt message, verify the second certificate with the root certificate public key; if 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; if the third digital signature is verified successfully, determine that the second device has been verified successfully.

[0155] In some optional implementations, the processor 610 is further configured to sign the fifth public key with the third private key to obtain a fourth digital signature; add 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.

[0156] In some optional implementations, the processor 610 is further configured to sign the first terminal-side trusted device list after adding the second device information using 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 using 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 using 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 using the third public key, and updates the server-side trusted device list based on the verification results of each device information.

[0157] In some optional implementations, the processor 610 is further configured to generate a first negotiation key based on the fifth public key and the second private key; encrypt the third key pair 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 using the first negotiation key to obtain the third key pair; upon receiving the updated server-side trusted device list from the server, the second device verifies the first certificate using the root certificate public key; if the first certificate verification is successful, the second device obtains the first public key from the first certificate and verifies the fifth digital signature using the first public key; if the fifth digital signature verification is successful, the second device verifies the device information in the updated server-side trusted device list using the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

[0158] 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 including 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 configured to verify the fourth certificate using the root certificate public key; if the fourth certificate is verified successfully, the processor obtains the fifth public key from the fourth certificate and displays a second prompt message through the display unit 606; if the processor receives a second input from the user regarding the second prompt message through the user input unit 607, the processor generates a random number and obtains a one-time password from the local storage; based on the random number and the one-time password, the processor generates a verification code; based on the fifth public key and the second private key, the processor generates a first negotiation key; based on the fifth public key and the second private key, the processor generates a third certificate of the second public key and the third public key; based on the fifth public key and the second public ... The public key, the second private key, and the verification code are used to generate a second negotiation key; the random number is encrypted using the first negotiation key to obtain a second ciphertext; the third key pair is encrypted using the second negotiation key to obtain a third ciphertext; the third certificate, the second ciphertext, and the third ciphertext are sent 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; the verification code is displayed through the display unit 606 so that the user can input 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 verified successfully, it is determined that the second device has passed the verification.

[0159] In some optional implementations, the processor 610 is further configured to: download the updated server-side trusted device list from the server when the second device is verified and the server-side trusted device list in the server is updated; 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 a 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.

[0160] It should be understood that, in this embodiment, the input unit 604 may include a graphics processing unit (GPU) 6041 and a microphone 6042. The GPU 6041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 606 may include a display panel 6061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 607 includes at least one of a touch panel 6071 and other input devices 6072. The touch panel 6071 is also called a touch screen. The touch panel 6071 may include a touch detection device and a touch controller. Other input devices 6072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

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

[0162] Processor 610 may include one or more processing units; optionally, processor 610 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 610.

[0163] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described method for establishing trust relationships between devices and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0164] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0165] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described method embodiment for establishing trust relationships between devices, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0166] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

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

[0168] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0169] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0170] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for establishing a trust relationship between devices, executed by a first device, the method comprising: If the first device is logged into an account and is the first device logged into the account, the first device information of the first device is sent to the server. A verification request for a second device is received. The verification request is sent from the second device to the first device via the server after the second device has logged into the account and it is determined that the server stores the information of the first device. The verification request includes the identity information of the second device. The second device is verified based on the identity information; If the second device passes the verification, a trust relationship is established with the second device.

2. The method according to claim 1, wherein, In the case where the first device is the first device to log in to the account and is the first device to log in to the account, sending 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, a first terminal-side trusted device list is created, which includes the first device information of the first device. The first terminal-side trusted device list is sent to the server so that the server, after verifying the first terminal-side trusted device list, creates a server-side trusted device list based on 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, wherein, The step of creating a first terminal-side trusted device list when the first device is the first device logged into the account and the first device is the first device logged into the account includes: When the first device logs in to the account and the first device is the first login device for the account, a first key pair, a second key pair, and a third key pair are obtained. 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. A first digital signature is obtained by signing the first device identifier of the first device and the second private key using the third private key; Create a first terminal-side trusted device list, which includes first device information of the first device, including the first device identifier, the second public key, and the first digital signature.

4. The method according to claim 3, wherein, The step of sending the first terminal-side trusted device list to the server, so that the server, after verifying the first terminal-side trusted device list, creates a server-side trusted device list based on the first terminal-side trusted device list, includes: Send the first public key to the server and obtain the first certificate of the first public key returned by the server; The first terminal-side trusted device list is signed 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 can verify the first certificate using 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 using 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 using the third public key. If the first device information is verified successfully, the server creates a server-side trusted device list.

5. The method according to claim 4, wherein, 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. The third digital signature is obtained by signing the second device identifier and the fifth public key with the fourth private key. The verification of the second device based on the identity information includes: The first prompt message is displayed; In response to the first input of the first prompt information, the second certificate is verified using the root certificate public key; If the second certificate is verified, the fourth public key is obtained from the second certificate, and the third digital signature is verified using the fourth public key; If the third digital signature verification is successful, the second device verification is confirmed to be successful.

6. The method according to claim 5, wherein, The establishment of a trust relationship with the second device includes: The fourth digital signature is obtained by signing the fifth public key with the third private key; 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 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, wherein, After establishing a trust relationship with the second device, the method further includes: The first terminal-side trusted device list, after adding the second device information, is signed using the first private key to obtain the 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 can verify the first certificate using 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 using the first public key. If the fifth digital signature is verified successfully, the server verifies the device information in the first terminal-side trusted device list after adding the second device information using 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, wherein, After establishing a trust relationship with the second device, the method further includes: Based on the fifth public key and the second private key, a first negotiation key is generated; The first ciphertext is obtained by encrypting the third key pair using the first negotiated key. The first ciphertext is sent 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 from the server, it verifies the first certificate using the root certificate public key. If the first certificate is verified successfully, the second device obtains the first public key from the first certificate and verifies the fifth digital signature using the first public key. If the fifth digital signature is verified successfully, the second device verifies the information of each device in the updated server-side trusted device list using 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, wherein, 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 of the second device based on the identity information includes: The fourth certificate is verified using the root certificate public key; If the fourth certificate is verified successfully, the fifth public key is obtained from the fourth certificate, and a second prompt message is displayed; Upon receiving a second input from the user regarding the second prompt information, a random number is generated, and a one-time password is retrieved from the local machine; A verification code is generated based on the random number and the one-time password; Based on the fifth public key and the second private key, a first negotiation key is generated; A second negotiation key is generated based on the fifth public key, the second private key, and the verification code; The random number is encrypted using the first negotiated key to obtain the second ciphertext; The third key pair is encrypted using the second negotiated key to obtain the third ciphertext; The third certificate, the second ciphertext, and the third ciphertext are sent to the second device via the server, so that the second device can decrypt the second ciphertext and the third ciphertext based on the verification code to obtain the random number and the third key pair; The verification code is displayed so that the user can input 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 passes verification, the second device is deemed to have passed verification.

10. The method according to claim 9, wherein, The establishment of a trust relationship with the second device includes: If 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. 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 the information of each device in the updated server-side trusted device list; Based on the verification results of each device, the list of trusted devices on the first terminal side is updated.

11. A device for establishing trust relationships between devices, the device comprising: The first sending unit is configured 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 is configured to receive a verification request for a second device. The verification request is sent from the second device to the first device via the server after the second device logs into the account and determines that the server stores the information of the first device. The verification request includes the identity information of the second device. A verification unit is used to verify the second device based on the identity information; The establishment unit is used to establish a trust relationship with the second device if the second device passes the verification.

12. The apparatus according to claim 11, wherein, The first transmitting unit is further configured to: When the first device is logged into an account and is the first device logged into the account, a first terminal-side trusted device list is created, which includes the first device information of the first device; the first terminal-side trusted device list is sent to the server, so that after verifying the first terminal-side trusted device list, the server creates a server-side trusted device list based on the first terminal-side trusted device list, which includes the first device information.

13. The apparatus according to claim 12, wherein, The first transmitting unit is further configured to: When the first device logs into an account and is the first device to log in to the account, a first key pair, a second key pair, and a third key pair are obtained. 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 first device identifier and the second private key of the first device are signed using the third private key to obtain a first digital signature. A first terminal-side trusted device list is created, which includes the first device information of the first device, which includes the first device identifier, the second public key, and the first digital signature.

14. The apparatus according to claim 13, wherein, The first transmitting unit is further configured to: The first public key is sent to the server to obtain a first certificate returned by the server. The first terminal-side trusted device list is signed 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 using the root certificate public key. If the first certificate is verified, the server retrieves the first public key from the first certificate and verifies the second digital signature using the first public key. If the second digital signature is verified, the server verifies the first device information in the first terminal-side trusted device list using the third public key. If the first device information is verified, a server-side trusted device list is created.

15. The apparatus according to claim 14, wherein, The second device stores 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, 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 verification unit 40 is further configured to: Display a first prompt message; respond to a first input to the first prompt message, verify the second certificate using the root certificate public key; if the second certificate is verified successfully, obtain the fourth public key from the second certificate, and verify the third digital signature using the fourth public key; if the third digital signature is verified successfully, determine that the second device has been verified successfully.

16. The apparatus according to claim 15, wherein, The establishment unit is further configured 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, wherein the second device information includes the second device identifier, the fifth public key and the fourth digital signature, and the devices in the first terminal-side trusted device list have a trust relationship.

17. The apparatus according to claim 16, wherein, The device further includes: The second sending unit is configured to: when the second device is verified, sign the first terminal-side trusted device list after adding the second device information using 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 can verify the first certificate using the root certificate public key; when the first certificate is verified, the server obtains the first public key from the first certificate and verifies the fifth digital signature using the first public key; when the fifth digital signature is verified, the server verifies the device information in the first terminal-side trusted device list after adding the second device information using the third public key, and updates the server-side trusted device list based on the verification results of each device information.

18. The apparatus according to claim 17, wherein, The device further includes: The third sending unit is configured to generate a first negotiation key based on the fifth public key and the second private key; encrypt the third key pair 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 using the first negotiation key to obtain the third key pair; when the second device receives the updated server-side trusted device list from the server, it verifies the first certificate using the root certificate public key; when the first certificate verification is successful, the second device obtains the first public key from the first certificate and verifies the fifth digital signature using the first public key; when the fifth digital signature verification is successful, the second device verifies the device information in the updated server-side trusted device list using the third public key, and creates a second terminal-side trusted device list based on the verification results of each device information.

19. The apparatus according to claim 14, wherein, The first device stores a third certificate of the second public key, the second device stores a fifth key pair, the fifth key pair including 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 is further configured to: The fourth certificate is verified using the root certificate public key; if the fourth certificate is verified successfully, the fifth public key is obtained from the fourth certificate, and a second prompt message is displayed. Upon receiving a second input from the user regarding the second prompt information, a random number is generated, and a one-time password is retrieved from the local machine; a verification code is generated based on the random number and the one-time password; Based on the fifth public key and the second private key, a first negotiation key is generated; A second negotiation key is generated based on the fifth public key, the second private key, and the verification code; The random number is encrypted using the first negotiation key to obtain the second ciphertext; the third key pair is encrypted using the second negotiation key to obtain the third ciphertext. The third certificate, the second ciphertext, and the third ciphertext are sent to the second device via the server, so that the second device can decrypt the second ciphertext and the third ciphertext based on the verification code to obtain the random number and the third key pair; The verification code is displayed so that the user can input 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 passes verification, the second device is deemed to have passed verification.

20. The apparatus according to claim 19, wherein, The establishment unit is also used for: If the second device is successfully verified, and if the server-side trusted device list in the server is updated, the updated server-side trusted device list is downloaded from the server. This 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 a fourth digital signature obtained by signing the fifth public key with the third private key. Each device information in the updated server-side trusted device list is verified. Based on the verification results of each device information, the first terminal-side trusted device list is updated.

21. An electronic device, comprising a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the inter-device trust relationship establishment method as described in any one of claims 1-10.

22. A readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the inter-device trust relationship establishment method as described in any one of claims 1-10.

23. A chip, the chip comprising a processor and a communication interface, the communication interface being coupled to the processor, the processor being configured to run a program or instructions to implement the steps of the inter-device trust relationship establishment method as described in any one of claims 1-10.

Images