Equipment cooperation method and device, electronic equipment and storage medium

Abstract

The invention relates to an equipment cooperation method and device, electronic equipment and a storage medium. The device cooperation method comprises the following steps: a first device obtains at least one second trust relationship voucher of a second device, wherein the at least one second trust relationship voucher is in one-to-one correspondence with at least one trust relationship; performing bidirectional verification on the at least one trust relationship between the first device and the second device; and in response to a target trust relationship included in the trust relationships passing the bidirectional verification, performing cooperative processing on a first service between the first device and the second device, the target trust relationship being a trust relationship supported by the first service. Therefore, one device is supported to have multiple trust relationships at the same time, and each device is supported to join the trusted network based on the multiple trust relationships, so that the networking application scene is expanded, and each distributed service can be supported to select the trusted device for monitoring which trust relationship is selected.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technologies, and in particular to a device collaboration method, apparatus, electronic device, and storage medium. Background Art

[0002] Self-organizing network technology builds trusted devices into a trusted device network, providing seamless and zero-wait device awareness notification services, making it easier for businesses to build distributed scenarios more quickly.

[0003] In some embodiments, different devices under the same account can achieve self-discovery, self-networking, and self-connection. That is, multiple devices can establish a trusted network based on the trust relationship of the account. Each device in the trusted network is a trusted device of each other, and data sharing, service linkage, etc. can be achieved between trusted devices.

[0004] Currently, there are still some technical problems in self-organizing network technology that need to be solved urgently. Summary of the Invention

[0005] The present disclosure provides a device collaboration method, apparatus, electronic device, and storage medium to address deficiencies in related technologies.

[0006] According to a first aspect of an embodiment of the present disclosure, a device collaboration method is proposed, comprising: obtaining at least one second trust relationship credential of a second device, the at least one second trust relationship credential corresponding one-to-one to at least one trust relationship; performing bidirectional verification on the at least one trust relationship between a first device and the second device; in response to a target trust relationship being included in the trust relationship that passes the bidirectional verification, performing collaborative processing on a first service between the first device and the second device, wherein the target trust relationship is a trust relationship supported by the first service.

[0007] Optionally, performing bidirectional verification on the at least one trust relationship between the first device and the second device includes: performing bidirectional verification on the at least one trust relationship during a process of establishing a connection between the first device and the second device.

[0008] Optionally, the bidirectional verification of the at least one trust relationship between the first device and the second device includes: after establishing a connection between the first device and the second device, bidirectional verification of the at least one trust relationship through the connection.

[0009] Optionally, the second device holds at least one second public-private key pair corresponding one-to-one to the at least one trust relationship; the second trust relationship certificate is the public key included in the second public-private key pair.

[0010] Optionally, the first device holds at least one first public-private key pair corresponding one-to-one to the at least one trust relationship; the bidirectional verification of any one of the at least one trust relationship is performed between the first device and the second device, including: generating first verification information based on the private key included in the first public-private key pair corresponding to any one of the trust relationships held by the first device, and sending the first verification information to the second device, so that the second device verifies the first verification information based on the first trust relationship certificate corresponding to any one of the trust relationships, wherein the first trust relationship certificate is the public key included in the first public-private key pair; and receiving second verification information from the second device, and verifying the second verification information based on the second trust relationship certificate corresponding to any one of the trust relationships, wherein the second verification information is generated based on the private key included in the second public-private key pair corresponding to any one of the trust relationships held by the second device.

[0011] Optionally, the first device and the second device negotiate a session key; sending the first verification information to the second device includes: encrypting the first verification information based on the session key, and sending the encrypted first verification information to the second device, so that the second device decrypts the encrypted first verification information based on the session key; receiving the second verification information from the second device includes: receiving the encrypted second verification information from the second device, and decrypting the encrypted second verification information based on the session key, wherein the encrypted second verification information is obtained by encrypting the second verification information based on the session key.

[0012] Optionally, the trust relationship includes at least one of the following: a first trust relationship, the first trust relationship indicates that different devices have been bound point-to-point; a second trust relationship, the second trust relationship indicates that the same account is logged in on different devices; a third trust relationship, the third trust relationship indicates that different accounts logged in on different devices have joined the same group; a fourth trust relationship, the fourth trust relationship indicates that different devices are configured in the same device set.

[0013] According to the second aspect of an embodiment of the present disclosure, a device collaboration device is proposed, which includes: a credential management module for obtaining at least one second trust relationship credential of a second device, wherein the at least one second trust relationship credential corresponds one-to-one to at least one trust relationship; a trust relationship verification module for performing bidirectional verification of the at least one trust relationship between a first device and the second device; and a business collaboration module for collaboratively processing a first business between the first device and the second device in response to the inclusion of a target trust relationship in a trust relationship that passes bidirectional verification, wherein the target trust relationship is a trust relationship supported by the first business.

[0014] According to a third aspect of the embodiments of the present disclosure, an electronic device is provided, including:

[0015] processor;

[0016] a memory for storing processor-executable instructions;

[0017] The processor is used to implement the device collaboration method of the first aspect.

[0018] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the steps of the device cooperation method in the first aspect are implemented.

[0019] The technical solutions provided by the embodiments of the present disclosure may have the following beneficial effects:

[0020] According to an embodiment of the present disclosure, at least one trust relationship can be bidirectionally verified between a first device and a second device, and in response to the target trust relationship supported by the first service being included in the bidirectionally verified trust relationship, the first service can be collaboratively processed between the first device and the second device. Accordingly, on the one hand, it supports the simultaneous existence of multiple trust relationships on a device, and also supports each device to join a trusted network based on multiple trust relationships, thereby expanding the application scenarios of the network; on the other hand, it supports each distributed service to choose which trusted device to monitor for a trust relationship, that is, it supports each distributed service to filter out some trusted devices that may collaborate from all trusted devices that have joined the trusted network according to its own needs, thereby avoiding unnecessary resource overhead.

[0021] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0023] Figure 1 The figure is a schematic diagram showing a device state change according to an exemplary embodiment.

[0024] Figure 2 is a schematic diagram showing another device state change according to an exemplary embodiment.

[0025] Figure 3 The figure is a schematic diagram showing a self-organizing network process according to an exemplary embodiment.

[0026] Figure 4 The figure is a schematic diagram showing an architecture of a trusted network according to an exemplary embodiment.

[0027] Figure 5A The figure is a schematic diagram showing a trustworthy scenario according to an exemplary embodiment.

[0028] Figure 5B is a schematic diagram showing another trusted scenario according to an exemplary embodiment.

[0029] Figure 5C is a schematic diagram showing another trusted scenario according to an exemplary embodiment.

[0030] Figure 6 The figure is a flowchart of a device cooperation method according to an exemplary embodiment.

[0031] Figure 7 The figure is a schematic diagram showing an interaction of two-way verification according to an exemplary embodiment.

[0032] Figure 8 The figure is a schematic diagram of a two-way verification algorithm according to an exemplary embodiment.

[0033] Figure 9 This is a schematic block diagram of a device collaboration apparatus according to an embodiment of the present disclosure.

[0034] Figure 10 It is a schematic block diagram of an apparatus for device collaboration according to an exemplary embodiment. DETAILED DESCRIPTION

[0035] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

[0036] In order to help those skilled in the art better understand the embodiments of the present disclosure, the following takes the example of establishing a trusted network based on the trust relationship of an account as an example. Figures 1 to 3 , briefly describes the trusted devices and ad hoc network process.

[0037] Figure 1 FIG. 1 is a schematic diagram showing a device state change according to an exemplary embodiment. Figure 1 As shown, an unfamiliar device refers to a device that has not established or authenticated any trust relationship. By performing a pairing process on an unfamiliar device, a trust relationship can be established for the unfamiliar device, turning the unfamiliar device into a trusted device. Trust relationship credentials can also be generated for trusted devices, so that after leaving the trust network, the trusted device can quickly join the trust network by performing an authentication process on the trust relationship credentials it holds, without having to perform the pairing process again. Potential trusted network devices refer to devices that hold trust relationship credentials. Among them, the pairing process for an unfamiliar device can be, for example, logging into an account on an unfamiliar device; the trust relationship credentials held by the trusted device can be, for example, an account (including but not limited to account ID, account token, account public key, account certificate, etc.).

[0038] Figure 2 FIG. 1 is a schematic diagram showing another device state change according to an exemplary embodiment. Figure 2 As shown, the trusted network can discover potential trusted devices through technologies such as Bluetooth Low Energy (BLE) and Multicast Domain Name System (mDNS), and at this time the device is a discovered device; further, the trusted device in the trusted network can request to establish a connection with the discovered device, and in the process of establishing the connection, the device authentication and key negotiation can be completed. After the authentication is passed, the device is a trusted online device; further, the trusted online device can log out of the account, and at this time the device is a discovered device. The trusted online device can be turned off or away from the trusted network (such as a local area network), and at this time the device is a trusted offline device; further, the trusted offline device can log out of the account, and at this time the device is a potential trusted device. Alternatively, the trusted offline device can be turned on or moved to the coverage area of ​​the trusted network, and the trusted network can discover the trusted offline device through technologies such as BLE and mDNS, and at this time the device is a discovered device.

[0039] Figure 3 FIG. 1 is a schematic diagram showing a self-organizing network process according to an exemplary embodiment. Figure 3As shown, in the device discovery phase, after starting the networking, potential trusted devices can be discovered by broadcasting and / or scanning through technologies such as BLE and mDNS, and the discovered potential trusted devices can be reported to the self-organizing network (such as trusted devices in a trusted network). Furthermore, in the device connection authentication phase, a request can be made to establish a connection, and device authentication, key negotiation and other processes can be performed during the connection process. Furthermore, in the networking information exchange phase, the two devices can exchange device information based on the established connection. Furthermore, the trusted device subscription module can also be notified to achieve data sharing, service linkage, etc. between trusted devices. Among them, for the specific implementation methods of the processes of establishing connections, device authentication, key negotiation, exchanging device information, etc., please refer to the relevant technologies for the parts not described in detail in this disclosure, and will not be repeated here.

[0040] In some embodiments, in addition to the account trust relationship, devices can also establish a trusted network based on other trust relationships. For example, one device can establish a trust relationship with another device through peer-to-peer binding. For example, different devices can log into the same home account or business account to establish a trust relationship between the different devices.

[0041] In one possible implementation, a device can authenticate one or more trust relationships, and one or more trust relationships may exist simultaneously between two devices. For example, if two devices are previously bound point-to-point without logging into the same account, a trust relationship (i.e., a trust relationship based on point-to-point binding) exists between them. If the two devices subsequently log into the same account again, two trust relationships (i.e., a trust relationship based on point-to-point binding and a trust relationship based on account) exist between them. Alternatively, if the two devices first unbind their point-to-point binding and then log into the same account, a trust relationship (i.e., an account-based trust relationship) exists between them.

[0042] In some embodiments, distributed services may not support all trust relationships. This means that trusted devices may need to decide whether to enable distributed services based on the type of trust relationship in the device network. Alternatively, they may need to filter devices in the device network that the distributed service does not need to monitor based on the type of trust relationship between devices. For example, if device A joins a trusted network established based on a point-to-point trust relationship, and service #1 running on device A expects to synchronize data between trusted devices logged into the same account, device A will not enable distributed service #1 in this trusted network.

[0043] The device collaboration method provided by the present disclosure is described below through specific embodiments and in combination with specific application scenarios.

[0044] See Figure 4 , Figure 4FIG. 1 is a schematic diagram showing an architecture of a trusted network according to an exemplary embodiment. Figure 4 As shown, the trusted network 400 includes a first device 401 and a second device 402 .

[0045] In some embodiments, real-time communication can be performed between the first device 401 and the second device 402 . The real-time communication may be based on at least one of the following systems: Long Term Evolution (LTE), LTE-Advanced (LTE-A), LTE-Beyond (LTE-B), SUPER 3G, IMT-Advanced, 4th generation mobile communication system (4G), 5th generation mobile communication system (5G), 5G new radio (NR), Future Radio Access (FRA), New-Radio Access Technology (RAT), New Radio (NR), New radio access (NX), Future generation radio access (FX), Global System for Mobile communications (GSM (registered trademark)), CDMA2000, Ultra Mobile Broadband (UMB), IEEE 1002.11 (Wi-Fi (registered trademark)), IEEE 1002.16 (WiMAX (registered trademark)), IEEE 1002.20, Ultra-WideBand (UWB), Bluetooth (registered trademark), Public Land Mobile Network (PLMN) networks, Device-to-Device (D2D) systems, Machine-to-Machine (M2M) systems, Internet of Things (IoT) systems, Vehicle-to-Everything (V2X), systems utilizing other communication methods, and next-generation systems based on and extending these methods.

[0046] In some embodiments, the first device 401 and the second device 402 may be different terminals. The terminals include, for example, at least one of a mobile phone, a wearable device, an Internet of Things device, a car with communication capabilities, a smart car, a tablet computer, a computer with wireless transceiver capabilities, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control, a wireless terminal device in self-driving, a wireless terminal device in remote medical surgery, a wireless terminal device in a smart grid, a wireless terminal device in transportation safety, a wireless terminal device in a smart city, and a wireless terminal device in a smart home, but are not limited thereto.

[0047] It should be noted that Figure 4 For example, the trusted network 400 may include more than two devices, any two of which may be the first device 401 and the second device 402 .

[0048] In addition, it should be noted that the first device and the second device involved in the present disclosure may be equivalent devices, the first device may be described as the current device, and the second device may be described as the opposite device, and the present disclosure does not limit this.

[0049] In some embodiments, one or more trust relationships may exist simultaneously between the first device 401 and the second device 402. In some embodiments, the trust relationship may include at least one of the following (1) to (4):

[0050] (1) A first trust relationship, wherein the first trust relationship indicates that different devices have been bound point-to-point.

[0051] For example, Figure 5A FIG. 1 is a schematic diagram showing a trustworthy scenario according to an exemplary embodiment. Figure 5A As shown, two devices can be bound point-to-point by entering a personal identification number (PIN code), near field communication (NFC), scanning a QR code, etc. to establish a first trust relationship between the two devices.

[0052] (2) A second trust relationship, wherein the second trust relationship indicates that the same account is logged in on different devices.

[0053] For example, Figure 5B FIG. 1 is a schematic diagram of another trustworthy scenario according to an exemplary embodiment. Figure 5B As shown, the same account (such as the same user account) can be logged in on two or more devices to establish a second trust relationship between the multiple devices.

[0054] (3) A third trust relationship, wherein the third trust relationship indicates that different accounts logged in on different devices have joined the same group.

[0055] For example, Figure 5C FIG. 1 is a schematic diagram of another trustworthy scenario according to an exemplary embodiment. Figure 5C As shown, different accounts (such as user accounts of user1, user2, and user3) can be logged in on two or more devices respectively. These accounts join the same group (such as a family group, an enterprise group, etc.), and a third trust relationship is established between these devices.

[0056] (4) A fourth trust relationship, where the fourth trust relationship indicates that different devices are configured in the same device set.

[0057] For example, based on device attributes such as the Media Access Control Address (MAC address) and Internet Protocol Address (IP address), two or more devices can be configured in the same device set to establish a fourth trust relationship between these devices. For example, office devices belonging to the same department or organization can be configured in the same device set.

[0058] It should be noted that the above embodiment only exemplifies four trust relationships, and the present disclosure may also cover other trust relationships, which cannot be listed here one by one.

[0059] In some embodiments, after a trust relationship is established between a first device and a second device, a first trust relationship credential corresponding to the trust relationship may be generated for the first device, and a second trust relationship credential corresponding to the trust relationship may be generated for the second device. The terms "first trust relationship credential" and "second trust relationship credential" are used to distinguish between trust relationship credentials generated for different devices and are not intended to limit the present disclosure. For example, after the same PIN code is entered on both the first and second devices, a first trust relationship credential #a1 may be generated for the first device, and a second trust relationship credential #b1 may be generated for the second device.

[0060] See Figure 6 , Figure 6 The device collaboration method provided by the present disclosure can be performed as follows: Figure 4 The first device 401 shown is executed. In some embodiments, the device collaboration method provided by the present disclosure can be executed by an operating system (OS) carried by the first device. In one possible implementation, a networking service is running in the operating system carried by the first device, and the device collaboration method provided by the present disclosure can be executed by the networking service.

[0061] like Figure 6 As shown, the device cooperation method may include the following steps.

[0062] In step 601, at least one second trust relationship credential of a second device is obtained, where the at least one second trust relationship credential corresponds one-to-one with at least one trust relationship.

[0063] For example, the first device can obtain the second trust relationship certificate #b1 and the second trust relationship certificate #b2, wherein the second trust relationship certificate #b1 corresponds to the first trust relationship (such as used to indicate that the second device has entered a certain pin code), and the second trust relationship certificate #b2 corresponds to the second trust relationship (for example, used to indicate that the user account of user1 is logged in on the second device).

[0064] Optionally, the second device may obtain at least one first trust relationship credential of the first device, where the at least one first trust relationship credential corresponds one-to-one to at least one trust relationship.

[0065] For example, the second device can obtain the first trust relationship certificate #a1 and the first trust relationship certificate #a2, wherein the first trust relationship certificate #a1 corresponds to the first trust relationship (such as used to indicate that the first device has entered a certain pin code), and the first trust relationship certificate #a2 corresponds to the second trust relationship (for example, used to indicate that the user account of user1 is logged in on the first device).

[0066] In one possible implementation, the first device may obtain the second trust relationship credential of the second device when the first device establishes a trust relationship with the second device for the first time. For example, after the first device and the second device have entered the same PIN code, a first trust relationship credential #a1 may be generated for the first device, and a second trust relationship credential #b1 may be generated for the second device. The first device and the second device may then exchange the trust relationship credentials corresponding to the first trust relationship. In this case, the first device may obtain the second trust relationship credential #b1 of the second device.

[0067] In another possible implementation, the first device may be configured as follows: Figure 3 During the device discovery phase, device connection authentication phase, or networking information exchange phase, the second trust relationship credential of the second device is obtained. For example, if user account user1 is logged in on both the first and second devices, the first device holds first trust relationship credential #a2 corresponding to the second trust relationship, and the second device holds second trust relationship credential #b2 corresponding to the second trust relationship. During the device discovery phase, when a discovered potentially trusted second device is reported to the first device, the second trust relationship credential #b2 held by the second device can also be reported.

[0068] In the above embodiment, the second trust relationship credential may be obtained from the second device, or may be obtained from an authentication service of a trusted network.

[0069] In step 602, bidirectional verification is performed on the at least one trust relationship between the first device and the second device.

[0070] For example, after the first device obtains the second trust relationship certificate #b1 and the second trust relationship certificate #b2, it can perform two-way verification on the first trust relationship corresponding to the second trust relationship certificate #b1, and perform two-way verification on the second trust relationship corresponding to the second trust relationship certificate #b2.

[0071] Since the first device and the second device are peers in the trusted network, the two devices need to undergo bidirectional verification to prove that they are mutually trusted. Bidirectional verification means that the first device needs to verify whether the second device has established a trust relationship with it based on the second trust relationship certificate it has obtained, and the first device also needs to prove to the second device that it has established a trust relationship corresponding to the first trust relationship certificate obtained by the second device. In other words, the second device needs to verify whether the first device has established a trust relationship with it based on the first trust relationship certificate it has obtained.

[0072] In some possible implementations, the trust relationship credentials may specifically include, but are not limited to, PIN codes, account identifiers, device collection identifiers, certificates, public keys, etc. Accordingly, different verification methods may be used for different trust relationship credentials. For specific verification methods for public key credentials, please refer to the embodiments shown below. For specific verification methods for other credentials, please refer to related technologies, which will not be detailed in this disclosure.

[0073] In step 603, in response to the trust relationship passed through bidirectional verification including a target trust relationship, collaborative processing of the first service is performed between the first device and the second device, wherein the target trust relationship is a trust relationship supported by the first service.

[0074] For example, if the first service only supports the second trust relationship, the target trust relationship is the second trust relationship; the first device obtains the second trust relationship certificate #b1 and the second trust relationship certificate #b2, and the two-way verification of the first trust relationship and the second trust relationship between the first device and the second device has passed. In response to the second trust relationship being included in the trust relationship that has passed the two-way verification, the first service can be collaboratively processed between the first device and the second device.

[0075] The first service is a distributed service. In one possible implementation, the first service may run on the first device and / or the second device. In one possible implementation, the first service may include any service running on the first device and / or the second device. In one possible implementation, the target trust relationship supported by the first service may include one or more trust relationships. For example, the first service may be a clipboard service, and the clipboard service may support a second trust relationship.

[0076] Among them, collaborative processing of the first service between the first device and the second device may include at least one of the following: indicating to the first service running on the first device that the second device is a collaborative device, so that the first service monitors the data related to the first service on the second device; synchronizing data related to the first service between the first device and the second device; and obtaining relevant data for collaborative processing of the first service from the second device in response to a collaboration request initiated by the first service.

[0077] As can be seen from the above embodiments, at least one trust relationship can be bidirectionally verified between the first device and the second device, and in response to the target trust relationship supported by the first service being included in the bidirectionally verified trust relationship, the first service can be collaboratively processed between the first device and the second device. Accordingly, on the one hand, it supports the simultaneous existence of multiple trust relationships on a device, and also supports each device to join a trusted network based on multiple trust relationships, thereby expanding the application scenarios of the network; on the other hand, it supports each distributed service to choose which trusted device to monitor for a certain trust relationship, that is, it supports each distributed service to filter out some trusted devices that may collaborate from all trusted devices that have joined the trusted network according to its own needs, thereby avoiding unnecessary resource overhead.

[0078] In some embodiments, at least one trust relationship may be bidirectionally verified during the process of establishing a connection between a first device and a second device. The connection established between the first device and the second device may generally refer to a communication connection or specifically refer to a trusted channel between two trusted devices in a trusted network.

[0079] For example, the first device may be Figure 3In the device connection authentication phase shown, a bidirectional verification is performed on the first trust relationship corresponding to the second trust relationship certificate #b1, and a bidirectional verification is performed on the second trust relationship corresponding to the second trust relationship certificate #b2.

[0080] In some embodiments, after a connection is established between the first device and the second device, the at least one trust relationship may be bidirectionally verified through the connection.

[0081] For example, the first device may be Figure 3 In the networking information exchange phase shown, the first trust relationship corresponding to the second trust relationship certificate #b1 can be bidirectionally verified, and the second trust relationship corresponding to the second trust relationship certificate #b2 can be bidirectionally verified.

[0082] As can be seen from the above embodiments, during the device connection authentication phase or the networking information exchange phase of the self-organizing network process, multiple trust relationships can be bidirectionally verified between the first device and the second device, without the need to design additional self-organizing network processes or even additional data packet interactions. Verifying multiple trust relationships during the device connection authentication phase allows verification to be completed earlier. Verifying multiple trust relationships during the networking information exchange phase, because the connection between the first device and the second device has security attributes such as anti-leakage, anti-tampering, and anti-masquerade, allows operations such as exchanging device information, exchanging trust relationship credentials, and verifying trust relationships to be performed on the basis of secure communication, thereby improving the security of trust relationship verification and the reliability of the trust relationship verification results.

[0083] In order to facilitate those skilled in the art to better understand the embodiments of the present disclosure, the following takes the bidirectional verification in the networking information exchange stage as an example. Figure 7 An exemplary description is given. Figure 7 The figure is a schematic diagram showing an interaction of two-way verification according to an exemplary embodiment.

[0084] like Figure 7 As shown, service #1 is running on device A, and the operating system carried by device A may include networking services and authentication services. Among them, the networking service of device A can communicate with the networking services of other devices. The authentication service of device A can communicate with the networking service of device A, but will not communicate with the networking services of other devices. The networking service of device A can also communicate with service #1 of device A. The authentication service of device A and the networking service of device A can be set as one module, or as two independent modules, and this disclosure does not impose any restrictions on this. Similarly, service #1 can also run on device B, and the operating system carried by device B may include networking services and authentication services.

[0085] In some embodiments, device A's service #1 indicates filter 1, which sets a trust relationship, to device A's networking service. Filter 1 indicates the target trust relationship supported by service #1. Furthermore, device A and device B need to perform trust relationship verification process #1 to prove that device A has established a trust relationship. Furthermore, device A and device B need to perform trust relationship verification process #2 to prove that device B has established a trust relationship. Furthermore, if the trust relationship that passes bidirectional verification includes the target trust relationship, device B is deemed to satisfy filter 1 and is reported to device A's service #1.

[0086] It should be noted that if the trust relationship that passes the two-way verification does not include the target trust relationship, it is considered that device B does not meet filter1 and there is no need to report device B to service #1 of device A. Figure 7 In addition, service #1 of device B can also obtain other trusted devices that meet the target trust relationship through a similar process, which will not be described in detail here.

[0087] Among them, the trust relationship verification process #1 may include: the networking service of device A obtains at least one second trust relationship certificate of device B from the authentication service of device A, determines the trust relationship that needs to be verified based on the obtained second trust relationship certificate, and generates first verification information for the trust relationship that needs to be verified; further, through the encrypted channel between device A and device B, the networking service of device A sends the device information and first verification information of device A to the networking service of device B; further, the networking service of device B can send the first verification information to the authentication service of device B for verification and synchronization, and can receive the verification result of the first verification information returned by the authentication service of device B.

[0088] Similarly, trust relationship verification process #2 may include: the networking service of device B obtains at least one first trust relationship credential of device A from the authentication service of device B, determines the trust relationship that needs to be verified based on the obtained first trust relationship credential, and generates second verification information for the trust relationship that needs to be verified; further, through the encrypted channel between device A and device B, the networking service of device B sends the device information and second verification information of device B to the networking service of device A; further, the networking service of device A can send the second verification information to the authentication service of device A for verification and synchronization, and can receive the verification result of the second verification information returned by the authentication service of device A.

[0089] In some embodiments, the trust relationship credential may be a public key credential. In this case, a trust relationship between a first device and a second device may correspond to a first public-private key pair and a second public-private key pair. In one possible implementation, the first device holds at least one first public-private key pair corresponding to at least one trust relationship; the first trust relationship credential is the public key included in the first public-private key pair. The second device holds at least one second public-private key pair corresponding to at least one trust relationship; the second trust relationship credential is the public key included in the second public-private key pair.

[0090] For example, refer to Table 1, which shows a trust relationship, a correspondence between a first public-private key pair, and a second public-private key pair according to an exemplary embodiment.

[0091] Trust relationship First public-private key pair Second public-private key pair First trust relationship (Pa_L1, Sa_L1) (Pb_L1, Sb_L1) Second trust relationship (Pa_L2, Sa_L2) (Pb_L2, Sb_L2)

[0092] Table 1

[0093] As shown in Table 1, the second trust relationship credential #b1 corresponding to the first trust relationship can be a public key Pb_L1, and the second trust relationship credential #b2 corresponding to the second trust relationship can be a public key Pb_L2. The first trust relationship credential #a1 corresponding to the first trust relationship can be a public key Pa_L1, and the first trust relationship credential #a2 corresponding to the second trust relationship can be a public key Pa_L2. The first public-private key pair and / or the second public-private key pair can be a long-term public-private key pair for the device. In one possible implementation, the first public-private key pair and / or the second public-private key pair can include an elliptic curve public-private key pair.

[0094] In some embodiments, when the trust relationship credential is a public key credential, for any one of at least one trust relationship that needs to be verified: the first device can generate first verification information based on the private key (secret key) included in the first public-private key pair corresponding to any one of the trust relationships, and send the first verification information to the second device, so that the second device verifies the first verification information based on the first trust relationship credential corresponding to any one of the trust relationships; and the first device can receive second verification information from the second device, and verify the second verification information based on the second trust relationship credential corresponding to any one of the trust relationships, wherein the second verification information is generated based on the private key included in the second public-private key pair corresponding to any one of the trust relationships.

[0095] In some embodiments, the first device can encrypt first verification information based on a session key and send the encrypted first verification information to the second device, so that the second device decrypts the encrypted first verification information based on the session key; and the first device can receive encrypted second verification information from the second device and decrypt the encrypted second verification information based on the session key, wherein the encrypted second verification information is obtained by encrypting the second verification information based on the session key.

[0096] The session key may be a key between the first device and the second device. Figure 3 The session key is obtained by negotiation during the device connection authentication phase shown. For specific negotiation methods, please refer to the relevant technology. In one possible implementation, the session key can be a symmetric key used to encrypt and decrypt information transmitted between the first device and the second device. The specific algorithm for encrypting and decrypting the verification information is not limited in this disclosure, and can be, for example, the AESGCM algorithm.

[0097] In order to facilitate those skilled in the art to better understand the embodiments of the present disclosure, the following takes the bidirectional verification of the first trust relationship as an example when the trust relationship credential is a public key, and combines Table 1 and Figure 8 An exemplary description is given. Figure 8 The figure is a schematic diagram of a two-way verification algorithm according to an exemplary embodiment.

[0098] like Figure 8 As shown, after a first trust relationship is established between device A and device B and trust relationship credentials are exchanged, device A holds a first public-private key pair (Pa_L1, Sa_L1) and a second trust relationship credential Pb_L1, and device B holds a second public-private key pair (Pb_L1, Sb_L1) and the first trust relationship credential Pa_L1. After the device connection authentication phase, device A and device B can negotiate a session key k.

[0099] Furthermore, based on its own second trust relationship credential Pb_L1, device A can determine that bidirectional verification of the first trust relationship is required. Device A can generate a random number random_a and digitally sign the random number random_a using the private key Sa_L1 included in the first public-private key pair (Pa_L1, Sa_L1) corresponding to the first trust relationship to obtain first verification information sign_a. Device A can also encrypt the first verification information sign_a using its own session key k to obtain encrypted first verification information enc_sign_a. Further, device A can send the encrypted first verification information enc_sign_a to device B. After receiving the encrypted first verification information enc_sign_a, device B can first decrypt the encrypted first verification information enc_sign_a using its own session key k to obtain the first verification information sign_a. Device B can also verify the signature of the first verification information sign_a based on its own first trust relationship credential Pa_L1. If device B passes the signature verification of the first verification information sign_a, device B may determine that the first trust relationship has been established with device A.

[0100] Similarly, based on its own first trust relationship certificate Pa_L1, device B can determine that it needs to perform two-way verification on the first trust relationship. Device B can generate a random number random_b and digitally sign the random number random_b using the private key Sb_L1 included in the second public-private key pair (Pb_L1, Sb_L1) corresponding to the first trust relationship to obtain second verification information sign_b. Device B can also encrypt the second verification information sign_b based on its own session key k to obtain encrypted second verification information enc_sign_b. Further, device B can send the encrypted second verification information enc_sign_b to device A. After receiving the encrypted second verification information enc_sign_b, device A can first decrypt the encrypted second verification information enc_sign_b using its own session key k to obtain the second verification information sign_b. Device A can also verify the signature of the second verification information sign_b based on its own second trust relationship certificate Pb_L1. If device A passes the signature verification of the second verification information sign_b, device A may determine that the first trust relationship has been established with device B.

[0101] As can be seen from the above embodiments, on the one hand, by using the public key as a trust relationship credential, a unified verification mechanism is designed for different trust relationships, which can quickly complete two-way verification of various trust relationships in networking scenarios that support multiple trust relationships at the same time; on the other hand, compared with using account identifiers, group identifiers, device collection identifiers, etc. as trust relationship credentials, using the public key as a trust relationship credential is conducive to improving the security of device collaboration and can prevent the trust relationship credential from being easily obtained and maliciously forged and used. In addition, by encrypting the verification information to be transmitted with the session key, the reliability of the trust relationship verification can be further guaranteed, thereby improving the security of device collaboration.

[0102] Corresponding to the aforementioned device collaboration method, the present disclosure also provides an embodiment of a device collaboration apparatus.

[0103] See Figure 9 , Figure 9 FIG. 1 is a schematic block diagram of a device collaboration apparatus according to an embodiment of the present disclosure. Figure 9 As shown, the device collaboration apparatus 900 may include: a credential management module 902 , a trust relationship verification module 904 and a business collaboration module 906 .

[0104] In some embodiments, the credential management module is configured to obtain at least one second trust relationship credential of the second device, the at least one second trust relationship credential corresponding to at least one trust relationship;

[0105] The trust relationship verification module is configured to perform bidirectional verification of the at least one trust relationship between the first device and the second device;

[0106] The business collaboration module is configured to collaboratively process the first business between the first device and the second device in response to a target trust relationship being included in a trust relationship that passes bidirectional verification, wherein the target trust relationship is a trust relationship supported by the first business.

[0107] In some embodiments, the trust relationship verification module includes:

[0108] The first verification submodule is configured to perform bidirectional verification on the at least one trust relationship during a process of establishing a connection between the first device and the second device.

[0109] In some embodiments, the trust relationship verification module includes:

[0110] The second verification submodule is configured to perform bidirectional verification on the at least one trust relationship through a connection after a connection is established between the first device and the second device.

[0111] In some embodiments, the second device holds at least one second public-private key pair corresponding one-to-one to the at least one trust relationship; the second trust relationship credential is a public key included in the second public-private key pair.

[0112] In some embodiments, the first device holds at least one first public-private key pair corresponding to the at least one trust relationship;

[0113] The trust relationship verification module includes a third verification submodule and a fourth verification submodule; wherein the third verification submodule is configured to generate first verification information based on a private key included in a first public-private key pair corresponding to any one of the trust relationships held by the first device, and send the first verification information to the second device, so that the second device verifies the first verification information based on a first trust relationship credential corresponding to any one of the trust relationships, wherein the first trust relationship credential is the public key included in the first public-private key pair;

[0114] The fourth verification submodule is used to receive second verification information from the second device and verify the second verification information based on a second trust relationship credential corresponding to any one of the trust relationships, wherein the second verification information is generated based on the private key included in the second public-private key pair corresponding to any one of the trust relationships held by the second device.

[0115] In some embodiments, the first device negotiates a session key with the second device;

[0116] the third verification submodule, configured to encrypt the first verification information based on the session key, and send the encrypted first verification information to the second device, so that the second device decrypts the encrypted first verification information based on the session key;

[0117] The fourth verification submodule is configured to receive encrypted second verification information from the second device and decrypt the encrypted second verification information based on the session key, wherein the encrypted second verification information is obtained by encrypting the second verification information based on the session key.

[0118] In some embodiments, the trust relationship includes at least one of the following: a first trust relationship, wherein the first trust relationship indicates that different devices have been point-to-point bound; a second trust relationship, wherein the second trust relationship indicates that the same account has been logged in on different devices; a third trust relationship, wherein the third trust relationship indicates that different accounts logged in on different devices have joined the same group; and a fourth trust relationship, wherein the fourth trust relationship indicates that different devices are configured in the same device set.

[0119] Regarding the device collaboration apparatus 900 in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the relevant method and will not be elaborated here.

[0120] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the disclosed solution. Those of ordinary skill in the art can understand and implement it without paying any creative work.

[0121] An embodiment of the present disclosure further provides an electronic device, including:

[0122] processor;

[0123] a memory for storing processor-executable instructions;

[0124] The processor is configured to implement the device collaboration method described in any of the above embodiments.

[0125] An embodiment of the present disclosure further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the device cooperation method described in any of the above embodiments.

[0126] Figure 10 1 is a schematic block diagram of an apparatus 1000 for device collaboration according to an embodiment of the present disclosure. For example, apparatus 1000 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0127] Reference Figure 8 , the device 1000 may include one or more of the following components: a processing component 1002 , a memory 1004 , a power component 1006 , a multimedia component 1008 , an audio component 1010 , an input / output (I / O) interface 1012 , a sensor component 1014 , and a communication component 1016 .

[0128] The processing component 1002 generally controls the overall operation of the device 1000, such as operations associated with display, phone calls, data communications, camera operation, and recording operations. The processing component 1002 may include one or more processors 1020 to execute instructions to perform all or part of the steps of the above-described method. In addition, the processing component 1002 may include one or more modules to facilitate interaction between the processing component 1002 and other components. For example, the processing component 1002 may include a multimedia module to facilitate interaction between the multimedia component 1008 and the processing component 1002.

[0129] The memory 1004 is configured to store various types of data to support the operation of the device 1000. Examples of such data include instructions for any application or method operating on the device 1000, contact data, phone book data, messages, pictures, videos, etc. The memory 1004 can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0130] The power supply component 1006 provides power to the various components of the device 1000. The power supply component 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device 1000.

[0131] The multimedia component 1008 includes a screen that provides an output interface between the device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensor can not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1008 includes a front camera and / or a rear camera. When the device 1000 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each front camera and rear camera can be a fixed optical lens system or have a focal length and optical zoom capability.

[0132] The audio component 1010 is configured to output and / or input audio signals. For example, the audio component 1010 includes a microphone (MIC) that is configured to receive external audio signals when the device 1000 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be further stored in the memory 1004 or transmitted via the communication component 1016. In some embodiments, the audio component 1010 also includes a speaker for outputting audio signals.

[0133] I / O interface 1012 provides an interface between processing component 1002 and peripheral interface modules, such as a keyboard, click wheel, buttons, etc. These buttons may include but are not limited to: a home button, volume buttons, a start button, and a lock button.

[0134] Sensor assembly 1014 includes one or more sensors for providing various aspects of the status assessment of device 1000. For example, sensor assembly 1014 can detect the open / closed state of device 1000, the relative positioning of components, such as the display and keypad of device 1000. Sensor assembly 1014 can also detect changes in the position of device 1000 or a component of device 1000, the presence or absence of user contact with device 1000, the orientation or acceleration / deceleration of device 1000, and changes in the temperature of device 1000. Sensor assembly 1014 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1014 can also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1014 can also include an accelerometer, a gyroscope, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0135] The communication component 1016 is configured to facilitate wired or wireless communication between the device 1000 and other devices. The device 1000 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, 4G LTE, 5G NR or a combination thereof. In an exemplary embodiment, the communication component 1016 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1016 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0136] In an exemplary embodiment, the apparatus 1000 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the method described in any of the above embodiments.

[0137] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1004 including instructions, and the instructions can be executed by the processor 1020 of the apparatus 1000 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0138] Other embodiments of the present disclosure will readily occur to those skilled in the art after considering the specification and practicing the disclosure herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the following claims.

[0139] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes can be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A device collaboration method, characterized in that: The method comprises: Obtaining at least one second trust relationship credential of the second device, the at least one second trust relationship credential corresponding to at least one trust relationship; performing bidirectional verification of the at least one trust relationship between the first device and the second device; In response to the trust relationship passed through bidirectional verification including a target trust relationship, collaborative processing of a first service is performed between the first device and the second device, wherein the target trust relationship is a trust relationship supported by the first service.

2. The method according to claim 1, characterized in that The bidirectional verification of the at least one trust relationship between the first device and the second device includes: During the process of establishing a connection between the first device and the second device, bidirectional verification is performed on the at least one trust relationship.

3. The method according to claim 1, characterized in that The bidirectional verification of the at least one trust relationship between the first device and the second device includes: After a connection is established between the first device and the second device, bidirectional verification is performed on the at least one trust relationship through the connection.

4. The method according to claim 1, wherein The second device holds at least one second public-private key pair corresponding to the at least one trust relationship; The second trust relationship certificate is the public key included in the second public-private key pair.

5. The method according to claim 4, characterized in that The first device holds at least one first public-private key pair corresponding to the at least one trust relationship; The performing bidirectional verification on any one of the at least one trust relationship between the first device and the second device includes: generating first verification information based on a private key included in a first public-private key pair corresponding to the any one trust relationship and held by the first device, and sending the first verification information to the second device, so that the second device verifies the first verification information based on a first trust relationship credential corresponding to the any one trust relationship, wherein the first trust relationship credential is the public key included in the first public-private key pair; as well as, Receive second verification information from the second device and verify the second verification information based on a second trust relationship credential corresponding to any one of the trust relationships, wherein the second verification information is generated based on a private key included in a second public-private key pair corresponding to any one of the trust relationships held by the second device.

6. The method according to claim 5, characterized in that The first device negotiates a session key with the second device; The sending the first verification information to the second device includes: encrypting the first verification information based on the session key, and sending the encrypted first verification information to the second device, so that the second device decrypts the encrypted first verification information based on the session key; The receiving second verification information from the second device includes: The encrypted second verification information is received from the second device, and the encrypted second verification information is decrypted based on the session key, wherein the encrypted second verification information is obtained by encrypting the second verification information based on the session key.

7. The method according to any one of claims 1 to 6, characterized in that The trust relationship includes at least one of the following: A first trust relationship, where the first trust relationship indicates that different devices have been bound point-to-point; A second trust relationship, wherein the second trust relationship indicates that the same account is logged in on different devices; A third trust relationship, wherein the third trust relationship indicates that different accounts logged in on different devices have joined the same group; A fourth trust relationship indicates that different devices are configured in the same device set.

8. A device collaboration apparatus, characterized in that: The device comprises: a credential management module, configured to obtain at least one second trust relationship credential of a second device, wherein the at least one second trust relationship credential corresponds one-to-one with at least one trust relationship; a trust relationship verification module, configured to perform bidirectional verification of the at least one trust relationship between the first device and the second device; The business collaboration module is used to collaboratively process the first business between the first device and the second device in response to the target trust relationship being included in the trust relationship through bidirectional verification, wherein the target trust relationship is the trust relationship supported by the first business.

9. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images