Equipment searching system and method and electronic equipment

Abstract

The invention provides a device searching system and method and an electronic device, relates to the field of electronic devices, and is used for reporting the position of a lost device to a server in a non-networking state. The device searching system comprises a first electronic device, a second electronic device and a first server. A master key of the first electronic device is stored in the first electronic device. The first electronic equipment is used for responding to the condition meeting the offline search function, generating at least two derived key pairs based on the master key of the first electronic equipment, and sending the Bluetooth broadcast. The Bluetooth broadcast carries a first derived public key, and the first derived public key is one derived public key in at least two derived key pairs. The second electronic device is used for responding to the received Bluetooth broadcast of the first electronic device and sending the first position where the second electronic device is located and the first derived public key to the first server. The first server is configured to associatively store a first location and a first derived public key.

Description

A device location system, method and electronic device Technical Field

[0001] This application relates to the field of electronic devices, and more particularly to a device discovery system, method, and electronic device. Background Technology

[0002] Find an application (APP) can be used to help users locate lost devices.

[0003] Typically, once a device has its location app's find function enabled, it can communicate with the server and report its location as long as it's connected to the internet, provided it's lost. Users can then use other devices to download the lost device's location from the server, thus helping them locate their lost device.

[0004] However, the lost device may be offline, in which case it cannot report its location to the server. Summary of the Invention

[0005] This application provides a device locator system, method, and electronic device for reporting the location of a lost device to a server when it is offline.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, a device discovery system is provided, comprising: a first electronic device, a second electronic device, and a first server; the first electronic device stores a master key of the first electronic device. Wherein:

[0008] The first electronic device, in response to conditions meeting the offline search function, generates at least two derived key pairs based on its master key and sends a Bluetooth broadcast. The Bluetooth broadcast carries a first derived public key, which is one of the at least two derived key pairs. The second electronic device, in response to receiving the Bluetooth broadcast from the first electronic device, sends its first location and the first derived public key to a first server. The first server associates and stores the first location and the first derived public key.

[0009] In the above scheme, when the offline search function is met, the first electronic device sends a Bluetooth broadcast carrying a derived public key to trigger a nearby second electronic device to upload its location to the first server. Thus, even if the first electronic device is offline, it can still report its location to the search server with the help of nearby devices, thereby helping the user locate the lost first electronic device. Furthermore, when the offline search function is met, the first electronic device generates multiple derived key pairs based on the master key. Then, the first electronic device can directly use the derived public key from the generated derived key pairs to send a Bluetooth broadcast. After the device is lost, its battery power may gradually decrease over time. When the device's battery is low, it will be unable to generate derived key pairs based on the master key. However, Bluetooth typically has a low-power mode, which allows it to send Bluetooth broadcasts even when the device's battery is low. Therefore, by pre-generating multiple derived key pairs in this scheme, even if the lost device is offline and has low battery, it can still send a Bluetooth broadcast based on the derived public key from the pre-generated derived key pairs, triggering a nearby second electronic device to report its location information. In this way, compared to the approach of generating a derived key pair every time a Bluetooth broadcast is sent, the lost device in this approach is likely to trigger nearby devices to report their location information over a longer period of time. The more location information reported, the better it is for locating the lost primary electronic device.

[0010] In one possible implementation of the first aspect, the device locator system further includes a third electronic device (i.e., device C mentioned above). This third electronic device, in response to a user's triggering operation, generates at least two derived key pairs based on the master key of the first electronic device and sends a second derived public key to the first server. The second derived public key is a derived public key from the at least two derived key pairs generated by the third electronic device. Specifically, the user's triggering operation is an operation to locate the device. In this scheme, the first server is also used to match the received second derived key with derived public keys stored in the first server; and if a target derived public key matching the second derived public key is found, it sends location information associated with the target derived public key to the third electronic device. It is understood that the matched target derived public key includes the first derived public key, i.e., the first derived public key of the first electronic device uploaded by the second electronic device. The location information includes the first location uploaded by the second server, i.e., the location uploaded by the second electronic device. In this above scheme, the user can download the location information representing the first electronic device from the first server through the third electronic device. This enables the determination of the location of the first electronic device in an offline state, thus helping to retrieve the first electronic device.

[0011] In one possible implementation of the first aspect, the third electronic device is a trusted device of the first electronic device, such as when the first and third electronic devices are logged into the same user account. The third electronic device is also used to obtain the master key of the first electronic device. Thus, the user can download location information representing the first electronic device from the first server through the third electronic device. This enables the determination of the location of the first electronic device when it is offline, thereby helping to retrieve the first electronic device.

[0012] In one possible implementation of the first aspect, the device locator system further includes a second server. The first electronic device is also used to synchronize its master key with the second server. The second server stores the master key of the first electronic device and, when the third electronic device is connected to the network, synchronizes the master key of the first electronic device with the third electronic device. In this scheme, the master key of the first electronic device can be synchronized to a trusted device of the first electronic device, such as the third electronic device, via the second server. Thus, even if the first electronic device did not have a trusted device before it was lost, its master key can be stored in the second server. After the first electronic device is lost, a user can log in with the same user account as the first electronic device using another device and then obtain the master key of the first electronic device from the second server. This device can then use the master key of the first electronic device to obtain location information representing the location of the first electronic device, i.e., the location information uploaded by the second electronic device, from the first server.

[0013] In one possible implementation of the first aspect, the first location sent by the second electronic device to the first server is an encrypted location. In this scheme, the second electronic device is also used to generate a temporary key pair and encrypt the first location based on a first derived public key and a temporary private key in the temporary key pair. Additionally, the second electronic device is also used to send the temporary public key from the temporary key pair to the first server. In this scheme, the first server is also used to associate and store the temporary public key with the first derived public key. This protects the security of the location of the second electronic device.

[0014] In one possible implementation of the first aspect, where the device location system includes a third electronic device, the first server is further configured to send a temporary public key stored in association with the target derived public key to the third electronic device if a target derived public key matching the second derived public key is found. The third electronic device is further configured to decrypt the first location information based on the received temporary public key stored in association with the first derived public key. Thus, the third electronic device can decrypt the encrypted first location information to obtain the decrypted location information, thereby aiding in the location of the first electronic device.

[0015] In one possible implementation of the first aspect, the first electronic device is further configured to generate a master key for the first electronic device in response to the opening operation of the offline lookup function.

[0016] In one possible implementation of the first aspect, the first electronic device is further configured to generate a master key based on a first preset elliptic curve. The master key may include a master key pair (master private key and master public key) and master key parameters.

[0017] In one possible implementation of the first aspect, the first electronic device is further configured to generate derived key pairs based on the master key pair and master key parameters using a key derivation function. This allows for the generation of multiple derived key pairs, which can be used to send Bluetooth broadcasts to trigger nearby electronic devices to report their locations to the first server.

[0018] In one possible implementation of the first aspect, the first electronic device is further configured to generate at least two derived key pairs based on the master key via its security encryption module. The first electronic device is also configured to store the derived public key from the at least two derived key pairs in a Bluetooth module. The technical solution proposed in this application can generate and store multiple derived key pairs after the security encryption module is activated once. Thus, under the condition of satisfying the offline search function, it is not necessary to activate the security encryption module multiple times, which can reduce the power consumption of the electronic device. In the scenario of a lost electronic device, reducing power consumption can increase the remaining battery life of the electronic device. The longer the remaining battery life of the electronic device, the more likely it is to trigger nearby electronic devices to report more location information to the search server, which is more beneficial for the user to help find the lost electronic device.

[0019] In one possible implementation of the first aspect, the location encryption key used by the second electronic device to encrypt the first location is generated based on the ECDH algorithm using a first derived public key and a temporary private key. In this scheme, the second electronic device uploads the first derived public key and the temporary public key to the first server, and the third electronic device can obtain the first derived public key and the temporary public key from the first server. The third electronic device can generate a derived key pair based on the master key of the first electronic device, thus obtaining the first derived private key corresponding to the first derived public key. Therefore, based on the first derived private key and the temporary public key, the third electronic device can determine the location encryption key using the ECDH algorithm, and then use the location encryption key to decrypt the encrypted first location. This not only enables the third electronic device to obtain the decrypted location information but also ensures the security of the information stored on the first server.

[0020] In one possible implementation of the first aspect, the first electronic device is further configured to generate at least two derived key pairs based on the master key of the first electronic device and send a Bluetooth broadcast in response to the condition that the network is not connected and the duration of the network disconnection exceeds a time threshold.

[0021] In one possible implementation of the first aspect, the first electronic device is further configured to generate at least two derived key pairs based on the master key of the first electronic device and send a Bluetooth broadcast in response to the conditions that the device is not connected to the network, the battery level is below a power threshold, and the duration of the period of being not connected to the network and having the battery level below the power threshold exceeds a time threshold.

[0022] Secondly, this application also provides a device locator method applied to a first electronic device, which stores a master key. The method includes: generating at least two derived key pairs based on the master key of the first electronic device in response to meeting the conditions for offline locator functionality; and sending a Bluetooth broadcast. The Bluetooth broadcast carries a first derived public key, which is one of the derived public keys in the at least two derived key pairs. The Bluetooth broadcast triggers a second electronic device receiving the Bluetooth broadcast to upload its location to a first server. In this scheme, when the conditions for offline locator functionality are met, the first electronic device sends a Bluetooth broadcast carrying a derived public key to trigger nearby second electronic devices to upload their location to the first server. Thus, even if the first electronic device is offline, it can still report its location to the locator server using nearby devices, thereby helping the user locate the lost first electronic device. Furthermore, when the conditions for offline locator functionality are met, the first electronic device generates multiple derived key pairs based on the master key. Afterward, the first electronic device can directly use the derived public key from the already generated derived key pairs to send a Bluetooth broadcast. After a device is lost, its battery power may gradually decrease over time. When the device's battery power is low, it will be unable to generate derived key pairs based on the master key. Bluetooth typically has a low-power mode, allowing devices to broadcast Bluetooth messages even with low battery levels. Therefore, this solution pre-generates multiple derived key pairs. Even when the lost device is offline and has low battery, it can still send Bluetooth broadcasts based on the derived public keys in the pre-generated key pairs, triggering nearby second electronic devices to report their location information. Compared to solutions that generate derived key pairs each time a Bluetooth broadcast is sent, this solution allows the lost device to potentially trigger nearby devices to report their location information for a longer period. The more location information reported, the better it helps in recovering the lost primary electronic device.

[0023] In one possible implementation of the second aspect, the conditions for the offline search function include: not being connected to the internet and the duration of not being connected to the internet exceeds a time threshold; or, not being connected to the internet, having a battery level below a battery level threshold, and the duration of not being connected to the internet and having a battery level below a battery level threshold exceeds a time threshold.

[0024] In one possible implementation of the second aspect, the first electronic device has activated the offline search function.

[0025] Thirdly, this application also provides a device location method applied to a second electronic device, which has activated an offline location function. The method includes: in response to receiving a Bluetooth broadcast carrying a first derived public key sent by a first electronic device, obtaining the first location of the second electronic device; and uploading the first location and the first derived public key to a first server. In this scheme, after receiving the Bluetooth broadcast from the first electronic device, the second electronic device reports its location to the first server, which can help locate the position of the first electronic device in an offline state.

[0026] In one possible implementation of the third aspect, the second electronic device has activated the offline search function.

[0027] In one possible implementation of the third aspect, the method further includes: generating a temporary key pair in response to receiving a Bluetooth broadcast from the first electronic device. Before uploading the first location and the first derived public key to the first server, the method further includes: encrypting the location of the second electronic device based on the first derived public key and a temporary private key from the temporary key pair. The first location sent by the second electronic device to the first server is the encrypted location. This ensures the security of the location information reported by the second electronic device to the first server. The method further includes: uploading the temporary public key from the temporary key pair to the first server. The temporary public key uploaded by the second electronic device to the first server can be used by the third electronic device to decrypt the encrypted first location.

[0028] Fourthly, this application also provides a device discovery method applied to a third electronic device. The method includes: in response to a user's trigger operation, obtaining the master key of a first electronic device; generating at least two derived key pairs based on the master key of the first electronic device; uploading a second derived public key to a first server; the second derived public key is a derived public key from the at least two derived key pairs generated by the third electronic device; the second derived public key is used by the first server to find a matching derived public key based on the second derived public key; obtaining location information corresponding to the target derived public key matched based on the second derived public key sent by the first server; and determining the historical location of the first electronic device based on the location information.

[0029] In another possible implementation of the fourth aspect, the third electronic device is a trusted device of the first electronic device, such as the third electronic device logging into the same user account as the first electronic device.

[0030] In another possible implementation of the fourth aspect, in response to a user's trigger operation, if the third electronic device detects that it stores the master key of the first electronic device, it retrieves the master key of the first electronic device from the storage location of the master key of the first electronic device in its memory. Conversely, if the third electronic device detects that it does not store the master key of the first electronic device, it retrieves the master key of the first electronic device from the second server.

[0031] Fifthly, this application also provides an electronic device. The electronic device may include a processor and a memory. The memory stores computer-executable instructions, and when the electronic device is running, the processor executes the computer-executable instructions stored in the memory to cause the electronic device to perform the device search method as described in any one of the second, third, and fourth aspects above.

[0032] Sixthly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, enable the computer to perform the device search method of any one of the second, third, and fourth aspects described above.

[0033] In a seventh aspect, a computer program product containing instructions is provided, which, when run on an electronic device, enables the electronic device to execute any of the device search methods of the second, third, and fourth aspects described above.

[0034] Eighthly, an apparatus (e.g., a system-on-a-chip) is provided, comprising a processor for supporting an electronic device in performing the functions described in the second, third, or fourth aspects above. In one possible design, the apparatus further comprises a memory for storing program instructions and data necessary for the electronic device. When the apparatus is a system-on-a-chip, it may be composed of chips or may include chips and other discrete devices.

[0035] The technical effects of any of the design methods in aspects two through eight can be found in the technical effects of different design methods in aspect one, and will not be repeated here. Attached Figure Description

[0036] Figure 1 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0037] Figure 2 is a schematic diagram of a communication system provided in an embodiment of this application;

[0038] Figure 3 is a software architecture diagram of an electronic device provided in an embodiment of this application;

[0039] Figure 4 is a schematic diagram of the operation interface of a search APP provided in an embodiment of this application;

[0040] Figure 5 is a flowchart of a device search method provided in an embodiment of this application;

[0041] Figure 6 is a flowchart of another device search method provided in an embodiment of this application;

[0042] Figure 7 is a flowchart of another device search method provided in an embodiment of this application;

[0043] Figure 8 is a flowchart of another device search method provided in an embodiment of this application;

[0044] Figure 9 is a flowchart of another device search method provided in an embodiment of this application;

[0045] Figure 10 is a flowchart of another device search method provided in an embodiment of this application;

[0046] Figure 11 is a timing interaction diagram of a device search method provided in an embodiment of this application;

[0047] Figure 12 is a framework diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0048] Typically, a lost device may be offline, in which case it cannot report its location to the server.

[0049] Based on this, this application proposes a device locator method for obtaining the location of a lost device when it is offline.

[0050] The device search method described above can be applied to a device search system, as shown in Figure 2. The device search system may include a first electronic device, a second electronic device, and a third electronic device, as well as a search server and a data server. The first electronic device and the third electronic device are mutually trusted devices; for example, the first electronic device and the third electronic device may be logged into the same user account. The search server corresponds to the first server; the data server corresponds to the second server.

[0051] Data servers are used to store data, such as master keys. Search servers are used to implement search functions, such as offline search.

[0052] The first electronic device is a lost device. The first electronic device stores its master key. After enabling the offline search function, in response to meeting the conditions for the offline search function, the first electronic device generates at least two derived key pairs based on its master key; each derived key pair includes a derived private key and a derived public key. Then, the first electronic device periodically sends a Bluetooth broadcast carrying a first derived public key, which is one of the derived public keys in the at least two derived key pairs. This Bluetooth broadcast instructs the second electronic device receiving the broadcast to upload its current location and the first derived public key to the search server. The master key of the first electronic device, when logged into a user account, can be synchronized to a data server so that the master key can be synchronized to trusted devices of the first electronic device.

[0053] If the second electronic device is near the first electronic device, it can receive a Bluetooth broadcast sent by the first electronic device. If the second electronic device has also activated the offline search function, it will respond to the Bluetooth broadcast by uploading its current location and the first derived public key to the search server.

[0054] After receiving the location of the second electronic device and the first derived public key uploaded by the second electronic device, the lookup server can store the location of the second electronic device and the first derived public key on the lookup server.

[0055] After logging into the same user account as the first electronic device, the third electronic device can download the master key of the first electronic device from the data server. The third electronic device can then use the same key derivation method as the first electronic device to generate at least two derived key pairs based on the master key of the first electronic device. Afterwards, the third electronic device can send a second derived public key to the lookup server. The second derived public key is the derived public key from the at least two derived key pairs generated by the third electronic device.

[0056] In this system, the second electronic device is located near the first electronic device. Therefore, the location of the second electronic device when it receives a Bluetooth broadcast from the first electronic device can indicate the approximate location of the first electronic device. If the same second electronic device receives Bluetooth broadcasts from the first electronic device multiple times, it can upload its location to the lookup server multiple times. Since the location of the second electronic device may change, it can send multiple approximate locations of the first electronic device to the lookup server. When a Bluetooth broadcast from the first electronic device is received by multiple second electronic devices, each of them can upload its current location to the lookup server. Over time, multiple second electronic devices can upload their locations once or multiple times. Subsequently, the third electronic device can obtain multiple location information from the lookup server to help determine the location of the lost first electronic device.

[0057] As an example, when a second electronic device uploads its location to a lookup server, it can generate a temporary key pair. Using a first derived public key and a temporary private key from this temporary key pair, it encrypts the location before uploading the encrypted location to the lookup server. In this example, the second electronic device also needs to upload the temporary public key from the temporary key pair to the lookup server for storage, so that a third electronic device can decrypt the encrypted location.

[0058] For example, the first electronic device, the second electronic device, and the third electronic device can be the same type of electronic device or different types of electronic devices. For instance, they can be mobile phones, tablets, personal computers (PCs), smart screens, desktop computers, laptops, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, smartwatches and other wearable devices, artificial intelligence (AI) speakers, and in-vehicle devices. They can also be various teaching aids (e.g., learning machines, early education machines), smart toys, portable robots, personal digital assistants (PDAs), augmented reality (AR) / virtual reality (VR) devices, media players, etc. Furthermore, they can be devices with mobile office functions, smart home functions, audio-visual entertainment functions, or devices supporting smart travel. This application does not impose any special limitations on the specific form of the electronic device.

[0059] Figure 1 shows a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. For example, the electronic device 100 may be a first electronic device, a second electronic device, or a third electronic device.

[0060] 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, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, buttons 190, a motor 191, a camera 192, a display screen 193, and a subscriber identification module (SIM) card interface 194, etc. The sensor module 180 may include a pressure sensor 180A, a touch sensor 180B, etc.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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 the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0065] USB interface 130 is an interface that conforms to the USB standard specification, specifically it can be a Mini USB interface, Micro USB interface, USB Type C interface, etc. USB interface 130 can be used to connect a charger to charge electronic device 100, and it can also be used for data transfer between electronic device 100 and peripheral devices.

[0066] 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. For example, music, video, and other files can be saved on the external memory card.

[0067] Internal memory 121 can be used to store 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 and at least one application program required for a given function (such as sound playback, image playback, etc.).

[0068] In addition, the 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.

[0069] The charging management module 140 is used to receive charging input from the charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 can receive charging input from the wired charger via the USB interface 130.

[0070] The power management module 141 is used to connect the battery 142, the charging management module 140, and 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 193, camera 192, and wireless communication module 160, etc.

[0071] In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may also be located in the same device.

[0072] 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.

[0073] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0074] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0075] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as Wi-Fi), Bluetooth, Global Navigation Satellite System (GNSS), frequency modulation (FM), near-field communication (NFC), and infrared (IR). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0076] In embodiments of this application, the Bluetooth in the wireless communication module 160 is used to send a Bluetooth broadcast when the conditions for offline search functionality are met.

[0077] 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.

[0078] Electronic device 100 can implement audio functions through audio module 170 and application processor, such as music playback and recording.

[0079] The audio module 170 is used to convert digital audio signals into analog audio signals for output, and also to convert analog audio inputs into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0080] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A may be disposed on display screen 193. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When a force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 193, electronic device 100 detects the touch operation intensity based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A.

[0081] Touch sensor 180B, also known as a "touch panel," can be located on display screen 193. The touch sensor 180B and display screen 193 together form a touchscreen, also known as a "touch screen." Touch sensor 180B is used to detect touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 193. In other embodiments, touch sensor 180B may also be located on the surface of electronic device 100, in a different position than display screen 193.

[0082] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0083] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback.

[0084] Camera 192 is used to capture still images or videos. In some embodiments, electronic device 100 may include one or N cameras 192, where N is a positive integer greater than 1.

[0085] Electronic device 100 implements display functions through a GPU, a display screen 193, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 193 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0086] The display screen 193 is used to display images, videos, etc. In some embodiments, the electronic device 100 may include one or N display screens 193, where N is a positive integer greater than 1.

[0087] The SIM card interface 194 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 194 to achieve contact and separation with the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1.

[0088] Figure 3 shows a software architecture diagram of an electronic device 100 according to an embodiment of this application.

[0089] Layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. As shown in Figure 3, electronic device 100 may include an application layer, an application framework layer, a kernel layer, and a trusted execution environment (TEE). The TEE is a secure area built using hardware and software methods to protect the security of the code and data loaded within it. It provides an isolated execution environment, independent of untrusted operating systems, ensuring the security of private data and sensitive computations.

[0090] The application layer may include a series of application packages. The application layer may include a Find My App and a Bluetooth App. In embodiments of this application, the application used to implement the offline search function in the electronic device is referred to as the Find My App. The Find My App may be a functional module within the settings application of the electronic device, or it may be a separate application. The Bluetooth App may be a functional module within the settings application of the electronic device, or it may be a separate application.

[0091] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0092] As shown in Figure 3, the application framework layer may include a lookup service module, an encryption / decryption module, and a Bluetooth service module. The lookup service module provides a downward interface for the lookup app. The encryption / decryption module generates temporary key pairs and encrypts the location of the electronic device to obtain the encrypted location. The Bluetooth service module provides an interface for the Bluetooth app.

[0093] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0094] The kernel layer is the layer between hardware and software. The kernel layer contains the Bluetooth driver. This Bluetooth driver is used to control the Bluetooth functionality (not shown in Figure 3) within the hardware of electronic devices.

[0095] Among them, Bluetooth APP, Bluetooth service module, Bluetooth driver and hardware layer Bluetooth can be collectively referred to as Bluetooth module.

[0096] In embodiments of this application, the TEE includes a security encryption module. This security encryption module is used to generate a master key and, based on the master key, generate derived key pairs, etc.

[0097] The device search method proposed in the embodiments of this application will be described below with reference to Figures 2 and 3.

[0098] Taking the lost device, i.e., the first electronic device shown in Figure 2, as an example, when the first electronic device receives an operation from the user to turn on the offline search function via the Find APP, it generates a master key for the first electronic device. The generation of the master key needs to be performed in a secure environment. Specifically, in this embodiment, the Find APP of the first electronic device, in response to the operation of turning on the offline search function, triggers the security encryption module of the first electronic device to generate the master key. After the master key is generated, if the upload conditions are met, the security encryption module of the first electronic device uploads the master key to the data server. After the master key is generated, the security encryption module of the first electronic device can also store the master key in its storage space. Furthermore, the Find APP of the first electronic device will automatically enter the offline search mode when it detects that the offline search function is met. After entering the offline search mode, the first electronic device can generate derived key pairs based on the master key; this process also needs to be performed in a secure environment. That is, in response to entering the offline search mode, the Find APP of the first electronic device triggers the security encryption module to generate multiple derived key pairs based on the master key. Furthermore, after generating multiple derived key pairs, the security encryption module of the first electronic device can send the derived public key to the Bluetooth module of the first electronic device for storage. Subsequently, the Find My App on the first electronic device sends a command to the Bluetooth module through the device's Find My Service module to control the Bluetooth module to send a Bluetooth broadcast carrying a derived public key. The offline search mode specifically refers to the mode entered after the device has enabled the offline search function and meets the conditions for doing so. In offline search mode, the device will generate a derived key pair based on the master key and send a Bluetooth broadcast carrying the derived public key to trigger nearby devices to report their location information.

[0099] Taking the second electronic device (shown in Figure 2) as an example, which is located near the lost device, as an example, the second electronic device, as a device near the lost device (which can be called a "helpful device"), uploads its location to the search server and also needs to enable the offline search function. After receiving a Bluetooth broadcast from the lost first electronic device, the second electronic device can trigger the encryption / decryption module to generate a temporary key pair through the search app on the second electronic device. Furthermore, the encryption / decryption module of the second electronic device can obtain the location of the second electronic device from its location-related module. After obtaining the location, the encryption / decryption module encrypts the location based on the derived public key carried in the Bluetooth broadcast and the temporary private key in the temporary key pair, obtaining the encrypted location. Then, the encryption / decryption module sends the encrypted location to the search app, which then uploads the encrypted location, derived public key, and temporary public key to the search server.

[0100] After receiving information from the second electronic device, the lookup server can determine the index based on the derived public key carried in the received information, and then store the corresponding encrypted location and temporary public key based on the index.

[0101] In the case where the electronic device is the trusted device of the lost device, i.e., the third electronic device shown in Figure 2, and the third electronic device is connected to the internet and logged into the same user account as the first electronic device, it can download the master key of the first electronic device from the data server. The third electronic device can store the master key of the first electronic device in the storage space of its security encryption module. Then, in response to user operation, the third electronic device triggers its security encryption module to generate a derived key pair based on the master key of the first electronic device through its search app. The security encryption module sends the derived public key from the derived key pair to the search app, which then uploads the derived public key to the search server for matching. When the search server matches the target derived key based on the derived public key uploaded by the third electronic device, it can send the target derived public key, its corresponding encrypted location, and a temporary public key to the third electronic device. The search app then sends the received encrypted location and temporary public key to the security encryption module. The security encryption module decrypts the encrypted location based on the derived public key and the temporary public key to obtain the decrypted location, thereby helping to locate the lost device.

[0102] Taking a mobile phone as the first electronic device and the Find My Device app as part of the phone's settings as an example, Figure 4 shows the operation interface of the Find My Device app provided by the mobile phone. Multiple application icons can be displayed on the phone's desktop, including the settings app icon. In response to the user's triggering operation on the settings app icon on the phone's desktop, the phone enters the settings app and displays the settings app interface 201. The settings app interface 201 includes multiple settings options. In response to the user's triggering operation on the security settings option 202 in the settings app interface 201, the phone displays the security settings interface 203. As shown in Figure 4, this security menu interface 203 includes the Find My Device option 204. Furthermore, in response to the user's triggering operation on the Find My Device option 204, the phone can display the Find My Device service interface 205. This Find My Device service interface 205 includes multiple switches. Among them, the Offline Find My Phone switch 206 is used to control the on or off of the offline search function. The offline search function specifically involves: when the conditions for the offline search function are met, the device triggers nearby devices to report their location information. Understandably, when the "Find My Phone Offline" switch 206 is turned on, if the phone is lost, nearby devices will be triggered to report their location information when the conditions for the offline search function are met. Specifically, if the phone shown in Figure 4 is lost, a signal will be sent to nearby devices to trigger them to report their location information when the conditions for the offline search function are met. It should be noted that nearby devices will only respond to receiving the signal sent by the lost device and report their location information to the search server to help the lost device achieve the offline search function if the "Find My Phone Offline" function is enabled.

[0103] The following describes in detail the process of the device search method proposed in the embodiments of this application with reference to the accompanying drawings.

[0104] Figure 5 shows a flowchart of the device search method in some embodiments. It should be noted that in the following embodiments, device A corresponds to the first electronic device, device B corresponds to the second electronic device, and device C corresponds to the third electronic device.

[0105] As shown in Figure 5, the device search method includes the following stages:

[0106] S1. Device A generates the master key.

[0107] In embodiments of this application, the master key is used to generate derived key pairs. These derived key pairs are then used for encryption when interacting with a nearby device B after the device A has been lost. This stage typically occurs before device A is lost, after the user initiates the offline search function on device A. In some embodiments, the master key may include a master key pair and master key parameters.

[0108] S2. Device A synchronizes the master key to other trusted devices.

[0109] Specifically, device A can synchronize its master key to other trusted devices through a data server. It should be noted that device A specifically synchronizes its own master key to other trusted devices.

[0110] S3. Device A generates and stores derived key pairs.

[0111] This stage typically occurs after device A is lost. As explained above, under certain conditions, device A can enter offline search mode.

[0112] S4. Device A triggers nearby device B to upload the location of device B to the lookup server.

[0113] Understandably, the location that device B uploads to the lookup server refers specifically to the location of device B at the very first moment after receiving the Bluetooth broadcast from device A. This location can be denoted as the first location.

[0114] This stage occurs after device A enters offline search mode. For example, device A may send a Bluetooth broadcast to trigger nearby devices, such as device B, to upload its location to the search server.

[0115] S5. The user triggers device C to download the location uploaded by device B from the lookup server.

[0116] Since device B can receive Bluetooth broadcasts from device A, it means that at least at some point, device B is near device A. Device B then uploads its location, which also indicates the approximate location of device A at that same time. Therefore, when the user triggers device C to download the location uploaded by device B, it can help locate the position of device A.

[0117] In the technical solution proposed in this application embodiment, when the conditions for offline locating are met, device A sends a Bluetooth broadcast carrying a derived public key to trigger nearby device B to upload its location to the locating server. Thus, even if device A is offline, it can still report its location to the locating server with the help of nearby device B, thereby helping the user locate the lost device A.

[0118] The following is a detailed introduction to S1-S5.

[0119] Please refer to Figure 6. S1 may specifically include the following steps:

[0120] S101. The user's action of enabling the offline search function was detected.

[0121] As can be seen from the above description, users can enable the offline search function by turning on the "Offline Search My Phone" switch 206 in the "Find Device Service" interface 205 shown in Figure 4.

[0122] S102. Generate master key pair and master key parameters.

[0123] The master key pair consists of a master private key and a master public key. The master private key can be represented by d0, and the master public key can be represented by p0. The master key pair can be denoted as (d0, p0). The master key parameter is denoted as SK0. The master key parameter and the master key pair are used together to generate derived key pairs.

[0124] S102 can be understood as generating the master key. The master key can include the master private key, the master public key, and master key parameters, and can be denoted as (d0, p0, SK0).

[0125] In some embodiments, device A generates a master key pair and master key parameters, which may be generated based on a first preset elliptic curve. An elliptic curve is a mathematically defined curve with a specific equation form. For example, the first preset elliptic curve may be P-244, P-256, P-384, or P-521, etc.

[0126] In some embodiments, the above-described S102 can be specifically executed in the security encryption module of the electronic device.

[0127] Users can typically enable the offline search function in the Find My app on electronic devices, such as Device A. When Device A, such as the Find My app on Device A, detects the operation of enabling the offline search function, it triggers the security encryption module to generate a master key pair and master key parameters.

[0128] S103. Store the master key pair and master key parameters.

[0129] After generating the master key pair and master key parameters, device A can store them within its own storage space. Specifically, device A can store the master key pair and master key parameters in the storage space of its security encryption module. The master key pair and master key parameters can be stored in JSON format (a data exchange format) within the storage space of device A's security encryption module.

[0130] Optionally, as an example, each time a device responds to a user's operation to activate the offline search function, it can regenerate a master key pair and master key parameters. S102 above includes: Device A, in response to the activation of the offline search function, generates its own master key pair and master key parameters. After activating the offline search function, the user may close it and then reopen it. In this embodiment, in response to the closure of the offline search function, Device A deletes the master key pair and master key parameters already stored in Device A. Furthermore, as illustrated in Figure 5, Device A's master key pair and master key parameters are also synchronized to other trusted devices of Device A via a data server. In this embodiment, the method further includes: Device A, in response to the closure of the offline search function, notifying the data server to delete Device A's master key pair and master key parameters, and notifying Device A's trusted devices via the data server to delete Device A's master key pair and master key parameters.

[0131] Optionally, as another example, for a device, the master key pair and master key parameters are unique; that is, the device only triggers the generation of the master key pair and master key parameters when the offline search function is first enabled. After the master key pair and master key parameters are generated for the first time, the device can store them in the device. Subsequently, if the user closes and reopens the offline search function, since the master key pair and master key parameters have already been stored, the device does not need to generate them again. Therefore, before S102 above, the method may also include: in response to the operation of opening the offline search function, querying whether device A stores device A's master key pair and master key parameters. Further, S102 above may specifically include: if device A determines that it does not store the master key pair and master key parameters, it generates device A's master key pair and master key parameters. Then, S103 is executed to store the master key pair and master key parameters. Conversely, if it is determined that device A already stores the master key pair and master key parameters, device A does not need to execute S102 and S103.

[0132] Please refer to Figure 7. The above S2 may specifically include the following steps:

[0133] S201. Device A synchronizes the master key to the data server.

[0134] When device A is connected to the internet and logged into a user account, it can upload the generated master key to the data server for storage. Device A's internet connection status specifically means that it is connected to the internet and can communicate with other devices or servers via the network. Device A can connect to the internet in any way.

[0135] To ensure data security, device A encrypts the master key before synchronizing it with the data server, and then synchronizes the encrypted master key with the data server. Device A can encrypt the master key using a first preset encryption algorithm. As an example, the first preset encryption algorithm can specifically be the Advanced Encryption Standard-Galois / Counter Mode (AES-GCM) algorithm. In this embodiment, device A can also synchronize the key encryption key (the key used to encrypt the master key) to the data server.

[0136] It should be noted that S201 requires device A to be connected to the internet; therefore, S201 typically occurs before device A is lost. Generally, after device A enables the offline search function and generates a master key, if device A meets the conditions of being connected to the internet and logged into a user account, device A can synchronize the master key to the data server.

[0137] As an example, the data server can store the master key of device A. Later, after a trusted device of device A comes online, the data server can synchronize the master key of device A to the trusted device of device A, as shown in S202 below.

[0138] S202. The data server synchronizes the master key to other trusted devices of device A.

[0139] When device C is connected to the network and logged into a user account (the same user account as device A), device C can send a notification message to the data server. Upon receiving the notification message from device C, the data server can synchronize device A's master key to device C.

[0140] In an embodiment where device A synchronizes the master key to the data server using a key encrypted with a key encryption key, the data server, in response to receiving a notification message from device C, synchronizes the encrypted master key and the key encryption key to device C.

[0141] S203. Device C stores the master key of device A.

[0142] When S201 occurs, device A may not have a trusted device, or the trusted device may not be logged into a user account. In this case, S202 and S203 cannot be executed. Device C may log into a user account before or after device A is lost. Therefore, S202 and S203 may specifically occur before or after device A is lost.

[0143] Through the synchronization process described above, device A can synchronize its generated master key to other trusted devices (such as device C). Then, on these other trusted devices, users can use device A's master key to download location information uploaded by nearby devices that triggered device A's offline state from the lookup server. This helps in locating device A's position.

[0144] Referring to Figure 8, the above S3 may specifically include the following steps:

[0145] S301. In response to the conditions for satisfying the offline lookup function, generate a derived key pair based on the master key.

[0146] In some embodiments, when device A has enabled the offline search function, it will automatically enter offline search mode if the conditions for offline search are met. After entering offline search mode, device A will trigger nearby eligible devices (which can be referred to as helpful devices) to report their locations to the search server to help device A's user locate device A.

[0147] As one example, the conditions for the offline search function include: the device is not connected to the internet and the duration of this offline state exceeds a time threshold. As another example, the preset conditions include: the device is not connected to the internet, the battery level is below a certain threshold, and the duration of this offline and low-battery state exceeds a certain time threshold. Both the time threshold and the battery threshold can be set according to actual needs. A device being offline means that it is not connected to the internet and cannot communicate online.

[0148] As described in the above embodiments, the master key can be denoted as (d0, p0, SK0). The derived key pair includes a derived private key and a derived public key. The derived private key can be represented by di, the derived public key by pi, and the derived key pair can be denoted as (di, pi).

[0149] In some embodiments, device A can generate derived key pairs based on the master key using a key derivation function (KDF). KDF is an algorithm that generates fixed-length, highly random, and unique keys by inputting one or more parameters. KDF is commonly used in encrypted communication, file encryption, cryptographic security protocols, and key management in memory.

[0150] Optionally, as an example, the process of generating the first derived key pair based on the master key using KDF includes: Step A, generating the first derived key parameter SK1 based on the master key parameter SK0 and the fixed parameter extract. Step B, generating the first intermediate parameter pair (u1, v1) based on the first derived key parameter SK1 and the fixed parameter expand. Step C, generating the first derived private key d1 based on the master private key d0 and the first intermediate parameter pair. Step D, generating the first derived public key p1 based on the first derived private key d1 and parameter G. Then, using the first derived key parameter SK1, the first derived private key d1, and the first derived public key p1 from the first derived key pair generation process, executing steps A-D yields the second derived key parameter SK2, the second derived private key d2, and the second derived public key p2. This process can be repeated to obtain multiple derived key pairs.

[0151] The process described above, which generates derived key pairs based on the master key using KDF, can be specifically represented as follows:

[0152] a.SKi = KDF(SKi-1, "extract", 32) / / SK key parameters are generated in a rolling manner (32 bytes);

[0153] b.(ui,vi)=KDF(SKi,"expand",72) / / ui.length==vi.length=36bytes;

[0154] c.di = (d0 * ui) + vi;

[0155] d.pi=di*G.

[0156] Among them, "extract", "expand" and G are all fixed parameters in KDF.

[0157] In some embodiments, the process of generating derived key pairs based on the master key in S301 can be specifically executed by the security encryption module of the electronic device. In this embodiment, S301 may specifically include: in response to the conditions of satisfying the offline search function, the search app activates the security encryption module and triggers the security encryption module to generate derived key pairs based on the master key. For example, the search app of device A triggers the security encryption module to generate 200 derived key pairs. That is, in the embodiments of this application, when entering the offline search mode, the security encryption module is triggered to generate multiple derived key pairs at once, and then the generated multiple derived key pairs can be stored for subsequent use. Since the search app needs to activate the security encryption module to generate derived key pairs when entering the offline search mode, each activation of the security encryption module consumes the power consumption of the electronic device. Compared with the technical solution of activating the security encryption module to regenerate derived key pairs every time a derived key pair is used (i.e., sending a Bluetooth broadcast), the technical solution proposed in this application embodiment can generate and store multiple derived key pairs after activating the security encryption module once. In this way, under the condition of meeting the offline search function, it is not necessary to repeatedly activate the security encryption module, which can reduce the power consumption of electronic devices. In the scenario of lost electronic devices, reducing power consumption can increase the remaining battery life of the electronic device. The longer the remaining battery life of the electronic device, the more likely it is to trigger nearby electronic devices to report more location information to the search server, which is more conducive to the user's efforts to find the lost electronic device.

[0158] S302. Device A stores derived key pairs.

[0159] In some embodiments, S302 described above can specifically store the derived public key pi from the derived key pair in the Bluetooth module. The Bluetooth module mentioned here can correspond to the Bluetooth APP, Bluetooth service module, Bluetooth driver, and Bluetooth at the mobile phone hardware layer shown in Figure 3. For the generated derived private key di, device A can store it in the storage space of the security encryption module.

[0160] Referring to Figure 9, the above S4 may specifically include the following steps:

[0161] S401. Device A sends a Bluetooth broadcast, which carries the derived public key.

[0162] In some embodiments, the Bluetooth broadcast sent by device A may also carry other information, such as device A's MAC address, device A's business data for finding the app, and other data required by the Bluetooth standard. Specifically, to ensure device A's security, the MAC address of device A may be a randomly generated MAC address.

[0163] When device B is within a certain range of device A, device B can receive Bluetooth broadcasts sent by device A.

[0164] After device A meets the conditions for offline location tracking, it sends a Bluetooth broadcast at preset intervals. For example, the preset interval can be short, such as 15 minutes, 20 minutes, or 30 minutes, or long, such as 12 hours or 24 hours. Each Bluetooth broadcast sent by device A carries a derived public key. Specifically, the derived public key carried in the Bluetooth broadcast is one of the derived public keys generated by device A based on its master key. Different Bluetooth broadcasts can carry different derived public keys. Thus, even if the same device B receives multiple Bluetooth broadcasts from device A, because the carried derived public keys are different, device B cannot determine whether the Bluetooth broadcasts originated from the same device. This prevents device A's location from being maliciously obtained.

[0165] S402. Device B, in response to receiving a Bluetooth broadcast, generates a temporary key pair.

[0166] In the embodiments of this application, device B is a device with offline search functionality enabled. As some examples, device B generates a temporary key pair, which can be based on a second preset elliptic curve. The second preset elliptic curve can specifically be elliptic curve cryptography (ECC)-244.

[0167] A temporary key pair consists of a temporary private key and a temporary public key. For example, a temporary private key can be represented by d', a temporary public key can be represented by p', and a temporary key pair can be represented as (d', p').

[0168] Optionally, device B will regenerate a temporary key pair each time it receives a Bluetooth broadcast carrying the derived public key.

[0169] S403. Device B obtains the location of Device B.

[0170] S404. Location of encrypted device B based on derived public key and temporary key pair.

[0171] Specifically, in S403 above, device B can encrypt its location based on the derived public key and the temporary private key in the temporary key pair. For example, device B can generate a location encryption key based on the derived public key and the temporary private key, and then encrypt its location using the generated location encryption key to obtain the encrypted location.

[0172] Optionally, as an example, device B generates a location encryption key based on a derived public key and a temporary private key, which can be implemented using the elliptic curve Diffie-Hellman (ECDH) method.

[0173] ECDH is a key exchange protocol that combines ECC and the Diffie-Hellman key exchange protocol. ECDH allows two parties to negotiate a shared secret key, such as the aforementioned location encryption key, over an insecure channel without needing to share any secret information beforehand. This shared secret key can be used to encrypt and decrypt messages, ensuring the security of communication.

[0174] The working principle of ECDH is as follows:

[0175] 1. Both parties choose a common elliptic curve and base point (G).

[0176] 2. Each entity generates its own private key and corresponding public key. The private key is randomly generated, while the public key is obtained by multiplying the private key by the base point.

[0177] 3. Both parties exchange public keys, but retain their respective private keys.

[0178] 4. Using the other party's public key and their own private key, each calculates a shared secret key (i.e., the location encryption key in the above embodiment). Due to the mathematical properties of elliptic curves, this secret key is identical.

[0179] In some embodiments, the location encryption key is represented by the Advanced Encryption Standard (AESKey). Based on the working principle of ECDH described above, the process by which device B generates a location encryption key using ECDH based on a derived public key and a temporary private key can be represented as: AESKey = ECDH(d`, pn). pn represents the derived public key carried in the Bluetooth broadcast from device A. Then, the location of device B can be encrypted using the AESKey. This encryption of device B's location using the AESKey can be implemented using a second preset encryption algorithm. For example, the second preset encryption algorithm can be the AES-GCM algorithm, specifically the AES-GCM 256 algorithm.

[0180] In the above embodiment, a location encryption key is calculated from the derived public key and the temporary private key using the ECDH method. This location encryption key is then used to encrypt the location of device B. This allows device C to decrypt the encrypted location by generating a new location encryption key using the same ECDH method based on the derived public key and the temporary public key. This method ensures data security during the processes of device B uploading data to the lookup server and the lookup server sending data to device C.

[0181] S405. Device B uploads the encrypted location, temporary public key, and derived public key to the lookup server.

[0182] In some embodiments, device B may upload a derived public key or a hash value of the derived public key, such as SHA256(pi), to the lookup server. The derived public key here is the one carried in the received Bluetooth broadcast. The derived public key or its hash value uploaded by device B to the lookup server can specifically be used as additional authenticated data (AAD).

[0183] As an example, before device B uploads data to the lookup server, the lookup server needs to authenticate device B. Only after successful authentication can device B upload data to the lookup server. For instance, before uploading the encrypted location, temporary public key, and derived public key to the lookup server, device B can first upload its device certificate. The lookup server can then authenticate device B based on this device certificate. After the lookup server successfully authenticates device B based on its device certificate, it notifies device B to upload the encrypted location, temporary public key, and derived public key to the lookup server. The device certificate is used to identify device B.

[0184] As another example, device B can also use its device certificate to sign the encrypted location, temporary public key, and derived public key separately, and then upload the signed encrypted location, temporary public key, and derived public key. In this embodiment, after receiving the signed encrypted location, temporary public key, and derived public key, the lookup server authenticates device B's device certificate. If the authentication is successful, the lookup server can parse and obtain the encrypted location, temporary public key, and derived public key.

[0185] By authenticating device B, it is possible to avoid the server receiving and storing data uploaded by unidentified devices.

[0186] S406. The lookup server uses the derived public key as an index to store the encrypted location and temporary public key.

[0187] In some embodiments, the lookup server can store the encrypted location, temporary public key, and derived public key using the derived public key as the key and the encrypted location and temporary public key as the value of the key-value pair. This not only achieves anonymity but also allows device C to find the encrypted location uploaded by device B near device A from the lookup server.

[0188] In the embodiment where device B uploads the hash value of the derived public key, such as SHA256(pi), to the lookup server, the lookup server can use SHA256(pi) as an index to store the encrypted location and temporary public key. The specific implementation is similar to that of using the derived public key as an index to store the encrypted location and temporary public key, and will not be elaborated further.

[0189] Understandably, if a device B receives Bluetooth broadcasts from device A at different times multiple times, device B may upload its encrypted location multiple times. If multiple devices B near device A all receive Bluetooth broadcasts from device A, then each device B can upload its encrypted location to the lookup server according to steps S402-S405 described above.

[0190] Please refer to Figure 10. The above S5 includes the following steps:

[0191] S501. Device C generates a derived key pair based on the master key of Device A.

[0192] In the embodiments of this application, device C can generate multiple derived key pairs based on the master key of device A. The number of derived key pairs generated by device C can be set according to actual needs, such as 200.

[0193] It should be noted that device C generates a derived key pair based on device A's master key, using the same method as device A in S301. For example, both device C and device A use KDF to generate derived key pairs based on their master keys. Since device A and device C are based on the same master key and use the same key derivation function, the derived key pair generated by device C may partially overlap with that generated by device A. Therefore, device C can use the derived key pair generated by device C to locate the encrypted position uploaded by device B near device A in the lookup server.

[0194] Based on the key derivation function, the derived key pairs generated by device C based on device A's master key may differ at different points in time. In some embodiments, device C can choose the time when generating the derived key pairs. For example, device C can generate derived key pairs within the last 7 days in response to user actions. Alternatively, device C can generate derived key pairs within a specified 7 days of the previous month in response to user actions, and so on. This increases the likelihood that the derived key pairs generated by device C overlap with those generated by device A, thereby increasing the probability that device C can obtain the encrypted location uploaded by device B near device A from the lookup server, which in turn helps the user find the lost device A.

[0195] To distinguish it from the derived key pair generated by device A based on device A's master key, the derived private key generated by device C based on device A's master key can be used as di. a This means that the derived public key generated by device C based on the master key of device A can be represented by pi. a This means that the derived key pair generated by device C based on the master key of device A is denoted as (di). a ,pi a ).

[0196] S502. Device C sends the derived public key generated by Device C to the lookup server.

[0197] In this embodiment, the derived public key sent by device C to the lookup server is a derived public key from the derived key pair generated by device C based on the master key of device A. In some embodiments, device C may send multiple derived public keys generated by device C to the lookup server at one time, which are used to search for matching encrypted location and other information in the lookup server.

[0198] Optionally, before device C sends its derived public key to the lookup server, the lookup server needs to authenticate device C. Only after successful authentication can device C upload data to the lookup server. For details on how the lookup server authenticates device C, please refer to the specific instructions on how the lookup server authenticates device B.

[0199] In an embodiment where the derived public key uploaded by device B to the lookup server is a hash value of the derived public key, after S501, the above method further includes: calculating the hash value of the derived public key generated by device C, such as SHA256(pi a In S502, the derived public key generated by device C and uploaded by device C to the lookup server is the hash value SHA256(pi) of the derived public key generated by device C. a In this way, the lookup server can utilize SHA256(pi). aMatching.

[0200] S503. The lookup server matches the derived public key generated by device C with the derived public key stored in the lookup server.

[0201] The lookup server stores the derived public key of device A, which was uploaded by device B, as described in S405-S406 above. Similarly, the lookup server may also store encrypted location information uploaded by other devices. In other words, the lookup server stores a large amount of encrypted location information.

[0202] The lookup server matches the derived public key sent by device C with the derived public keys stored in the lookup server. Specifically, it checks whether a derived public key identical to the one sent by device C exists. If an identical derived public key exists, the lookup server can send the matched derived public key and its corresponding data to device C, so that device C can determine the location of device A based on the encrypted location.

[0203] S504. The lookup server sends the matched derived public key, its corresponding encrypted location, and the temporary public key to device C.

[0204] In the technical solution provided in this application embodiment, all data uploaded by devices is anonymous to the lookup server, eliminating the need to verify whether device A and device C are logged into the same user account. Instead, the lookup server only needs to match the derived public key sent by device C with the derived public key stored on the lookup server. If a match is found, the lookup server sends the matched data (encrypted location, temporary public key, and derived public key) to device C. This ensures the security of the data on the lookup server and protects the user's location data from being leaked.

[0205] S505. Decrypt the encrypted location.

[0206] In some embodiments, in S505 above, device C can determine the location encryption key in the same way as when device B encrypted its location. Then, the encrypted location is decrypted based on the location encryption key. As can be seen from the above embodiments, when device B encrypts its location, it uses a derived public key (such as pn), a temporary private key (d'), and a location encryption key determined based on the ECDH algorithm. According to the characteristics of the ECDH algorithm, device C can also obtain the location encryption key used when encrypting the device's location using the derived private key corresponding to the derived public key pn and the temporary public key corresponding to the temporary private key d', based on the ECDH algorithm. Here, the derived public key pn is a derived public key issued from the lookup server, and the derived key pair generated by device C based on device A's master key contains a derived public key pn that is the same as the derived public key pn issued by the lookup server.a and the corresponding derived private key DN a The temporary public key corresponding to the temporary private key d' is the temporary public key p' issued by the lookup server. Therefore, after S504, device C can obtain the corresponding derived private key dn based on the derived public key issued by the lookup server. a And based on dn a Using the derived public key, the location encryption key is determined. The location encryption key determined by device C can be expressed as: AESKey = ECDH(dn a ,p`).

[0207] After device C calculates and obtains the location encryption key, it can decrypt the encrypted location based on the location encryption key to obtain the decrypted location data.

[0208] Understandably, if the lookup server matches multiple derived public keys based on the derived public key generated by device C, then device C can obtain these multiple derived public keys along with their corresponding encrypted locations and temporary public keys. After decrypting these encrypted locations, device C can obtain the location information of device B near device A at multiple times, thus determining the approximate location of device A at those times. Alternatively, the location information obtained by device C through decryption could also be the location information of multiple devices B near device A at a specific point in time, thus determining the approximate location of device A at that point in time. Based on this location information, it can help to recover the lost device A.

[0209] Furthermore, the decrypted location information can be displayed on device C. For example, device C can display the decrypted location information in map data so that users can better view the location.

[0210] In the above embodiments, the search server and data server can be two different servers or server clusters, or they can be two different modules of the same server used to implement different functions. Alternatively, the search server and data server can also be different servers within the same server cluster. Both the search server and data server in the above embodiments can be cloud servers.

[0211] Figure 11 shows the specific implementation flow of the device search method proposed in the embodiments of this application.

[0212] S601. In response to the offline search function being enabled, the Find APP of Device A sends instruction 1 to the security encryption module.

[0213] S602. The security encryption module of device A generates a master key.

[0214] In some embodiments, upon receiving instruction 1, the security encryption module can directly generate a master key. Subsequently, if the search app sends an instruction to the security encryption module in response to the offline search function being disabled, the security encryption module can delete the generated master key. The next time the offline search function is enabled, the security encryption module regenerates a new master key.

[0215] In other embodiments, after receiving instruction 1, the security encryption module first determines whether the master key has been stored. If the master key has not been stored, it needs to be generated. That is, S602 specifically includes: if the security encryption module determines that the master key has not been stored, it generates the master key. If the master key has already been stored, it does not generate a new master key, and S602 and S603 do not need to be executed.

[0216] S603. The security encryption module of device A stores the master key.

[0217] It should be noted that S601-S603 correspond to S1 in the above embodiments.

[0218] S604. The security encryption module of device A synchronizes the master key of device A with the data server.

[0219] S605. The data server synchronizes the master key of device A with device C.

[0220] S606. The security encryption module of the device C for finding the APP notification stores the master key of device A.

[0221] Specifically, the Find Me app for device C can send the master key of device A to the security encryption module, which can then store the master key of device A in its storage space.

[0222] In the embodiment where device A uploads the encrypted master key to the data server, device C can also receive the key encryption key from the data server simultaneously with the encrypted master key. In this embodiment, after device C's search app sends the encrypted master key and the key encryption key to the security encryption module, the security encryption module decrypts the encrypted master key based on the key encryption key and stores the decrypted master key of device A.

[0223] It should be noted that S604-S606 correspond to S2 in the above embodiments.

[0224] S607. In response to the conditions for meeting the offline search function, the Find APP of Device A sends instruction 2 to the security encryption module.

[0225] S608. The security encryption module of device A generates derived key pairs based on the master key.

[0226] In the embodiments of this application, the security encryption module generates multiple derived key pairs based on the master key.

[0227] S609. The security encryption module of device A sends a derived public key to the Bluetooth module.

[0228] S610. The Bluetooth module of device A stores the derived public key.

[0229] In the embodiments of this application, the security encryption module generates multiple derived key pairs when entering offline search mode, thus the Bluetooth module can store multiple derived public keys. Subsequently, when device A sends a Bluetooth broadcast, it can directly use the derived public keys already stored in the Bluetooth module without needing to restart the security encryption module to generate derived key pairs again. This reduces the number of times the security encryption module is restarted, thereby reducing the power consumption of the electronic device.

[0230] It should be noted that S607-S610 correspond to S3 in the above embodiments.

[0231] S611. Device A's Bluetooth module sends a Bluetooth broadcast.

[0232] The Bluetooth broadcast carries a derived public key.

[0233] At this time, if device B is within a certain range (such as Bluetooth communication range) of device A, device B can receive the Bluetooth broadcast sent by device A. After device B receives the Bluetooth broadcast sent by device A through its Bluetooth module, it can execute S612.

[0234] S612. The Bluetooth module of device B sends notification message 1 to the Find My App of device B.

[0235] Notification message 1 can be used to notify the Finder app that it has received a Bluetooth broadcast from device A.

[0236] As examples, prior to S612, after receiving a Bluetooth broadcast, the Bluetooth module of device B parses the broadcast to obtain the derived public key. In this embodiment, the Bluetooth module can carry this derived public key in notification message 1 sent to the Find APP.

[0237] S613. The Find App for Device B determines whether the offline search function is enabled.

[0238] In some embodiments, a device can use an identifier to record whether the offline search function is enabled. In this embodiment, the Find My App can determine whether the current device B has the offline search function enabled by querying this identifier.

[0239] If the result of S613 is "otherwise", device B can ignore the Bluetooth broadcast sent by device A and will not upload the location of device B to the lookup server; this decision branch is not shown in Figure 11. If the result of S613 is "yes", then S614 is executed.

[0240] S614. The Find App of Device B sends notification message 2 to the encryption / decryption module.

[0241] S615. Device B's encryption / decryption module generates a temporary key pair.

[0242] A temporary key pair consists of a temporary public key and a temporary private key.

[0243] S616. Device B's encryption / decryption module obtains the location of Device B.

[0244] S617. The encryption / decryption module of device B uses a derived public key and a temporary private key to encrypt the location of device B and obtain the encrypted location.

[0245] S618. Device B's encryption / decryption module sends the encrypted location and temporary public key to Device B's Find APP.

[0246] S619. The APP for finding device B calculates SHA256(pi).

[0247] Here, SHA256(pi) represents the hash value of the derived public key carried in the Bluetooth broadcast sent by device A.

[0248] S620. The Find App of Device B uploads the encrypted location, temporary public key and SHA256(pi) to the Find Server.

[0249] S621. Locate the server's stored encrypted location, temporary public key, and SHA256(pi).

[0250] It should be noted that S611-S621 correspond to S4 in the above embodiments.

[0251] S622. In response to the device search function being triggered, the device search APP of device C sends instruction 3 to the security encryption module.

[0252] S623. The security encryption module of device C generates a derived key pair based on the master key of device A.

[0253] When generating derived key pairs based on the master key of device A, the security encryption module of device C can select a historical time interval to generate derived key pairs within that time interval. This allows users on device C to generate corresponding derived key pairs based on the selected loss period, increasing the likelihood of overlap between the derived public key and the derived key pair generated when device A enters offline search mode. This improves the chances of matching the encrypted location from the search server, thus aiding in the search for the lost device A.

[0254] S624. The security encryption module of device C sends the derived public key to the Find APP.

[0255] S625. The APP for finding device C calculates SHA256`(pi).

[0256] Wherein, SHA256`(pi) represents the hash value of the derived public key generated by device C based on the master key of device A.

[0257] S626. The Find App of Device C sends SHA256`(pi) to the Find Server.

[0258] S627. The lookup server matches SHA256`(pi) with the hash values ​​of all derived public keys in the lookup server.

[0259] S628. The search server sends the matched SHA256(pi) and its corresponding encrypted location, along with the temporary public key, to the search app on device C.

[0260] S629. The Find App of Device C sends the matched SHA256(pi) and its corresponding encrypted location, and the temporary public key to the security encryption module.

[0261] S630. The security encryption module of device C decrypts the encrypted location.

[0262] Specifically, S626 mentioned above may include: obtaining the derived private key corresponding to SHA256`(pi), determining the location encryption key based on the derived private key and the temporary public key, and then decrypting the encrypted location based on the location encryption key.

[0263] S631. The security encryption module of device C sends the decrypted location to the locator app.

[0264] After receiving the decrypted location, the app can display the decrypted location on the interface for the user to view.

[0265] It should be noted that S622-S631 correspond to S5 in the above embodiments.

[0266] The specific implementation of S601-S631 can be referred to the description in the above embodiments.

[0267] In the technical solution proposed in this application embodiment, when entering offline search mode, the security encryption module is triggered to generate multiple derived key pairs at once. Subsequent Bluetooth broadcasts do not require the security encryption module to be activated again to generate derived key pairs, thus reducing power consumption of the electronic device. Due to the anonymous data storage method used on the search server side, other trusted devices, such as device C, can obtain the corresponding encrypted location information once according to the selected loss period and send it to the end side for decryption, increasing the likelihood of matching the encrypted location from the search server and facilitating the search for the lost device A.

[0268] Other embodiments of this application provide a device search system, which includes a first electronic device (i.e., device A above), a second electronic device (i.e., device B above), and a first server (i.e., the search server above). Both the first and second electronic devices have offline search functions enabled; the first electronic device stores its master key.

[0269] A first electronic device, in response to conditions meeting the offline search function, generates at least two derived key pairs based on the master key of the first electronic device and sends a Bluetooth broadcast. The Bluetooth broadcast carries a first derived public key, which is one of the derived public keys in the at least two derived key pairs.

[0270] The second electronic device is configured to, in response to receiving a Bluetooth broadcast from the first electronic device, send to the first server the first location of the second electronic device and a first derived public key.

[0271] The first server is used to associate and store the first location and the first derived public key.

[0272] In the technical solution proposed in this application embodiment, when the offline search function is met, the first electronic device sends a Bluetooth broadcast carrying a derived public key to trigger a nearby second electronic device to upload its location to the first server. Thus, even if the first electronic device is offline, it can still report its location to the search server with the help of nearby devices, thereby helping the user locate the lost first electronic device. Furthermore, when the offline search function is met, the first electronic device generates multiple derived key pairs based on the master key. Then, the first electronic device can directly use the derived public key from the generated derived key pairs to send a Bluetooth broadcast. After the device is lost, its battery power may gradually decrease over time. When the device's battery is low, it will be unable to generate derived key pairs based on the master key. However, Bluetooth typically has a low-power mode, which allows it to send Bluetooth broadcasts even when the device's battery is low. Therefore, by pre-generating multiple derived key pairs in this solution, even if the lost device is offline and has low battery, it can still send a Bluetooth broadcast based on the derived public key from the pre-generated derived key pairs, triggering a nearby second electronic device to report its location information. In this way, compared to the approach of generating a derived key pair every time a Bluetooth broadcast is sent, the lost device in this approach is likely to trigger nearby devices to report their location information over a longer period of time. The more location information reported, the better it is for locating the lost primary electronic device.

[0273] In some embodiments, the device search system further includes a third electronic device (i.e., device C mentioned above). This third electronic device, in response to a user's triggering operation, generates at least two derived key pairs based on the master key of the first electronic device and sends a second derived public key to the first server. The second derived public key is the derived public key from the at least two derived key pairs generated by the third electronic device. Specifically, the user's triggering operation is the user triggering the device search operation.

[0274] In this scheme, the first server is also used to match the received second derived key with the derived public keys stored in the first server; and if a target derived public key matching the second derived public key is found, the first server sends location information associated with the target derived public key to the third electronic device. It can be understood that the matched target derived public key includes the first derived public key, i.e., the first derived public key of the first electronic device uploaded by the second electronic device. The location information includes the first location uploaded by the second server, i.e., the location uploaded by the second electronic device.

[0275] In the technical solution proposed in this application, a user can download location information representing a first electronic device from a first server using a third electronic device. This enables the determination of the location of the first electronic device when it is offline, thus helping to retrieve the first electronic device.

[0276] In some embodiments, the third electronic device is a trusted device of the first electronic device; the third electronic device is also used to obtain the master key of the first electronic device. The first electronic device and the third electronic device log in to the same user account.

[0277] In some embodiments, the device locator system further includes a second server. The first electronic device is also used to synchronize its master key with the second server. The second server stores the master key of the first electronic device and, when the third electronic device is connected to the network, synchronizes the master key of the first electronic device with the third electronic device. In this scheme, the master key of the first electronic device can be synchronized to a trusted device of the first electronic device, such as the third electronic device, via the second server. Thus, even if the first electronic device did not have a trusted device before it was lost, its master key can be stored in the second server. After the first electronic device is lost, a user can log in with the same user account as the first electronic device using another device and then retrieve the master key of the first electronic device from the second server. This device can then obtain the location information representing the first electronic device from the first server based on the master key.

[0278] In some embodiments, the first location sent by the second electronic device to the first server is an encrypted location. In this scheme, the second electronic device is further configured to generate a temporary key pair and encrypt the first location based on a first derived public key and a temporary private key in the temporary key pair. Additionally, the second electronic device is further configured to send the temporary public key from the temporary key pair to the first server. In this scheme, the first server is further configured to associate and store the temporary public key with the first derived public key. This protects the security of the location of the second electronic device.

[0279] In some embodiments, where the system includes a third electronic device, the first server is further configured to send a temporary public key associated with the target derived public key to the third electronic device when a target derived public key matching the second derived public key is found. The third electronic device is further configured to decrypt the first location in the location information based on the received temporary public key associated with the first derived public key. Thus, the third electronic device can decrypt the encrypted first location information to obtain the decrypted location information, thereby aiding in locating the first electronic device.

[0280] In some embodiments, the first electronic device is further configured to generate at least two derived key pairs based on the master key of the first electronic device and send a Bluetooth broadcast in response to the condition that the network outage lasts for a duration exceeding a time threshold.

[0281] In other embodiments, the first electronic device is further configured to generate at least two derived key pairs based on the master key of the first electronic device and send a Bluetooth broadcast in response to the conditions that the device is not connected to the network, the battery level is below a power threshold, and the duration of the period of being not connected to the network and having the battery level below the power threshold exceeds a time threshold.

[0282] Other embodiments of this application provide an electronic device (such as device A, device B, or device C). The electronic device may include a memory and one or more processors. The memory is coupled to the processors. The memory is also used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device can perform various functions or steps performed by device A, device B, or device C in the above method embodiments. The structure of this electronic device can be referenced to the structure of the electronic device 100 shown in FIG1.

[0283] This application also provides a chip system, as shown in FIG12, which includes at least one processor 1201 and at least one interface circuit 1202. The processor 1201 and the interface circuit 1202 are interconnected via lines. For example, the interface circuit 1202 can be used to receive signals from other devices (e.g., a computer's memory). As another example, the interface circuit 1202 can be used to send signals to other devices (e.g., the processor 1201). Exemplarily, the interface circuit 1202 can read instructions stored in memory and send those instructions to the processor 1201. When the instructions are executed by the processor 1201, the computer can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in this application.

[0284] This application also provides a computer-readable storage medium including computer instructions that, when executed on the electronic device (such as device A, device B, or device C), cause the electronic device to perform various functions or steps performed by device A, device B, or device C in the above method embodiments.

[0285] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps performed by device A, device B, or device C in the above method embodiments. The computer can be an electronic device, such as device A, device B, or device C.

[0286] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0287] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0288] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0289] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0290] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0291] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A device location system, characterized in that, include: First electronic device, second electronic device, and first server; The first electronic device stores the master key of the first electronic device; The first electronic device is configured to generate at least two derived key pairs based on the master key of the first electronic device and send a Bluetooth broadcast in response to the condition of satisfying the offline search function; the Bluetooth broadcast carries a first derived public key, which is one of the derived public keys in the at least two derived key pairs; The second electronic device is configured to, in response to receiving the Bluetooth broadcast from the first electronic device, send to the first server the first location of the second electronic device and the first derived public key; The first server is used to associate and store the first location and the first derived public key.

2. The system according to claim 1, characterized in that, The system further includes: a third electronic device; the third electronic device stores the master key of the first electronic device; the third electronic device is configured to, in response to a user's trigger operation, generate at least two derived key pairs based on the master key of the first electronic device, and send a second derived public key to the first server; the second derived public key is a derived public key among the at least two derived key pairs generated by the third electronic device; the first server is further configured to match the received second derived public key with derived public keys stored in the first server; and, if a target derived public key matching the second derived public key is found, send location information associated with the target derived public key to the third electronic device; the target derived public key includes the first derived public key, and the location information includes the first location; the third electronic device is further configured to determine the historical location of the first electronic device based on the received location information.

3. The system according to claim 2, characterized in that, The third electronic device is a trusted device of the first electronic device; the third electronic device is also used to obtain the master key of the first electronic device.

4. The system according to claim 3, characterized in that, The system further includes a second server; the first electronic device is also used to synchronize the master key of the first electronic device to the second server; the second server is used to store the master key of the first electronic device and synchronize the master key of the first electronic device to the third electronic device when the third electronic device is connected to the network.

5. The system according to any one of claims 1-4, characterized in that, The first location sent by the second electronic device to the first server is an encrypted location; the second electronic device is also used to generate a temporary key pair and encrypt the first location based on the first derived public key and the temporary private key in the temporary key pair; the second electronic device is also used to send the temporary public key in the temporary key pair to the first server; the first server is also used to associate and store the temporary public key with the first derived public key.

6. The system according to claim 5, characterized in that, In the case where the system includes a third electronic device, the first server is further configured to send a temporary public key associated with the target derived public key to the third electronic device when a target derived public key that matches the second derived public key is found; the third electronic device is further configured to decrypt the first location in the location information based on the received temporary public key associated with the first derived public key.

7. The system according to any one of claims 1-6, characterized in that, The first electronic device is further configured to, in response to the condition that the duration of being offline and offline exceeds a time threshold, generate at least two derived key pairs based on the master key of the first electronic device and send a Bluetooth broadcast; or, the first electronic device is further configured to, in response to the condition that the duration of being offline and offline exceeds a time threshold, generate at least two derived key pairs based on the master key of the first electronic device and send a Bluetooth broadcast.

8. A device location method, characterized in that, The method is applied to a first electronic device, which stores a master key of the first electronic device; the method includes: in response to a condition that satisfies an offline lookup function, generating at least two derived key pairs based on the master key of the first electronic device; sending a Bluetooth broadcast; the Bluetooth broadcast carries a first derived public key, which is one of the derived public keys in the at least two derived key pairs; the Bluetooth broadcast is used to trigger a second electronic device that receives the Bluetooth broadcast to upload a first location of the second electronic device to a first server.

9. The method according to claim 8, characterized in that, The conditions for the offline search function include: not being connected to the Internet and the duration of not being connected to the Internet exceeds a time threshold, or not being connected to the Internet, having a battery level below a battery level threshold, and the duration of not being connected to the Internet and having a battery level below a battery level threshold exceeds a time threshold.

10. A device location method, characterized in that, The method is applied to a second electronic device, which has activated an offline search function; the method includes: in response to receiving a Bluetooth broadcast carrying a first derived public key sent by the first electronic device, obtaining a first location of the second electronic device; and uploading the first location and the first derived public key to a first server.

11. The method according to claim 10, characterized in that, The method further includes: generating a temporary key pair in response to receiving the Bluetooth broadcast sent by the first electronic device; before uploading the first location and the first derived public key to the first server, the method further includes: encrypting the location of the second electronic device based on the first derived public key and the temporary private key in the temporary key pair; wherein the first location sent by the second electronic device to the first server is the encrypted location; the method further includes: uploading the temporary public key in the temporary key pair to the first server.

12. A device location method, characterized in that, The method, applied to a third electronic device, includes: in response to a user's triggering operation, obtaining a master key of a first electronic device; generating at least two derived key pairs based on the master key of the first electronic device; uploading a second derived public key to a first server; the second derived public key being a derived public key from the at least two derived key pairs generated by the third electronic device; the second derived public key being used by the first server to find a matching derived public key based on the second derived public key; obtaining location information corresponding to a target derived public key matched based on the second derived public key sent by the first server; and determining the historical location of the first electronic device based on the location information.

13. An electronic device, characterized in that, The electronic device includes: a processor, a memory, and a computer program stored in the memory; the memory is coupled to the processor; when the electronic device is running, the processor executes the computer program to implement the method as described in any one of claims 8-12.

14. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor of an electronic device, implements the method as described in any one of claims 8-12.

15. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method as described in any one of claims 8-12.

Images