Method for establishing communication, electronic device, system and readable storage medium

Abstract

The application discloses a method for establishing communication, an electronic device, a system and a readable storage medium, and belongs to the terminal technical field. The method comprises the following steps: in response to that a first electronic device logs in an account system, obtaining authentication information of a second electronic device from a trusted storage device, the second electronic device does not log in the account system, the second electronic device has networked with a third electronic device, the third electronic device has logged in the account system, and the authentication information of the second electronic device is registered in the trusted storage device after the second electronic device is bound with the third electronic device. In response to that the distance between the first electronic device and the second electronic device is less than a preset distance, performing trusted authentication with the second electronic device based on the authentication information of the second electronic device. In the case that the authentication is passed, the networking communication with the second electronic device is established. According to the application, the authentication information is registered to the cloud, so that the first electronic device can be networked with the second electronic device based on the authentication information without the participation of the user.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method for establishing communication, an electronic device, a system, and a readable storage medium. Background Technology

[0002] With the development of the Internet of Things (IoT) and smart devices, electronic devices such as mobile phones, smart home devices, and tablets are widely used in people's daily lives. In some application scenarios, two or more electronic devices are often required to network and communicate, so that one electronic device can control or transmit data to other electronic devices, such as controlling smart home devices through a mobile phone.

[0003] To ensure network security, the electronic devices involved in the network typically need to undergo trusted authentication before communication can proceed. Currently, electronic devices from the same manufacturer typically have their own account systems, so trusted authentication is usually based on these device accounts when forming a network.

[0004] However, in some scenarios, users may need to add electronic devices from other manufacturers to the network. Since these devices lack the necessary account system, trusted authentication based on the device account is impossible. Therefore, how to enable trusted authentication for electronic devices not logged into the account system to achieve secure network communication becomes a pressing issue. Summary of the Invention

[0005] This application provides a method, electronic device, system, and readable storage medium for establishing communication, which solves the problem that electronic devices without login or account access cannot perform secure network communication based on trusted device account authentication. The technical solution is as follows:

[0006] In a first aspect, a method for establishing communication is provided, applied to a first electronic device, the first electronic device being able to log in to an account system, the method comprising:

[0007] In response to the first electronic device logging into the account system, the system retrieves the authentication information of the second electronic device from the trusted storage device. This occurs when the second electronic device is not logged into the account system, the second and third electronic devices are networked, and the third electronic device is logged into the account system. The authentication information of the second electronic device is registered on the trusted storage device after the second and third electronic devices are bound together. In response to the distance between the first and second electronic devices being less than a preset distance, the system performs trusted authentication with the second electronic device based on its authentication information. If authentication is successful, network communication is established with the second electronic device.

[0008] The preset distance can be set according to needs. When the distance between the first electronic device and the second electronic device is less than the preset distance, it means that the first electronic device and the second electronic device are very close.

[0009] In one example, the first electronic device is mobile phone B logged into the account system, the second electronic device is vehicle-mounted device C not logged into the account system, and the third electronic device is mobile phone A logged into the account system. When the second and third electronic devices are linked, the third electronic device can register the authentication information of the second electronic device to the cloud. Thus, after the first electronic device logs into the account system, it can obtain the authentication information of the second electronic device from the cloud, enabling seamless and trusted authentication between the two devices for secure networking and improved networking efficiency.

[0010] As an example of this application, a specific implementation of trusted authentication with a second electronic device based on the authentication information of the second electronic device may include: exchanging information with the second electronic device, the exchanged information including at least a device identifier and authentication type, and may also include a device account and the authentication types it can support. If the authentication type indicated by the second electronic device is based on authentication information, a first personal identification code is generated, for example, PIN1 is generated. Based on the authentication information of the second electronic device, the first personal identification code, the first device identifier of the first electronic device (e.g., device ID2), and the authentication information are encrypted to obtain first authentication information. The first authentication information is sent to the second electronic device, enabling the second electronic device to obtain the first personal identification code, the first device identifier, and the authentication information of the first electronic device from the first authentication information. The second authentication information is received from the second electronic device, which is obtained by encrypting the second device identifier (e.g., device ID1) and the second personal identification code (e.g., PIN2) of the second electronic device based on the authentication information of the first electronic device. The second personal identification code is generated by the second electronic device. If the second personal identification code and the second device identifier are obtained from the second identity verification information based on the authentication information of the first electronic device, it indicates that the authentication information of the vehicle-mounted device C is secure and reliable. In this case, authentication is performed based on the first personal identification code, the second personal identification code, the first device identifier, and the second device identifier. Thus, by verifying the authentication information, the PIN code is exchanged upon successful verification, facilitating further authentication based on the PIN codes of both parties and the user's own PIN code, thereby improving the effectiveness of the authentication.

[0011] As an example of this application, a specific implementation of trusted authentication based on a first personal identification code and a second personal identification code may include: sending an authentication request to a second electronic device, the authentication request including PAKE protocol information to instruct the second electronic device to perform trusted authentication via the PAKE protocol based on the first personal identification code and the second personal identification code. Subsequently, the first electronic device performs trusted authentication with the second electronic device via the PAKE protocol based on the first personal identification code and the second personal identification code. Furthermore, after successful authentication based on the authentication information, authentication is performed again based on a PIN code to improve the reliability of the authentication.

[0012] As an example of this application, a specific implementation of obtaining authentication information of a second electronic device from a trusted storage device may include: sending an information retrieval request to the trusted storage device, and then receiving an information retrieval response from the trusted storage device in response to the information retrieval request, wherein the information retrieval response carries the authentication information of the second electronic device. That is, the first electronic device can proactively retrieve the authentication information from the trusted storage device, so that the first electronic device can obtain the latest authentication information of the second electronic device, avoiding updates to the authentication information on the trusted storage device, thereby improving the effectiveness of authentication.

[0013] In one example, a trusted storage device could be the cloud, or it could be a trusted storage device, such as trusted storage device X.

[0014] As an example of this application, a specific implementation of obtaining authentication information of a second electronic device from a trusted storage device may include: monitoring the authentication information sent by the trusted storage device to the second electronic device. That is, the cloud can also proactively push the authentication information, avoiding the need for the first electronic device to retrieve it itself.

[0015] As an example of this application, after authentication based on the first personal identification code and the second personal identification code, the first electronic device can store the authentication result so that before the next authentication based on the authentication information, it can first query whether the authentication result has been authenticated. If it has not been authenticated, the subsequent authentication process will be triggered. If it has been authenticated, information can be exchanged directly to avoid duplicate authentication.

[0016] Secondly, a method for establishing communication is provided, applied to a second electronic device that is not logged into an account system. The method includes:

[0017] In response to the distance between the second electronic device and the first electronic device being less than a preset distance, a trusted authentication is performed with the first electronic device based on the authentication information of the second electronic device. This trusted authentication is triggered by the first electronic device, which, while logged into the account system, obtains the authentication information of the second electronic device from a trusted storage device. This authentication information is registered on the trusted storage device after the second electronic device is bound to a third electronic device, which is already logged into the account system. Upon successful authentication, network communication is established with the first electronic device.

[0018] In this way, after the first electronic device logs into the account system, it can obtain the authentication information of the second electronic device from the cloud. When the first and second electronic devices are close to each other, they can perform trusted authentication without the user's notice, so as to form a secure network and improve networking efficiency.

[0019] As an example of this application, in response to the distance between the second electronic device and the first electronic device being less than a preset distance, before the first electronic device performs trusted authentication based on the authentication information of the second electronic device, the second electronic device, in response to a first user operation, displays a first interface including a third personal identification code (e.g., PIN0). If the distance between the second electronic device and the third electronic device is less than the preset distance, in response to the authentication request of the third electronic device, the second electronic device binds itself to the third electronic device based on the third personal identification code. The authentication request is triggered by the third electronic device after receiving a personal identification code input by the user using the third personal identification code. Thus, by displaying the third personal identification code, the user binds the second electronic device to the third electronic device, ensuring the reliability of the authentication information registered to the trusted storage device after binding.

[0020] As an example of this application, when the distance between the second electronic device and the third electronic device is less than a preset distance, after binding with the third electronic device based on a third person's identification code, upon successful binding, the second electronic device receives an authentication information retrieval request sent by the third electronic device. In response to the authentication information retrieval request, the second electronic device sends its own authentication information to the third electronic device, thereby registering the second electronic device's authentication information to a trusted storage device. Thus, by registering the authentication information to the trusted storage device through the second electronic device, other devices with accounts (such as the first electronic device) can subsequently obtain this authentication information from the trusted storage device, facilitating seamless trusted authentication between these other devices and the second electronic device based on this authentication information.

[0021] As an example of this application, when the distance between the second electronic device and the third electronic device is less than a preset distance, after binding with the third electronic device based on a third person's identification code, upon successful binding, the second electronic device receives registration information sent by the third electronic device. This registration information is obtained by the third electronic device from a trusted storage device after binding with the second electronic device. Based on the registration information, a registration negotiation is conducted with the trusted storage device. If the negotiation is successful, the authentication information of the second electronic device is registered with the trusted storage device. Thus, by requesting registration information through the third electronic device and then sending it to the second electronic device, the second electronic device can use this registration information to register its own authentication information to the cloud, avoiding the need for registration through the third electronic device.

[0022] As an example of this application, the second electronic device is equipped to communicate with a trusted storage device. In this case, when the distance between the second electronic device and the third electronic device is less than a preset distance, after binding with the third electronic device based on a third person identification code, the second electronic device receives an authentication information upload instruction. This instruction is sent by the third electronic device after binding with the second electronic device. In response to the authentication information upload instruction, the second electronic device registers its authentication information with the trusted storage device. That is, the second electronic device can register its authentication information with the trusted storage device itself, avoiding the need for registration through a third electronic device.

[0023] Thirdly, a system for establishing communication is provided, the system comprising a first electronic device, a second electronic device, a third electronic device, and a trusted storage device, including:

[0024] The first electronic device is used to respond to the login account system and obtain the authentication information of the second electronic device from the trusted storage device. The second electronic device is not logged into the account system. The authentication information of the second electronic device is registered in the trusted storage device after the second electronic device and the third electronic device are bound. The second electronic device and the third electronic device are networked. The third electronic device is logged into the system account.

[0025] The first electronic device is used to perform trusted authentication with the second electronic device based on the authentication information of the second electronic device when the distance between the first electronic device and the second electronic device is less than a preset distance;

[0026] The second electronic device is used to perform trusted authentication with the first electronic device based on the authentication information of the second electronic device;

[0027] The first electronic device is used to establish network communication with the second electronic device after successful authentication.

[0028] Fourthly, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method for establishing communication as described in the first or second aspect.

[0029] Fifthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the communication establishment method described in the first or second aspect above.

[0030] In a sixth aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the method for establishing communication described in the first or second aspect above.

[0031] The technical effects achieved by the fourth, fifth and sixth aspects mentioned above are similar to the technical effects achieved by the corresponding technical means in the first and / or second aspects mentioned above, and will not be repeated here. Attached Figure Description

[0032] Figure 1 This is a schematic diagram illustrating a network configuration using the same account, according to an exemplary embodiment.

[0033] Figure 2 This is a network diagram illustrating a device with an account and a device without an account, according to an exemplary embodiment.

[0034] Figure 3 This is a network diagram illustrating a device with an account and a device without an account, according to an exemplary embodiment.

[0035] Figure 4 This is a schematic diagram of the interface of an in-vehicle infotainment device according to an exemplary embodiment;

[0036] Figure 5 This is a schematic diagram of a mobile phone interface according to an exemplary embodiment;

[0037] Figure 6 This is a schematic diagram illustrating an application scenario according to an exemplary embodiment;

[0038] Figure 7 This is a flowchart illustrating a login account system according to an exemplary embodiment;

[0039] Figure 8 This is a schematic diagram illustrating an application scenario according to another exemplary embodiment;

[0040] Figure 9 This is a schematic diagram illustrating a software system of an electronic device according to an exemplary embodiment;

[0041] Figure 10 This is a flowchart illustrating a method for establishing communication according to an exemplary embodiment;

[0042] Figure 11 This is a schematic diagram illustrating a process of device bonding according to an exemplary embodiment;

[0043] Figure 12 This is a flowchart illustrating a method for establishing communication according to another exemplary embodiment;

[0044] Figure 13 This is a flowchart illustrating a method for establishing communication according to another exemplary embodiment;

[0045] Figure 14 This is a schematic diagram illustrating a method for establishing communication according to another exemplary embodiment;

[0046] Figure 15 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0048] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0049] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0050] In daily life, people often need to control or transmit data to other electronic devices through one electronic device, such as controlling a TV, air conditioner, printer, or in-vehicle infotainment system via a mobile phone. Typically, electronic devices can control or transmit data to other devices through communication methods such as Bluetooth, mobile networks, the Internet, and near-field communication (NFC). Short-range or area-restricted link communication such as Bluetooth, LAN, and NFC is generally called near-field communication, while long-range link communication such as mobile networks and the Internet is generally called far-field communication. Communication between two or more electronic devices based on a certain trusted relationship in the near-field or far-field is generally called network communication. During the network setup process, for electronic devices from the same manufacturer, since these devices can all log into the manufacturer's account system (such as Honor's account system), these electronic devices generally perform trusted authentication based on the device account (such as Honor account). Once authentication is successful, a trusted network communication can be established. For example... Figure 1 As shown, electronic devices with device accounts include electronic device A and electronic device B. During the networking process, electronic device A and electronic device B can perform trusted authentication based on their device accounts. If the authentication is successful, electronic device A and electronic device B can communicate in the network; if the authentication fails, electronic device A and electronic device B cannot communicate in the network. In some embodiments, trusted authentication based on device accounts for two or more electronic devices (from the same manufacturer) belonging to the same user can be referred to as same-account authentication.

[0051] However, in one possible scenario, an electronic device with a device account may not be logged into the account system. In this case, same-account authentication cannot be performed during network formation. In another possible scenario, users need secure network formation for electronic devices from different manufacturers. For example, when using multiple Honor electronic devices in a network, the user may need to add electronic devices from other manufacturers to the network, or vice versa. However, since other manufacturers do not have Honor's account system, their electronic devices appear to be without device accounts to the network's users, thus preventing same-account authentication. For ease of description, we will refer to electronic devices in both scenarios as "devices without accounts" and those logged into the account system as "devices with accounts."

[0052] In some embodiments, to enable secure networking between devices without accounts and devices with accounts, users can manually bind the devices with accounts to the devices without accounts. Therefore, if there are multiple devices with accounts, the user needs to manually bind the devices without accounts to each of the multiple devices with accounts, for example, see [link to relevant documentation]. Figure 2 In Figure (a), if device A (with an account), device B (with an account), and device C (without an account) need to be networked securely, the user needs to manually bind device C (without an account) to device A (with an account), and also manually bind device C (without an account) to device B (with an account). This results in low network communication efficiency. See also... Figure 2 As shown in Figure (b), if a new device N with an account is connected after the network is set up, the user needs to manually bind the device C without an account to the device N with an account again, which is a rather cumbersome operation.

[0053] In other embodiments, see Figure 3 In diagram (a), a user can manually bind an accounted device A to an accountless device C. Afterward, the accounted device A can share devices, meaning it can send device information or capabilities of the accountless device C to an accounted device B within the network via trusted transmission. At this point, the accounted device B can communicate directly with the accountless device C without any authentication. However, in this scenario, to ensure the security and privacy of controlling or operating the accountless device C, a master-slave relationship exists between the accounted devices A and B, with A as the master and B as the slave. If the master device is not present, the slave device cannot establish a communication relationship with the accountless device C. See, for example... Figure 3In Figure (b), when a new device N (slave device) with an account connects, if device A with an account is still present, device sharing can be achieved through trusted transmission, enabling device N with an account to establish a communication relationship with device C without an account. Otherwise, if device A with an account is not present, device N with an account cannot establish a communication relationship with device C without an account. Thus, because the devices with accounts are not in a peer-to-peer relationship but rather a master-slave relationship, secure networking is not possible in some scenarios.

[0054] Therefore, this application provides a method for establishing communication, which enables electronic devices without device accounts to easily and securely network with one or more electronic devices with device accounts without requiring multiple user interventions, and all devices with accounts are peers, that is, there is no master-slave relationship.

[0055] To facilitate understanding, the following sections will introduce several exemplary scenarios of network communication involved in the embodiments of this application:

[0056] Scenario 1: A device without an account forms a network with a device that has an account for the first time, that is, a device without an account joins the network.

[0057] An exemplary application scenario includes mobile phone A (an accounted device) and in-vehicle infotainment device C (an accountless device). Before networking, neither mobile phone A nor in-vehicle infotainment device C is connected to any other electronic devices. When a user wants to establish network communication between mobile phone A and in-vehicle infotainment device C, the user can enable Bluetooth on in-vehicle infotainment device C. Additionally, please refer to [link to relevant documentation]. Figure 4 In Figure (a), the user can open "Mobile Connectivity" on the vehicle-mounted device C to display the device connectivity interface U1. The device connectivity interface U1 includes a device addition control 41, which the user can click. In response to the user's triggering of the device addition control 41, the vehicle-mounted device C begins broadcasting a device discovery message. This message includes, but is not limited to, information such as the device name, device identifier, category, and address of the vehicle-mounted device C, so that the mobile phone A can discover the vehicle-mounted device C. The device name is the name of the vehicle-mounted device C, for example, XX; the device identifier is a unique identifier for the vehicle-mounted device C, such as a device ID or a unique device identifier (UDID); and the category indicates the type of vehicle-mounted device C. See also... Figure 4In Figure (b), in response to the user's triggering operation of adding control 41 to the device, the vehicle device C also displays a pop-up window 42, which includes a mobile phone interconnection connection code, such as 43662. The mobile phone interconnection connection code is a personal identification number (PIN). In addition, the pop-up window 42 may also include prompts to guide the user on how to proceed, such as "Turn on Bluetooth on your phone > Bring it close to the vehicle's PAD > Enter the above connection code on your phone".

[0058] On phone A, the user can turn on Bluetooth on phone A, causing phone A to begin scanning for device discovery messages. As phone A approaches the vehicle's infotainment system C, see [link to relevant documentation]. Figure 5 In Figure (a), when mobile phone A discovers vehicle-mounted device C through a scanning device notification, mobile phone A displays pop-up window 51. Pop-up window 51 includes relevant information about the discovered vehicle-mounted device C, such as "xx car". Pop-up window 51 also includes a prompt message to encourage the user to bind mobile phone A to vehicle-mounted device C, such as "Bind with vehicle through local smart connectivity service". Additionally, pop-up window 51 includes a "Bind" control 52. If the user confirms that they want to bind mobile phone A to vehicle-mounted device C, they can click the "Bind" control 52. See also... Figure 5 In Figure (b), in response to the user's click on the "Bind" control 52, mobile phone A displays a connection code input box 53. The user can then input the mobile phone interconnection connection code displayed in the pop-up window 42 of the vehicle device C, i.e., input 43662. Afterwards, the user can click the "OK" control provided in the connection code input box 53. (See also...) Figure 5 In Figure (c), in response to the user's triggering of the "Confirm" control in the connection code input box 53, mobile phone A is bound to vehicle device C, and a "Binding" message is displayed. See also [example example]. Figure 5 In Figure (d), after successful binding, mobile phone A displays a binding success message on the smart connectivity interface, such as "Binding successful, xx car has joined the smart connectivity." Additionally, as an example and not a limitation, the vehicle's infotainment device C can also display a binding success message after successful binding, as shown in [see...]. Figure 4 In Figure (c), the vehicle-mounted device C displays a prompt window 43, which shows information about the bound mobile phone A, such as "Honor 5.0 is connected".

[0059] It should be noted that the above explanation uses the example of a user binding mobile phone A to vehicle-mounted device C via a PIN code to establish a trusted relationship between the two. In another example, the user can also bind mobile phone A to vehicle-mounted device C in other ways, such as through NFC proximity discovery or user authorization. This application embodiment does not limit this method.

[0060] As an example of this application, see Figure 6 After being bound to the vehicle-mounted device C, mobile phone A can obtain the authentication information (including public key or certificate) required for trusted authentication from the vehicle-mounted device C through the established communication connection. In other words, mobile phone A obtains the authentication information of the vehicle-mounted device C. Afterwards, mobile phone A can register the obtained authentication information to the cloud, or it can store the obtained authentication information in a trusted storage device X. Storage device X is typically used to store trusted data of the electronic devices from the manufacturer of mobile phone A. This allows other devices with accounts to quickly perform trusted authentication with the vehicle-mounted device C based on the authentication information of the vehicle-mounted device C stored in the cloud or on storage device X when they subsequently join the network. See Scenario 2 for a detailed implementation example.

[0061] Scenario 2: After a device without an account joins the network, other devices with accounts join the network.

[0062] Building upon Scenario 1, another device with an account (such as phone B) joins the network. That is, after phone A and vehicle-mounted device C form a network, a new device with an account (i.e., phone B) joins the network. See an example. Figure 7 During the process of joining the network, mobile phone B first logs into the account system, for example... Figure 7 As shown in Figure (a), the user clicks the "Log in" option in the settings interface U2 displayed on phone B. Figure 7 As shown in Figure (b), in response to the user's click on the "Login Account" option, mobile phone B displays a quick login interface U3. Quick login interface U3 includes a "One-Click Login / Register" control, which the user can click. See also... Figure 7 In diagram (c), in response to the user's triggering of the "One-Click Login / Register" control, mobile phone B displays the login interface U4. The login interface U4 provides an account input box, a password input box, and a login control. The user can then log in to their device account in the account input box and enter their password in the password input box, after which they can click the login control. In response to the user's triggering of the login control, mobile phone B logs into the account system. When mobile phone B logs into the account system, it actively registers with the cloud (or storage device X), allowing the cloud to recognize mobile phone B. In one possible implementation, such as... Figure 6As shown, the cloud (or storage device X) proactively pushes the authentication information of the vehicle's infotainment device C to mobile phone B. Thus, when mobile phone B approaches vehicle device C, it performs trusted authentication with C based on this authentication information. If authentication is successful, mobile phone B establishes a communication connection with vehicle device C, thereby enabling trusted network communication between them. Since trusted authentication between mobile phone B and vehicle device C can be performed seamlessly without the user needing to manually bind their phone, establishing a trusted network, and eliminating the need for manual user intervention, the efficiency of network setup is improved.

[0063] Of course, during the networking process, since both mobile phone B and mobile phone A can log in to the account system, mobile phone B and mobile phone A can perform trusted authentication based on the device account to establish a trusted network. This application embodiment will not go into too much detail about this.

[0064] It should be noted that the embodiments in this application are illustrated using the example of mobile phone B logging into the account system only when joining the network. In another example, if mobile phone B has already logged into the account system beforehand, that is, before joining the network, in one possible implementation, if mobile phone B disconnects from the network and then reconnects, mobile phone B can actively retrieve the authentication information of the vehicle device C from the cloud (or storage device X), so that when mobile phone B is near the vehicle device C, it can automatically perform trusted authentication without the user's awareness based on the retrieved authentication information.

[0065] See Figure 8 After mobile phone A, mobile phone B, and vehicle-mounted device C form a network, if a new account-enabled device N joins the network, device N can also obtain the authentication information of vehicle-mounted device C from the cloud (or storage device X). Then, when device N and vehicle-mounted device C are close together, device N can perform seamless and trusted authentication based on vehicle-mounted device C's authentication information, establishing an equal and trusted relationship with vehicle-mounted device C. Therefore, for users with multiple account-enabled devices, when networking with unaccounted devices, at most one account-enabled device requires user participation for binding, while the user's other account-enabled devices can establish seamless and trusted authentication with unaccounted devices, greatly improving the user experience.

[0066] It should be noted that the above explanation uses an electronic device that cannot log in to the account system as an example. In another example, if an electronic device that can log in to the account system is not logged in, it is also considered an unaccounted device. That is to say, for an electronic device that can log in to the account system, it is considered an accounted device if it is logged in, and an unaccounted device if it is not logged in. For example, if mobile phone A is not logged in to the account system, it is considered an unaccounted device. This embodiment of the application uses mobile phone A that has logged in to the account system as an example for explanation.

[0067] As an example of this application, the software systems of the electronic devices involved in the above embodiments can all have a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses the layered architecture Android system as an example to exemplify the software system of the electronic device.

[0068] Figure 9 This is a block diagram of a software system for an electronic device provided in an embodiment of this application. See also... Figure 9 A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime, the system layer, and the kernel layer.

[0069] The application layer can include a series of application packages. For example... Figure 9 As shown, the application package can include system applications, camera, gallery, call, map, navigation, WLAN, Bluetooth, music, video, SMS, and other applications. System applications can be settings apps, smart mobility apps, or smartphone connectivity apps, and there can be one or more system applications. For example, if the electronic device is a mobile phone, the system applications can include settings apps and smart mobility apps; if the electronic device is an in-vehicle infotainment system, the system applications can be smartphone connectivity apps.

[0070] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions. As an example in this application, such as... Figure 9As shown, the application framework layer may include, but is not limited to, a proximity discovery module, a device management module, a device trust registration module, a device binding authentication module, a device networking module, and an authentication service module. The proximity discovery module, when triggered, is used by electronic devices to discover other electronic devices, or by other electronic devices discovering an electronic device. The device management module manages the device information, online / offline status, etc., of electronic devices. The device trust registration module registers electronic devices with the cloud (or storage device X) and sends the information required for registration to the cloud (or storage device X); that is, the device trust registration module is mainly used for interaction with the cloud (or storage device X). The device binding authentication module securely binds electronic devices with other electronic devices. The device networking module can be used to control device online status. In one example, during the operation of an electronic device, the device networking module can periodically broadcast device discovery messages to enable other electronic devices to discover this electronic device, and periodically scan nearby device discovery messages to discover other electronic devices, where the scanning period and broadcast period can be different. The authentication service module performs trusted authentication between devices.

[0071] It should be noted that the embodiments in this application are illustrated using the example of the aforementioned modules residing in the application framework layer. In one example, one of the aforementioned modules may also exist within an Android package (APK), in which case the module resides in the application layer. That is, one or more modules within each application may have multiple forms of existence, and this embodiment does not limit this.

[0072] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0073] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, and audio driver.

[0074] exist Figure 9 Based on the embodiments shown, the following embodiments will be used to describe the method for establishing communication.

[0075] Please see Figure 10 , Figure 10 This is a schematic diagram illustrating a method for establishing communication according to an exemplary embodiment. This method is applied to scenario 1 described above, i.e., it is implemented through interaction between mobile phone A, vehicle-mounted device C, and the cloud. As an example and not a limitation, mobile phone A has… Figure 9 The software system shown, as well as the vehicle-mounted device C, also have Figure 9 The software system shown. This method may include some or all of the following:

[0076] S1001: Mobile phone A's Bluetooth receives and starts after Bluetooth is enabled.

[0077] As an example, when a user needs to establish communication between mobile phone A and vehicle device C, they can turn on Bluetooth on mobile phone A. After detecting the user's Bluetooth activation, Bluetooth on mobile phone A will start.

[0078] S1002: Bluetooth of mobile phone A triggers the proximity discovery module of mobile phone A to start.

[0079] The proximity discovery module in mobile phone A provides a proximity discovery function. As an example, when Bluetooth is enabled, mobile phone A activates the proximity discovery function to scan for nearby device discovery messages, thereby making it easier to discover other nearby electronic devices.

[0080] S1003: The proximity detection module of mobile phone A performs a message scan.

[0081] In one example, the proximity discovery module begins packet scanning upon startup to detect the presence of discoverable electronic devices nearby. For instance, the proximity discovery module may perform packet scanning periodically.

[0082] Additionally, it should be noted that, see Figure 10 When mobile phone A logs into the account system, the device management module of mobile phone A sends the device account used by mobile phone A to the device trust registration module, and calls the device trust registration module to request that mobile phone A be registered to the cloud. Accordingly, the device trust registration module registers the device account of mobile phone A to the cloud, and furthermore, the device ID of mobile phone A can also be registered to the cloud. The cloud can store the device account and device ID of device A.

[0083] S1004: The vehicle's infotainment device C receives Bluetooth signals and starts up after Bluetooth is enabled.

[0084] When a user needs to establish secure communication between mobile phone A and vehicle infotainment device C, not only does mobile phone A need to have its Bluetooth turned on, but also vehicle infotainment device C's Bluetooth needs to be turned on, so that mobile phone A and vehicle infotainment device C can be near-field bound via Bluetooth.

[0085] It should be noted that the embodiments in this application only illustrate near-field binding via Bluetooth. In another example, mobile phone A and vehicle device C can also be bound through other communication methods. For example, they can also be bound through wireless fidelity (WiFi) networks or far-field communication, etc., and the embodiments in this application do not limit this.

[0086] It should be noted that there is no strict order of execution between S1001 to S1003 and S1004.

[0087] S1005: Application 2 of vehicle infotainment device C receives device addition operation.

[0088] Application 2 can be a system application of the vehicle's infotainment device C, such as mobile phone connectivity.

[0089] Since the vehicle-mounted device C is an unregistered device, when it first connects to a mobile phone A that has an account, user intervention is usually required; that is, the user needs to manually bind the device. See one example. Figure 4 The vehicle infotainment device C can be bound to mobile phone A based on a PIN code. To do this, the user can open the device interconnection interface U1 on the vehicle infotainment device C and then trigger the device add control 41 in the device interconnection interface U1 to trigger the device add operation. Accordingly, the vehicle infotainment device C detects the device add operation triggered by the user.

[0090] S1006: Application 2 triggers the proximity detection module of vehicle device C to start.

[0091] As an example, for vehicle device C, the proximity discovery module of vehicle device C can be activated without triggering Bluetooth after it is started. Instead, it can be activated only when needed, so as to avoid vehicle device C frequently broadcasting device discovery messages.

[0092] For example, when application 2 receives a device add operation, it indicates that the proximity discovery function needs to be used to broadcast a device discovery message so that the vehicle device C can be discovered. Therefore, in response to the device add operation, vehicle device C starts the proximity discovery module to provide proximity discovery function.

[0093] S1007: The proximity detection module of the vehicle-mounted device C broadcasts a message.

[0094] That is, after the proximity detection module of the vehicle-mounted device C is activated, it begins to broadcast device detection messages.

[0095] As an example, after application 2 starts the proximity discovery module of vehicle device C, the proximity discovery module of vehicle device C can send a call result back to application 2 to indicate that the start was successful, such as sending an OK call result to application 2.

[0096] S1008: Application 2 generates PIN0.

[0097] As an example of this application, application 2 randomly generates a PIN code, denoted as PIN0.

[0098] Optionally, application 2 can also set a binding timeout period. The binding timeout period is used to limit the maximum duration of binding between the vehicle device C and the mobile phone A. That is, if the binding is completed within this binding timeout period, the binding is successful; if the binding is not completed within this binding timeout period, the binding fails.

[0099] S1009: Application 2 sends PIN0 to the device binding authentication module of vehicle device C.

[0100] That is, after application 2 generates PIN0, it sends PIN0 to the device binding authentication module so that the device binding authentication module can know what PIN code the vehicle device C will use in the subsequent authentication process.

[0101] Optionally, if the application 2 also sets a binding timeout, the application 2 will also send the binding timeout to the device binding authentication module so that the device binding authentication module can monitor whether the binding is completed within the specified time based on the binding timeout.

[0102] S1010: Application 2 sends a callback to the device binding authentication module registration status to vehicle device C.

[0103] Application 2 registers a status callback with the device binding authentication module of the vehicle device C, so that the device binding authentication module can provide feedback on the binding result to Application 2 if the binding is successful or fails.

[0104] As an example, application 2 can sequentially register status callbacks with the device binding authentication module of vehicle-mounted device C through the device management module and the device trust registration module. For instance, application 2 can send a status callback registration to the device management module of vehicle-mounted device C, the device management module of vehicle-mounted device C can send a status callback registration to the device trust registration module of vehicle-mounted device C, and then the device trust registration module of vehicle-mounted device C can send a status callback registration to the device binding authentication module of vehicle-mounted device C, thereby registering the status callbacks.

[0105] It should be noted that there is no strict order of execution between S1009 and S1010.

[0106] S1011: Application 2 displays a pop-up window P1, which includes PIN0.

[0107] As an example of this application, after generating PIN0, the application 2 of the vehicle infotainment device C displays a pop-up window P1, and displays the generated PIN0 in the pop-up window P1, for example... Figure 4 As shown in Figure (c), pop-up window P1 is pop-up window 42, and the displayed PIN0 is 43662.

[0108] It should be noted that there is no strict order of execution between the operation of application 2 triggering the proximity discovery module and the operation of displaying pop-up window P1; that is, there is no strict order of execution between S1006 to S1007 and S1008 to S1011. In one example, these two operations can be executed in parallel, meaning that application 2 can display pop-up window P1 at the same time as it launches the proximity discovery module.

[0109] S1012: When mobile phone A is close to vehicle-mounted device C, the proximity detection module of mobile phone A detects vehicle-mounted device C.

[0110] Since mobile phone A's proximity discovery module starts scanning for device discovery messages after it is activated, and vehicle device C's proximity discovery function starts broadcasting device discovery messages after it is activated, mobile phone A can detect vehicle device C by scanning the device discovery messages broadcast by vehicle device C's proximity discovery module when the distance between mobile phone A and vehicle device C is close enough.

[0111] It should be noted that this application embodiment uses the example of mobile phone A discovering vehicle-mounted device C. In one possible implementation, vehicle-mounted device C can also discover mobile phone A. For example, mobile phone A can broadcast its own device discovery message, and vehicle-mounted device C can scan for the device discovery message. In this way, when mobile phone A is close to vehicle-mounted device C, vehicle-mounted device C may also discover mobile phone A. This application embodiment does not limit this.

[0112] S1013: The proximity discovery module of mobile phone A sends the device information of vehicle device C to application 1 of mobile phone A.

[0113] Application 1 can be a system application in phone A, for example, application 1 is the smart travel application in phone A.

[0114] As an example, device information may include the name and category (i.e., product category) of the in-vehicle device C. For instance, device information may include "XX car," meaning the name of in-vehicle device C is "XX" and its category is "car." Additionally, device information may also include the device ID.

[0115] In one example, the proximity discovery module of mobile phone A can obtain the device information of vehicle-mounted device C by parsing the scanned device discovery message. Furthermore, mobile phone A may also obtain the address information of vehicle-mounted device C by parsing the device discovery message.

[0116] S1014: Application 1 displays pop-up window P2, which displays the device information of vehicle infotainment device C.

[0117] After receiving the device information from vehicle-mounted device C, application 1 displays pop-up window P2, which shows the device information of vehicle-mounted device C. (See also...) Figure 5 In Figure (a), the pop-up window P2 displayed on mobile phone A is the same as pop-up window 51 in the figure, and the device information of vehicle device C is XX car. In this way, the user can know which nearby electronic device mobile phone A is currently scanning, so that the user can decide whether to bind the scanned electronic device.

[0118] S1015: Application 1 receives the binding operation triggered by the user based on the displayed device information in pop-up window P2.

[0119] In one example, see Figure 5 In Figure (a), a "binding" control 52 is provided in pop-up window P2. When the user confirms the binding, he / she can click the "binding" control 52, and accordingly, mobile phone A receives the binding operation.

[0120] S1016: In response to the binding operation, application 1 displays the connection code input box.

[0121] Upon receiving a binding request from the user, it indicates that the user has confirmed binding mobile phone A to the vehicle's infotainment device C. In response to this binding request, mobile phone A displays a connection code input box, allowing the user to enter the PIN code (PIN0) displayed on the vehicle's infotainment device C. For example, the connection code input box displayed on mobile phone A might look like this: Figure 5 As shown in Figure (b) of the document.

[0122] S1017: Application 1 sends an authentication method query command (carrying the category identifier of vehicle device C) to the device management module of mobile phone A.

[0123] The category identifier indicates the category to which the in-vehicle device C belongs. As an example, after receiving device information from the proximity discovery module, application 1 can determine the category identifier of in-vehicle device C based on the device discovery information, that is, determine which category of electronic device C belongs to. If the user confirms that mobile phone A is bound to in-vehicle device C, application 1 sends the category identifier of in-vehicle device C to the device management module of mobile phone A to query which authentication method is currently used for trusted authentication.

[0124] S1018: The device management module of mobile phone A determines the authentication type based on the category identifier.

[0125] As an example of this application, the device management module of mobile phone A stores a correspondence between category identifiers and authentication types. Thus, when the device management module of mobile phone A receives an authentication method query command sent by application 1, in response to the query command, the device management module of mobile phone A can determine the authentication type corresponding to the category identifier in the authentication method query command based on this correspondence. For example, the authentication type can be, but is not limited to, PIN code-based authentication, authentication information-based authentication, and device account-based authentication.

[0126] Among them, PIN code authentication is based on a PIN code, authentication information authentication is based on a public key or certificate, and device account authentication is the same as account authentication.

[0127] S1019: The device management module of mobile phone A sends the authentication type to application 1.

[0128] As an example of this application, the currently determined authentication type is PIN code-based authentication, that is, when mobile phone A and vehicle device C are connected to the network for the first time, authentication based on PIN code is required.

[0129] S1020: Application 1 receives the PIN code entered by the user in the connection code input box.

[0130] In one example, see Figure 5 In Figure (b), the user can enter a PIN code in the connection code input box.

[0131] It should be noted that the embodiments of this application are illustrated using a PIN code that includes 5 digits as an example. In another example, the PIN code may include more or fewer digits, such as 6 digits. The embodiments of this application do not limit this.

[0132] It should also be noted that this embodiment of the application uses the user inputting a PIN code as an example for illustration. In another example, the vehicle-mounted device C may also send PIN0 to mobile phone A. In this case, after application 1 displays the connection code input box, it can directly display PIN0 in the connection code input box, avoiding the need for the user to manually input it. This embodiment of the application does not limit this.

[0133] It should also be noted that there is no strict order of execution between S1016 to S1019 and S1020.

[0134] S1021: Application 1 sends a binding instruction to the device binding authentication module of mobile phone A (carrying the address information of vehicle device C, the PIN code entered by the user, and the authentication type).

[0135] As mentioned above, the address information of the vehicle-mounted device C can be obtained by the proximity discovery module from the scanned device discovery message and then sent to the application 1.

[0136] S1022: The device binding authentication module of mobile phone A is bound to the device binding authentication module of vehicle device C.

[0137] As an example of this application, the specific implementation of binding the device binding authentication module of mobile phone A with the device binding authentication module of vehicle device C in response to the binding command can be found in [link to application]. Figure 11 The illustrated embodiment may specifically include the following steps:

[0138] A1. In response to the binding command, the device binding authentication module of mobile phone A sends the device ID, device account, and authentication type of mobile phone A to vehicle device C based on the address information of vehicle device C.

[0139] The device ID and device account can be obtained by the device binding authentication module of phone A from the device management module of phone A. As an example and not a limitation, after phone A is powered on, the device management module sends the device ID and device account of phone A to the device binding authentication module.

[0140] Upon receiving a binding command, the device binding authentication module of mobile phone A sends its device ID, device account, and authentication type to the vehicle infotainment device C. Optionally, the device binding authentication module of mobile phone A can also send the authentication types it supports to the vehicle infotainment device C.

[0141] A2. The device binding authentication module of vehicle device C receives the device ID, device account, and authentication type from mobile phone A.

[0142] In other words, the vehicle-mounted device C receives the device ID, device account, and authentication type from mobile phone A through its own device binding and authentication module. Optionally, it also includes the authentication types that mobile phone A supports. Then, the device binding and authentication module of vehicle-mounted device C stores this information.

[0143] A3. The device binding authentication module of vehicle-mounted device C sends the device ID and authentication type of vehicle-mounted device C to mobile phone A.

[0144] Since vehicle-mounted device C is an accountless device, the device account sent by vehicle-mounted device C to mobile phone A is empty; that is, it only sends its own device ID and authentication type to mobile phone A. The authentication type of vehicle-mounted device C can be sent by its device management module to its device binding authentication module after startup. The device management module of vehicle-mounted device C starts after vehicle-mounted device C is powered on. Furthermore, the device management module of vehicle-mounted device C can also send information such as category identifiers to its device binding authentication module after startup.

[0145] Optionally, the device binding authentication module of the vehicle-mounted device C can also send the authentication types it supports to the mobile phone A.

[0146] A4. The device binding authentication module of mobile phone A receives the device ID and authentication type of vehicle device C.

[0147] In other words, the mobile phone receives the device ID and authentication type of the vehicle's infotainment device C through its own device binding and authentication module. Optionally, the received information also includes the authentication types supported by the vehicle's infotainment device C. The device binding and authentication module of mobile phone A then stores this received information.

[0148] In this way, mobile phone A and vehicle-mounted device C exchange device IDs, device accounts, and initial authentication types. Furthermore, they also exchange the authentication types they support. Exchanging initial authentication types allows mobile phone A and vehicle-mounted device C to determine which method to use for trusted authentication. The device ID can be used to identify the other end.

[0149] A5. When PIN code authentication is determined based on the authentication type, the device binding authentication module of mobile phone A sends the PIN code entered by the user, the device ID of mobile phone A, and the device ID of vehicle device C to the authentication service module of mobile phone A.

[0150] After determining that trusted authentication via PIN code is required based on the authentication type sent by vehicle device C, the device binding authentication module of mobile phone A sends the PIN code entered by the user to the authentication service module of mobile phone A, so that trusted authentication can be performed by the authentication service module of mobile phone A based on the PIN code.

[0151] A6. The authentication service module of mobile phone A sends an authentication request (carrying PAKE protocol information) to the device authentication service module of vehicle device C.

[0152] The PAKE protocol information is used to indicate that the protocol used in the authentication process is the PAKE protocol.

[0153] It should be noted that the embodiments of this application are only illustrated by taking the PAKE protocol information carried in the authentication request as an example. In practice, the authentication request may also carry other parameters that need to be used in the authentication process, which will not be described in detail in the embodiments of this application.

[0154] It should also be noted that this application embodiment uses the PAKE protocol for authentication as an example. In another example, authentication can also be performed using other protocols, and this application embodiment does not limit this.

[0155] A7. The authentication service module of vehicle-mounted device C sends a processing request to the device binding authentication module of vehicle-mounted device C.

[0156] The vehicle-mounted device C receives the authentication request sent by mobile phone A through its own authentication service module, and then sends a processing request to the device binding authentication module of the vehicle-mounted device C to request the device binding authentication module to process the authentication request.

[0157] A8. In response to the processing request, the device binding authentication module of vehicle device C sends PIN0, the device ID of mobile phone A and the device ID of vehicle device C to the authentication service module of vehicle device C.

[0158] As described above, after application 2 generates PIN0, it sends PIN0 to the device binding authentication module of vehicle device C. Therefore, when a processing request is received, the device binding authentication module of vehicle device C determines to perform trusted authentication. In this case, the PIN0 generated by application 2 is sent to the authentication service module of vehicle device C so that trusted authentication can be performed by the authentication service module of vehicle device C based on PIN0.

[0159] A9. The authentication service module of mobile phone A and the authentication service module of vehicle device C are based on PIN code and device ID, and perform trusted authentication through PAKE protocol.

[0160] In one example, the authentication service module of mobile phone A and the authentication service module of vehicle device C exchange their generated random numbers. For instance, the random number generated by the authentication service module of mobile phone A is R1, and the random number generated by the authentication service module of vehicle device C is R2. Then, the authentication service module of mobile phone A calculates a value using the PAKE protocol based on the user-input PIN code, the device ID of mobile phone A, the device ID of vehicle device C, R1, and R2. Similarly, the authentication service module of vehicle device C calculates a value using the PAKE protocol based on PIN0, the device ID of mobile phone A, the device ID of vehicle device C, R1, and R2. If the calculation results from both sides match, authentication is successful; otherwise, if the calculation results are inconsistent, authentication fails.

[0161] It should be noted that the authentication method described herein is merely exemplary. In another example, random numbers may not be used, or other authentication methods may be employed. This application embodiment does not limit this approach.

[0162] A10. After successful authentication, the authentication service module of mobile phone A sends the binding key to the device binding authentication module of mobile phone A.

[0163] The binding key can be obtained through negotiation between the authentication service modules of mobile phone A and vehicle-mounted device C after successful authentication. The binding key is used to encrypt business data during subsequent business data interactions between mobile phone A and vehicle-mounted device C.

[0164] A11. After successful authentication, the authentication service module of vehicle-mounted device C sends the binding key to the device binding authentication module of vehicle-mounted device C.

[0165] A12. The authentication service module of mobile phone A exchanges authentication credentials with the authentication service module of vehicle device C.

[0166] The authentication credential confirms that mobile phone A and vehicle infotainment device C have successfully authenticated each other using a PIN code. Therefore, if mobile phone A needs to bind with vehicle infotainment device C again using a PIN code after restarting, and if the authentication credential for vehicle infotainment device C is found locally, it does not need to perform trusted authentication again and can proceed directly to the binding operation. Similarly, if vehicle infotainment device C needs to bind with mobile phone A again using a PIN code after restarting, and if the authentication credential for mobile phone A is found locally, it does not need to authenticate with mobile phone A again and can proceed directly to the binding operation.

[0167] A13. The authentication service module of mobile phone A sends the authentication result to the device binding authentication module of mobile phone A.

[0168] The certification result is used to indicate that certification has been completed.

[0169] A14. The authentication service module of vehicle-mounted device C sends the authentication result to the device binding authentication module of vehicle-mounted device C.

[0170] It should be noted that there is no strict order of execution between A13 and A14.

[0171] A15. The device binding authentication module of vehicle-mounted device C generates a public key or certificate.

[0172] It should be noted that this embodiment of the application uses the example of the device binding authentication module of the vehicle-mounted device C generating a public key or certificate after receiving the authentication result. In an optional embodiment, the vehicle-mounted device C can query whether a public key or certificate is stored locally. If a public key or certificate exists, it can be obtained directly; if no public key or certificate is stored locally, a public key or certificate is generated.

[0173] The public key or certificate can be stored in a specified storage location on the vehicle's infotainment device C. The specified storage location can be set according to requirements.

[0174] A16. The device binding authentication module of mobile phone A exchanges and verifies the public key or certificate with the device binding authentication module of vehicle device C.

[0175] Mobile phone A's device binding authentication module sends its public key or certificate to vehicle infotainment device C, and vehicle infotainment device C receives mobile phone A's public key or certificate through its own device binding authentication module. Similarly, vehicle infotainment device C's device binding authentication module sends its public key or certificate to mobile phone A, and mobile phone A receives vehicle infotainment device C's public key or certificate through its own device binding authentication module.

[0176] After exchanging public keys or certificates, further verification can be performed to re-authenticate the device binding, thereby improving the reliability of the authentication. In one example, the device binding authentication module of mobile phone A can generate a random number, encrypt it using the public key or certificate of vehicle device C, and then send it to vehicle device C. Vehicle device C receives the encrypted random number through its own device binding authentication module and decrypts it using its own public key or certificate. If the random number can be decrypted, the verification is considered successful; otherwise, if the random number cannot be decrypted, the verification fails. Similarly, the device binding authentication module of vehicle device C can also generate a random number, encrypt it using the public key or certificate of mobile phone A, and send the encrypted random number to mobile phone A. Mobile phone A receives the encrypted random number through its own device binding authentication module and decrypts it using its own public key or certificate. If the random number can be decrypted, the verification is considered successful; otherwise, if the random number cannot be decrypted, the verification fails.

[0177] If the verification fails, the binding between mobile phone A and vehicle device C will fail. If the verification succeeds, continue with the following steps A17 and beyond.

[0178] A17. The device binding authentication module of mobile phone A exchanges information with the device binding authentication module of vehicle device C.

[0179] After successful verification, the device binding authentication module of mobile phone A and the device binding authentication module of vehicle device C exchange information, such as exchanging P2P channel information, device UDID, media access control (MAC) address and other detailed information related to electronic devices. The exchanged information can be used for the reliable transmission of business data between mobile phone A and vehicle device C in the future.

[0180] As an example of this application, during the information exchange process between the device binding authentication module of mobile phone A and the device binding authentication module of vehicle device C, public keys or certificates can be used for encryption to ensure the security of data exchange.

[0181] A18. The device binding authentication module of mobile phone A and the device binding authentication module of vehicle device C close the channel.

[0182] After exchanging information, mobile phone A and vehicle-mounted device C close their current transmission channel, indicating that they are now bound together. When business data transmission is needed later, they can re-establish the transmission channel based on the exchanged information. Thus, closing the channel after binding conserves channel resources and avoids waste.

[0183] A19. The device binding authentication module of mobile phone A stores the device account and the device ID of vehicle device C.

[0184] As mentioned earlier, since mobile phone A and vehicle-mounted device C exchange device IDs and device accounts, mobile phone A's device binding authentication module contains vehicle-mounted device C's device ID. Because the aforementioned authentication process is performed while mobile phone A is logged into this device account, this device account can be used as the device account for vehicle-mounted device C. Furthermore, vehicle-mounted device C's device binding authentication module contains mobile phone A's device account and device ID. Thus, after mobile phone A is bound to vehicle-mounted device C, mobile phone A's device binding authentication module can store the device account and device ID in a corresponding manner, so that it can subsequently verify that trusted authentication has been successfully completed with vehicle-mounted device C under this device account.

[0185] A20. The device binding authentication module of mobile phone A sends a device online notification to application 1 through the device management module of mobile phone A.

[0186] This allows application 1 to know that mobile phone A and vehicle device C are already bound together.

[0187] As an example, and not a limitation, application 1, upon receiving a device online notification, can update and display its current interface, for example, it can display something like... Figure 5 The interface shown in Figure (c) is shown in the diagram.

[0188] A21. The device binding authentication module of vehicle device C stores the device account and the device ID of mobile phone A.

[0189] Similarly, on the vehicle's infotainment device C side, events related to the binding between mobile phone A and vehicle's infotainment device C can also be stored locally.

[0190] A22. The device binding authentication module of vehicle-mounted device C sends a device online notification to application 2 through the device management module of vehicle-mounted device C.

[0191] Because application 2 registers a status callback with the device binding authentication module of vehicle device C in S1010, after mobile phone A is bound to vehicle device C, the device binding authentication module of vehicle device C performs a status callback, that is, notifies application 2 that vehicle device C has been bound to mobile phone A, so that application 2 can know that the binding has been completed.

[0192] In one example, if a binding timeout is set, and the binding operation is completed within the binding timeout period, the device binding authentication module of vehicle device C will call back the device online notification. Otherwise, if the binding operation is not completed within the binding timeout period, the device binding authentication module of vehicle device C will call back the binding timeout notification, that is, send the binding timeout notification to application 2 through the device management module.

[0193] After mobile phone A is bound to vehicle infotainment device C, mobile phone A can obtain the authentication information of vehicle infotainment device C from vehicle infotainment device C, and then register the authentication information of vehicle infotainment device C to the cloud. As an example, the specific implementation of mobile phone A registering the authentication information of vehicle infotainment device C to the cloud may include the following steps:

[0194] S1023. Application 1 sends a registration request to the device management module of mobile phone A.

[0195] The registration request is used to request the authentication information of the vehicle-mounted device C and register the authentication information of the vehicle-mounted device C to the cloud.

[0196] That is, after mobile phone A and vehicle device C are near-field bound, application 1 of mobile phone A calls the device management module of mobile phone A to request the authentication information of vehicle device C to be registered to the cloud.

[0197] S1024. The device management module of mobile phone A sends a registration request to the device trust registration module of mobile phone A.

[0198] As mentioned earlier, mobile phone A interacts with the cloud through the device trust registration module. Therefore, mobile phone A's device management module can call mobile phone A's device trust registration module to obtain the authentication information of vehicle device C and register it to the cloud.

[0199] S1025. The device trust registration module of mobile phone A sends an authentication information acquisition request to the vehicle device C.

[0200] The authentication information retrieval request is used to request the authentication information of the vehicle-mounted device C.

[0201] S1026. The device trust registration module of vehicle device C sends authentication information to the device trust registration module of mobile phone A.

[0202] Vehicle-mounted device C receives an authentication information retrieval request through its own device trust registration module. Then, it queries its own authentication information and sends it to mobile phone A. Mobile phone A receives this authentication information through its own device trust registration module.

[0203] S1027. The device trust registration module of mobile phone A registers the authentication information to the cloud.

[0204] In one example, mobile phone A can send an authentication information registration request to the cloud. This request can include the authentication information of vehicle-mounted device C, as well as information identifying device C, such as its device ID. After receiving the registration request, the cloud can associate the authentication information of device C, the device account logged in by mobile phone A, and the device ID of device C. For example, it can store these in a device list, indicating that in addition to mobile phone A, the associated vehicle-mounted device C also exists under that device account.

[0205] S1028. The device trust registration module of mobile phone A sends the registration result to application 1 through the device management module of mobile phone A.

[0206] The registration result indicates that the authentication information of the vehicle-mounted device C has been registered to the cloud, which means that the network is successfully established.

[0207] In practice, the device trust registration module of mobile phone A sends the registration result to the device management module of mobile phone A, and the device management module of mobile phone A sends the registration result to application 1 to report the successful networking to application 1.

[0208] S1029. Application 1 displays a network formation success notification.

[0209] In one example, upon receiving a registration result indicating that the authentication information has been successfully registered to the cloud, application 1 can display the binding relationship, for example, see [link to example]. Figure 5 The diagram (d) shows that the user is aware that a secure network has been established between mobile phone A and vehicle-mounted device C.

[0210] S1030. The device trust registration module of mobile phone A sends the registration result to the vehicle device C.

[0211] In other words, after the device trust registration module of mobile phone A registers the authentication information of vehicle device C to the cloud, it can send the registration result to vehicle device C to notify vehicle device C that the authentication information registration has been completed.

[0212] As an example, the registration result sent from the device trust registration module of mobile phone A to the vehicle device C can carry the device ID of vehicle device C registered in the cloud, the device ID of mobile phone A, the device account, etc.

[0213] It should be noted that there is no strict order of execution between S1028 to S1029 and S1030.

[0214] S1031. The device trust registration module of the vehicle-mounted device C sends the registration result to the application 2 through the device management module of the vehicle-mounted device C.

[0215] Vehicle-mounted device C receives the registration result sent by mobile phone A through its own device trust registration module, and then sends the registration result to the device management module of vehicle-mounted device C. The device management module of vehicle-mounted device C sends the registration result to application 2 to notify application 2 that the network has been successfully established.

[0216] S1032. Application 2 displays the binding relationship.

[0217] In other words, after receiving the registration result from the device management module of the vehicle-mounted device C, application 2 confirms that the network is successfully formed. In this case, the binding relationship can be displayed, for example, please refer to [link to relevant documentation]. Figure 4 Figure (c) shows the connected phone "Honor5.0" in window 43.

[0218] In this embodiment, when mobile phone A and vehicle-mounted device C first connect to the network, user participation in binding improves binding security. Furthermore, after binding, the authentication information of vehicle-mounted device C is registered to the cloud. This allows subsequent access by other devices with accounts to obtain this authentication information from the cloud and perform seamless, trusted authentication with vehicle-mounted device C based on this information, thereby improving networking efficiency. This avoids requiring user participation to bind each new device with an account to vehicle-mounted device C, and ensures a peer-to-peer relationship between devices with accounts, enabling newly connected devices with accounts to securely connect to vehicle-mounted device C without relying on mobile phone A.

[0219] exist Figure 10 Based on the illustrated embodiment, see also Figure 12 , Figure 12This is a schematic diagram illustrating a method flow for establishing communication according to another exemplary embodiment. This method is applied in scenario 2 above and is implemented through interaction between mobile phone B, vehicle-mounted device C, and the cloud. As an example and not a limitation, mobile phone B also has… Figure 9 The software system shown below will be described using the example of vehicle infotainment system B with Bluetooth enabled. This method may include some or all of the following:

[0220] S1201: When mobile phone B is logged into the account system, the device management module of mobile phone B obtains the device account.

[0221] As an example of this application, see Figure 7 Users can follow Figure 7 The process shown triggers mobile phone B's login account system. Accordingly, mobile phone B's device management module can obtain the device account used by mobile phone B to log in to the account system, for example, it can be sent from mobile phone B's settings application to mobile phone B's device management module.

[0222] This application example illustrates the use of the same device account for both mobile phone B and mobile phone A when logging into the account system.

[0223] S1202: The device management module of mobile phone B sends the device account to the device trust registration module of mobile phone B.

[0224] S1203: The device management module of mobile phone B sends a device registration request to the device trust registration module of mobile phone B.

[0225] S1204: In response to the device registration request, the device trust registration module of mobile phone B registers the device account of mobile phone B with the cloud.

[0226] In this way, the cloud can know that mobile phone B has logged into the account system, that is, mobile phone B has accessed the Internet.

[0227] S1205: The device trust registration module of mobile phone B sends the device registration result back to the device management module of mobile phone B.

[0228] After registration is complete, the device trust registration module of mobile phone B can send the device registration result back to the device management module of mobile phone B, so that the device management module of mobile phone B can know that mobile phone B has been registered to the cloud.

[0229] S1206: The device management module of mobile phone B sends an information retrieval command to the device trust registration module of mobile phone B.

[0230] The information retrieval command is used to instruct the device trust registration module of mobile phone B to retrieve the device list from the cloud. The device list includes the device ID associated with the device account, authentication information, etc., such as the device account, the device ID of the vehicle device C (the following explanation uses device ID1 as an example) and authentication information.

[0231] S1207: The device trust registration module of mobile phone B obtains the device list from the cloud (including the device ID1 and authentication information of vehicle device C).

[0232] As an example, the device trust registration module of mobile phone B can send an information retrieval request to the cloud. The information retrieval request can carry the device account of mobile phone B, so that if the cloud determines that it can send the device list to mobile phone B based on the device account of mobile phone B, it will feed back the device list to the device trust registration module of mobile phone B through the information retrieval response.

[0233] In one example, the device list also includes device accounts, which are stored in correspondence with the device ID1 and authentication information of the vehicle device C.

[0234] In another example, after receiving the information retrieval request, the cloud can query the information associated with the device account of mobile phone B (such as the device ID1 and authentication information of the vehicle device C), and then send the information associated with the device account of mobile phone B to the device trust registration module of mobile phone B, for example, by feeding back the device retrieval response to the device trust registration module of mobile phone B.

[0235] S1208: The device trust registration module of mobile phone B sends a device list to the device binding authentication module of mobile phone B.

[0236] S1209: The device binding authentication module of mobile phone B writes the device list into the local device knowledge base.

[0237] It's worth noting that after registering with the cloud, mobile phone B proactively retrieves a device list from the cloud to obtain the latest device list. This allows it to identify the relevant information of all electronic devices logged into the cloud, facilitating rapid network setup when connecting with these devices later. Furthermore, because the obtained authentication information is up-to-date, it enhances the effectiveness of subsequent trusted authentication.

[0238] It should be noted that this embodiment of the application illustrates the example of mobile phone B actively retrieving a device list from the cloud after logging into the account system. In another example, after mobile phone B registers with the cloud, the cloud can also push a device list to mobile phone B; this embodiment of the application does not limit this approach.

[0239] S1210: The device binding authentication module of mobile phone B marks and stores device ID1 based on the authentication information.

[0240] For a given device ID, if authentication information exists for that device ID, it indicates that the device ID is an unregistered device, such as vehicle infotainment device C. To facilitate subsequent authentication based on authentication information when mobile phone B discovers vehicle infotainment device C, mobile phone B's device binding authentication module marks device ID1, indicating that trusted authentication will be performed based on authentication information when vehicle infotainment device C, corresponding to device ID1, is networked.

[0241] S1211: When mobile phone B is close to vehicle-mounted device C, the device networking module of mobile phone B discovers vehicle-mounted device C.

[0242] As an example of this application, the device networking module of mobile phone B runs after mobile phone B is powered on. As mentioned above, after running, the device networking module can periodically scan for device discovery messages and periodically broadcast device discovery messages. Similarly, the device networking module of vehicle-mounted device C runs after vehicle-mounted device C is powered on, and periodically scans for device discovery messages and periodically broadcasts device messages. Thus, when mobile phone B is close to vehicle-mounted device C, mobile phone B's device networking module can scan for the device discovery messages broadcast by vehicle-mounted device C's device networking module, thereby discovering vehicle-mounted device C.

[0243] It should be noted that this application embodiment uses the example of mobile phone B discovering vehicle-mounted device C. In one possible implementation, vehicle-mounted device C can also discover mobile phone B. For example, the device networking module of vehicle-mounted device C scans the device discovery message broadcast by the device networking module of mobile phone B, thereby discovering mobile phone B. This application embodiment does not limit this.

[0244] S1212: The device networking module of mobile phone B sends a query request (carrying device ID1) to the device binding authentication module of mobile phone B to query whether device ID1 has been marked.

[0245] As an example, the device networking module of mobile phone B can parse the device ID of vehicle-mounted device C from the scanned device discovery message. Then, the device networking module of mobile phone B queries the device binding authentication module of mobile phone B to see if device ID1 is marked. To do so, it sends a query request to the device binding authentication module of mobile phone B to check whether the authentication information of vehicle-mounted device C exists.

[0246] S1213: The device binding authentication module of mobile phone B sends the query result back to the device networking module of mobile phone B. The query result indicates that device ID1 has been marked.

[0247] As mentioned earlier, after retrieving the device list from the cloud, the device binding and authentication module of mobile phone B locally marks the device ID1 of the vehicle-mounted device C. Therefore, upon receiving a query request, the device binding and authentication module of mobile phone B sends the query result back to the device networking module of mobile phone B to indicate that device ID1 has been marked. Afterwards, the device networking module of mobile phone B executes operation S1214.

[0248] Of course, if the device ID of the vehicle's infotainment device C is not marked, then subsequent operations need not be performed.

[0249] It should be noted that for vehicle-mounted device C, if mobile phone B is detected during the scanning process, the device networking module of vehicle-mounted device C can also query the device binding and authentication module of vehicle-mounted device C to see if the device ID of mobile phone B has been marked. Since mobile phone B has not been marked and stored, the device networking module of vehicle-mounted device C does not perform any other operations. That is, even if vehicle-mounted device C and mobile phone B are close to each other, and vehicle-mounted device C detects mobile phone B through its own device networking module, it will not trigger the authentication operation; instead, it is mobile phone B that triggers the authentication.

[0250] S1214: The device networking module of mobile phone B sends an authentication command to the device binding authentication module of mobile phone B.

[0251] Authentication instructions are used to instruct authentication to be performed based on authentication information.

[0252] S1215: The device binding authentication module of mobile phone B exchanges device ID, device account, authentication type, and authentication disk placement instruction information with the device binding authentication module of vehicle device C.

[0253] The authentication type refers to the method of trusted authentication that needs to be used. For example, for mobile phone B, since the device ID1 of the vehicle's infotainment device C has been marked locally, it is determined that authentication information is required.

[0254] The authentication disk write-in indication information is used to indicate whether the peer device has successfully authenticated locally based on the authentication information. For example, for mobile phone A, since it has already been authenticated and locally stores the mapping between the device account and the device ID1 of the vehicle device C, it is determined that the vehicle device C has been successfully authenticated locally. However, for mobile phone B, since it has not successfully authenticated with the vehicle device C based on the authentication information, that is, it does not locally store the mapping between the device account and the device ID1 of the vehicle device C, mobile phone B's authentication disk write-in indication information indicates that it has not been authenticated based on the authentication information. In this way, the exchange of authentication disk write-in indication information between mobile phone B and vehicle device C can avoid duplicate authentication.

[0255] If the authentication disk placement instruction indicates that the peer has not successfully authenticated locally based on the authentication information, execute operation S1216. Otherwise, if the authentication disk placement instruction indicates that the peer has successfully authenticated locally based on the authentication information, you can directly execute the following operations S1234 and thereafter.

[0256] Of course, exchanging authentication disk instruction information is an optional operation. In another example, it is also possible to skip the exchange and directly execute the subsequent S1216 operation.

[0257] It should be noted that, for vehicle-mounted device C, since vehicle-mounted device C does not have the device ID and device account of mobile phone B, mobile phone B and vehicle-mounted device C need to exchange device ID and device account.

[0258] S1216: After the device binding authentication module of mobile phone B determines that the authentication type is authentication based on authentication information, it generates PIN1.

[0259] Since the device binding authentication module of vehicle device C and the device binding authentication module of mobile phone B have exchanged authentication types, the device binding authentication of mobile phone B can determine which authentication method both parties use. After reaching an agreement on authentication based on the authentication information, the device binding authentication module generates PIN1, which may be randomly generated.

[0260] S1217: The device binding authentication module of mobile phone B uses the authentication information of vehicle device C to encrypt its own device ID2, authentication information and PIN1 to obtain the first identity verification information.

[0261] S1218: The device binding authentication module of mobile phone B sends the first identity verification information to the binding authentication module of vehicle device C.

[0262] S1219: The device binding authentication module of vehicle-mounted device C uses its own authentication information to decrypt the first identity verification information.

[0263] After decrypting the first authentication information, you can obtain the device ID2, authentication information and PIN1 of mobile phone B.

[0264] S1220: The device binding authentication module of vehicle-mounted device C generates PIN2.

[0265] S1221: The device binding authentication module of the vehicle device C uses the authentication information of mobile phone B to encrypt its own device ID1 and PIN2 to obtain the second authentication information.

[0266] Optionally, the device binding authentication module of the vehicle device C can also add its own authentication information to the second authentication information to prevent the authentication information of the vehicle device C from being updated.

[0267] S1222: The device binding authentication module of vehicle device C sends the second identity verification information to the device binding authentication module of mobile phone B.

[0268] S1223: The device binding authentication module of mobile phone B uses its own authentication information to decrypt the second authentication information.

[0269] After decrypting the second authentication information, the device ID1 and PIN2 of the vehicle device C can be obtained.

[0270] S1224: The device binding authentication module of mobile phone B sends PIN1, PIN2, device ID1 and device ID2 to the authentication service module of mobile phone B.

[0271] S1225: The authentication service module of mobile phone B sends an authentication request (carrying PAKE protocol information) to the authentication service module of vehicle device C.

[0272] S1226: The authentication service module of vehicle-mounted device C sends a processing request to the device binding authentication module of vehicle-mounted device C.

[0273] S1227: The device binding authentication module of vehicle device C sends PIN1, PIN2, device ID1, and device ID2 to the authentication service module of vehicle device C.

[0274] S1228: The authentication service module of mobile phone B and the authentication service module of vehicle device C perform trusted authentication based on PIN1, PIN2 and device ID through the PAKE protocol.

[0275] For its specific implementation, please refer to Figure 11 A9 in the illustrated embodiment.

[0276] S1229: After successful authentication, the authentication service module of mobile phone B sends the binding key to the device binding authentication module of mobile phone B.

[0277] S1230: After successful authentication, the authentication service module of vehicle-mounted device C sends the binding key to the device binding authentication module of vehicle-mounted device C.

[0278] S1231: The authentication service module of mobile phone B exchanges authentication credentials with the authentication service module of vehicle device C.

[0279] S1232: The authentication service module of mobile phone B sends the authentication result to the device binding authentication module of mobile phone B.

[0280] S1233: The authentication service module of vehicle-mounted device C sends the authentication result to the device binding authentication module of vehicle-mounted device C.

[0281] S1234: The device binding authentication module of mobile phone B exchanges information with the device binding authentication module of vehicle device C.

[0282] S1235: The device binding authentication module of mobile phone B and the device binding authentication module of vehicle device C close the channel.

[0283] S1236: The device binding authentication module of mobile phone B stores the device account and device ID1.

[0284] S1237: The device binding authentication module of mobile phone B sends a device online notification to application 3 of mobile phone B through the device management module of mobile phone B.

[0285] Upon receiving a notification that the device has come online, application 3 determines that the network has been successfully established. In one example, application 3 can display a notification related to the successful network establishment with vehicle-mounted device C.

[0286] S1238: The device binding authentication module of vehicle-mounted device C stores the device account and device ID1.

[0287] S1239: The device binding authentication module of vehicle-mounted device C sends a device online notification to application 2 of vehicle-mounted device C through the device management module of vehicle-mounted device C.

[0288] Upon receiving a notification that the device has come online, application 2 confirms that the network has been successfully established. Similarly, application 2 can display relevant notifications regarding the successful network establishment with mobile phone B.

[0289] In this embodiment of the application, when mobile phone B is logged into the account system, it obtains the authentication information of vehicle device C from the cloud. Thus, when mobile phone B is close to vehicle device C, mobile phone B can perform trusted authentication with vehicle device C without the user's notice based on the authentication information. That is, secure networking can be achieved without user intervention, thereby improving networking efficiency.

[0290] It should be noted that the above explanation only assumes a single device without an account within the network. In another scenario, multiple devices without accounts may exist within the network. In this case, the cloud (or storage device X) stores the authentication information of each of these devices. This authentication information can be registered by an account-enabled device (e.g., phone A) after successful binding. After phone B logs into the account system, the cloud (or storage device X) can push the authentication information of all devices without accounts to phone B, or phone B can actively retrieve this information from the cloud (or storage device X). Subsequently, when phone B approaches any of these devices without accounts, it can perform trusted authentication based on the authentication information of that single device to establish a trusted network with that device.

[0291] To make it easier to understand, the following will be explained... Figure 13 The illustrated embodiments describe the networking process for scenarios 1 and 2 above.

[0292] S1301. In response to the user-triggered Bluetooth activation, mobile phone A turns on Bluetooth and activates the proximity discovery function.

[0293] S1302. In response to a user-triggered Bluetooth activation operation, the vehicle infotainment device C activates Bluetooth.

[0294] S1303. In response to a user-triggered device addition operation, the vehicle device C activates the proximity discovery function.

[0295] S1304. The vehicle infotainment system C displays a pop-up window P1, which includes PIN0.

[0296] The vehicle's infotainment system C generates PIN0, then displays a pop-up window P1, which shows PIN0.

[0297] There is no strict execution order between S1304 and S1303. In one example, the two operations are executed in parallel.

[0298] S1305. When mobile phone A is close to vehicle-mounted device C, mobile phone A detects vehicle-mounted device C.

[0299] S1306. Mobile phone A displays a pop-up window P2, which shows the device information of vehicle-mounted device C.

[0300] S1307. In response to the binding operation received in pop-up window P2, mobile phone A displays a connection code input box.

[0301] S1308. Mobile phone A receives the PIN code entered by the user in the connection code input box based on PIN0.

[0302] S1309. Mobile phone A binds to vehicle-mounted device C based on the PIN code entered by the user.

[0303] For details on how mobile phone A binds to the vehicle's infotainment system C based on a user-input PIN code, please refer to [link / reference]. Figure 11 The illustrated embodiment.

[0304] S1310. Mobile phone A obtains the authentication information of vehicle infotainment device C from vehicle infotainment device C.

[0305] Authentication information may include a public key, or it may include a certificate, or it may include both a public key and a certificate.

[0306] S1311. Mobile phone A sends an authentication information registration request to the cloud, and the authentication information registration request carries the authentication information of vehicle device C.

[0307] In one example, mobile phone A can also include information such as the device ID of vehicle-mounted device C in the authentication information registration request.

[0308] Of course, mobile phone A can also send the device ID of vehicle device C to the cloud separately, but this application embodiment does not limit this.

[0309] S1312. Cloud storage of vehicle infotainment device C's certification information.

[0310] As an example of this application, the cloud associates the authentication information and device ID of the vehicle-mounted device C with the device account of mobile phone A, indicating that there is also a vehicle-mounted device C under the device account that has passed security authentication.

[0311] S1313. The cloud returns the registration result to mobile phone A.

[0312] The registration result is used to notify mobile phone A whether the authentication information of vehicle device C has been successfully stored.

[0313] As an example of this application, for mobile phone A, after receiving the registration result and the registration result indicating that the authentication information of vehicle device C has been successfully stored, mobile phone A internally reports that it has successfully formed a network with vehicle device C.

[0314] S1314. Log in to the system account on mobile phone B and register to the cloud.

[0315] S1315. The cloud pushes the authentication information of the vehicle device C to mobile phone B.

[0316] Alternatively, mobile phone B can proactively retrieve the authentication information of vehicle-mounted device C from the cloud. Then, the authentication information of vehicle-mounted device C is stored, and its device ID is marked.

[0317] S1316. When mobile phone B is near vehicle-mounted device C, it detects vehicle-mounted device C.

[0318] S1317. Mobile phone B performs trusted authentication with vehicle-mounted device C based on authentication information.

[0319] For a detailed implementation, please refer to [link / reference]. Figure 12 The example shown.

[0320] S1318. If authentication is successful, mobile phone B reports to the internal system that it has successfully formed a network with vehicle-mounted device C.

[0321] S1319. If authentication is successful, the vehicle-mounted device C reports to the internal system that it has successfully formed a network with mobile phone B.

[0322] In this embodiment of the application, when mobile phone B is logged into the account system, it obtains the authentication information of vehicle device C from the cloud. Thus, when mobile phone B is close to vehicle device C, mobile phone B can perform trusted authentication with vehicle device C without the user's notice based on the authentication information. That is, secure networking can be achieved without user intervention, thereby improving networking efficiency.

[0323] It should be noted that the above embodiment illustrates the example of mobile phone A registering the authentication information of vehicle device C with the cloud after mobile phone A is bound to vehicle device C. In another example, after mobile phone A is bound to vehicle device C, vehicle device C can also register its authentication information with the cloud. For example, in one possible scenario, vehicle device C has cloud interaction capabilities, such as permission to interact with the cloud and the ability to perform remote communication. In this case, after mobile phone A is bound to vehicle device C, mobile phone A can instruct vehicle device C to store its own authentication information in the cloud. For example, vehicle device C can register its authentication information with the cloud through its own device trust registration module. In yet another example, after mobile phone A is bound to vehicle device C, mobile phone A can also assist vehicle device C in registering its authentication information with the cloud. For example, in implementation, after binding with vehicle device C, mobile phone A can apply for registration information from the cloud, and then mobile phone A sends the registration information to vehicle device C. In this way, the vehicle-mounted device C can negotiate registration with the cloud based on the registration information. If the negotiation is successful, the vehicle-mounted device C will register its own authentication information to the cloud.

[0324] It should also be noted that the above embodiments are illustrated using the example of mobile phone B and mobile phone A being devices with the same account. In another example, where mobile phone B and mobile phone A are devices with different accounts, the method provided in this application embodiment can also be applied based on certain security management measures such as authorization protection. In one example, a method for implementing different accounts is as follows: Figure 14As shown, assume that device account 1 is logged into on mobile phone A, and device account 2 is logged into on mobile phone B. After mobile phone A is bound to vehicle-mounted device C, it can upload account 2 to the cloud along with the authentication information of vehicle-mounted device C. Account 2 can be obtained by mobile phone A through information exchange during the connection establishment process with mobile phone B. In this way, the cloud can know that vehicle-mounted device C allows electronic devices logged into account 2 to use its services. For example, if mobile phone B logs into account 2, when mobile phone B registers with the cloud, the cloud can push the authentication information of vehicle-mounted device C to mobile phone B, so that when mobile phone B is near vehicle-mounted device C, it can perform a seamless and reliable authentication based on this authentication information. This improves the applicability of the method.

[0325] It should be noted that whether it is far-field communication, near-field communication, or other communication methods, they are all differences in the means or implementation methods of data interaction between devices. The communication method between any devices should not be affected by the communication methods provided in the above embodiments. For example, the communication between mobile phone A and vehicle device C can be near-field communication or far-field communication.

[0326] It should also be noted that the embodiments of this application can be used for access scenarios between different accounts or devices from different manufacturers. Furthermore, the methods provided in the embodiments of this application can also be applied to software engineering projects that require modular adaptive loading.

[0327] Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. See also... Figure 15 The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0328] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0329] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0330] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0331] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from this memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0332] In some embodiments, the processor 110 may include one or more interfaces, such as an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0333] The charging management module 140 receives charging input from the charger. The power management module 141 connects to the battery 142, and the charging management module 140 connects to the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0334] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0335] Mobile communication module 150 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, for use on electronic device 100. Wireless communication module 160 can provide wireless communication solutions, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies, for use on electronic device 100.

[0336] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with networks and other devices through wireless communication technology.

[0337] Electronic device 100 implements display functions through GPU, display screen 194, and application processor.

[0338] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0339] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions, such as saving music, video, and other files on the external memory card.

[0340] Internal memory 121 can be used to store computer-executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created by electronic device 100 during use (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0341] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D and application processor.

[0342] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0343] The above-described embodiments are optional embodiments provided by this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the technical scope disclosed in this application should be included within the protection scope of this application.

Claims

1. A method for establishing communication, characterized in that, Applied to a first electronic device, the first electronic device being able to log in to an account system, the method includes: In response to the first electronic device logging into the account system, the authentication information of the second electronic device is obtained from the trusted storage device. The second electronic device is not logged into the account system, the second electronic device and the third electronic device are networked together, the third electronic device is logged into the account system, the authentication information of the second electronic device is registered on the trusted storage device after the second electronic device and the third electronic device are bound together, and the authentication information in the trusted storage device is associated with the device account used by the first electronic device to log into the account system. The first electronic device and the third electronic device can establish a peer-to-peer network communication relationship with the second electronic device. In response to the distance between the first electronic device and the second electronic device being less than a preset distance, a trusted authentication is performed on the second electronic device based on the authentication information of the second electronic device; If authentication is successful, network communication is established with the second electronic device.

2. The method as described in claim 1, characterized in that, The step of responding to the distance between the first electronic device and the second electronic device being less than a preset distance, and performing trusted authentication with the second electronic device based on the authentication information of the second electronic device, includes: In response to the fact that the distance between the first electronic device and the second electronic device is less than the preset distance, information is exchanged with the second electronic device, and the exchanged information includes at least the device identifier and authentication type; When the authentication type indicated by the second electronic device is authentication based on authentication information, a first personal identification code is generated; Based on the authentication information of the second electronic device, the first personal identification code, the first device identifier of the first electronic device, and the authentication information are encrypted to obtain the first identity verification information; Send the first authentication information to the second electronic device, so that the second electronic device can obtain the first personal identification code, the first device identifier and the authentication information of the first electronic device from the first authentication information based on the authentication information of the second electronic device; The second electronic device receives second authentication information, which is obtained by encrypting the second device identifier and the second personal identification code of the second electronic device based on the authentication information of the first electronic device. The second personal identification code is generated by the second electronic device. When the second personal identification code and the second device identifier are obtained from the second identity verification information based on the authentication information of the first electronic device, trusted authentication is performed based on the first personal identification code and the second personal identification code.

3. The method as described in claim 2, characterized in that, In the case where the second personal identification code and the second device identifier are obtained from the second identity verification information based on the authentication information of the first electronic device, trusted authentication is performed based on the first personal identification code and the second personal identification code; When the second personal identification code and the second device identifier are obtained from the second identity verification information based on the authentication information of the first electronic device, an authentication request is sent to the second electronic device. The authentication request includes information about the PAKE protocol and is used to instruct the second electronic device to perform trusted authentication through the PAKE protocol. Based on the first personal identification code, the second personal identification code, the first device identifier, and the second device identifier, trusted authentication is performed with the second electronic device through the PAKE protocol.

4. The method according to any one of claims 1-3, characterized in that, The step of retrieving authentication information of the second electronic device from a trusted storage device in response to the first electronic device logging into the account system includes: In response to the first electronic device logging into the account system, an information retrieval request is sent to the trusted storage device; The trusted storage device receives an information retrieval response sent in response to the information retrieval request, the information retrieval response carrying the authentication information of the second electronic device.

5. The method according to any one of claims 1-3, characterized in that, The step of retrieving authentication information of the second electronic device from a trusted storage device in response to the first electronic device logging into the account system includes: In response to the first electronic device logging into the account system, the system listens for the authentication information of the second electronic device sent by the trusted storage device.

6. A method for establishing communication, characterized in that, The method is applied to a second electronic device that is not logged into an account system, and includes: In response to the distance between the second electronic device and the first electronic device being less than a preset distance, the first electronic device performs trusted authentication based on the authentication information of the second electronic device. The trusted authentication is triggered by the first electronic device. The first electronic device obtains the authentication information of the second electronic device from the trusted storage device when it is logged into the account system. The authentication information of the second electronic device is registered on the trusted storage device after the second electronic device is bound to the third electronic device. The third electronic device has logged into the account system, and the authentication information in the trusted storage device is associated with the device account used by the first electronic device to log into the account system. The first electronic device and the third electronic device can establish a peer-to-peer network communication relationship with the second electronic device. If authentication is successful, network communication is established with the first electronic device.

7. The method as described in claim 6, characterized in that, Before the first electronic device performs trusted authentication based on the authentication information of the second electronic device in response to the distance between the second electronic device and the first electronic device being less than a preset distance, the method further includes: In response to a first user operation, a first interface is displayed, which includes a third person identification code; If the distance between the second electronic device and the third electronic device is less than the preset distance, in response to the authentication request sent by the third electronic device, the third electronic device is bound to the third electronic device based on the third personal identification code. The authentication request is triggered by the third electronic device after receiving the user's personal identification code input based on the third personal identification code.

8. The method as described in claim 7, characterized in that, When the distance between the second electronic device and the third electronic device is less than the preset distance, after binding the third person identification code to the third electronic device, the method further includes: If the binding is successful, receive the authentication information acquisition request sent by the third electronic device; In response to the authentication information acquisition request, the authentication information of the second electronic device is sent to the third electronic device so as to register the authentication information of the second electronic device to the trusted storage device through the third electronic device.

9. The method as described in claim 7, characterized in that, When the distance between the second electronic device and the third electronic device is less than the preset distance, after binding the third person identification code to the third electronic device, the method further includes: If the binding is successful, the system receives registration information sent by the third electronic device, which is obtained by the third electronic device from the trusted storage device after binding with the second electronic device. Based on the registration information, a registration negotiation is conducted with the trusted storage device; If the registration negotiation is successful, the authentication information of the second electronic device will be registered to the trusted storage device.

10. The method as described in claim 9, characterized in that, The second electronic device is equipped to communicate with the trusted storage device; When the distance between the second electronic device and the third electronic device is less than the preset distance, after binding the third person identification code to the third electronic device, the method further includes: Receive authentication information upload instruction, which is sent by the third electronic device after it is bound to the second electronic device; In response to the authentication information upload instruction, the authentication information of the second electronic device is registered to the trusted storage device.

11. A system for establishing communication, characterized in that, The system includes a first electronic device, a second electronic device, a third electronic device, and a trusted storage device, including: The first electronic device is configured to, in response to the login account system, obtain the authentication information of the second electronic device from the trusted storage device. The second electronic device is not logged into the account system. The authentication information of the second electronic device is registered on the trusted storage device after the second electronic device is bound to the third electronic device. The second electronic device and the third electronic device are networked together. The third electronic device is logged into the account system. The authentication information in the trusted storage device is associated with the device account used by the first electronic device to log into the account system. The first electronic device and the third electronic device are able to establish a peer-to-peer network communication relationship with the second electronic device. The first electronic device is configured to perform trusted authentication with the second electronic device based on the authentication information of the second electronic device in response to the distance between the first electronic device and the second electronic device being less than a preset distance; The second electronic device is used to perform trusted authentication with the first electronic device based on the authentication information of the second electronic device; The first electronic device is used to establish network communication with the second electronic device when authentication is successful.

12. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any one of claims 1-5, or to implement the method as described in any one of claims 6-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-5, or to implement the method as described in any one of claims 6-10.

Images