Bluetooth processing circuit and method of operating the same
By rejecting subsequent enable commands during the channel probe security startup process in the Bluetooth processing circuit, the vulnerability of the channel probe security mechanism to attacks is solved, and more robust security parameter management and attack defense are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-14
- Publication Date
- 2026-04-14
AI Technical Summary
Existing Bluetooth channel probing security mechanisms are vulnerable to distance spoofing and man-in-the-middle attacks, especially due to insufficient basic security assumptions of pseudo-random functions, leading to inconsistent security parameters and system attacks.
By introducing a mechanism into the Bluetooth processing circuitry, the integrity and consistency of security parameters are protected so that subsequent enable commands are rejected during the secure initiation process of channel probing (CS) until the previous process is completed.
It improves the security and reliability of the channel detection process, prevents distance spoofing interference and man-in-the-middle attacks, and ensures the correct updating of security parameters and the successful establishment of new security contexts.
Smart Images
Figure CN121865232A_ABST
Abstract
Description
[0001] Cross-referencing
[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 706,793, filed October 14, 2024, the contents of which are incorporated herein by reference. Technical Field
[0003] This invention relates to Bluetooth, and more particularly, to Bluetooth processing circuitry and methods of operating Bluetooth processing circuitry. Background Technology
[0004] Bluetooth wireless technology enables short-range communication between devices, facilitating widespread applications. In Bluetooth Low Energy (LE), channel sensing (CS) equidistant estimation allows devices to estimate the physical distance between them. These functions rely on the exchange of specific radio frequency (RF) signals and typically involve security procedures to protect the integrity and confidentiality of measurements and related communications.
[0005] Bluetooth is a registered trademark of Bluetooth SIG, Inc., and Wi-Fi is a registered trademark of the Wi-Fi Alliance. For the sake of readability and brevity in this specification, the terms “Bluetooth” and “Wi-Fi” will be used hereafter to refer to their respective technologies without duplication of the trademark symbol ®. This use is for descriptive purposes only and is not intended to challenge the validity or ownership of these trademarks.
[0006] Secure distance estimation protocols are crucial for applications such as secure access control (e.g., digital car keys). Many such protocols rely on cryptographic primitives, including pseudo-random functions (PRFs), to establish a secure communication context. However, existing security analyses suggest that relying solely on the basic assumption of PRF properties may be insufficient to prevent certain sophisticated attacks. If the underlying security mechanisms, particularly those involving the setting and management of PRF-based security parameters, are not handled properly, vulnerabilities such as distance spoofing interference (malicious devices tricking verifiers into believing they are closer than they actually are) or man-in-the-middle (MiTM) attacks (attackers relaying communications and potentially modifying them) can emerge. Therefore, mechanisms need to be enhanced in Bluetooth channel probing security procedures to mitigate these risks and ensure the integrity and robustness of distance estimation operations under potential security threats. Summary of the Invention
[0007] One embodiment of the present invention provides a Bluetooth processing circuit. The Bluetooth processing circuit includes a first memory and a central processing circuit coupled to the first memory. The first memory is configured to store first instructions. The central processing circuit is configured to execute the first instructions stored in the first memory to perform operations of a Bluetooth controller layer. Operations of the Bluetooth controller layer include: receiving a first Channel Probe (CS) security enable command from a host layer to initiate a first CS security boot process with a peer Bluetooth device; initiating the first CS security boot process based on the first CS security enable command; receiving a second CS security enable command from the host layer while the first CS security boot process is in progress; and rejecting the second CS security enable command while the first CS security boot process is still in progress.
[0008] Another embodiment of the present invention provides a method for operating Bluetooth processing circuitry. The method includes: initiating a first CS secure boot process with a peer Bluetooth device based on a first channel probing (CS) secure enable command; and rejecting a second CS secure enable command while the first CS secure boot process is still in progress.
[0009] These, and other objectives of the invention, will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments illustrated in conjunction with various figures and drawings. Attached Figure Description
[0010] Figure 1 It is a sequence diagram illustrating a test process that ensures the completion of the initial CS secure start process by rejecting subsequent secure start requests during the initial channel probe (CS) secure start process, according to an embodiment of the present invention.
[0011] Figure 2 This is a block diagram illustrating the architecture of two interactive Bluetooth devices configured for channel probing according to an embodiment of the present invention.
[0012] Figure 3 This is a block diagram illustrating an exemplary hardware architecture of an electronic device capable of implementing Bluetooth functionality according to an embodiment of the present invention. Detailed Implementation
[0013] The following detailed description, taken in conjunction with the accompanying drawings, is intended to illustrate various configurations and is not intended to represent the only configurations that the concepts described herein may be practiced. The detailed description includes specific details to provide a thorough understanding of the various concepts. However, those skilled in the art will appreciate that these concepts can be practiced without these specific details.
[0014] As described in the background, secure distance estimation protocols, including aspects of Bluetooth channel probing, are vulnerable. These issues can arise if their underlying security mechanisms are not carefully managed. This problem is particularly relevant to the process of establishing the required secure arrangements using pseudo-random functions. Such processes typically involve agreeing or exchanging specific security parameters and deriving or generating the cryptographic keys or key material required for secure operation from these parameters. Allowing multiple concurrent processes designed to establish these secure arrangements between two Bluetooth devices introduces risks. Such concurrent operation can lead to inconsistencies in active security parameters or derived cryptographic states within the system. They can also expose the system to attacks such as distance spoofing interference or man-in-the-middle (MiTM) attacks. In these cases, attackers could exploit obfuscation associated with time or the correct set of security parameters and derived keys. The embodiments described herein address these potential problems. They introduce a mechanism to ensure the security of the channel probing (CS) secure initiation process.
[0015] Within the context of Bluetooth Core Specification 6.0 testing, particularly regarding Channel Probe (CS) functionality, three main entities are involved: the upper-layer tester, the implementation under test (IUT), and the lower-layer tester. Each entity plays its own role in the testing process. Their roles contribute to a comprehensive evaluation of the conformity and functionality of Bluetooth devices.
[0016] Upper-layer testers typically reside in the host portion of the Bluetooth system architecture. Their primary responsibility is to initiate and control test scenarios by interacting with the IUT (Integrated Device) through a standardized interface, typically the Host Controller Interface (HCI). The HCI provides the host with a unified method for accessing Bluetooth controller functionality. The upper-layer tester sends commands to the IUT. In turn, it receives status events or packet reports indicating the results of these commands or the operational status of the IUT. When testing channel probe functionality, the upper-layer tester's role involves initiating security-related procedures on the IUT. This includes enabling or configuring security functions related to channel probe. Furthermore, the upper-layer tester monitors the IUT's behavior and responses to these security-related commands. It looks for signs of successful or failed channel probe system activation. Essentially, the upper-layer tester acts as the director of the test. It operates at a higher protocol level to drive the IUT's actions and observe the results of the security test.
[0017] Please see Figure 1 . Figure 1This is a sequence diagram illustrating a test procedure for ensuring that an initial channel probe (CS) secure initiation process can be completed by rejecting subsequent secure initiation requests while the initial CS secure initiation process is in progress, according to an embodiment of the invention. The test procedure aims to verify that the implementation under test (IUT) 20, acting as the central entity, can reject another CS secure initiation request from the upper-layer tester 10, while the initial CS secure initiation process is already underway. In this test scenario, the upper-layer tester 10 typically acts as the host, responsible for sending high-level commands to the IUT 20 via the Host Controller Interface (HCI). On the other hand, the lower-layer tester 30 acts as the controller for the peer device, responsible for interacting with the link layer of the IUT 20, for example, by exchanging Link Layer Control Protocol Data Units (LL PDUs). The IUT 20 is the Bluetooth device under test and plays a central role in the test procedure. The upper-layer tester 10 and the lower-layer tester 30 can be dedicated test equipment or standard Bluetooth devices with corresponding functions. The IUT 20 is a Bluetooth device that supports channel probe functionality.
[0018] The testing procedure includes the following steps:
[0019] Step S110: The upper-layer tester 10 sends the HCI_LE_CS_Security_Enable command (i.e., "Host Controller Interface Low Energy Channel Probe Security Enable Command", hereinafter referred to as "Channel Probe (CS) Security Enable Command" or simply "CS Security Enable Command", as described in the claim) to the IUT 20. The HCI_LE_CS_Security_Enable command is used to request the IUT 20 to start or restart the CS secure boot process.
[0020] Step S120: IUT 20 sends a successful HCI_Command_Status event (i.e., Host Controller Interface Command Status event) to the upper-layer tester 10. The HCI_Command_Status event indicates that IUT 20 has received the HCI_LE_CS_Security_Enable command and has begun processing it. This processing is the initial CS security boot process.
[0021] Step S130: As part of the initial CS secure startup process, IUT 20 sends LL_CS_SEC_REQ PDU (Link Layer Channel Probe Security Request Protocol Data Unit) to its peer device, the lower-layer tester 30, requesting the exchange of security parameters.
[0022] Step S140: The lower-layer tester 30 intentionally delays its response and does not immediately send LL_CS_SEC_RSPPDU (Link Layer Channel Probe Security Response Protocol Data Unit) to IUT 20. This delay is to simulate the state where the initial CS secure startup process has not yet been completed.
[0023] Step S150: While IUT 20 is still waiting for a response from the lower-level tester 30 (i.e., the initial CS secure boot process is still in progress), the upper-level tester 10 sends another HCI_LE_CS_Security_Enable command to IUT 20 in an attempt to start another CS secure boot process.
[0024] Step S160: According to an embodiment of the present invention, the IUT 20 rejects the duplicate request from the upper-layer tester 10 (i.e., the HCI_LE_CS_Security_Enable command sent in step S150) and sends an HCI_Command_Status event to the upper-layer tester 10, wherein the status field of the HCI_Command_Status event contains an error code greater than 0, such as Command Disallowed (0x0C) as defined in Bluetooth Core Specification 6.0, thereby constituting the "error status event" as described in the claims, indicating that the new request cannot be executed because the initial CS secure boot process is still in progress.
[0025] Step S170: At this time, the lower-level tester 30 sends an LL_CS_SEC_RSP PDU to the IUT 20 in response to the request in step S130.
[0026] Step S180: After receiving the response from the lower-level tester 30, the IUT 20 completes the initial CS security startup process and sends a successful HCI_LE_CS_Security_Enable_Complete event (hereinafter referred to as the "HCI Low Energy Channel Probe Security Enable Completion Event" as described in the claims) to the upper-level tester 10, indicating that the initial CS security startup process has been successfully completed.
[0027] It should be understood that once the initial CS secure boot process initiated by the command in step S110 is successfully completed as shown in step S180, the IUT 20 is ready to accept and process new HCI_LE_CS_Security_Enable commands. For example, if the upper-layer tester 10 sends another HCI_LE_CS_Security_Enable command after the completion event in step S180, the IUT 20 will process this new command normally, send back an HCI_Command_Status event indicating successful reception (status = 0), and then continue with the new CS secure boot process, finally sending another HCI_LE_CS_Security_Enable_Complete event upon successful completion, assuming no other interference errors. In other words, if the initial CS secure boot process initiated by the first HCI_LE_CS_Security_Enable command completes successfully (e.g., as shown by the HCI_LE_CS_Security_Enable_Complete event in step S180), then the IUT 20 will be ready to accept and process subsequent new HCI_LE_CS_Security_Enable commands. This subsequent command will initiate a new CS secure boot process, which will be processed normally without being rejected, since no previous CS secure boot process is in progress.
[0028] The expected outcome of this test process is a pass / fail decision. The key to passing the decision lies in step S160, where the IUT 20 sends an HCI_Command_Status event with a valid error code (status > 0) to the upper-layer tester 10, indicating that it correctly rejected the request to start a new process during the initial CS secure boot process. Furthermore, passing the decision also occurs in step S180, where the IUT 20 ultimately successfully completes the initial CS secure boot process and sends a successful HCI_LE_CS_Security_Enable_Complete event to the upper-layer tester 10.
[0029] Please see Figure 2 . Figure 2This is a block diagram of the architecture of two interactive Bluetooth devices 50A and 50B configured for channel probing according to an embodiment of the present invention. Bluetooth device 50A includes a host layer 60A and a controller layer 70A communicatively coupled to the host layer 60A. Bluetooth device 50B includes a host layer 60B and a controller layer 70B communicatively coupled to the host layer 60B. The host layer 60A communicates with the controller layer 70A via a host controller interface (HCI) 80A, and the host layer 60B communicates with the controller layer 70B via the host controller interface (HCI) 80B. The mechanisms and procedures described herein for managing the CS secure boot process are applicable regardless of whether Bluetooth devices 50A and 50B are in a paired or unpaired state. These CS security management mechanisms are effective when Bluetooth devices 50A and 50B are in a paired state, in which a trusted link has been previously established and security keys have been exchanged. These mechanisms are also fully applicable if the devices are in an unpaired state, i.e., the devices themselves lack any prior security associations or shared cryptographic material.
[0030] Host layer 60A includes one or more user applications 62A and a channel probing (CS) configuration module 64A. Host layer 60B includes one or more user applications 62B and a channel probing (CS) configuration module 64B. User applications 62A and 62B are responsible for handling user interaction and high-level application logic, such as initiating distance measurement functions. For example, multiple user applications 62A on Bluetooth device 50A may independently attempt to initiate a channel probing process with Bluetooth device 50B. CS configuration modules 64A and 64B are responsible for configuring the relevant parameters of the channel probing process and sending control commands to controller layer 70A and controller layer 70B respectively via HCI 80A and HCI 80B. For example, CS configuration module 64A and / or CS configuration module 64B can send the HCI_LE_CS_Security_Enable command to initiate or restart the CS secure boot process. The functionality of host layer 60A is typically implemented by software running on the main processor of Bluetooth device 50A, and the functionality of host layer 60B is typically implemented by software running on the main processor of Bluetooth device 50B.
[0031] Controller layer 70A includes CS measurement module 72A, and controller layer 70B includes CS measurement module 72B. CS measurement modules 72A and 72B are responsible for performing actual channel sounding measurements, including handling link layer protocols related to channel sounding, such as sending and receiving LL_CS_SEC_REQ PDUs and LL_CS_SEC_RSP PDUs, and performing calculations related to the Normalized Attack Detector Metric (NADM) algorithm. The functionality of controller layers 70A and 70B can be implemented by firmware, hardware, or a combination thereof, typically running on a Bluetooth chip or a dedicated wireless communication processor.
[0032] The controller layer 70A of Bluetooth device 50A and the controller layer 70B of Bluetooth device 50B synchronize with each other through a channel detection synchronization (CS Sync) mechanism 90. CS Sync 90 ensures that the two Bluetooth devices 50A and 50B have coordinated timing and frequency when performing the channel detection process.
[0033] When the host layer 60A of Bluetooth device 50A wishes to initiate or restart the Secure Boot (CS) process with another Bluetooth device 50B, the CS configuration module 64A in its host layer 60A sends the HCI_LE_CS_Security_Enable command to its local controller layer 70A via HCI 80A. Upon receiving this HCI_LE_CS_Security_Enable command, controller layer 70A will begin executing link layer operations related to the CS Secure Boot process, such as sending an LL_CS_SEC_REQ PDU to the controller layer 70B of the peer device (i.e., Bluetooth device 50B).
[0034] Figure 1 The test process shown in the image verifies Figure 2 The key behavior in the system architecture shown is as follows: When the initial Secure Startup (CS) process is in progress, the controller layer is designed to reject requests to initiate a new Secure Startup (CS) process. This request will be initiated by the host layer, which can be a local host or a remote host. This behavior conforms to the following rule: "When a Secure Startup (CS) process is in progress, the local link layer should reject CS Secure Startup processes invoked by local or remote hosts until the CS Secure Startup process is complete."
[0035] The CS secure start process involves the exchange of security parameters, including CS_IV (Channel Sensing Initialization Vector), CS_IN (Channel Sensing Instantiation Random Number), and CS_PV (Channel Sensing Personalization Vector). These parameters form the basis for the pseudo-random function in subsequent channel sensing steps. To enhance security and make man-in-the-middle (MiTM) attacks more difficult, it is important to refresh these three security parameters periodically or based on certain triggering conditions, which requires initiating a new CS secure start process. However, if another CS secure start process (possibly using different parameters or designed to refresh existing parameters) is allowed to start before the previous one has completed, the pseudo-noise (PN) bit sequence corresponding to the previous process may be tampered with or corrupted, affecting the accuracy and security of channel sensing measurements. Therefore, rejecting any attempt to start a new process before the previous CS secure start process has completed is crucial for protecting the integrity of the ongoing CS secure start process and the correctness of its parameters, ensuring that each parameter refresh or the establishment of a new security context can be successfully completed before starting another process.
[0036] Figure 1 and Figure 2 The relationship is that the upper-layer tester 10 simulates the behavior of the host layer, such as host layer 60A or host layer 60B. IUT 20 represents a Bluetooth device containing a controller layer, such as controller layer 70A or controller layer 70B. The HCI_LE_CS_Security_Enable command in steps S110 and S150 corresponds to a startup request sent from the host layer to the controller layer. The behavior of IUT 20 rejecting the second command in step S160 is precisely a manifestation of the controller layer protection mechanism.
[0037] The first application scenario of this invention involves a user manually triggering a distance measurement. Assume a user operates a user application 62A on the host layer 60A of a Bluetooth device 50A. The user clicks a button in the user application 62A to initiate a distance measurement using channel probing. The user application 62A then sends a first HCI_LE_CS_Security_Enable command to the local controller layer 70A via the CS configuration module 64A to initiate a CS secure boot process with a peer device (e.g., Bluetooth device 50B). Upon receiving the command, the controller layer 70A begins executing the initial CS secure boot process, which includes link-layer interaction with the controller layer 70B of the Bluetooth device 50B, such as sending an LL_CS_SEC_REQ PDU. Assume that before this initial CS secure boot process is complete (e.g., due to Bluetooth device 50B not yet responding or network latency), the user quickly clicks the button on the user application 62A again, intending to trigger another distance measurement. At this time, the user application 62A will again send a second HCI_LE_CS_Security_Enable command to the controller layer 70A. Alternatively, different user applications running on host layer 60A (e.g.) Figure 3 Another instance of user application 62 shown in the image, or Figure 2 Different user applications (62B) shown in the diagram may also attempt to send the HCI_LE_CS_Security_Enable command to the controller layer 70A to initiate the same peer device 50B boot process. According to the mechanism of the invention, the controller layer 70A detects that an initial CS secure boot process is currently being processed and therefore will refuse to execute a second HCI_LE_CS_Security_Enable command (regardless of whether it comes from the same user application 62A or a different application). The controller layer 70A will send an HCI_Command_Status event to its upper-layer host layer 60A (specifically, user application 62A), whose status field indicates an error (e.g., command not allowed (0x0C)). This ensures that the initial CS secure boot process is not interfered with or interrupted by subsequent requests, thus guaranteeing the integrity and accuracy of the measurement process.
[0038] A second application scenario of the present invention relates to periodic distance measurements in the background. Assume a user has activated one or more user applications 62A in the host layer 60A on a Bluetooth device 50A. These user applications 62A periodically perform channel sounding distance measurements in the background and report the results to the user. To perform periodic measurements, user application 62A periodically sends an HCI_LE_CS_Security_Enable command to the local controller layer 70A via the CS configuration module 64A (e.g., at fixed intervals, i.e., the first time interval between sending the first command and the second command is equal to the second time interval between sending the second command and the subsequent third command) to initiate or restart the CS secure boot process with the Bluetooth device 50B. Assume that at some point, controller layer 70A is processing an initial CS secure boot process triggered by a previous periodic command, and this initial CS secure boot process has not yet completed. At this time, if user application 62A sends the next HCI_LE_CS_Security_Enable command according to its periodic schedule, then according to the mechanism of the present invention, controller layer 70A will reject this new command request. The reason for the rejection is that controller layer 70A detected that a CS secure boot process is already in progress. Controller layer 70A will send an HCI_Command_Status event with an error status (Status > 0) to its upper host layer 60A. This mechanism ensures that even in scenarios with periodic triggering, controller layer 70A processes only one CS secure boot process at a time, avoiding parameter confusion or process status errors caused by command stacking. This helps maintain the stability and reliability of background measurement tasks.
[0039] The third application scenario illustrates the behavior upon completion of the CS secure boot process. It should be understood that after the initial CS secure boot process, initiated by the command in step S110, successfully completes—for example, via an event indication in step S180—the IUT20 or controller layer 70A is ready to accept and process a new HCI_LE_CS_Security_Enable command. If the upper-layer tester 10 or host layer 60A sends another such command after the successful completion of the HCI_LE_CS_Security_Enable_Complete event indication in step S180, controller layer 70A will process this new command normally. This normal processing will involve sending an HCI_Command_Status event indicating successful reception, for example, a status field of zero, and then continuing the new CS secure boot process. Assuming no other interfering errors, this new process will eventually also complete successfully, resulting in another HCI_LE_CS_Security_Enable_Complete event. Essentially, once the previous CS secure boot process is no longer suspended, the subsequent HCI_LE_CS_Security_Enable command will trigger a new CS secure boot process, which will be processed normally without being rejected.
[0040] Please see Figure 3 . Figure 3 This is a block diagram illustrating an exemplary hardware architecture of a Bluetooth device 50 capable of implementing Bluetooth functionality according to an embodiment of the present invention. The electronic device may be... Figure 2 The Bluetooth device 50A or 50B shown includes processing circuitry 100, memory 110, input / output (I / O) interface 120, display 130, input module 140, power supply 150, and one or more antennas 160.
[0041] The processing circuit 100 is the core of the Bluetooth device 50, responsible for executing instructions and processing data. The processing circuit 100 is designed to handle both host and controller functions of the Bluetooth device 50. In a typical implementation, this involves a first processing circuit 101 dedicated to controller layer operations and a second processing circuit 102 dedicated to host layer operations, such as... Figure 3 As shown. The first processing circuit 101 is responsible for implementing the controller layer functions (e.g. Figure 2(See controller layers 70A or 70B shown). The first processing circuit 101 can be implemented as a microcontroller (MCU) or a dedicated Bluetooth communication chip, and it can be a separate physical component from the second processing circuit 102. In other words, the first processing circuit 101 and the second processing circuit 102 can be implemented as different physical chips. In this case, the central processing circuit 103 is contained in the first physical chip, while the second processing circuit 102 is contained in a second physical chip, which is different from the first physical chip. Alternatively, the first processing circuit 101 and the second processing circuit 102 can be integrated, for example, as different cores in a single system-on-a-chip (SoC). In other embodiments, the second processing circuit 102 and the first processing circuit 101, along with other functions such as Wi-Fi (e.g., Wi-Fi 7), can be integrated into a single, unified SoC. In this case, the HCI between the host and controller sections is likely to be an internal bus or shared memory interface within the SoC. The term "Bluetooth processing circuit" as used in this specification and the appended claims may refer to the overall processing circuit 100, the first processing circuit 101 (particularly when performing controller layer operations), the second processing circuit 102 (particularly when performing host layer operations in some embodiments), or a combination thereof, performing the described functions for managing the secure channel probing process.
[0042] Regardless of the specific implementation of the first processing circuit 101, it includes several key components for performing operations of the Bluetooth controller layer. These components include a memory 105 and a central processing circuit 103. The memory 105 is configured to store instructions 106, which can be implemented as firmware of the first processing circuit 101. The central processing circuit 103 is coupled to the memory 105 and configured to execute the instructions 106, thereby performing operations of the controller layer of the Bluetooth device 50 (e.g.,...). Figure 2 (Host layer 60A or 60B shown). The central processing circuit 103, acting as the core of the first processing circuit 101, executes instructions 106 from the memory 105. The responsibilities of the central processing circuit 103 include managing the lower layers of the Bluetooth protocol stack, covering link layer operations such as connection management, packet transmission / reception, and timing control. Specifically for this invention, the central processing circuit 103 manages the CS secure boot process. This involves determining whether to execute a new secure boot request based on the state of any ongoing process.
[0043] The first processing circuit 101 may further include radio frequency (RF) circuitry 104 and interface circuitry 107. Interface circuitry 107 provides a communication path, such as a host controller interface (HCI), between the first processing circuitry 101 (controller layer) and the second processing circuitry 102 (host layer). The host layer sends commands to the controller layer via interface circuitry 107, and the controller layer sends events and data to the host layer via interface circuitry 107.
[0044] The central processing circuit 103 also controls the RF circuit 104 for signal transmission and reception. The RF circuit 104 is responsible for transmitting and receiving RF signals through one or more antennas 160. This includes modulating digital baseband signals for transmission, amplifying them, and converting the received RF signals back to digital baseband signals through amplification, filtering, downconversion, and demodulation for processing by the central processing circuit 103.
[0045] The second processing circuit 102 typically serves as the main application processor for the Bluetooth device 50. The second processing circuit 102 can be a central processing unit (CPU), a core in a more complex system-on-a-chip (SoC), or a similar processing unit. This is to implement host layer functions (e.g.) Figure 2 (As shown in the host layer 60A or 60B), the second processing circuit 102 executes general instructions 112 stored in the memory 110 and specific instructions of one or more user applications 62. The second processing circuit 102 executes the instructions 112 stored in the memory 110 to perform host layer operations (e.g., Figure 2 The host layer 60A or 60B shown in the diagram. The second processing circuit 102 is mainly responsible for running the operating system, executing the upper layers of the Bluetooth protocol stack (e.g., L2CAP, SDP, various configuration files), processing application logic, generating commands for the controller layer, processing events from the controller layer, and managing user interface interaction through the IO interface 120.
[0046] The memory 110 is coupled to a second processing circuit 102 of the processing circuit 100 and is used to store program code and data of the host layer of the Bluetooth device 50. For example... Figure 3As shown, memory 110 stores one or more user applications 62, instructions 112, and data 114. User application 62 represents specific application-level logic, such as an application that initiates distance measurement. Instructions 112 may include operating system program code, host-level Bluetooth stack components, and other system software executed by the second processing circuitry 102. Data 114 may include various data required by the operating system, host stack, or user application 62 during runtime, such as configuration parameters, security keys, etc. Memory 110 may be a combination of volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory, ROM, or EEPROM).
[0047] Input / output (I / O) interface 120 is responsible for communication between the second processing circuitry 102 and other peripheral devices. For example, I / O interface 120 is connected to display 130 (which may include display panel 132 and touch panel 134) and input module 140 (e.g., buttons, microphone, etc.). I / O interface 120 may also include communication ports such as Universal Asynchronous Receiver / Transmitter (UART), Universal Serial Bus (USB), or Secure Digital Input / Output (SDIO).
[0048] Power supply 150 provides the necessary power to all components of Bluetooth device 50. Antenna 160 is coupled to RF circuitry 104 of first processing circuitry 101 for transmitting and receiving Bluetooth wireless signals.
[0049] Figure 2 Various logical components in it can be used Figure 3 The hardware architecture shown is used for implementation. The functions of the host layers 60A and 60B include one or more user applications 62A and 62B (in...). Figure 3 The user application 62 and CS configuration modules 64A and 64B, collectively referred to as user application 62, are typically implemented by the second processing circuit 102 executing software instructions 112 stored in memory 110 and user application 62. The functions of controller layers 70A and 70B, including CS measurement modules 72A and 72B, are implemented by the first processing circuit 101. This involves the central processing circuit 103 executing instructions 106 stored in memory 105 and utilizing RF circuitry 104 and interface circuitry 107. Implementation may also involve dedicated hardware logic integrated within the first processing circuitry 101. HCI 80A and HCI 80B are logical or physical interfaces, implemented via interface circuitry 107. RF signal exchange for channel sensing is performed by RF circuitry 104 via antenna 160.
[0050] use Figure 3 The hardware architecture shown can implement the protection mechanisms in the first, second, and third application scenarios mentioned above.
[0051] In the first application scenario, triggered manually multiple times by the user, the user operates via the input module 140 of the display 130 or the touch panel 134. The second processing circuit 102 of the processing circuit 100 executes the instructions of the user application 62 stored in the memory 110, responds to the user's first trigger, and generates the first HCI_LE_CS_Security_Enable command. The user application 62, such as... Figure 3 As shown, for example, it could be Figure 2 The user application 62A or 62B is shown. The first HCI_LE_CS_Security_Enable command is sent from the second processing circuit 102 (host layer) to the first processing circuit 101, which performs controller layer functions, via interface circuit 107 (HCI). The first processing circuit 101 begins executing the initial CS secure boot process. The status of the initial CS secure boot process (e.g., "process in progress") can be recorded in memory 105 or in a register within the central processing circuit 103. When the user makes a second trigger from the same or a different user application 62 (e.g., a second user application different from the first trigger), the second processing circuit 102 again executes the relevant instructions to generate a second HCI_LE_CS_Security_Enable command. When this second HCI_LE_CS_Security_Enable command arrives at the first processing circuit 101, the logic executed by the central processing circuit 103 (based on instruction 106) checks the current status. If the central processing circuit 103 detects that the initial CS secure boot process is still in progress, the central processing circuit 103 will reject the second HCI_LE_CS_Security_Enable command and send an HCI_Command_Status event with an error code to the second processing circuit 102 (host layer) through the interface circuit 107 (HCI).
[0052] In the second application scenario involving background periodic triggering, the user application 62 executed by the second processing circuit 102 may periodically generate the HCI_LE_CS_Security_Enable command using an internal timer and send it to the first processing circuit 101 (controller layer). Similar to the first application scenario, if the internal state of the first processing circuit 101 indicates that the previous CS secure boot process has not yet been completed when it receives a new periodic command, the central processing circuit 103 will reject the new HCI_LE_CS_Security_Enable command and report an error status to the second processing circuit 102 (host layer).
[0053] Figure 3The hardware architecture also supports a third application scenario, where a new CS secure boot process is processed normally after the previous CS secure boot process has successfully completed. Assume the initial CS secure boot process managed by the first processing circuit 101 (controller layer) has completed. Subsequently, the second processing circuit 102 (host layer) generates and transmits a new HCI_LE_CS_Security_Enable command to the first processing circuit 101 via interface circuit 107 (HCI). Upon receiving the new command, the central processing circuit 103 within the first processing circuit 101 checks the status of any CS secure boot processes. Finding no CS secure boot process currently in progress because the previous process has completed, the central processing circuit 103 accepts the new HCI_LE_CS_Security_Enable command. The central processing circuit 103 then sends an HCI_Command_Status event, for example, a status of zero indicating successful reception, and returns to the second processing circuit 102 via interface circuit 107. Subsequently, the central processing circuit 103 will initiate a new CS secure boot process based on this new command, involving necessary link-layer communication with the peer device via RF circuit 104. This new process will execute normally until completion, at which point an HCI_LE_CS_Security_Enable_Complete event will be sent to the second processing circuit 102. Therefore, Figure 3 The hardware architecture shown facilitates the seamless startup and execution of a new CS Secure Boot process when the previous CS Secure Boot process is no longer in progress.
[0054] In summary, the controller layer of this invention, implemented, for example by the first processing circuit 101, effectively manages the secure initiation process of channel probing (CS). This management method is effective for processes triggered by various sources, such as multiple command requests from users rapidly repeating operations, or commands periodically initiated by background applications. The controller layer accurately assesses the current state of any ongoing secure initiation process. Based on this assessment, the controller layer decides how to handle a new request for another secure initiation process. If a secure initiation process is in progress, the new request is rejected to protect the integrity of the ongoing operation. Conversely, once a previous secure initiation process has successfully completed, the new request is accepted, and a new secure initiation process is initiated. This intelligent management, which relies on the current operational state, prevents potential errors by avoiding problems such as unintentional modification of security parameters or inconsistent encryption states that could result from multiple secure initiation operations being executed simultaneously. This approach significantly improves the reliability of distance measurements and further enhances system security. The disclosed management mechanism ensures that key security parameters of channel probing, such as CS_IV, CS_IN, and CS_PV, are correctly established and maintained at any given time. This is achieved by using a single secure initiation process that is not interfered with by other concurrent operations. Therefore, this mechanism helps defend against security threats such as distance spoofing interference or man-in-the-middle attacks. The overall security of channel detection is thus enhanced across different application scenarios.
[0055] Those skilled in the art will readily observe that many modifications and changes can be made to the apparatus and method while retaining the teachings of the invention. Therefore, the above disclosure should be interpreted only within the scope of the appended claims.
Claims
1. A Bluetooth processing circuit, comprising: The first memory is configured to store the first instruction; as well as A central processing circuit is coupled to the first memory and configured to execute a first instruction stored in the first memory to perform operations of the Bluetooth controller layer; This operation includes: Receive the first channel probe CS security enable command from the host layer to initiate the first CS security boot process with the peer Bluetooth device; The first CS secure boot process is initiated based on the first CS secure enable command; During the first CS secure boot process, a second CS secure enable command is received from the host layer; and Deny the second CS security enable command while the first CS security boot process is still in progress.
2. The Bluetooth processing circuit as described in claim 1, further comprising: An interface circuit, coupled to the central processing circuit, wherein the interface circuit is configured as follows: Receive the first CS security enable command and the second CS security enable command from the host layer; and The first CS security enable command and the second CS security enable command are forwarded to the central processing circuit.
3. The Bluetooth processing circuit as described in claim 2, wherein, This interface circuit is the Host Controller Interface (HCI).
4. The Bluetooth processing circuit as described in claim 1, wherein, This operation further includes: While the first CS secure boot process is still in progress, an error status event is sent to the host layer.
5. The Bluetooth processing circuit as described in claim 1, further comprising: The radio frequency (RF) circuit is coupled to the central processing circuit. The operations for initiating the first CS secure boot process include: The central processing circuit controls the RF circuit to transmit the Link Layer CS Security Request Protocol Data Unit LL_CS_SEC_REQ PDU to the peer Bluetooth device via the wireless radio frequency channel.
6. The Bluetooth processing circuit as described in claim 5, wherein, The radio frequency (RF) circuit is coupled to at least one antenna, and the RF circuit is configured to transmit the LL_CS_SEC_REQ PDU and receive radio frequency signals through at least one antenna.
7. The Bluetooth processing circuit as described in claim 5, wherein, The operation of the Bluetooth controller layer further includes: After transmitting the LL_CS_SEC_REQ PDU and rejecting the second CS security enable command, the link layer CS security response protocol data unit LL_CS_SEC_RSP PDU is received from the peer Bluetooth device via the RF circuit.
8. The Bluetooth processing circuit as described in claim 7, wherein, The operation of the Bluetooth controller layer further includes: After receiving the LL_CS_SEC_RSP PDU from the peer Bluetooth device, the first CS secure boot process is completed; and The interface circuit sends an HCI low-energy channel probe security enable completion event to the host layer, indicating the successful completion of the first CS security boot process.
9. The Bluetooth processing circuit as claimed in claim 1, further comprising: The processing circuitry is coupled to a second memory and configured to execute a second instruction stored in the second memory to perform host-level operations; The host-level operations performed by the processing circuit through executing the second instruction include: Generate the first CS security enable command and the second CS security enable command; and The first CS security enable command and the second CS security enable command are transmitted to the Bluetooth controller layer.
10. The Bluetooth processing circuit as described in claim 9, wherein, The second instruction includes instructions for the first user application and the second user application; Specifically, the first CS security enable command is generated by executing instructions from the first user application through the processing circuit; and Specifically, the second CS security enable command is generated by executing the instructions of the second user application through the processing circuit.
11. The Bluetooth processing circuit as described in claim 9, wherein, The host-level operations performed by the processing circuit through executing the second instruction further include: After generating the second CS security enable command, generate the third CS security enable command; and Transmit the third CS security enable command to the Bluetooth controller layer; The first time interval between the time of generating the first CS security enable command and the time of generating the second CS security enable command is equal to the second time interval between the time of generating the second CS security enable command and the time of generating the third CS security enable command.
12. The Bluetooth processing circuit as described in claim 9, wherein, The central processing circuitry and processing circuitry are embedded in a single system-on-a-chip (SoC).
13. The Bluetooth processing circuit of claim 9, wherein the central processing circuit is contained in a first physical chip, and the processing circuit is contained in a second physical chip different from the first physical chip.
14. A method for operating a Bluetooth processing circuit, the method comprising: Based on the first CS security enable command, the peer Bluetooth device initiates the first channel probe CS security boot process; as well as The second CS security enable command is denied while the first CS security boot process is still in progress.
15. The method of claim 14, further comprising: While the first CS secure boot process is still in progress, an error status event is sent to the host layer.
16. The method of claim 15, wherein an error status event is sent to the host layer via the Host Controller Interface (HCI).
17. The method of claim 14, wherein initiating the first CS secure boot process with the peer Bluetooth device based on the first CS secure enable command includes: Transmits Link Layer CS Security Request Protocol Data Unit (LL_CS_SEC_REQ PDU) to peer Bluetooth devices via a wireless radio frequency channel.
18. The method of claim 17, further comprising: After transmitting the LL_CS_SEC_REQ PDU and rejecting the second CS security enable command, the link layer CS security response protocol data unit LL_CS_SEC_RSP PDU is received from the peer Bluetooth device.
19. The method of claim 18, further comprising: After receiving the LL_CS_SEC_RSP PDU from the peer Bluetooth device, the first CS secure boot process is completed. as well as Send an HCI low-energy channel probe security enable completion event to the host layer, indicating that the first CS security startup process has been successfully completed.
20. The method of claim 14, further comprising: Generate the first CS security enable command, and the first CS security boot process is based on this command; as well as Generate a second CS security enable command that was rejected.