Methods and related equipment for data transmission for service continuity
By using IRK and LTK at the application layer to achieve secure pairing and data encryption between devices, the problem of insufficient data transmission security in cross-device collaborative operations is solved, and universality and security are achieved between devices with different operating systems.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-06-30
- Publication Date
- 2026-04-03
AI Technical Summary
In existing technologies, cross-device collaborative operations between devices have limitations in key negotiation and data transmission, resulting in insufficient data transmission security and making them unusable across devices with different operating systems.
Data transmission is protected by application-layer IRK, service broadcast key and application-layer LTK. Secure pairing and data encryption between devices are achieved through application-layer protocols, avoiding reliance on Bluetooth protocol's OOB capability and MAC address read permission.
It achieves secure and universal data transmission between devices operating systems, improves the security of data transmission between devices, and avoids device identification leakage and tracking.
Smart Images

Figure CN115567921B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communications, and more specifically, to a method for data transmission of service continuity and related equipment. Background Technology
[0002] Currently, for operating systems of smart terminals (such as Android, Windows, HarmonyOS, etc.), different electronic devices within the network can discover and control each other, such as controlling the startup, binding, and cross-device collaborative operation of peer devices.
[0003] Cross-device collaborative work, also known as application migration, business continuity, or handoff, refers to transferring data of an application running on electronic device A to electronic device B logged in with the same account. The same application on electronic device B continues the running state of the application on electronic device A. That is, when an application is running on electronic device A, after the application data is migrated from electronic device A to electronic device B, the application on electronic device B continues the state or extent of running on electronic device A. The whole process is imperceptible to the user, and the user will not perceive any lag or stuttering in the application.
[0004] Currently, cross-device collaborative operations require key negotiation between devices to ensure data transmission security. However, both the key negotiation process and the encryption of data transmission using the negotiated key have limitations and lack universality, resulting in compromised data transmission security and reduced security during business continuity. Summary of the Invention
[0005] This application provides a method and related equipment for service continuity data transmission, which protects near-field communication (such as Bluetooth) between trusted devices by using the terminal's application layer IRK, service broadcast key (such as a Handoff key), and application layer LTK. This ensures data security and device anti-tracking. Application-layer IRK, service broadcast key, and application-layer LTK do not rely on Bluetooth's OOB capabilities or underlying communication protocol capabilities (such as Bluetooth's OOB and MAC address read permissions). They can be implemented directly at the application layer protocol level, thus enabling their use on Android devices, Windows devices, and other near-field communication protocols (such as Bluetooth and Wi-Fi). This improves versatility while ensuring data transmission security.
[0006] In a first aspect, a method for transmitting data for service continuity is provided. This method is applied to a service continuity system, which includes a first terminal and a second terminal. The first terminal and the second terminal are logged into the same account or mutually trusted accounts. The method includes: the first terminal sending a broadcast message to the second terminal, the broadcast message including the application-layer device identifier of the first terminal and a service continuity event; the application-layer device identifier of the first terminal being encrypted by the first terminal's application-layer identity resolution key (IRK) or a shared application-layer IRK; and the service continuity event being encrypted by the first terminal's service broadcast key or a shared service broadcast key; the second terminal decrypting the application-layer device identifier of the first terminal using the first terminal's application-layer IRK or a shared application-layer IRK to determine that the first terminal is a trusted device; and the second terminal decrypting the service continuity event using the first terminal's service broadcast key or a shared service broadcast key.
[0007] The first aspect provides a method for data transmission during service continuity. It protects the application-layer device identifier in Bluetooth broadcast messages using an application-layer IRK to prevent leakage of the sender's device identifier and to prevent attackers from tracking the sender's device through the device identifier. It encrypts and protects the service status (such as Handoff status or other data related to the service scenario) in Bluetooth broadcast messages using an application-layer service broadcast key to prevent leakage of service data in broadcast messages. Finally, it encrypts and protects the service data transmitted during the Bluetooth connection using an application-layer LTK to prevent leakage of service data. This approach improves versatility while ensuring data transmission security.
[0008] For example, the accounts (such as Huawei accounts) that a user logs into on the first terminal and the second terminal can be the same account or two different accounts. However, these two different accounts trust each other and allow the devices logged into by the accounts to automatically continue services. For example, the two accounts may belong to the same household, or the two accounts may have authorized each other to continue services.
[0009] In one possible implementation of the first aspect, the application layer device identifier of the first terminal can be defined by the service layer or application layer on the first terminal and is related to the service or application. Different services or applications on the same device correspond to different application layer device identifiers.
[0010] In this embodiment, the application layer device identifier of the first terminal is defined and managed by the application layer of the first terminal, such as being generated by a cross-device collaborative application using random numbers and persistently stored in the device. Traditional identifiers of the first terminal (e.g., the MAC address and IP address of the first terminal) are defined at the corresponding protocol layer. For example, the link layer defines the MAC address, which can be used to identify devices at the link layer and above (e.g., the network layer and application layer), and the network layer defines the IP address, which can be used to identify devices at the network layer and above (e.g., the transport layer and application layer). The application layer device identifier of the first terminal can be defined by the service layer or application layer on the first terminal, and is related to the service or application. Different services or applications on the same device correspond to different application layer device identifiers. The application layer device identifier of the first terminal is used to identify the identity or address of the first terminal, and is different from the link layer device identifier of the first terminal (e.g., MAC address, IP address, etc.).
[0011] For example, the application layer device identifier of the first terminal can be a random number of the UUID standard, or it can be the serial number of the first terminal, the IMEI of the first terminal, etc.
[0012] For example, there are several ways to encrypt the application layer device identifier of the first terminal using its application layer IRK or a shared application layer IRK. For instance, it can use Bluetooth's Random Resolvable Device Address method, in which the application layer IRKs of the first terminal and the second terminal are different. Another example is that the first terminal can use a symmetric key algorithm to encrypt its application layer device identifier.
[0013] For example, a business event (or business continuity event) can be understood as a Handoff event or Handoff state, and can be understood as a device activity event for cross-device collaborative business. It generally includes event type (such as opening an application, closing an application, opening a document, closing a document, etc.) and event operation object (such as application name, document name, etc.). For example, if a user opens a webpage using a browser on the first terminal, the business event is "open browser".
[0014] In one possible implementation of the first aspect, the method further includes: the first terminal sending service connection data to the second terminal, the service connection data being encrypted by the first terminal's application layer long-term key (LTK) or a shared application layer LTK; the second terminal decrypting the service connection data using the first terminal's application layer long-term key (LTK) or a shared application layer LTK; and the second terminal activating the service connection event on the second terminal based on the service connection data. In this implementation, the service data transmitted in the Bluetooth connection is encrypted and protected by the application layer LTK to prevent leakage of service data.
[0015] For example, the way the application layer LTK of the first terminal or the shared application layer LTK encrypts the connection service data can be by using a symmetric encryption algorithm to encrypt the data, such as AES-CBC, AES-GCM or Chacha20.
[0016] In one possible implementation of the first aspect, the system further includes a server, and the method further includes: the first terminal generating a shared application layer IRK, a shared service broadcast key, and a shared application layer LTK; the first terminal sending the shared application layer IRK, the shared service broadcast key, the shared application layer LTK, and the first terminal's account authentication credentials to the server; after the server successfully authenticates the first terminal's account authentication credentials, the server sending the shared application layer IRK, the shared service broadcast key, and the shared application layer LTK to the second terminal. In this implementation, the pairing between devices and the negotiation of IRK, LTK, and service broadcast key are completed by the server, which does not rely on the Bluetooth protocol's OOB capability or the underlying communication protocol capabilities of the device (such as Bluetooth's OOB and MAC address read permissions). It can be implemented directly at the application layer protocol, and therefore can be used on Android devices, Windows devices, and other near-field communication protocols (such as Wi-Fi), improving versatility while ensuring data transmission security.
[0017] For example, the account authentication credentials of the first terminal can be the first terminal's access token or session ID, etc.
[0018] In one possible implementation of the first aspect, the system further includes a server, and the method further includes: a first terminal generating an application layer IRK, a service broadcast key, and an application layer LTK; the first terminal sending its application layer IRK, service broadcast key, application layer LTK, account authentication credentials, and application layer device identifier to the server; and after the server authenticates the account authentication credentials of the first terminal, the server sending its service broadcast key, application layer LTK, application layer IRK, and application layer device identifier to a second terminal.
[0019] In one possible implementation of the first aspect, the system further includes a server, and the method further includes: a first terminal generating the shared application layer IRK and a shared application layer temporary key TK; the first terminal sending the shared application layer IRK, the shared application layer TK, and the account authentication credentials of the first terminal to the server; after the server authenticates the account authentication credentials of the first terminal, the server sending the shared application layer IRK and the shared application layer TK to a second terminal.
[0020] In one possible implementation of the first aspect, the system further includes a server, and the method further includes: a first terminal generating an application layer IRK and an application layer temporary key TK; the first terminal sending its application layer IRK, application layer TK, account authentication credentials, and application layer device identifier to the server; and after the server authenticates the account authentication credentials of the first terminal, the server sending its application layer IRK, application layer TK, and application layer device identifier to a second terminal.
[0021] In one possible implementation of the first aspect, the method further includes: a first terminal generating a service broadcast key; the first terminal and a second terminal negotiating an application layer LTK or a shared application layer LTK based on the first terminal's application layer TK or the shared application layer TK; and the first terminal and the second terminal exchanging the first terminal's service broadcast key and the second terminal's service broadcast key using the first terminal's application layer LTK or the shared application layer LTK. In this implementation, the negotiation of the service broadcast key (such as a handoff key) and the application layer LTK is performed during near-field communication between devices, eliminating the need for server involvement. The two devices directly negotiate the service broadcast key and the application layer LTK during near-field communication, resulting in higher security.
[0022] In one possible implementation of the first aspect, the first terminal sends service connection data to the second terminal, including: the first terminal sends service connection data to the second terminal via Bluetooth or Wi-Fi connection.
[0023] In one possible implementation of the first aspect, the service broadcast key is a Handoff key.
[0024] Secondly, a method for transmitting service continuity data is provided. This method is applied to a first terminal and includes: the first terminal sending a broadcast message to a second terminal, the broadcast message including the application layer device identifier of the first terminal and a service continuity event; the application layer device identifier of the first terminal being encrypted by the application layer identity resolution key IRK of the first terminal or a shared application layer IRK; and the service continuity event being encrypted by the service broadcast key of the first terminal or a shared service broadcast key; the first terminal sending service continuity data to the second terminal, the service continuity data being encrypted by the application layer long-term key LTK of the first terminal or a shared application layer LTK.
[0025] The second aspect provides a method that protects the application-layer device identifier in Bluetooth broadcast messages using an application-layer IRK, preventing the sender's device identifier from being leaked and preventing attackers from tracking the sender's device through the device identifier. It also encrypts and protects the service status (such as Handoff status or other data related to the service scenario) in Bluetooth broadcast messages using a service broadcast key, preventing the leakage of service data in broadcast messages. Finally, it encrypts and protects the service data transmitted in the Bluetooth connection using an application-layer LTK, preventing the leakage of service data. This approach improves versatility while ensuring data transmission security.
[0026] In one possible implementation of the second aspect, the method further includes: the first terminal generating the shared application layer IRK, the shared service broadcast key, and the shared application layer LTK; the first terminal sending the shared application layer IRK, the shared service broadcast key, the shared application layer LTK, and the account authentication credentials of the first terminal to the server;
[0027] In one possible implementation of the second aspect, the method further includes: the first terminal generating an application layer IRK, a service broadcast key, and an application layer LTK; and the first terminal sending the application layer IRK, the service broadcast key, the application layer LTK, the account authentication credentials, and the application layer device identifier to the server.
[0028] In one possible implementation of the second aspect, the method further includes: the first terminal generating the shared application layer IRK and the shared application layer temporary key TK; the first terminal sending the shared application layer IRK, the shared application layer TK, and the account authentication credentials of the first terminal to the server.
[0029] In one possible implementation of the second aspect, the method further includes: the first terminal generating an application layer IRK and an application layer temporary key TK; the first terminal sending the application layer IRK, the application layer TK, the account authentication credentials, and the application layer device identifier to the server.
[0030] In one possible implementation of the second aspect, the method further includes: a first terminal generating a service broadcast key for the first terminal; the first terminal and the second terminal negotiating an application layer LTK or a shared application layer LTK based on the first terminal's application layer TK or the shared application layer TK; and the first terminal and the second terminal exchanging the first terminal's service broadcast key and the second terminal's service broadcast key using the first terminal's application layer LTK or the shared application layer LTK.
[0031] In one possible implementation of the second aspect, the first terminal sends service connection data to the second terminal, including: the first terminal sends service connection data to the second terminal via Bluetooth or Wi-Fi connection.
[0032] In one possible implementation of the second aspect, the application layer device identifier of the first terminal includes at least one of the first terminal's Universally Unique Identifier (UUID), the first terminal's serial number, and the first terminal's International Mobile Equipment Identity (IMEI).
[0033] Thirdly, a communication device is provided, which includes units for performing the steps of the second aspect or any possible implementation of the second aspect above.
[0034] Fourthly, a communication device is provided, comprising at least one processor and a memory coupled together, the memory storing program instructions that, when executed by the processor, perform the methods of the second aspect or any two possible implementations of the second aspect.
[0035] Fifthly, a communication device is provided, comprising at least one processor and interface circuitry, wherein the at least one processor is configured to execute the method of the second aspect above or any possible implementation thereof.
[0036] Sixthly, a terminal device is provided, which includes any one of the communication devices provided in the third, fourth, or fifth aspects described above.
[0037] In a seventh aspect, a communication device is provided, the communication device including at least one processor and a memory coupled together, the processor and the memory storing program instructions, which, when executed by the processor, execute the method performed by a second terminal in the first aspect or any possible implementation of the first aspect.
[0038] Eighthly, a system for data transmission for business continuity is provided. The system includes a first terminal and a second terminal. The first terminal and the second terminal log in to the same account or mutually trusted accounts. The first terminal is used to execute the method executed by the first terminal in any possible implementation of the first aspect above or any possible implementation of the first aspect above, and the second terminal is used to execute the method executed by the second terminal in any possible implementation of the first aspect above or any possible implementation of the first aspect above.
[0039] Optionally, the system for connecting data transmission in this service also includes a server, which is used to execute the methods performed by the server in any possible implementation of the first aspect or any aspect of the first aspect.
[0040] Ninth aspect, a computer program product is provided, the computer program product comprising a computer program, which, when executed by a processor, is used to perform a method in the first aspect or any possible implementation thereof, or to perform a method in the second aspect or any possible implementation thereof.
[0041] In a tenth aspect, a computer-readable storage medium is provided, wherein a computer program is stored therein, which, when executed, is used to perform a method in the first aspect or any possible implementation thereof, or to perform a method in the second aspect or any possible implementation thereof.
[0042] Eleventhly, a chip is provided, comprising: a processor for calling and running a computer program from a memory, causing a communication device on which the chip is installed to perform the method of the first aspect or any possible implementation thereof, or to perform the method of the second aspect or any possible implementation thereof. Attached Figure Description
[0043] Figure 1 This is a schematic diagram illustrating a service continuity scenario applicable to an embodiment of this application.
[0044] Figure 2This is a schematic flowchart illustrating the process of automatic authentication and key negotiation between devices A and B based on the same account login status in related technologies.
[0045] Figure 3 A schematic diagram of a communication system applicable to embodiments of this application.
[0046] Figure 4 This is a schematic diagram of an example terminal software architecture provided in this application.
[0047] Figure 5 This is a schematic flowchart illustrating a method for transmitting data for service continuity provided in this application.
[0048] Figure 6 This is a schematic flowchart illustrating an example of the process by which a first terminal and a second terminal negotiate the application layer IRK, the service broadcast key, and the application layer LTK, as provided in this application.
[0049] Figure 7 This is an example of a schematic interface diagram provided in this application for displaying a service connection icon to the user.
[0050] Figure 8 This is a schematic flowchart illustrating another example of a service continuity data transmission method provided in this application.
[0051] Figure 9 This is another example of a schematic flowchart provided in this application of the process by which a first terminal and a second terminal negotiate the application layer IRK, the service broadcast key, and the application layer LTK.
[0052] Figure 10 This is a schematic block diagram of an example terminal provided in an embodiment of this application.
[0053] Figure 11 This is a schematic block diagram of an example chip system provided in an embodiment of this application. Detailed Implementation
[0054] The technical solutions in this application will now be described with reference to the accompanying drawings.
[0055] In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.
[0056] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.
[0057] Furthermore, various aspects or features of this application can be implemented as methods, apparatus, or articles of manufacture using standard programming and / or engineering techniques. The term "article of manufacture" as used herein encompasses a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). Additionally, the various storage media described herein may represent one or more devices and / or other machine-readable media for storing information. The term "machine-readable medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.
[0058] Various aspects or features of this application can be implemented as methods, apparatus, or articles of manufacture using standard programming and / or engineering techniques. As used herein, the term "article of manufacture" encompasses a computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). Additionally, the various storage media described herein may represent one or more devices and / or other machine-readable media for storing information. The term "machine-readable medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.
[0059] Currently, for operating systems of smart terminals (such as Android, Windows, HarmonyOS, etc.), different electronic devices within the network can discover and control each other's electronic devices, such as controlling the startup, binding, and application migration of the other device.
[0060] Application migration, also known as cross-device collaboration, business continuity, or handoff, refers to transferring data from an application running on device A to device B, which is logged into the same account. The same application on device B continues the running state of the application on device A. In other words, when an application is running on device A, and its data is migrated to device B, the application continues running on device B in the same state or at the same level as it was running on device A. The entire process is seamless for the user, who will not experience any lag or stuttering.
[0061] For example, Figure 1 The diagram shown illustrates a typical service continuity scenario. Figure 1 As shown in Figure a, when a user browses a website on a Mate40 phone, and brings the Mate40 close to a tablet logged into the same account, a service connection icon is displayed on the tablet. Figure 1 As shown in Figure b, this is used to prompt the user to continue service. After the user clicks "Continue Mate40," the webpage the user was browsing on the phone can be resumed on the user's tablet, displaying the webpage viewed on the phone again. Figure 1 As shown in Figure c.
[0062] For example, when a user is editing a document on their mobile phone and brings the phone close to a computer logged in with the same account, a service connection icon appears on the computer, prompting the user to connect the service. After the user confirms the connection, they can continue editing the document on the computer.
[0063] Currently, the automatic service handover process between devices logged in with the same account mainly includes the following two steps:
[0064] The first step: Devices that support automatic connection (such as the phone in the example above) periodically and continuously send Bluetooth broadcast messages, broadcasting the device's activity status. The device's activity status can be understood as the running status of the application that needs to be connected. For example, in... Figure 1 In the example shown, the activity state of the Mate40 mobile phone is: the browser is running or the user is browsing web pages using the browser. In this application, the device's activity state can also be referred to as the device's Handoff state, the device's Handoff event, or the device's business event.
[0065] The second step: Other devices logged in with the same account (such as the tablet in the example above) establish a Bluetooth connection with the device that sent the broadcast message after receiving the broadcast message. After the devices complete identity authentication, they transmit automatic resume messages and business data between each other via Bluetooth.
[0066] During the automatic service resuming process between devices, firstly, the Bluetooth broadcast messages continuously and periodically sent by the device need to prevent tracking of the device and leakage of its activity status. Secondly, the automatic resuming messages and service data must be end-to-end encrypted to prevent eavesdropping by other devices.
[0067] To meet the above security and privacy requirements, the two devices need to be securely paired before connecting services. This means that authentication and key negotiation between the devices are automatically completed based on the same account login status, protecting message security and privacy during the connection process. The pairing process does not require user intervention.
[0068] Currently, in related technologies, secure configuration between devices is mainly achieved through the following methods. Device A and Device B log in using the same account, and the main process is as follows: Figure 2 As shown, including:
[0069] S101, Device A and Device B negotiate a temporary key (TK) through the server and each save the TK.
[0070] For example, device A and device B can negotiate TK (Trust Key) through Apple's Push Notification Service (APNs) and Apple Identity Service (IDS) provided by the server.
[0071] S102, when device A and device B are close to each other, they pair and bind using Bluetooth Low Energy (BLE) out-of-band (OOB) transmission, using TK for authentication and encryption of pairing messages. Furthermore, they exchange the identity resolving key (IRK) and long-term key (LTK) between the devices using TK (i.e., TK encryption). Here, LTK and IRK are the link layer LTK and link layer LTK respectively, and TK is the link layer TK.
[0072] S103, after device A and device B are paired, device A generates a Handoff key for device A.
[0073] S104, after device A and device B are paired, device B generates device B's Handoff key.
[0074] S105, Device A periodically sends Bluetooth broadcast messages. These broadcast messages include Device A's Handoff status (e.g., the user currently browsing a webpage in a browser). Device A's Handoff status is encrypted using its Handoff key to prevent interception and tracking of the device's activity. Furthermore, Device A's Media Access Control (MAC) address in the broadcast message is encrypted using Device A's IRK to prevent attackers from tracking the device's movement based on its MAC address.
[0075] For example, the random resolvable device address of device A can be encrypted using IRK. Device A's random resolvable device address changes every period (e.g., 15 minutes), and in each period, device A generates a random number prand. Let h = hash(IRK, prand), where hash represents the hash algorithm, and h = hash(IRK, prand) means h is generated using the IRK and prand parameters through a hash algorithm. Then, device A's random resolvable device address is h||prand. After device B scans for this type of Bluetooth address, it uses the saved IRK of device A and the prand from device A's address to perform the same hash operation, and compares the result with the hash field in the address. If they match, device B determines device A's address.
[0076] S106 Since device B does not have the Handoff key of device A, device B cannot parse the Bluetooth broadcast message. In this case, device A and device B establish a BLE connection. Based on the BLE connection, the LTK is used to exchange the Handoff key between the devices (i.e., the Handoff key is encrypted using the LTK).
[0077] S107, Device B uses Device A's Handoff key to decrypt Device A's Handoff state.
[0078] S108, after device B obtains the Handoff status of device A, device B displays a connection prompt icon.
[0079] S109, the user clicks the continue icon.
[0080] S110, after the user clicks the connection icon, device A transmits handoff connection data (such as the URL address accessed by the user in the browser) to device B via BLE connection. The handoff connection data is protected by LTK encryption of device A.
[0081] S111, Device B uses Device A's LTK to decrypt the Handoff connection data. Device B then completes the service connection based on the obtained Handoff connection data, such as opening a browser.
[0082] However, the above methods rely on Bluetooth's OOB technology for pairing and binding between devices, and on the device's Random Resolvable device address for MAC address tracking prevention. But when used in Android systems, these two technologies have limitations and cannot cover all Android devices.
[0083] The first limitation is that the Bluetooth protocol stack of the Android system has a method to create a bond out of bound (OOB), but this method is not open. Systems prior to Android 9.0 can call it via reflection, but systems after Android 9.0 cannot call it via reflection. Therefore, pairing based on Bluetooth OOB technology cannot be implemented.
[0084] The second limitation: Obtaining the device's Bluetooth MAC address on an Android device requires system permissions. In Android 8.0 and above, ordinary applications cannot obtain the system's actual Bluetooth MAC address; only pre-installed applications can obtain the device's real Bluetooth MAC address. Applications installed after the device leaves the factory cannot obtain the device's real Bluetooth MAC address. Therefore, in the current Android system, the Bluetooth connection negotiation method used by factory-installed applications is unavailable.
[0085] In view of this, this application provides a method for data transmission for service continuity, which protects near-field communication (such as Bluetooth) between trusted devices by using the application layer IRK, service broadcast key (such as a Handoff key), and application layer LTK of the device (e.g., a terminal). This technology ensures data security and device anti-tracking. Application-layer IRK, service broadcast key, and application-layer LTK do not rely on Bluetooth's OOB capabilities. Device pairing and binding are completed at the device's application layer, independent of underlying communication protocol capabilities (such as Bluetooth's OOB and MAC address read permissions). Therefore, it can be implemented directly at the application layer protocol level, making it usable on Android devices, Windows devices, and other near-field communication protocols (such as Bluetooth and Wi-Fi). This improves versatility while ensuring data transmission security.
[0086] The following examples illustrate the method for data transmission for service continuity provided in this application.
[0087] Figure 3 The diagram shown is an example of a communication system 200 applicable to an embodiment of this application. For example... Figure 3 As shown, the system includes: a first terminal 210, a second terminal 220, and a server 230. The server 230 provides authentication and a secure transmission channel for pairing and key negotiation between the first terminal 210 and the second terminal 220. Figure 3 In the example shown, the first terminal 210 is a smartphone used by the user, and the second terminal 220 is a tablet computer used by the user. Of course, Figure 3 The communication system shown may also include other terminal devices. This application does not impose any limitations.
[0088] For example, in the embodiments of this application, the terminal device may include: smartphones, smart TVs, large-screen devices, tablet computers, personal digital assistants (PDAs), handheld computer communication devices, speakers, in-vehicle devices (also known as vehicle-mounted systems), laptops, ultra-mobile personal computers (UMPCs), handheld computers, netbooks, wearable electronic devices, virtual reality devices, and other IoT (Internet of Things) devices, handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, terminal devices in 5G networks, or terminal devices in future evolved public land mobile networks (PLMNs), etc., and the embodiments of this application are not limited thereto.
[0089] It should be understood that Figure 3 The examples shown should not be construed as limiting the scope of the embodiments in this application.
[0090] The first terminal 210 and the second terminal 220 can be interconnected through a communication network. For example, this communication network can be a wired network or a wireless network. For instance, the communication network can be a local area network (LAN) or a wide area network (WAN), such as the Internet. The aforementioned communication network can be implemented using any known network communication protocol, which can be various wired or wireless communication protocols, such as Ethernet, Universal Serial Bus (USB), FireWire, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Bluetooth, Wireless Fidelity (Wi-Fi), Wi-Fi Direct (Wi-Fi P2P) connection, NFC, Voice Over Internet Protocol (VoIP), communication protocols supporting network slicing architecture, or any other suitable communication protocol.
[0091] The first terminal 210 and the second terminal 220 can also communicate with the server 230 through the aforementioned communication network.
[0092] In other words, the various devices within the communication system can form a network (i.e., networking) according to certain communication protocols and networking strategies, enabling the various terminals within the audio system to communicate with each other.
[0093] Optionally, in this application, the first terminal needs to transmit its business data to the second terminal, and the business data of the first terminal involves user privacy issues. Therefore, before the first terminal sends application data to the second terminal, a trusted relationship must be established between the first terminal and the second terminal, that is, a device-level authentication relationship must be established between the first terminal and the second terminal.
[0094] In this application, a device-level authentication relationship can be established between the first terminal and the second electronic device using various different methods. The embodiments in this application are not limited thereto.
[0095] In one possible application scenario, a user uses an application (e.g., a document editing application, a browser application, an audio and video playback application, etc.) on a smartphone. The user wants to migrate the data of that application to a tablet so that the second terminal can continue using the application. In this process, the service continuity data transmission method provided in this application can be used.
[0096] Figure 4 The diagram shown is a schematic representation of an example terminal device software architecture provided in this application. Figure 4 As shown, the terminal's system architecture includes: application layer, transport layer, network layer, link layer, and physical layer.
[0097] The application layer refers to modules that implement specific business logic such as cross-device collaboration and handoff. It provides application interfaces for computer users and also directly provides users with various network services.
[0098] The transport layer establishes end-to-end links between hosts. Its role is to provide reliable and transparent end-to-end data transmission services for upper-layer protocols, including handling error control and flow control. This layer shields higher layers from the details of lower-layer data communication, allowing higher-layer users to see only a reliable, user-controllable, and configurable host-to-host data path between two transport entities.
[0099] The network layer establishes connections between two nodes through IP addressing, selects appropriate routes and switching nodes for packets sent from the transport layer at the source, and correctly transmits them to the network layer at the destination according to the address.
[0100] The link layer includes modules for service discovery, logical link control, and adaptation protocols for wireless protocols such as Bluetooth, Bluetooth Low Energy, and Wi-Fi. It is used to combine bits into bytes, then bytes into frames, access the medium using link layer addresses (MAC addresses for Ethernet), and perform error detection.
[0101] The physical layer includes hardware modules that implement wireless protocols such as Bluetooth, Bluetooth Low Energy, and Wi-Fi. It is responsible for wireless signal transmission and reception, data transmission, and conversion, such as baseband and Bluetooth transceivers. The actual final signal transmission is achieved through the physical layer. Bit streams are transmitted through physical media. Levels, speeds, and cable pinouts are defined. Common devices include hubs, repeaters, modems, network cables, twisted-pair cables, and coaxial cables. These are all transmission media for the physical layer.
[0102] It should be understood that Figure 4 This is merely an example and should not impose any limitations on the architecture of the terminal in this application. For example, in other embodiments of this application, the terminal system architecture may also adopt a similar approach. Figure 4 The examples shown may depict different hierarchical structures, or each layer may include more or fewer modules, or combinations of various module types. This application does not impose limitations on the embodiments described herein.
[0103] The following section describes the service continuity data transmission method provided in this application, using specific scenarios as examples.
[0104] Assumptions: A user has logged into accounts (e.g., Huawei accounts) on both a first terminal and a second terminal, and has enabled the service continuity function on both terminals. The user opens an application that supports service continuity on the first terminal (e.g., a browser), and wants to continue using that application on the second terminal (e.g., opening a webpage browsed on the first terminal).
[0105] Figure 5 This is a schematic flowchart illustrating a method for data transmission continuity in a service connection scenario provided in this application, as shown below. Figure 5 As shown, the method includes:
[0106] S301: Users log in to their account (such as a Huawei account) on the first terminal. For example, users enter their username and password on the first terminal and click "Account Login".
[0107] S302, the first terminal sends an account login request to the server. The account login request includes the username and password entered by the user.
[0108] S303, the server processes the account login request sent by the first terminal and verifies the username and password in the login request. If the verification passes, the server returns a login success result to the first terminal; otherwise, it returns a login failure result to the first terminal.
[0109] S304, users log in to their account (such as a Huawei account) on a second terminal. For example, a user enters their username and password on the second terminal and clicks "Account Login".
[0110] It should be understood that in this application, the accounts (such as Huawei accounts) that a user logs into on the first terminal and the second terminal can be the same account or two different accounts. However, these two different accounts trust each other and allow the devices logged into by the accounts to automatically continue services. For example, the two accounts may belong to the same household, or the two accounts may have authorized each other to continue services. This application does not impose any restrictions on this.
[0111] The S305 second terminal sends an account login request to the server, which includes the username and password entered by the user.
[0112] S306: The server processes the account login request sent by the second terminal, verifies the username and password in the request, and returns a login success result to the second terminal if the verification is successful; otherwise, it returns a login failure result to the second terminal.
[0113] S301 to S306 can be understood as the specific process of account login.
[0114] S307, the first terminal and the second terminal negotiate the application layer IRK, the service broadcast key (e.g., the Handoff key), and the application layer LTK.
[0115] For specific steps regarding S307, please refer to [link / reference]. Figure 6 As shown. Wherein, if the first terminal and the second terminal use the same (or shared) application layer IRK, service broadcast key, and application layer LTK, then S3071a to S3073a are executed; if the first terminal and the second terminal use their own application layer IRK, service broadcast key, and application layer LTK respectively, then S3071b to S3076b are executed.
[0116] S3071a, the first terminal generates an application layer IRK (i.e., a shared application layer IRK), a service broadcast key (i.e., a shared service broadcast key), and an application layer LTK (i.e., a shared application layer LTK).
[0117] S3072a, the first terminal sends a first request message to the server. The first request message includes: a shared application layer IRK, a shared service broadcast key, a shared application layer LTK, and the first terminal's account authentication credentials (such as an access token, session ID, etc.).
[0118] S3073a, the server authenticates the account authentication credentials of the first terminal. After successful authentication, the server sends the application layer IRK, service broadcast key, and application layer LTK generated by the first terminal to the second terminal.
[0119] It should be understood that, in this application, the server may also send the application layer IRK, service broadcast key, and application layer LTK generated by the first terminal to other devices that log in with the same account as the first terminal, or to other devices that have mutually trusted accounts with the account logged in by the first terminal (e.g., devices logged in with two accounts under the same household). This application does not impose any limitations on these.
[0120] S3071b, the first terminal generates its own application layer IRK (i.e., the first terminal's application layer IRK), service broadcast key (i.e., the first terminal's service broadcast key), and application layer LTK (i.e., the first terminal's application layer LTK).
[0121] S3072b, the first terminal sends a second request message to the server. The second request message includes: the first terminal's application layer IRK, the first terminal's service broadcast key, the first terminal's application layer LTK, the first terminal's account authentication credentials (e.g., access token, session ID, etc.) and the first terminal's application layer device identifier.
[0122] It should be understood that, in this embodiment, the application layer device identifier of the first terminal is defined and managed by the application layer of the first terminal, such as being generated by a cross-device collaborative application through random numbers and persistently stored in the device. Traditional identifiers of the first terminal (e.g., the MAC address and IP address of the first terminal) are defined at the corresponding protocol layer. For example, the link layer defines the MAC address, which can be used to identify devices at the link layer and above protocol layers (such as the network layer and application layer); the network layer defines the IP address, which can be used to identify devices at the network layer and above protocol layers (such as the transport layer and application layer).
[0123] In other words, in this application, the application layer device identifier of the first terminal can be defined by the service layer or application layer on the first terminal, and is related to the service or application. Different services or applications on the same device correspond to different application layer device identifiers. The application layer device identifier of the first terminal is used to identify the identity or address of the first terminal, and the application layer device identifier of the first terminal is different from the link layer device identifier of the first terminal (e.g., MAC address, IP address, etc.). For example, the application layer device identifier of the first terminal can be a random number of the universally unique identifier (UUID) standard, or it can be the serial number of the first terminal, the international mobile equipment identity (IMEI) of the first terminal, etc.
[0124] S3073b: The server authenticates the account authentication credentials of the first terminal. After successful authentication, the server sends the application layer IRK, service broadcast key, application layer LTK, and application layer device identifier of the first terminal generated by the first terminal to the second terminal.
[0125] It should be understood that in this application, the server may also send the application layer IRK, service broadcast key, application layer LTK, and application layer device identifier of the first terminal generated by the first terminal to other devices that log in with the same account as the first terminal, or to other devices whose accounts are mutually trusted accounts with the account logged in by the first terminal. This application does not impose any restrictions on these.
[0126] S3074b, the second terminal generates the second terminal's application layer IRK, the second terminal's service broadcast key (such as the Handoff key), and the second terminal's application layer LTK.
[0127] S3075b, the second terminal sends a third request message to the server. The third request message includes: the application layer IRK of the second terminal, the service broadcast key of the second terminal, the application layer LTK of the second terminal, the account authentication credentials of the second terminal (e.g., access token, session ID, etc.) and the application layer device identifier of the second terminal.
[0128] It should be understood that in this application, the application layer device identifier of the second terminal can be defined by the service layer on the second terminal to identify the identity or address of the second terminal. The application layer device identifier of the second terminal is different from the link device identifier of the second terminal (e.g., MAC address, IP address, etc.). For example, the application layer device identifier of the second terminal can be a random number according to the UUID standard, or it can be the serial number, IMEI, etc. of the second terminal.
[0129] S3076b: The server authenticates the account authentication credentials of the second terminal. After successful authentication, the server sends the application layer IRK, service broadcast key, application layer LTK, and application layer device identifier of the second terminal generated by the second terminal to the first terminal.
[0130] It should be understood that in this application, the server may also send the application layer IRK, service broadcast key, application layer LTK, and application layer device identifier of the second terminal generated by the second terminal to other devices that log in with the same account as the second terminal, or to other devices whose accounts are mutually trusted accounts with the account logged in by the second terminal. This application does not impose any restrictions on these.
[0131] Application layer IRK and application layer LTK differ from link layer IRK and link layer LTK. Application layer IRK is used to encrypt the application layer device identifier or address, while link layer IRK is used to encrypt the link layer device address (e.g., MAC address, IP address). Application layer LTK is used to encrypt application layer service data. Link layer IRK and link layer LTK are defined and generated at the protocol layer, while application layer IRK and application layer LTK are defined and generated at the application layer.
[0132] S308: Users open web pages using a browser on the first terminal; the browser is an application that supports business continuity.
[0133] S309, the first terminal sends a Bluetooth broadcast message, which includes: the application layer device identifier of the first terminal and service event (e.g., Handoff event) information. The application layer device identifier of the first terminal is encrypted using the first terminal's application layer IRK or a shared application layer IRK, and the service event information is encrypted using the first terminal's service broadcast key or a shared service broadcast key (e.g., Handoff key).
[0134] In this application, a business event (or business continuity event) can be understood as a Handoff event or Handoff state, and can be understood as a device activity event for cross-device collaborative business. It generally includes event type (such as opening an application, closing an application, opening a document, closing a document, etc.) and event operation object (such as application name, document name, etc.). For example, if a user opens a webpage using a browser on the first terminal, the business event is "open browser".
[0135] Optionally, in this embodiment, in S309, the broadcast message sent by the first terminal to the second terminal can also be a Wi-Fi broadcast message. This application does not impose any limitations on this.
[0136] Optionally, in this embodiment, the application layer IRK or shared application layer IRK of the first terminal can encrypt the application layer device identifier of the first terminal in various ways.
[0137] For example, the Random Resolvable Device Address (IRK) method of Bluetooth can be used. When using this method, the application layer IRKs corresponding to the first terminal and the second terminal are different.
[0138] For example, the first terminal can use a symmetric key algorithm to encrypt the application layer device identifier of the first terminal.
[0139] For example, the application layer device identifier of the first terminal can be encrypted using methods such as Advanced Encryption Standard (AES) or Hash-based Message Authentication Code (HMAC). When using this method, the Bluetooth broadcast message sent by the first terminal carries the encrypted device identifier of the first terminal. Here, the encrypted device identifier = AES / HMAC(Application Layer IRK, Application Layer Device Identifier, IV), where IV is the initialization vector (IV), also known as a random number, which needs to be updated periodically (e.g., every 15 minutes).
[0140] S310, after receiving the Bluetooth broadcast message, the second terminal uses the application layer IRK of the first terminal or a shared application layer IRK to parse the application layer device identifier of the first terminal.
[0141] For example, when the second terminal parses the application layer device identifier of the first terminal, it traverses the stored application layer device identifier, the IV carried in the Bluetooth broadcast message, and the stored application layer IRK (which may be different application layer IRKs for different devices or shared application layer IRKs) to calculate the device identifier ciphertext of the corresponding device. If the calculation result is equal to the device identifier ciphertext carried in the Bluetooth broadcast message, the device identity of the sender of the Bluetooth broadcast message is determined.
[0142] S311, after the second terminal correctly parses the application layer device identifier of the first terminal, the second terminal uses the service broadcast key of the first terminal or the shared service broadcast key (e.g., the Handoff key) to decrypt the service event information.
[0143] S312, the second terminal will display a service continuation prompt icon based on the type of service event.
[0144] For example, the service continuation prompt icon can Figure 7 As shown, this is used to prompt the user whether to allow service continuity on the second terminal. Assume the first terminal is a Huawei Mate 30 phone, the second terminal is phone B, and the first terminal needs to continue using a browser application on the second terminal. On the second terminal's interface, as shown... Figure 7As shown, phone B can display a pop-up window, which may include the message "HUAWEI MATE30 requests to continue the browser application on this device, do you agree?". The pop-up window may also include "Agree" and "Disagree" trust buttons. The "Disagree" button may also display a countdown (e.g., 14 seconds). If the user does not click any button when the countdown ends, the pop-up window will automatically disappear. In response to the user clicking the "Agree" button, phone B can then continue the browser application on the first device.
[0145] It should also be understood that, in the embodiments of this application, Figure 7 The interface diagrams shown are merely illustrative and should not impose any limitations on the interface displaying service connection prompt icons on the terminal in the embodiments of this application. For example, in other embodiments of this application, the icons on the terminal's displayed interface may include those that are larger than those shown in the diagrams. Figure 7 The interface shown may display more or fewer icons, or combine certain icons, or split certain icons, or different icons, or other forms of prompt icons or patterns. This application's embodiments are not limited to these specific examples.
[0146] S308 to S312 are the processes of the first terminal broadcast service state (e.g., Handoff state).
[0147] S313, the user clicks the service continuation icon on the second terminal.
[0148] S314: After clicking the service connection icon on the second terminal, the first terminal and the second terminal establish a Bluetooth connection.
[0149] S315, the first terminal sends connection service data (such as the URL of a webpage browsed by the user on the first terminal) to the second terminal via Bluetooth connection, wherein the connection service data is encrypted by the first terminal's application layer LTK or a shared application layer LTK.
[0150] Optionally, in S315, the method by which the application layer LTK of the first terminal or the shared application layer LTK encrypts the connection service data can use a symmetric encryption algorithm to encrypt the data, such as using AES Cipher Block Chaining (AES-CBC), AES Galois / Counter Mode (AES-GCM), or Chacha20, etc. This application does not impose any restrictions on this.
[0151] S316, the second terminal decrypts the connection service data based on the application layer LTK of the first terminal or a shared application layer LTK, and performs service connection on the second terminal based on the connection service data (e.g., displaying the webpage browsed by the user on the first terminal).
[0152] The service continuity data transmission method provided in this application protects the application layer device identifier in Bluetooth broadcast messages through application layer IRK, preventing the leakage of the sender's device identifier and preventing attackers from tracking the sender's device through the device identifier. It also encrypts and protects the service status (such as Handoff status or other data related to the service scenario) in Bluetooth broadcast messages through a service broadcast key (such as a Handoff key), preventing the leakage of service data in broadcast messages. Finally, it encrypts and protects the service data transmitted in the Bluetooth connection through application layer LTK, preventing the leakage of service data.
[0153] Furthermore, this application directly completes device pairing and IRK, LTK, and service broadcast key negotiation through the server, without relying on the Bluetooth protocol's OOB capability or the device's underlying communication protocol capabilities (such as Bluetooth's OOB and MAC address reading permissions). It can be implemented directly at the application layer protocol, and therefore can be used on Android devices, Windows devices, and other near-field communication protocols (such as Wi-Fi protocol), thus improving versatility while ensuring data transmission security.
[0154] Figure 8 Here is a schematic flowchart illustrating another example of a service continuity data transmission method provided in this application in the above scenario, as shown below. Figure 8 As shown, the method includes:
[0155] S401: Users log in to their account (such as a Huawei account) on the first terminal. For example, a user enters their username and password on the first terminal and clicks "Account Login".
[0156] S402, the first terminal sends an account login request to the server. The account login request includes the username and password entered by the user.
[0157] S403, the server processes the account login request sent by the first terminal and verifies the username and password in the login request. If the verification passes, the server returns a login success result to the first terminal; otherwise, it returns a login failure result to the first terminal.
[0158] S404: Users log in to their account (such as a Huawei account) on a second terminal. For example, a user enters their username and password on the second terminal and clicks "Account Login".
[0159] It should be understood that in this application, the accounts (such as Huawei accounts) that a user logs into on the first terminal and the second terminal can be the same account or two different accounts. However, these two different accounts trust each other and allow the devices logged into by the accounts to automatically continue services. For example, the two accounts may belong to the same household, or the two accounts may have authorized each other to continue services. This application does not impose any restrictions on this.
[0160] The S405 second terminal sends an account login request to the server, which includes the username and password entered by the user.
[0161] S406. The server processes the account login request sent by the second terminal, verifies the username and password in the request, and returns a login success result to the second terminal if the verification is successful, otherwise returns a login failure result to the second terminal.
[0162] S401 to S406 can be understood as the specific process of account login.
[0163] In S407, the first terminal and the second terminal negotiate the application layer IRK and application layer TK. For specific steps regarding S407, please refer to [link / reference needed]. Figure 9 As shown. Wherein, if the first terminal and the second terminal use the same (or shared) application layer IRK and application layer TK, then S4071a to S4073a are executed; if the first terminal and the second terminal use their own application layer IRK and application layer TK respectively, then S4071b to S4076b are executed.
[0164] S4071a, the first terminal generates application layer IRK (shared application layer IRK) and application layer TK (shared application layer TK).
[0165] S4072a, the first terminal sends a fourth request message to the server. The fourth request message includes: the shared application layer IRK, the shared application layer TK, and the first terminal's account authentication credentials (such as AccessToken, SessionID, etc.).
[0166] S4073a, the server authenticates the account authentication credentials of the first terminal. After successful authentication, the server sends the shared application layer IRK and shared application layer TK generated by the first terminal to the second terminal.
[0167] It should be understood that, in this application, the server may also send the shared application layer IRK and shared application layer TK generated by the first terminal to other devices that are logged into the same account as the first terminal, or to other devices whose accounts are mutually trusted with the first terminal (e.g., devices logged into by two accounts under the same household). This application does not impose any limitations on this.
[0168] S4071b, the first terminal generates its own application layer IRK (the first terminal's application layer IRK) and application layer TK (the first terminal's application layer TK).
[0169] S4072b, the first terminal sends a fifth request message to the server. The fifth request message includes: the first terminal's application layer IRK, the first terminal's application layer TK, the first terminal's account authentication credentials (e.g., AccessToken, SessionID, etc.) and the first terminal's application layer device identifier.
[0170] For example, the application layer device identifier of the first terminal can be a random number according to the UUID standard, or it can be the serial number, IMEI, etc. of the first terminal.
[0171] S4073b: The server authenticates the account authentication credentials of the first terminal. After successful authentication, the server sends the application layer IRK, application layer TK, and application layer device identifier of the first terminal generated by the first terminal to the second terminal.
[0172] It should be understood that in this application, the server may also send the application layer IRK, application layer TK, and application layer device identifier of the first terminal generated by the first terminal to other devices that log in with the same account as the first terminal, or to other devices that have mutual trust accounts with the account logged in by the first terminal. This application does not impose any restrictions on these.
[0173] S4074b, the second terminal generates its own application layer IRK (the application layer IRK of the second terminal) and application layer TK (the application layer TK of the second terminal).
[0174] S4075b, the first terminal sends a sixth request message to the server. The sixth request message includes: the application layer IRK of the second terminal, the application layer TK of the second terminal, the account authentication credentials of the second terminal (e.g., AccessToken, SessionID, etc.) and the application layer device identifier of the second terminal.
[0175] S4076b: The server authenticates the account authentication credentials of the second terminal. After successful authentication, the server sends the application layer IRK, application layer TK, and application layer device identifier of the second terminal generated by the second terminal to the first terminal.
[0176] It should be understood that in this application, the server may also send the application layer IRK, application layer TK, and application layer device identifier of the second terminal generated by the second terminal to other devices that log in with the same account as the second terminal, or to other devices whose accounts are mutually trusted accounts with the account logged in by the second terminal. This application does not impose any restrictions on these.
[0177] S407 can be understood as the specific process by which the first terminal and the second terminal negotiate the application layer key.
[0178] S408: Users open web pages using a browser on the first terminal. The browser is an application that supports business continuity.
[0179] S409, the first terminal generates its own service broadcast key. This service broadcast key is exclusively owned by the first terminal and cannot be shared; in other words, different terminals generate or have different service broadcast keys.
[0180] Optionally, the second terminal can also generate its own service broadcast key. This service broadcast key is exclusively owned by the second terminal and cannot be shared.
[0181] S410, the first terminal sends a Bluetooth broadcast message, which includes: the application layer device identifier of the first terminal and service event information (such as a Handoff event or Handoff state). The application layer device identifier of the first terminal is encrypted by the first terminal's application layer IRK or a shared application layer IRK, and the service event information is encrypted by the first terminal's service broadcast key (such as a Handoff key).
[0182] S411 After receiving the Bluetooth broadcast message, the second terminal uses the application layer IRK of the first terminal or a shared application layer IRK to parse the application layer device identifier of the first terminal.
[0183] If the second terminal does not obtain the service broadcast key and application layer LTK from the first terminal, then execute S412. Otherwise, execute S413 directly.
[0184] S412, the first terminal and the second terminal establish a Bluetooth connection and negotiate the application layer LTK and exchange the service broadcast key based on the application layer TK. The negotiation scheme can adopt a variety of methods.
[0185] For example, a similar approach to pairing in Bluetooth OOB out-of-band mode can be adopted, with the application layer TK as a symmetric key (in this approach, the application layer TK is a shared application layer TK). Using an algorithm and interaction process similar to Bluetooth, the first terminal and the second terminal negotiate the application layer LTK based on the application layer TK, and then exchange their service broadcast keys (such as the Handoff key) using the application layer LTK encryption method.
[0186] For example, the first and second terminals can negotiate the LTK using a key negotiation algorithm (such as DH (Diffie-Hellman) or an elliptic curve cryptography-based key exchange protocol (ECDH)). Here, the application layer TK is the public key of an asymmetric key algorithm (RSA or Elliptic Curve Cryptography (ECC)). (In this method, the application layer TK is not shared; each device has its own corresponding application layer TK). The private key corresponding to the application layer TK is stored separately on each device. The application layer LTK can be calculated using the following algorithm: LTK = ECDH / DH (the private key corresponding to the application layer TK of this device, and the application layer TK of the other device). Then, the business broadcast keys (such as the handoff key) of both parties are exchanged using encryption based on the application layer LTK.
[0187] S413, the second terminal decrypts the service event information using the service broadcast key of the first terminal or a shared service broadcast key (e.g., the Handoff key) obtained from the first terminal.
[0188] S414, the second terminal will display a service continuation prompt icon based on the type of service event.
[0189] S408 to S414 represent the process of the first terminal broadcast service state (Handoff state).
[0190] S415, the user clicks the service continuation icon on the second terminal.
[0191] S416, after clicking the service connection icon on the second terminal, the first terminal sends connection service data (such as the URL address of the webpage browsed by the user on the first terminal) to the second terminal via Bluetooth connection. The connection service data is encrypted by the negotiated application layer LTK.
[0192] S417, the second terminal decrypts the connection service data according to the negotiated application layer LTK, and performs service connection on the second terminal according to the connection service data (e.g., displaying the webpage browsed by the user on the first terminal).
[0193] The service continuity data transmission method provided in this application protects the application layer device identifier in Bluetooth broadcast messages through application layer IRK, preventing the leakage of the sender's device identifier and preventing attackers from tracking the sender's device through the device identifier. It also encrypts and protects the service status (such as the Handoff status) in Bluetooth broadcast messages through a service broadcast key (such as a Handoff key), preventing the leakage of service data in the broadcast messages. Finally, it encrypts and protects the service data transmitted in the Bluetooth connection through application layer LTK, preventing the leakage of service data.
[0194] Furthermore, this application completes the negotiation and exchange of application layer IRK, application layer LTK, and service broadcast keys through the near-field communication process between the server and the device. It does not rely on the OOB capability of the Bluetooth protocol, nor on the underlying communication protocol capabilities of the device (such as Bluetooth OOB and MAC address reading permissions). It can be implemented directly on the application layer protocol, so it can be used on Android devices, Windows devices, and other near-field communication protocols (such as Wi-Fi protocol), thus improving versatility while ensuring data transmission security.
[0195] It should be understood that the above description is merely to help those skilled in the art better understand the embodiments of this application, and is not intended to limit the scope of the embodiments of this application. Based on the examples given above, those skilled in the art can obviously make various equivalent modifications or changes. For example, some steps in the above methods may be unnecessary, or new steps may be added. Alternatively, any combination of two or more of the above embodiments may be used. Such modifications, changes, or combinations also fall within the scope of the embodiments of this application.
[0196] It should also be understood that the methods, situations, categories, and classifications of embodiments in this application are for the convenience of description only and should not constitute a special limitation. Various methods, categories, situations, and features in embodiments can be combined without contradiction.
[0197] It should also be understood that the various numerical designations used in the methods of the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0198] It should also be understood that the above description of the embodiments of this application focuses on highlighting the differences between the various embodiments. Any similarities or differences not mentioned can be referred to each other. For the sake of brevity, they will not be repeated here.
[0199] The above combination Figures 1-9An embodiment of the service continuity data transmission method provided in this application has been described. The terminal device and server provided in this application embodiment are described below.
[0200] This embodiment can divide the various devices (including the first terminal, the second terminal, and the server) into functional modules according to the above method. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.
[0201] It should be noted that the relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.
[0202] The terminal device and server provided in this application embodiment are used to execute any of the service continuity data transmission methods provided in the above method embodiments, and therefore can achieve the same effect as the above implementation method. When using integrated units, the terminal device or server may include a processing module, a storage module, and a communication module. The processing module can be used to control and manage the actions of the terminal device or server. For example, it can be used to support the terminal device or server in executing the steps executed by the processing unit. The storage module can be used to support the storage of program code and data, etc. The communication module can be used to support communication between the terminal device or server and other devices.
[0203] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other terminal devices.
[0204] Figure 10 The diagram shown is a schematic representation of the terminal device structure provided in this application. Figure 10As shown, the terminal device 500 may include a processor 510, an external memory interface 520, an internal memory 521, a universal serial bus (USB) interface 530, an antenna 1, an antenna 2, a mobile communication module 550, a wireless communication module 560, an audio module 570, a speaker 570A, a receiver 570B, a microphone 570C, a headphone jack 570D, a sensor module 580, etc.
[0205] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the terminal device 500. In other embodiments of this application, the terminal device 500 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.
[0206] Processor 510 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. The different processing units may be independent devices or integrated into one or more processors.
[0207] The processor 510 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 510 is a cache memory. This memory can store instructions or data that the processor 510 has just used or that are used repeatedly. If the processor 510 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 510, and thus improves the efficiency of the system.
[0208] The wireless communication function of the terminal device 500 can be implemented through antenna 1, antenna 2, mobile communication module 550, wireless communication module 560, modem processor and baseband processor, etc.
[0209] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal device 500 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 a tuning switch.
[0210] The mobile communication module 550 can provide solutions for wireless communication, including 2G / 5G / 4G / 5G, applied to the terminal device 500. The mobile communication module 550 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 550 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 550 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 550 may be housed in the processor 510. In some embodiments, at least some functional modules of the mobile communication module 550 and at least some modules of the processor 510 may be housed in the same device.
[0211] The wireless communication module 560 can provide solutions for wireless communication applications on the terminal device 500, including wireless local area networks (WLAN), such as wireless fidelity (Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 560 can be one or more devices integrating at least one communication processing module. The wireless communication module 560 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 510. The wireless communication module 560 can also receive signals to be transmitted from processor 510, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.
[0212] In some embodiments, antenna 1 of terminal device 500 is coupled to mobile communication module 550, and antenna 2 is coupled to wireless communication module 560, enabling terminal device 500 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), LTE, BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).
[0213] The terminal device 500 implements display functions through a GPU, a display screen 594, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 594 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 510 may include one or more GPUs, which execute program instructions to generate or modify display information.
[0214] Display screen 594 is used to display images, videos, etc. Display screen 594 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, terminal device 500 may include one or N displays 594, where N is a positive integer greater than 1.
[0215] The terminal device 500 can perform shooting functions through an ISP, camera 593, video codec, GPU, display 594, and application processor.
[0216] The ISP (Image Signal Processor) is used to process data fed back from the camera 593. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 593.
[0217] Camera 593 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the terminal device 500 may include one or N cameras 593, where N is a positive integer greater than 1.
[0218] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when terminal device 500 is selecting a frequency, the DSP performs Fourier transforms on the frequency energy.
[0219] Video codecs are used to compress or decompress digital video. Terminal device 500 may support one or more video codecs. Thus, terminal device 500 can play or record video in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG5, MPEG4, etc.
[0220] The external storage interface 520 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the terminal device 500. The external storage card communicates with the processor 510 through the external storage interface 520 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.
[0221] Internal memory 521 can be used to store computer executable program code, which includes instructions. Processor 510 executes various functional applications and data processing of terminal device 500 by running the instructions stored in internal memory 521. Internal memory 521 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of terminal device 500 (such as audio data, phonebook, etc.). Furthermore, internal memory 521 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.
[0222] Terminal device 500 can implement audio functions, such as music playback and recording, through audio module 570, speaker 570A, receiver 570B, microphone 570C, headphone jack 570D, and application processor.
[0223] The audio module 570 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 570 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 570 may be located in the processor 510, or some functional modules of the audio module 570 may be located in the processor 510.
[0224] The speaker 570A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The terminal device 500 can listen to music or make hands-free calls through the speaker 570A.
[0225] The receiver 570B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the terminal device 500 answers a phone call or voice message, the receiver 570B can be brought close to the listener's ear to hear the voice.
[0226] Microphone 570C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 570C, inputting the sound signal into microphone 570C. Terminal device 500 may be equipped with at least one microphone 570C. In some embodiments, terminal device 500 may be equipped with two microphones 570C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, terminal device 500 may be equipped with three, four, or more microphones 570C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.
[0227] The 570D headphone jack is used to connect wired headphones. The 570D headphone jack can be a USB 530 interface or a 5.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.
[0228] The sensor module 580 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.
[0229] Of course, the terminal device 500 may also include a charging management module, a power management module, a battery, buttons, indicators, and one or more SIM card interfaces, etc., and this application embodiment does not impose any restrictions on this.
[0230] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the terminal device 500. In other embodiments of this application, the terminal device 500 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.
[0231] It should be understood that the specific process of the terminal device 500 performing the above-mentioned corresponding steps is described in the relevant descriptions of the first or second terminal execution steps in the various embodiments described above. For the sake of brevity, it will not be repeated here.
[0232] This application also provides a chip system, such as... Figure 11 As shown, the chip system includes at least one processor 610 and at least one interface circuit 620. The processor 610 and the interface circuit 620 are interconnected via lines. For example, the interface circuit 620 can be used to receive signals from other devices (e.g., the memory of the terminal device 500). As another example, the interface circuit 620 can be used to send signals to other devices (e.g., the processor 610). Exemplarily, the interface circuit 620 can read instructions stored in the memory and send those instructions to the processor 610. When the instructions are executed by the processor 610, the terminal device can perform the various steps executed by the terminal (first terminal, second terminal, or server) in the above embodiments. Of course, the chip system may also include other discrete components, which are not specifically limited in this application embodiment.
[0233] It should also be understood that the division of units in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, all units in the device can be implemented entirely through software calls from processing elements; all units can be implemented entirely in hardware; or some units can be implemented through software calls from processing elements, while others are implemented in hardware. For example, each unit can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as a program in memory, and its function can be called and executed by a processing element within the device. Here, the processing element can also be called a processor, which can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above units can be implemented through integrated logic circuits in the processor element or through software calls from processing elements. In one example, a unit in any of the above devices can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these forms of integrated circuits. As another example, when a unit in the device can be implemented in the form of a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Furthermore, these units can be integrated together to implement a system-on-a-chip (SOC).
[0234] This application also provides an apparatus included in a terminal device or server, which has the function of implementing the terminal device or server in any of the methods described above. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes at least one module or unit corresponding to the above function. For example, a detection module or unit, a display module or unit, a determination module or unit, and a calculation module or unit, etc.
[0235] This application also provides a system for data transmission to continue services, which includes: a first terminal, a second terminal, and a server as described in the above method embodiments.
[0236] This application also provides a computer-readable storage medium for storing computer program code, the computer program including instructions for executing any of the service connection data transmission methods provided in the embodiments of this application. The readable medium may be a read-only memory (ROM) or a random access memory (RAM), and this application does not impose any limitations on this.
[0237] This application also provides a computer program product including instructions that, when executed, cause a first terminal, a second terminal, and a server to perform operations corresponding to those described in the above method.
[0238] This application also provides a chip located in a communication device, the chip including a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer instructions to cause the communication device to perform any of the service connection data transmission methods provided in the above-described embodiments of this application.
[0239] Optionally, the computer instructions are stored in a storage unit.
[0240] Optionally, the storage unit can be an internal storage unit within the chip, such as a register or cache. Alternatively, it can be an external storage unit located within the terminal, such as a ROM or other types of static storage devices capable of storing static information and instructions, such as random access RAM. The processor mentioned above can be a CPU, microprocessor, ASIC, or one or more integrated circuits used to control the execution of a program for transmitting the aforementioned feedback information. The processing unit and the storage unit can be decoupled and located on different physical devices, connected via wired or wireless means to implement their respective functions, thereby supporting the system chip in implementing the various functions described in the above embodiments. Alternatively, the processing unit and the memory can also be coupled to the same device.
[0241] In this embodiment, the terminal device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.
[0242] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be RAM, which is used as an external cache. RAM has various types, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).
[0243] In this application, various objects such as messages / information / devices / network elements / systems / apparatus / actions / operations / processes / concepts may be named. It is understood that these specific names do not constitute a limitation on the relevant objects. The names may be changed depending on the scenario, context, or usage habits. The understanding of the technical meaning of the technical terms in this application should be mainly determined from their functions and technical effects embodied / performed in the technical solution.
[0244] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.
[0245] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0246] The methods in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server integrating one or more available media.
[0247] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0248] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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 system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0249] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0250] In addition, 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.
[0251] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned readable storage medium includes various media capable of storing program code, such as USB flash drives, external hard drives, ROM, RAM, magnetic disks, or optical disks.
[0252] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology 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 method for data transmission during service continuity, characterized in that, The method is applied to a service continuity system, which includes a first terminal and a second terminal. The first terminal and the second terminal log in with the same account or mutually trusted accounts. The method includes: The first terminal sends a broadcast message to the second terminal. The broadcast message includes the application layer device identifier of the first terminal and a service continuation event. The application layer device identifier of the first terminal is encrypted by the application layer identity resolution key IRK of the first terminal or a shared application layer IRK. The service continuation event is encrypted by the service broadcast key of the first terminal or a shared service broadcast key. The service continuation event includes the continuation event type and the event operation object. The second terminal uses the application layer IRK of the first terminal or a shared application layer IRK to decrypt the application layer device identifier of the first terminal and determine that the first terminal is a trusted device. The second terminal uses the service broadcast key of the first terminal or the shared service broadcast key to decrypt the service connection event.
2. The method according to claim 1, characterized in that, The method further includes: The first terminal sends service connection data to the second terminal, and the service connection data is encrypted by the first terminal's application layer long-term key LTK or a shared application layer LTK. The second terminal uses the first terminal's application layer long-term key (LTK) or a shared application layer LTK to decrypt the service connection data; The second terminal continues the service connection event on the second terminal according to the service connection data.
3. The method according to claim 1 or 2, characterized in that, The system also includes a server, and the method further includes: The first terminal generates the shared application layer IRK, the shared service broadcast key, and the shared application layer LTK; The first terminal sends the shared application layer IRK, the shared service broadcast key, the shared application layer LTK, and the account authentication credentials of the first terminal to the server. After the server successfully authenticates the account authentication credentials of the first terminal, the server sends the shared application layer IRK, the shared service broadcast key, and the shared application layer LTK to the second terminal.
4. The method according to claim 1 or 2, characterized in that, The system also includes a server, and the method further includes: The first terminal generates the first terminal's application layer IRK, the first terminal's service broadcast key, and the first terminal's application layer LTK; The first terminal sends the first terminal's application layer IRK, the first terminal's service broadcast key, the first terminal's application layer LTK, the first terminal's account authentication credentials, and the first terminal's application layer device identifier to the server. After the server successfully authenticates the account authentication credentials of the first terminal, the server sends the service broadcast key of the first terminal, the application layer LTK of the first terminal, and the application layer device identifier of the first terminal to the second terminal.
5. The method according to claim 1 or 2, characterized in that, The system also includes a server, and the method further includes: The first terminal generates the shared application layer IRK and the shared application layer temporary key TK; The first terminal sends the shared application layer IRK, the shared application layer TK, and the account authentication credentials of the first terminal to the server; After the server successfully authenticates the account authentication credentials of the first terminal, the server sends the shared application layer IRK and the shared application layer TK to the second terminal.
6. The method according to claim 1 or 2, characterized in that, The system also includes a server, and the method further includes: The first terminal generates the first terminal's application layer IRK and the first terminal's application layer temporary key TK; The first terminal sends its application layer IRK, application layer TK, account authentication credentials, and application layer device identifier to the server. After the server successfully authenticates the account authentication credentials of the first terminal, the server sends the application layer IRK, application layer TK, and application layer device identifier of the first terminal to the second terminal.
7. The method according to claim 5 or 6, characterized in that, The method further includes: The first terminal generates the service broadcast key for the first terminal; The second terminal generates the service broadcast key for the second terminal; The first terminal and the second terminal negotiate the application layer LTK of the first terminal or the shared application layer LTK based on the application layer TK of the first terminal or the shared application layer TK; The first terminal and the second terminal exchange the service broadcast key of the first terminal and the service broadcast key of the second terminal using the application layer LTK of the first terminal or the shared application layer LTK.
8. The method according to claim 2, characterized in that, The first terminal sends service connection data to the second terminal, including: The first terminal sends service connection data to the second terminal via Bluetooth or Wi-Fi connection.
9. The method according to any one of claims 1 to 8, characterized in that, The service broadcast key includes the Handoff key.
10. The method according to any one of claims 1 to 9, characterized in that, The application layer device identifier of the first terminal includes at least one of the following: the Universally Unique Identifier (UUID) of the first terminal, the serial number of the first terminal, and the International Mobile Equipment Identity (IMEI) of the first terminal.
11. A method for data transmission during service continuity, characterized in that, The method is applied to a first terminal, and the method includes: The first terminal sends a broadcast message to the second terminal. The broadcast message includes the application layer device identifier of the first terminal and a service continuation event. The application layer device identifier of the first terminal is encrypted by the application layer identity resolution key IRK of the first terminal or a shared application layer IRK. The service continuation event is encrypted by the service broadcast key of the first terminal or a shared service broadcast key. The service continuation event includes the continuation event type and the event operation object. The first terminal sends service connection data to the second terminal, and the service connection data is encrypted by the first terminal's application layer long-term key (LTK) or a shared application layer LTK.
12. The method according to claim 11, characterized in that, The method further includes: The first terminal generates the shared application layer IRK, the shared service broadcast key, and the shared application layer LTK; The first terminal sends the shared application layer IRK, the shared service broadcast key, the shared application layer LTK, and the account authentication credentials of the first terminal to the server.
13. The method according to claim 11, characterized in that, The method further includes: The first terminal generates the first terminal's application layer IRK, the first terminal's service broadcast key, and the first terminal's application layer LTK; The first terminal sends to the server its application layer IRK, service broadcast key, application layer LTK, account authentication credentials, and application layer device identifier.
14. The method according to claim 11, characterized in that, The method further includes: The first terminal generates the shared application layer IRK and the shared application layer temporary key TK; The first terminal sends the shared application layer IRK, the shared application layer TK, and the account authentication credentials of the first terminal to the server.
15. The method according to claim 11, characterized in that, The method further includes: The first terminal generates the first terminal's application layer IRK and the first terminal's application layer temporary key TK; The first terminal sends its application layer IRK, application layer TK, account authentication credentials, and application layer device identifier to the server.
16. The method according to claim 14 or 15, characterized in that, The method further includes: The first terminal generates the service broadcast key for the first terminal; The first terminal and the second terminal negotiate the application layer LTK of the first terminal or the shared application layer LTK based on the application layer TK of the first terminal or the shared application layer TK; The first terminal and the second terminal exchange the service broadcast key of the first terminal and the service broadcast key of the second terminal using the application layer LTK of the first terminal or the shared application layer LTK.
17. The method according to claim 11, characterized in that, The first terminal sends service connection data to the second terminal, including: The first terminal sends service connection data to the second terminal via Bluetooth or Wi-Fi connection.
18. The method according to any one of claims 11 to 17, characterized in that, The service broadcast key includes the Handoff key.
19. The method according to any one of claims 11 to 18, characterized in that, The application layer device identifier of the first terminal includes at least one of the following: the Universally Unique Identifier (UUID) of the first terminal, the serial number of the first terminal, and the International Mobile Equipment Identity (IMEI) of the first terminal.
20. A terminal device, characterized in that, include: Processor and memory; The processor is coupled to a memory, the memory storing program instructions, and when the program instructions stored in the memory are executed by the processor, the method as described in any one of claims 11 to 19 is performed.
21. A system for data transmission during service continuity, characterized in that, The system includes a first terminal and a second terminal, wherein the first terminal and the second terminal are logged into the same account or mutually trusted accounts, the first terminal is used to perform the steps of any one of claims 1 to 10 performed by the first terminal, and the second terminal is used to perform the steps of any one of claims 1 to 10 performed by the second terminal.
22. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 11 to 19.
23. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a communication device on which the chip is mounted to perform the method as described in any one of claims 11 to 19.
Citation Information
Patent Citations
Wireless communication device and method for realizing service security thereof
CN101873587A
Content continuation method and system, and electronic device
WO2021023220A1