Bluetooth node pairing method and related device

Abstract

To provide an association method and device applied to nodes supporting Bluetooth communication.SOLUTION: A method includes the following: receiving a pairing request message from a first node, where the pairing request message includes information indicating whether the first node has a PSK pairing capability; in response to the pairing request message including information indicating that the first node has the PSK pairing capability, sending a pairing response message to the first node, where the pairing response message indicates performing pairing using a shared PSK; and authenticating the first node on the basis of the PSK. The embodiment of the present application can improve security during the node pairing process, and the node is not connected to an untrusted device. The solution can be used to improve autonomous driving or ADAS capabilities. It can be applied to the Internet of vehicles, for example, V2X, LTE-V, and V2 V.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present application relates to the field of communication technologies and connected vehicle technologies, and in particular to a Bluetooth node pairing method and related apparatus, for example, for Bluetooth communication in a cockpit domain. [Background technology]

[0002] With the rapid development of information technology, communication technology has become widely used in people's lives. While enjoying convenient communication, people are also threatened by security vulnerabilities and privacy leaks. Intelligent vehicles are used as an example. With the wide application of vehicle communication, communication can be implemented between a vehicle and another device and between components within a vehicle by utilizing wireless communication technology. Generally, before two nodes can implement wireless communication, an association relationship needs to be established between the two nodes. This process of establishing an association relationship is sometimes called a node pairing process.

[0003] In the pairing process between two Bluetooth nodes, there are four modes: Numeric Comparison, Just Work, Passkey Entry, and Out of Band. The pairing mode is related to the input / output capabilities of the node. For NoInputNoOutput nodes, DisplayOnly nodes, or DisplayYesNo nodes, in most cases, only Just Work mode or Numeric Comparison mode can be used for pairing. In such pairing modes, the security of the node is easily compromised. For example, when a mobile phone is paired with a Bluetooth headset, the headset cannot enter a passkey or display a screen, so the headset can only be connected in Just Work mode, i.e., by directly tapping the name of the Bluetooth headset on the mobile phone. In such pairing mode, an attacker can easily attack a node by utilizing a device connected in just work mode, or an attacker can attack a node that can only be connected in just work mode, which significantly threatens the privacy of users and the security of the vehicle. Particularly for in-vehicle communication systems, this situation can result in an untrusted connection to the vehicle, leading to communication between the vehicle and an untrusted attacker, and further endangering the safety of the driver and passengers.

[0004] Therefore, how to improve the security of the Bluetooth pairing process and prevent nodes from connecting to untrusted devices is a problem that is being studied by those skilled in the art. Summary of the Invention

[0005] SUMMARY OF THE INVENTION Embodiments of the present application disclose a Bluetooth node pairing method and related apparatus to improve the security of the node pairing process and prevent nodes from connecting to untrusted devices.

[0006] According to a first aspect, an embodiment of the present application discloses a Bluetooth node pairing method, including:

[0007] The second node receives a pairing request message from the first node, the pairing request message including information used to indicate whether the first node has pre-shared key (PSK) pairing capability.

[0008] The second node transmits a pairing response message to the first node in response to the pairing request message including information utilized to indicate that the first node has PSK pairing capability, the pairing response message being utilized to indicate that the first node will perform pairing by utilizing the first PSK shared by the first node and the second node.

[0009] The second node authenticates the first node based on the first PSK.

[0010] A PSK is a secret value shared by a first node and a second node. In this embodiment of the present application, the PSK shared with the second node is predefined or configured on the first node. Thus, the pairing request message may include information indicating that the first node has PSK pairing capability. Correspondingly, the PSK shared with the first node (referred to as the first PSK for ease of explanation) is also predefined or preconfigured on the second node. The second node may authenticate the first node based on the first PSK and determine that the first node's identity is trustworthy, and therefore, subsequent pairing can be successful. In this way, the identity of the node for which the PSK is preconfigured or defined is usually trustworthy. This avoids successful pairing between the second node and an untrustworthy node, improving the security of the node pairing process.

[0011] In possible implementations of the first aspect, the first node is a NoInputNoOutput Bluetooth node, a DisplayOnly Bluetooth node, or a DisplayYesNo Bluetooth node.

[0012] An existing NoInputNoOutput Bluetooth node can only pair with a second node in just work mode. A DisplayOnly Bluetooth node or a DisplayYesNo Bluetooth node does not have input / output capabilities. Therefore, if the second node does not have input / output capabilities, the second node also connects in just work mode. Because just work mode has low security, in such pairing, an attacker can easily attack the second node by exploiting the first node. Therefore, for the above three types of nodes, pairing can be performed by utilizing a PSK to improve the security of node pairing. Of course, for nodes with input / output capabilities, pairing can be performed by entering a passkey, or pairing can be performed by utilizing a PSK.

[0013] In another possible implementation of the first aspect, the method further comprises:

[0014] The second node determines that the second node shares the first PSK with the first node.

[0015] In yet another possible implementation of the first aspect, the second node determining that the second node shares the first PSK with the first node includes:

[0016] The second node obtains the first device identifier of the first node.

[0017] The second node determines that a first PSK exists that corresponds to the first device identifier.

[0018] In yet another possible implementation of the first aspect, the pairing request message includes an Input / Output Capabilities IOC field, where the IOC field includes information utilized to indicate whether the first node has PSK pairing capabilities.

[0019] The above describes the data format of the pairing request message. It can be understood that the value of the IOC field may represent information about whether the first node has PSK pairing capability or whether the first PSK shared with the second node exists on the first node. For example, when the IOC field is 0x05, it may indicate that the first node has PSK pairing capability.

[0020] In yet another possible implementation of the first aspect, one portion of the bits in the IOC field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0021] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0022] The above describes another data format of the pairing request message. It can be understood that one part of the bits in the IOC field contains the PSK capability value of the first node. For example, the IOC field may contain 8 bits. Two bits contain the PSK capability value of the first node, and the PSK capability value is used to indicate whether the first node has PSK pairing capability. For example, "01" indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0023] Furthermore, another part of the bits in the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the 6 bits in the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0024] In yet another possible implementation of the first aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0025] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0026] The above describes yet another data format of the pairing request message. It can be seen that the PSK capability field is used to indicate the PSK capability value of the first node. For example, 0x01 indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0027] Furthermore, the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0028] In yet another possible implementation of the first aspect, before the second node sends a pairing response message to the first node, the method further includes:

[0029] The second node determines a pairing response message based on the pairing request message and preset pairing mode priority information, where the pairing mode priority information indicates that when the first node and the second node share a PSK, pairing implemented by utilizing the PSK shared by the first node and the second node has the highest priority among multiple pairing modes.

[0030] In yet another possible implementation of the first aspect, the second node authenticating the first node based on the first PSK includes:

[0031] The second node receives the first authentication parameter from the first node.

[0032] The second node verifies the first authentication parameter based on the first PSK.

[0033] The above implementation describes a manner in which a second node authenticates a first node, where first authentication parameters are generated by the first node based on a first PSK. Because the second node also has the first PSK, the second node can verify the first authentication parameters based on the first PSK in a corresponding manner to determine whether the first PSK on the first node matches the first PSK on the second node. If the first PSK on the first node matches the first PSK on the second node, this indicates that the identity of the first node is trustworthy. This prevents successful pairing between the second node and an untrusted node and improves the security of the node pairing process.

[0034] In yet another possible implementation of the first aspect, the method further comprises:

[0035] The second node generates second authentication parameters based on the first PSK.

[0036] The second node sends the second authentication parameters to the first node.

[0037] It can be understood that the second node may also generate second authentication parameters based on the first PSK, and the second authentication parameters are utilized by the first node to authenticate the second node.

[0038] In yet another possible implementation of the first aspect, the second node generating the second authentication parameters based on the first PSK includes:

[0039] The second node receives the first freshness parameter sent by the first node.

[0040] The second node generates second authentication parameters based on the first freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0041] In yet another possible implementation of the first aspect, before the second node receives the first authentication parameters from the first node, the method further includes:

[0042] The second node sends a second freshness parameter to the first node.

[0043] The second node verifying the first authentication parameter based on the first PSK further includes:

[0044] The second node generates a second check parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK.

[0045] The second node determines, based on the second check parameter and the first authentication parameter, that the first authentication parameter has been successfully verified.

[0046] In yet another possible implementation of the first aspect, after the second node authenticates the first node based on the first PSK, the method further includes:

[0047] The second node receives a third authentication parameter from the first node.

[0048] The second node generates a fourth check parameter based on the PSK capability value of the first node.

[0049] The second node determines that the authenticity authentication of the first node's PSK capability value is successful based on the fourth check parameter and the third authentication parameter.

[0050] The method further includes:

[0051] The second node generates a fourth authentication parameter based on the PSK capability value of the second node.

[0052] The second node sends the fourth authentication parameter to the first node.

[0053] It can be understood that if the first pairing request message includes the PSK capability value of the first node, the second node can authenticate the authenticity of the PSK capability value of the first node to avoid tampering with the PSK capability value of the first node.

[0054] According to a second aspect, an embodiment of the present application discloses a Bluetooth node pairing method, including:

[0055] The first node sends a pairing request message to the second node, the pairing request message including information used to indicate that the first node has pre-shared key (PSK) pairing capability.

[0056] The first node receives a pairing response message fed back by the second node, which is used to indicate that pairing is to be performed by utilizing a first PSK shared by the first node and the second node.

[0057] The first node authenticates the second node based on the first PSK.

[0058] It can be understood that a PSK is a secret value shared by a first node and a second node, and the PSK shared with the second node is predefined or configured on the first node. Thus, the pairing request message may indicate that the first node has PSK pairing capability. Correspondingly, the PSK shared with the first node (referred to as the first PSK for ease of explanation) is also predefined or preconfigured on the second node. The first node may authenticate the second node based on the first PSK and determine that the identity of the second node is trusted, and therefore, subsequent pairing can be successful. In this way, the identity of the node for which the PSK is preconfigured or defined is typically trusted. This avoids successful pairing between the first node and an untrusted node, improving the security of the node pairing process.

[0059] In possible implementations of the second aspect, the first node is a NoInputNoOutput Bluetooth node, a DisplayOnly Bluetooth node, or a DisplayYesNo Bluetooth node.

[0060] An existing NoInputNoOutput Bluetooth node can only pair with a second node in just work mode. A DisplayOnly Bluetooth node or a DisplayYesNo Bluetooth node does not have input / output capabilities. Therefore, if the second node does not have input / output capabilities, the second node also connects in just work mode. Because just work mode has low security, in such pairing, an attacker can easily attack the second node by exploiting the first node. Therefore, for the above three types of nodes, pairing can be performed by utilizing a PSK to improve the security of node pairing. Of course, for nodes with input / output capabilities, pairing can be performed by entering a passkey, or pairing can be performed by utilizing a PSK.

[0061] In another possible implementation of the second aspect, before the first node sends a pairing request message to the second node, the method further includes:

[0062] The first node determines that the second node shares a first PSK with the first node.

[0063] In yet another possible implementation of the second aspect, the first node determining that the second node will share the first PSK with the first node includes:

[0064] The first node obtains a second device identifier of the second node.

[0065] The first node determines that a first PSK exists that corresponds to the second device identifier.

[0066] In yet another possible implementation of the second aspect, the pairing request message includes an Input / Output Capabilities IOC field, which includes information utilized to indicate whether the first node has PSK pairing capabilities.

[0067] The above describes the data format of the pairing request message. It can be understood that the value of the IOC field may represent information about whether the first node has PSK pairing capability or whether the first PSK shared with the second node exists on the first node. For example, when the IOC field is 0x05, it may indicate that the first node has PSK pairing capability.

[0068] In yet another possible implementation of the second aspect, one portion of the bits in the IOC field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0069] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0070] The above describes another data format of the pairing request message. It can be understood that one part of the bits in the IOC field contains the PSK capability value of the first node. For example, the IOC field may contain 8 bits. Two bits contain the PSK capability value of the first node, and the PSK capability value is used to indicate whether the first node has PSK pairing capability. For example, "01" indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0071] Furthermore, another part of the bits in the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the 6 bits in the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0072] In yet another possible implementation of the second aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0073] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0074] The above describes yet another data format of the pairing request message. It can be seen that the PSK capability field is used to indicate the PSK capability value of the first node. For example, 0x01 indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0075] Furthermore, the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0076] In yet another possible implementation of the second aspect, the first node authenticating the second node based on the first PSK includes:

[0077] The first node receives a second authentication parameter from the second node.

[0078] The first node verifies the second authentication parameter based on the first PSK.

[0079] The above implementation describes a manner in which a first node authenticates a second node, where second authentication parameters are generated by the second node based on a first PSK. Because the first node also has the first PSK, the first node can verify the second authentication parameters based on the first PSK in a corresponding manner to determine whether the first PSK on the first node matches the first PSK on the second node. If the first PSK on the first node matches the first PSK on the second node, this indicates that the identity of the second node is trustworthy. This prevents successful pairing between the first node and an untrusted node and improves the security of the node pairing process.

[0080] In yet another possible implementation of the second aspect, the method further comprises:

[0081] The first node generates a first authentication parameter based on the first PSK.

[0082] The first node sends a first authentication parameter to the second node.

[0083] It can be understood that the first node may also generate a first authentication parameter based on the first PSK, and the first authentication parameter is utilized by the second node to authenticate the first node.

[0084] In yet another possible implementation of the second aspect, the first node generating the first authentication parameter based on the first PSK includes:

[0085] The first node receives the second freshness parameter sent by the second node.

[0086] The first node generates a first authentication parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0087] In yet another possible implementation of the second aspect, before the first node receives the second authentication parameters from the second node, the method further includes:

[0088] The first node transmits a first freshness parameter to the second node.

[0089] The first node verifying the second authentication parameter based on the first PSK further includes:

[0090] The first node generates a first check parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK.

[0091] The first node determines, based on the first check parameter and the second authentication parameter, that the second authentication parameter has been successfully verified.

[0092] In yet another possible implementation of the second aspect, after the second node authenticates the first node based on the first PSK, the method further includes:

[0093] The second node receives a third authentication parameter from the first node.

[0094] The second node generates a fourth check parameter based on the PSK capability value of the first node.

[0095] The second node determines that the authenticity authentication of the first node's PSK capability value is successful based on the fourth check parameter and the third authentication parameter.

[0096] The method further includes:

[0097] The second node generates a fourth authentication parameter based on the PSK capability value of the second node.

[0098] The second node sends the fourth authentication parameter to the first node.

[0099] It can be appreciated that the first node may authenticate the authenticity of the PSK capability value of the second node to avoid tampering with the PSK capability value of the second node.

[0100] According to a third aspect, an embodiment of the present application comprises: a receiving unit configured to receive a pairing request message from a first node, the pairing request message including information utilized to indicate whether the first node has pre-shared key (PSK) pairing capability; a transmitting unit configured to transmit a pairing response message to the first node in response to the pairing request message including information utilized to indicate that the first node has PSK pairing capability, the pairing response message utilized to indicate that pairing will be performed by utilizing a first PSK shared by the first node and the second node; a processing unit configured to authenticate the first node based on the first PSK; A Bluetooth pairing device is disclosed.

[0101] It can be understood that a PSK is a secret value shared by a first node and a second node, and the PSK shared with the second node is predefined or configured on the first node. Therefore, the device may include information in the pairing request message indicating that the first node has PSK pairing capability. Correspondingly, the first PSK shared with the first node is also predefined or preconfigured on the second node. The device may authenticate the first node based on the first PSK and determine that the identity of the first node is trusted, and therefore, subsequent pairing can be successful. In this way, the identity of a node for which a PSK is preconfigured or defined is usually trusted. This avoids successful pairing between the device and an untrusted node and improves the security of the node pairing process.

[0102] In a possible implementation of the third aspect, the processing unit The second node decides to share the first PSK with the first node It is further configured as follows.

[0103] In another possible implementation of the third aspect, the processing unit is, in particular, Obtain a first device identifier for the first node; Determine that a first PSK exists that corresponds to a first device identifier. It is configured as follows.

[0104] In yet another possible implementation of the third aspect, the pairing request message includes an Input / Output Capabilities IOC field, where the IOC field includes information utilized to indicate whether the first node has PSK pairing capabilities.

[0105] In yet another possible implementation of the third aspect, the pairing request message includes an Input / Output Capabilities IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0106] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0107] In yet another possible implementation of the third aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0108] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0109] In yet another possible implementation of the third aspect, the processing unit is further configured to determine a pairing response message based on the pairing request message and predetermined pairing mode priority information, where the pairing mode priority information indicates that when the first node and the second node share a PSK, a pairing implemented by utilizing the PSK shared by the first node and the second node has a highest priority among multiple pairing modes.

[0110] In yet another possible implementation of the third aspect, the receiving unit is further configured to receive a first authentication parameter from the first node.

[0111] The processing unit is further configured to verify the first authentication parameter based on the first PSK.

[0112] In yet another possible implementation of the third aspect, the processing unit is further configured to generate a second authentication parameter based on the first PSK.

[0113] The sending unit is further configured to send the second authentication parameter to the first node.

[0114] In yet another possible implementation of the third aspect, the receiving unit is further configured to receive a third authentication parameter from the first node.

[0115] The processing unit is further configured to generate a fourth check parameter based on the PSK capability value of the first node.

[0116] The processing unit is further configured to determine, based on the fourth check parameter and the third authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0117] The processing unit is further configured to generate a fourth authentication parameter based on the PSK capability value of the second node.

[0118] The sending unit is further configured to send a fourth authentication parameter to the first node.

[0119] According to a fourth aspect, an embodiment of the present application comprises: a transmitting unit configured to transmit a pairing request message to a second node, the pairing request message including information utilized to indicate that the first node has pre-shared key (PSK) pairing capability; a receiving unit configured to receive a pairing response message fed back by the second node, the pairing response message being utilized to indicate that pairing will be performed by utilizing a first PSK shared by the first node and the second node; and a processing unit configured to authenticate the second node based on the first PSK; A Bluetooth pairing device is disclosed.

[0120] It can be understood that a PSK is a secret value shared by a first node and a second node, and the PSK shared with the second node is predefined or configured on the first node. Thus, the second node may indicate in the pairing request message that the first node has PSK pairing capability. Correspondingly, the PSK shared with the first node (referred to as the first PSK for ease of explanation) is also predefined or preconfigured on the second node. The device may authenticate the second node based on the first PSK and determine that the identity of the second node is trusted, and therefore, subsequent pairing can be successful. In this way, the identity of a node for which a PSK is preconfigured or defined is typically trusted. This avoids successful pairing between the device and an untrusted node and improves the security of the node pairing process.

[0121] In a possible implementation of the fourth aspect, the processing unit is further configured to determine that the second node shares the first PSK with the first node.

[0122] In another possible implementation of the fourth aspect, the processing unit is, in particular: Obtain a second device identifier for the second node; Determining that a first PSK exists that corresponds to a second device identifier It is configured as follows.

[0123] In yet another possible implementation of the fourth aspect, the pairing request message includes an Input / Output Capabilities IOC field, where the IOC field includes information utilized to indicate whether the first node has PSK pairing capability.

[0124] In yet another possible implementation of the fourth aspect, one portion of the bits in the IOC field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0125] Another portion of the bits in the IOC field is used to indicate the output capabilities of the first node.

[0126] In yet another possible implementation of the fourth aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0127] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0128] In yet another possible implementation of the fourth aspect, the receiving unit is further configured to receive second authentication parameters from the second node.

[0129] The processing unit is further configured to verify a second authentication parameter based on the first PSK.

[0130] In yet another possible implementation of the fourth aspect, the processing unit is further configured to generate a first authentication parameter based on the first PSK.

[0131] The sending unit is further configured to send the first authentication parameter to the second node.

[0132] In yet another possible implementation of the fourth aspect, the pairing response message includes a PSK capability value of the second node, and the PSK capability value of the second node is utilized to indicate that the second node has PSK pairing capability.

[0133] The receiving unit is further configured to receive a fourth authentication parameter from the second node.

[0134] The processing unit is further configured to generate a third check parameter based on the PSK capability value of the second node.

[0135] The processing unit is further configured to determine, based on the third check parameter and the fourth authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0136] The processing unit is further configured to generate a third authentication parameter based on the PSK capability value of the first node.

[0137] The sending unit is further configured to send a third authentication parameter to the second node.

[0138] According to a fifth aspect, an embodiment of the present application discloses a Bluetooth node pairing method, including:

[0139] The second node receives a pairing request message from the first node. The pairing request message includes information used to indicate the pairing capabilities of the first node. The pairing capabilities of the first node include whether the first node has the first node's pre-shared key (PSK) pairing capabilities and input / output capabilities.

[0140] The second node determines a pairing mode based on the information about the pairing capabilities of the first node and the information about the pairing capabilities of the second node. The pairing capabilities of the second node include whether the second node has PSK pairing capabilities and input / output capabilities of the second node. The pairing modes include PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0141] The second node sends a pairing response message to the first node, the pairing response message including information used to indicate the pairing capabilities of the second node.

[0142] The second node performs pairing with the first node based on the pairing mode.

[0143] It can be understood that the pairing request message includes information about the pairing capabilities of the first node, and the second node may determine a corresponding pairing mode based on the requirements and whether the first node has the PSK pairing capabilities and input / output capabilities of the first node. For example, the second node may determine a pairing mode that meets the requirements of the second node by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0144] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0145] In a possible implementation of the fifth aspect, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0146] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0147] The data format of the pairing request message has been described above. It can be understood that one part of the bits in the IOC field contains the PSK capability value of the first node. For example, the IOC field may contain 8 bits. Two bits contain the PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability. For example, "01" indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0148] Furthermore, another part of the bits in the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the 6 bits in the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0149] In another possible implementation of the fifth aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0150] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0151] The above describes another data format of the pairing request message. It can be understood that the PSK capability field is used to indicate the PSK capability value of the first node. For example, 0x01 indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0152] Furthermore, the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0153] In yet another possible implementation of the fifth aspect, the second node determining a pairing mode based on information regarding the pairing capabilities of the first node and information regarding the pairing capabilities of the second node includes:

[0154] The second node determines that the first node has PSK pairing capability based on information about the pairing capability of the first node.

[0155] The second node determines that the second node shares the first PSK with the first node.

[0156] The second node performs the pairing by utilizing the first PSK shared by the first node and the second node.

[0157] In yet another possible implementation of the fifth aspect, the second node determining that the second node shares the first PSK with the first node includes:

[0158] The second node obtains the first device identifier of the first node.

[0159] The second node determines that a first PSK exists that corresponds to the first device identifier.

[0160] In yet another possible implementation of the fifth aspect, the second node determining a pairing mode based on information regarding the pairing capabilities of the first node and information regarding the pairing capabilities of the second node includes:

[0161] The second node determines that the first node has PSK pairing capability based on information about the pairing capability of the first node.

[0162] The second node determines that the second node shares the first PSK with the first node.

[0163] The second node determines a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, and the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0164] The second node determines the pairing mode based on the priority of the first pairing mode and the priority of the PSK-based pairing.

[0165] In yet another possible implementation of the fifth aspect, the second node determining a pairing mode based on information regarding the pairing capabilities of the first node and information regarding the pairing capabilities of the second node includes:

[0166] The second node determines that the first node has PSK pairing capability based on information about the pairing capability of the first node.

[0167] The second node determines that the second node shares the first PSK with the first node.

[0168] The second node determines a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, and the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0169] The second node determines the pairing mode based on the priority of the first pairing mode and the priority of the PSK-based pairing.

[0170] In yet another possible implementation of the fifth aspect, the second node performing the pairing by utilizing the first PSK shared by the first node and the second node includes:

[0171] The second node receives the first authentication parameter from the first node.

[0172] The second node verifies the first authentication parameter based on the first PSK.

[0173] In yet another possible implementation of the fifth aspect, the method further comprises:

[0174] The second node generates second authentication parameters based on the first PSK.

[0175] The second node sends the second authentication parameters to the first node.

[0176] In yet another possible implementation of the fifth aspect, the second node generating the second authentication parameters based on the first PSK includes:

[0177] The second node receives the first freshness parameter sent by the first node.

[0178] The second node generates second authentication parameters based on the first freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0179] In yet another possible implementation of the fifth aspect, before the second node receives the first authentication parameters from the first node, the method further includes:

[0180] The second node sends a second freshness parameter to the first node.

[0181] The second node verifying the first authentication parameter based on the first PSK further includes:

[0182] The second node generates a second check parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK.

[0183] The second node determines, based on the second check parameter and the first authentication parameter, that the first authentication parameter has been successfully verified.

[0184] In yet another possible implementation of the fifth aspect, after the second node authenticates the first node based on the first PSK, the method further includes:

[0185] The second node receives a third authentication parameter from the first node.

[0186] The second node generates a fourth check parameter based on the PSK capability value of the first node.

[0187] The second node determines that the authenticity authentication of the first node's PSK capability value is successful based on the fourth check parameter and the third authentication parameter.

[0188] The method further includes:

[0189] The second node generates a fourth authentication parameter based on the PSK capability value of the second node.

[0190] The second node sends the fourth authentication parameter to the first node.

[0191] According to a sixth aspect, an embodiment of the present application discloses a Bluetooth node pairing method, including:

[0192] The first node sends a pairing request message to the second node. The pairing request message includes information used to indicate the pairing capabilities of the first node. The pairing capabilities of the first node include whether the first node has pre-shared key (PSK) pairing capabilities and input / output capabilities of the first node.

[0193] The first node receives a pairing response message from the second node. The pairing response message includes information used to indicate the pairing capabilities of the second node. The pairing capabilities of the second node include whether the second node has PSK pairing capabilities and input / output capabilities of the second node.

[0194] The first node determines a pairing mode based on the information about the pairing capabilities of the first node and the information about the pairing capabilities of the second node, where the pairing mode includes PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0195] The first node performs pairing with the second node based on the pairing mode.

[0196] It can be understood that the pairing request message includes information about the pairing capabilities of the first node, and the pairing response message includes information about the pairing capabilities of the second node. The first node may determine a corresponding pairing mode based on the requirements and based on the information about the pairing capabilities of the first node and the information about the pairing capabilities of the second node. For example, the first node may determine a pairing mode that meets the requirements by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0197] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0198] In a possible implementation of the sixth aspect, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0199] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0200] The data format of the pairing request message has been described above. It can be understood that one part of the bits in the IOC field contains the PSK capability value of the first node. For example, the IOC field may contain 8 bits. Two bits contain the PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability. For example, "01" indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0201] Furthermore, another part of the bits in the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the 6 bits in the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0202] In another possible implementation of the sixth aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0203] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0204] The above describes yet another data format of the pairing request message. It can be seen that the PSK capability field is used to indicate the PSK capability value of the first node. For example, 0x01 indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0205] Furthermore, the IOC field is used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching can be performed between the first node and the second node in Passkey entry (PE) mode.

[0206] In yet another possible implementation of the sixth aspect, before the first node sends a pairing request message to the second node, the method includes:

[0207] The first node determines that the second node shares a first PSK with the first node.

[0208] The first node determining a pairing mode based on the information regarding the pairing capability of the first node and the information regarding the pairing capability of the second node includes:

[0209] The first node determines that the first node has PSK pairing capability based on information about the pairing capability of the second node.

[0210] The first node performs the pairing by utilizing a first PSK shared by the first node and the second node.

[0211] In yet another possible implementation of the sixth aspect, the first node determining that the second node shares the first PSK with the first node includes:

[0212] The first node obtains a second device identifier of the second node.

[0213] The first node determines that a first PSK exists that corresponds to the second device identifier.

[0214] In yet another possible implementation of the sixth aspect, the second node determining a pairing mode based on information regarding the pairing capabilities of the first node and information regarding the pairing capabilities of the second node includes:

[0215] The first node determines, based on information about the pairing capabilities of the second node, that the second node does not have PSK pairing capabilities.

[0216] The first node determines a pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, which may be Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0217] In yet another possible implementation of the sixth aspect, the second node determining a pairing mode based on information regarding the pairing capabilities of the first node and information regarding the pairing capabilities of the second node includes:

[0218] The first node determines that the first node has PSK pairing capability based on information about the pairing capability of the second node.

[0219] The first node determines that the second node shares a first PSK with the first node.

[0220] The first node determines a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, and the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0221] The first node determines the pairing mode based on the priority of the first pairing mode and the priority of the PSK-based pairing.

[0222] In yet another possible implementation of the sixth aspect, the first node performing pairing by utilizing a first PSK shared by the first node and the second node includes:

[0223] The first node receives a second authentication parameter from the second node.

[0224] The first node verifies the second authentication parameter based on the first PSK.

[0225] In yet another possible implementation of the sixth aspect, the method further comprises:

[0226] The first node generates a first authentication parameter based on the first PSK.

[0227] The first node sends a first authentication parameter to the second node.

[0228] In yet another possible implementation of the sixth aspect, the first node generating the first authentication parameter based on the first PSK includes:

[0229] The first node receives the second freshness parameter sent by the second node.

[0230] The first node generates a first authentication parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0231] In yet another possible implementation of the sixth aspect, before the first node receives the second authentication parameters from the second node, the method further includes:

[0232] The first node transmits a first freshness parameter to the second node.

[0233] The first node verifying the second authentication parameter based on the first PSK further includes:

[0234] The first node generates a first check parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK.

[0235] The first node determines, based on the first check parameter and the second authentication parameter, that the second authentication parameter has been successfully verified.

[0236] In yet another possible implementation of the sixth aspect, after the second node authenticates the first node based on the first PSK, the method further includes:

[0237] The second node receives a third authentication parameter from the first node.

[0238] The second node generates a fourth check parameter based on the PSK capability value of the first node.

[0239] The second node determines that the authenticity authentication of the first node's PSK capability value is successful based on the fourth check parameter and the third authentication parameter.

[0240] The method further includes:

[0241] The second node generates a fourth authentication parameter based on the PSK capability value of the second node.

[0242] The second node sends the fourth authentication parameter to the first node.

[0243] According to a seventh aspect, an embodiment of the present application comprises: a receiving unit configured to receive a pairing request message from a first node, the pairing request message including information utilized to indicate pairing capabilities of the first node, the pairing capabilities of the first node including whether the first node has pre-shared key (PSK) pairing capabilities and input / output capabilities of the first node; a processing unit configured to determine a pairing mode based on information regarding a pairing capability of the first node and information regarding a pairing capability of the second node, wherein the pairing capability of the second node includes whether the second node has PSK pairing capability and input / output capability of the second node, and the pairing mode includes PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); a transmitting unit configured to transmit a pairing response message to the first node, the pairing response message including information utilized to indicate pairing capability of the second node; A Bluetooth pairing device is disclosed.

[0244] The processing unit is further configured to perform pairing with the first node based on the pairing mode.

[0245] It can be understood that the pairing request message includes information regarding the pairing capabilities of the first node, and the apparatus can determine a corresponding pairing mode based on the requirements and whether the first node has the PSK pairing capabilities and input / output capabilities of the first node. For example, the apparatus can determine a pairing mode that meets the requirements of the second node by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0246] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0247] In a possible implementation of the seventh aspect, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0248] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0249] In another possible implementation of the seventh aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0250] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0251] In yet another possible implementation of the seventh aspect, the processing unit is configured to, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; Performing pairing by utilizing a first PSK shared by the first node and the second node It is configured as follows.

[0252] In yet another possible implementation of the seventh aspect, the processing unit is configured to, inter alia: Obtain a first device identifier for the first node; Determine that a first PSK exists that corresponds to a first device identifier. It is configured as follows.

[0253] In yet another possible implementation of the seventh aspect, the processing unit is configured to, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0254] In yet another possible implementation of the seventh aspect, the processing unit is configured to, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0255] In yet another possible implementation of the seventh aspect, the receiving unit is further configured to receive a first authentication parameter from the first node.

[0256] The processing unit is further configured to verify the first authentication parameter based on the first PSK.

[0257] In yet another possible implementation of the seventh aspect, the processing unit is further configured to generate a second authentication parameter based on the first PSK.

[0258] The sending unit is further configured to send the second authentication parameter to the first node.

[0259] In yet another possible implementation of the seventh aspect, the receiving unit is further configured to receive a first freshness parameter sent by the first node.

[0260] The processing unit is further configured to generate a second authentication parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0261] In yet another possible implementation of the seventh aspect, the sending unit is further configured to send a second freshness parameter to the first node.

[0262] The processing unit is further configured to generate a second check parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK.

[0263] The processing unit is further configured to: the second node determine, based on the second check parameter and the first authentication parameter, that the first authentication parameter has been successfully verified.

[0264] In yet another possible implementation of the seventh aspect, the receiving unit is further configured to receive a third authentication parameter from the first node.

[0265] The processing unit is further configured to generate a fourth check parameter based on the PSK capability value of the first node.

[0266] The processing unit is further configured to determine, based on the fourth check parameter and the third authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0267] The processing unit is further configured to generate a fourth authentication parameter based on the PSK capability value of the second node.

[0268] The sending unit is further configured to send a fourth authentication parameter to the first node.

[0269] According to an eighth aspect, an embodiment of the present application comprises: a transmitting unit configured to transmit a pairing request message to a second node, the pairing request message including information utilized to indicate a pairing capability of the first node, the pairing capability of the first node including whether the first node has a pre-shared key (PSK) pairing capability and an input / output capability of the first node; a receiving unit configured to receive a pairing response message from the second node, the pairing response message including information utilized to indicate pairing capabilities of the second node, the pairing capabilities of the second node including whether the second node has PSK pairing capabilities and input / output capabilities of the second node; and a processing unit configured to determine a pairing mode based on information regarding a pairing capability of the first node and information regarding a pairing capability of the second node, the pairing mode including PSK-based pairing, numeric comparison (NC), Just Work (JW), or passkey entry (PE); A Bluetooth node pairing device is disclosed, including:

[0270] The processing unit is further configured to perform pairing with the second node based on the pairing mode.

[0271] It can be understood that the pairing request message includes information about the pairing capability of the first node, and the pairing response message includes information about the pairing capability of the second node. The apparatus may determine a corresponding pairing mode based on the requirements and based on the information about the pairing capability of the first node and the information about the pairing capability of the second node. For example, the apparatus may determine a pairing mode that meets the requirements by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0272] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0273] In a possible implementation of the eighth aspect, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0274] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0275] In another possible implementation of the eighth aspect, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0276] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0277] In yet another possible implementation of the eighth aspect, the processing unit: The second node determines to share the first PSK with the first node; determining, based on information about the pairing capability of the second node, that the first node has PSK pairing capability; Performing pairing by utilizing a first PSK shared by the first node and the second node It is further configured as follows.

[0278] In yet another possible implementation of the eighth aspect, the processing unit obtains a second device identifier of the second node; Determining that a first PSK exists that corresponds to a second device identifier It is further configured as follows.

[0279] In yet another possible implementation of the eighth aspect, the processing unit is configured to, inter alia: determining, based on information regarding the pairing capability of the second node, that the second node does not have PSK pairing capability; determining a pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, the pairing mode being Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); It is configured as follows.

[0280] In yet another possible implementation of the eighth aspect, the processing unit is configured to, inter alia: determining, based on information about the pairing capability of the second node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0281] In yet another possible implementation of the eighth aspect, the receiving unit is further configured to receive second authentication parameters from the second node.

[0282] The processing unit is further configured to verify a second authentication parameter based on the first PSK.

[0283] In yet another possible implementation of the eighth aspect, the processing unit is further configured to generate a first authentication parameter based on the first PSK.

[0284] The sending unit is further configured to send the first authentication parameter to the second node.

[0285] In yet another possible implementation of the eighth aspect, the receiving unit is further configured to receive a second freshness parameter sent by the second node.

[0286] The processing unit is further configured to generate a first authentication parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0287] In yet another possible implementation of the eighth aspect, the sending unit is further configured to send the first freshness parameter to the second node.

[0288] The processing unit is further configured to generate a first check parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK.

[0289] The processing unit is further configured to: determine, based on the first check parameter and the second authentication parameter, that the second authentication parameter has been successfully verified.

[0290] In yet another possible implementation of the eighth aspect, the receiving unit is further configured to receive a third authentication parameter from the first node.

[0291] The processing unit is further configured to generate a fourth check parameter based on the PSK capability value of the first node.

[0292] The processing unit is further configured to determine, based on the fourth check parameter and the third authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0293] The processing unit is further configured to generate a fourth authentication parameter based on the PSK capability value of the second node.

[0294] The sending unit is further configured to send a fourth authentication parameter to the first node.

[0295] According to a ninth aspect, an embodiment of the present application further provides a Bluetooth pairing device. The Bluetooth pairing device includes at least one processor and a communication interface. The communication interface is configured to transmit and / or receive data. The at least one processor is configured to invoke a computer program stored in at least one memory, such that the device implements the method described in the first aspect or any one of the possible implementations of the first aspect, the second aspect or any one of the possible implementations of the second aspect, the fifth aspect or any one of the possible implementations of the fifth aspect, or the sixth aspect or any one of the possible implementations of the sixth aspect.

[0296] According to a tenth aspect, an embodiment of the present application further provides a communication system. The communication system includes a first node and a second node. The first node is the device described in the third aspect or any one of the possible implementations of the third aspect, or the seventh aspect or any one of the possible implementations of the seventh aspect. The second node is the device described in the fourth aspect or any one of the possible implementations of the fourth aspect, or the eighth aspect or any one of the possible implementations of the eighth aspect.

[0297] According to an eleventh aspect, an embodiment of the present application discloses a computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed on one or more processors, performs a method described in the first aspect or any one of the possible implementations of the first aspect, the second aspect or any one of the possible implementations of the second aspect, the fifth aspect or any one of the possible implementations of the fifth aspect, or the sixth aspect or any one of the possible implementations of the sixth aspect.

[0298] According to a twelfth aspect, an embodiment of the present application discloses a computer program product, which, when executed on one or more processors, causes the apparatus to perform a method set forth in the first aspect or any one of its possible implementations, the second aspect or any one of its possible implementations, the fifth aspect or any one of its possible implementations, or the sixth aspect or any one of its possible implementations.

[0299] According to a thirteenth aspect, an embodiment of the present application discloses a chip system. The chip system includes at least one processor, a memory, and an interface circuit. The interface circuit is configured to provide information input and output to the at least one processor. The memory stores a computer program, which, when executed on the one or more processors, performs the method described in the first aspect or any one of the possible implementations of the first aspect, or the method described in the fifth aspect or any one of the possible implementations of the fifth aspect.

[0300] According to a fourteenth aspect, an embodiment of the present application discloses a chip system. The chip system includes at least one processor, a memory, and an interface circuit. The interface circuit is configured to provide information input and output to the at least one processor. The memory stores a computer program, which, when executed on the one or more processors, performs the method described in the second aspect or any one of the possible implementations of the second aspect, or the method described in the sixth aspect or any one of the possible implementations of the sixth aspect.

[0301] According to a fifteenth aspect, an embodiment of the present application discloses a vehicle. The vehicle includes a first node (e.g., a cockpit domain controller CDC of an automobile). The first node is the device described in the third aspect or any one of the possible implementations of the third aspect, or the seventh aspect or any one of the possible implementations of the seventh aspect.

[0302] Furthermore, the vehicle includes a second node (e.g., at least one of a camera, a screen, a microphone, a speaker, a radar, an electronic key, and a module such as a passive entry / passive start system controller), wherein the second node is a device described in the fourth aspect or any one of the possible implementations of the fourth aspect, or the eighth aspect or any one of the possible implementations of the eighth aspect. [Brief explanation of the drawings]

[0303] The following describes the accompanying drawings that are used in the embodiments of the present application.

[0304] [Figure 1] 1 is a schematic diagram of an application scenario according to an embodiment of the present application; [Figure 2] 2 is a flowchart of a Bluetooth pairing method according to an embodiment of the present application. [Figure 3]FIG. 2 is a schematic diagram of a frame structure of a pairing request message according to an embodiment of the present application; [Figure 4] FIG. 10 is a schematic diagram of a frame structure of another pairing request message according to an embodiment of the present application; [Figure 5] FIG. 10 is a schematic diagram of a frame structure of yet another pairing request message according to an embodiment of the present application; [Figure 6] FIG. 2 is a schematic diagram of a method for determining a pairing mode according to an embodiment of the present application; [Figure 7] 4 is a flowchart of another Bluetooth pairing method according to an embodiment of the present application. [Figure 8] 4 is a flowchart of another Bluetooth pairing method according to an embodiment of the present application. [Figure 9A] 4 is a flowchart of another Bluetooth pairing method according to an embodiment of the present application. [Figure 9B] 4 is a flowchart of another Bluetooth pairing method according to an embodiment of the present application. [Figure 10A] 4 is a flowchart of another Bluetooth pairing method according to an embodiment of the present application. [Figure 10B] 4 is a flowchart of another Bluetooth pairing method according to an embodiment of the present application. [Figure 11] 1 is a schematic diagram of the structure of a Bluetooth pairing device according to an embodiment of the present application; [Figure 12] 1 is a schematic diagram of the structure of another Bluetooth pairing device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0305] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application. It should be noted that in this application, words such as "example" or "for example" are used to indicate providing an example, illustration, or explanation. Any embodiment or design manner described in this application using "example" or "for example" should not be described as being preferred or having more advantages than another embodiment or design manner. The use of words such as "example" or "for example" is intended to present related concepts in a particular manner.

[0306] The following first briefly describes the relevant technologies and terminology in this application for ease of understanding.

[0307] 1. Node

[0308] A node is an electronic device capable of transmitting and receiving data. For example, a node may be a cockpit domain device or a module in a cockpit domain device (e.g., one or more of a cockpit domain controller (CDC), a camera, a screen, a microphone, a speaker, an electronic key, and a passive entry / passive start system controller). In a specific implementation, a node may alternatively be a data forwarding device, for example, a router, a repeater, a bridge, or a switch, or may be a terminal device, for example, various types of user equipment (UE), a mobile phone, a tablet computer (pad), a desktop computer, a headset, or a speaker, or may further include a machine intelligence device, such as a self-driving device, a transportation safety device, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a machine type communication (MTC) device, an industrial control device, a remote medical device, a smart grid device, or a smart city device, or may further include a wearable device (for example, a smart watch, a smart band, or a pedometer), etc. In some technical scenarios, the name of a device with similar data transmission and reception capabilities may not be a node. However, for ease of explanation, electronic devices capable of transmitting and receiving data are collectively referred to as nodes in the embodiments of this application.

[0309] 2.Shared key (SK)

[0310] A shared key is the same secret value stored in the nodes of the two communicating parties, and the shared key can be generated by the two communicating parties by using the same key derivation method. A pre-shared key (PSK) is also a type of shared key.

[0311] For example, a vehicle's cockpit domain controller (CDC) and a vehicle owner's mobile phone are two nodes that can communicate with each other by utilizing Bluetooth technology. When a vehicle owner needs to perform pairing with the vehicle's CDC by utilizing the mobile phone, the vehicle owner may first generate a shared key by exchanging public keys, e.g., by exchanging key agreement algorithm parameters between the mobile phone and the vehicle's CDC by utilizing a key agreement algorithm. The shared key may be used to verify the identity of both nodes when the mobile phone later requests pairing with the vehicle's CDC again.

[0312] 3.Key agreement

[0313] Key agreement is a process in which two communicating parties exchange several parameters to derive a key through agreement. The cryptographic algorithm used for key agreement is called a key agreement algorithm, or sometimes called a key exchange algorithm. Common key agreement algorithms include the Diffie-Hellman (DH) algorithm, the elliptic curve cryptosystem (ECC)-based Diffie-Hellman (ECDH) algorithm, the Oakley algorithm, and SM algorithms (such as SM1, SM2, SM3, and SM4).

[0314] 4. Bluetooth pairing process

[0315] Bluetooth is a short-range wireless communication technology that can be used for wireless information exchange between nodes. Pairing must first be performed between nodes that communicate with each other by using Bluetooth. The pairing process aims to generate a link key between two Bluetooth nodes, which is used to authenticate each other's identity and encrypt exchanged data. In practical applications, the two nodes generally do not perform encryption by directly using the link key, but export a session key by using the link key to encrypt exchanged data. The session key may include one or more of an encryption key, an integrity key, etc.

[0316] Bluetooth pairing methods mainly include personal identification number / legacy pairing (PIN / LP) and secure simple pairing (SSP). When the PIN / legacy pairing method is used, two Bluetooth nodes export a link key when they input the same password PIN. This method requires both nodes to have input capability, is applicable to few scenarios, and has relatively low security.

[0317] 5.Input / Output, I / O ability

[0318] The input / output capabilities of a node can be obtained by combining the input and output capabilities. The input capabilities can be "No Input", "Yes / No" (which can also be represented as "YesNo"), or "Keyboard", which will be explained in detail next.

[0319] (1) "No Input" indicates that the node does not have the ability to input "Yes," "No," or other data.

[0320] (2) "Yes / No" indicates that the node has at least two buttons, and the two buttons can be mapped to "Yes" and "No," or the node has another mechanism that can indicate "Yes" or "No."

[0321] (3) "Keyboard" indicates that the node has at least one numeric keyboard that can input Arabic numerals from 0 to 9 or other characters, and confirmation. The node has at least two buttons, and the two buttons can be mapped to "Yes" and "No," or the node has another mechanism that can indicate "Yes" or "No."

[0322] The output function may be "No Output" or "Numeric Output", which will be explained in more detail below.

[0323] (1) "No Output" indicates that the node does not have the ability to display or transmit six characters.

[0324] (2) "Numeric Output" indicates that the node has the ability to display or transmit six characters.

[0325] I / O capabilities can be obtained by combining input and output functions. Table 1 is a table of I / O capability combinations provided in an embodiment of the present application. It can be understood that the I / O capabilities of a node include no input / output (NoInputNoOutput), display only (DisplayOnly), display yes / no (DisplayYesNo), keyboard only (KeyboardOnly), and keyboard display (KeyboardDisplay).

[0326] [Table 1]

[0327] 6. Key Derivation

[0328] Key derivation is the derivation of one or more secret values ​​from a single secret value, and the algorithm used to derive a key is called a key derivation function (KDF) or a key derivation algorithm. For example, a new secret value DK derived from a secret value Key can be expressed as DK = KDF(Key).

[0329] The symmetric key derivation algorithm includes a password-based key derivation function (PBKDF), a scrypt algorithm, etc. The PBKDF algorithm further includes a first-generation PBKDF1 and a second-generation PBKDF2. Optionally, in the key derivation process of some KDF algorithms, a hash algorithm is utilized to perform a hash modification on the input secret value. Therefore, an algorithm identifier may be further received as an input of the KDF function to indicate the hash algorithm to be utilized.

[0330] 7. Freshness Parameters

[0331] A freshness parameter is a parameter commonly used in cryptography, and is usually used to generate keys, authentication parameters, etc. A freshness parameter, sometimes called freshness or a fresh parameter, may include at least one of a number once (NONCE), a counter, a sequence number, etc. A NONCE is a random value that is used only once (or is not repeated). Freshness parameters generated at different moments are usually different. In other words, the specific value of a freshness parameter changes every time a freshness parameter is generated. Therefore, the freshness parameter used to generate a current key (or authentication parameter, etc.) is different from the freshness parameter used to generate the previous key (or authentication parameter, etc.). This can improve the security of the generated key.

[0332] For example, the freshness parameter may be a random number obtained by the node by utilizing a random number generator.

[0333] The following describes the system architecture and service scenarios in the embodiments of the present application. It should be noted that the system architecture and service scenarios described in the present application are intended to more clearly explain the technical solutions in the present application, and do not constitute limitations on the technical solutions provided in the present application. Those skilled in the art may know that with the development of system architecture and the emergence of new service scenarios, the technical solutions provided in the present application can also be applied to similar technical problems.

[0334] 1 is a schematic diagram of an application scenario of a Bluetooth node pairing method according to an embodiment of the present application. A vehicle's cockpit domain controller (CDC) 101 is a control center in an intelligent cockpit device and may be considered as a first node, and a smartphone 102 may be considered as a second node. The smartphone 102 may send a pairing request message to the CDC 101 to request pairing with the CDC 101. The CDC 101 may select a pairing mode for pairing based on the input / output capabilities of the smartphone 102 described in the pairing request message. Generally, the smartphone 102 may support input and display, and the CDC 101 may also support input and display. Therefore, pairing may be performed by utilizing a numeric comparison or a passkey input mode. However, if an attacker breaks into the vehicle at this time and connects to CDC101 by using the attacker's mobile phone, the numeric comparison mode cannot prevent the attacker from connecting to CDC101, so CDC101 will be successfully connected to the attacker's mobile phone, and the security of the vehicle will be compromised.

[0335] In another example, when the CDC 101 is connected to a Bluetooth headset, the Bluetooth headset cannot input or display content, so the Bluetooth headset can only be connected in Just Work mode. Furthermore, if an attacker requests to connect to the Bluetooth headset, the Bluetooth headset will also be successfully paired with the attacker's device. Therefore, the security of the Bluetooth headset is threatened. Therefore, existing pairing methods cannot meet the security requirements of the node.

[0336] 2 is a schematic flowchart of a Bluetooth pairing method according to an embodiment of the present application. The method includes, but is not limited to, the following steps:

[0337] Step S201: A first node sends a pairing request message to a second node.

[0338] In particular, the pairing request message includes information used to indicate whether the first node has pre-shared key (PSK) pairing capability. If the first PSK shared with the second node exists on the first node, the first node has PSK pairing capability. Correspondingly, if the first PSK shared with the second node does not exist on the first node, the first node does not have PSK pairing capability.

[0339] The pairing request message including information used to indicate whether the first node has PSK pairing capability may be specifically implemented in several manners as follows.

[0340] Implementation 1: The pairing request message includes an I / O Capability IOC field, which contains information used to indicate whether the first node has PSK pairing capability. See, for example, FIG. 3. FIG. 3 is a schematic diagram of a possible pairing request message according to an embodiment of the present application. The pairing request message 301 includes fields such as a message code (Code), I / O capability (IOC), an out-of-band data flag (OOB Data Flag), a configuration request (AuthReq), a maximum encryption key size (Maximum Encryption Key Size), an initiator key distribution (Initiator Key Distribution), and a responder key distribution (Responder Key Distribution). The Code is used to indicate the type of message, for example, 0x01 indicates a request message and 0x02 indicates a response message. The AuthReq may contain identifiers such as Bonding_Flags (BF), Man-In-The-Middle (MITM), Secure Connections (SC), and keypress. Maximum encryption key size is used to indicate the longest supported key length (usually ranging from 7 bytes to 16 bytes). Initiator key distribution and Responder key distribution are used to indicate the key distribution method. The most significant bit (MSB) is the most significant weighted bit in a binary number, similar to the left-most bit in a decimal number. Correspondingly, the least significant bit (LSB) is the least significant weighted bit in a binary number, similar to the right-most bit in a decimal number.

[0341] The IOC field is used to indicate the I / O capability of the first node. Table 2 shows the values ​​of the IOC field and the corresponding descriptions of the values ​​provided in this embodiment of the present application. It can be understood that when the value of the IOC field in the pairing request message is 0x05, it may indicate that the first node has PSK pairing capability. Correspondingly, when the value of the IOC field is another value, it may indicate that the first node does not have PSK pairing capability. Furthermore, when the value of the IOC field is another value, the I / O capability of the first node may be specifically indicated. For example, when the value of the IOC field is 0x01, it may indicate that the I / O capability of the first node is display only.

[0342] [Table 2]

[0343] Implementation 2: The pairing request message includes an IOC field, and one part of the bits in the IOC field includes the PSK capability value of the first node, and the PSK capability value of the first node is used to indicate whether the first node has PSK pairing capability. Figure 4 is a schematic diagram of a possible pairing request message according to an embodiment of the present application. Pairing Request Message 401 contains fields such as Code, IOC, OOB data flags, AuthReq, Maximum encryption key size, Initiator key distribution, and Responder key distribution.

[0344] The IOC field includes 8 bits (1 byte), and 2 bits in the IOC field are used to indicate whether the first node has PSK pairing capability. In particular, the 2 bits in the IOC field include the PSK capability value of the first node, and the PSK capability value of the first node is used to indicate whether the first node has PSK pairing capability. Table 3 shows possible PSK capability values ​​and corresponding descriptions provided in this embodiment of the present application. For example, a PSK capability value of "01" indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing can be supported. In another example, a PSK capability value of "00" indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0345] [Table 3]

[0346] It can be understood that in this embodiment of the present application, an example in which one portion of bits is 2 bits is used. In a specific implementation, one portion of bits can be other bits, for example, 3 bits. "000" indicates no PSK pairing capability, "001" indicates PSK pairing capability, and "002" to "111" are used as reserved values.

[0347] See Figure 4. Optionally, another portion of the bits in the IOC field may be used to indicate the I / O capability of the first node, so that the second node can determine the pairing mode based on the I / O capability of the first node. For example, the value of the 6 bits in the IOC field is 0x01, indicating that the I / O capability of the first node is DisplayOnly. If the I / O capability of the second node is KeyboardDisplay, matching may be performed between the first node and the second node in Passkey entry (PE) mode.

[0348] Implementation 3: The pairing request message includes a PSK capability field, which includes a PSK capability value of the first node, and the PSK capability value of the first node is used to indicate whether the first node has PSK pairing capability. Figure 5 is a schematic diagram of a possible pairing request message according to an embodiment of the present application. The pairing request message 501 includes fields such as Code, IOC, OOB data flag, AuthReq, Max encryption key size, Initiator key distribution, Responder key distribution, and PSK capability.

[0349] The PSK capability field is used to indicate whether the first node has PSK pairing capability. In particular, the PSK capability field includes a PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability. Table 4 shows other possible PSK capability values ​​and corresponding descriptions provided in this embodiment of the present application. For example, a PSK capability value of 0x01 indicates that the first node has PSK pairing capability or that a first PSK shared with the second node exists. Therefore, PSK-based pairing may be supported. In another example, a PSK capability value of 0x00 indicates that the first node does not have PSK pairing capability or that a first PSK shared with the second node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0350] [Table 4]

[0351] See Figure 4. Optionally, the IOC may be used to indicate the I / O capabilities of the first node, so that the second node can determine the pairing mode based on the I / O capabilities of the first node. For example, a value of 0x01 in the IOC field indicates that the I / O capabilities of the first node are DisplayOnly.

[0352] Optionally, before sending the pairing request message, the first node first determines whether to share a PSK with the second node. For ease of explanation, the PSK shared by the first node and the second node is referred to as the first PSK in the embodiments of the present application. If the first node determines to share the first PSK with the second node, the pairing request message includes information indicating that the first node has PSK pairing capability. Correspondingly, if the first PSK to be shared with the second node does not exist on the first node, the pairing request message includes information indicating that the first node does not have PSK pairing capability.

[0353] Further, optionally, the first node stores a correspondence between at least one node's device identifier and a corresponding PSK. The node's device identifier may be the node's identification (ID), media access control (MAC) address, domain name, domain address, or another user-defined identifier. The first node may obtain the second node's device identifier (for ease of explanation, the second node's device identifier is referred to as the second device identifier) ​​and determine, based on the second device identifier, whether a first PSK corresponding to the second device identifier exists on the first node. If a first PSK corresponding to the second device identifier exists on the first node, it indicates that the first node has PSK pairing capability. See, for example, Table 5. Table 5 shows possible correspondences between node's device identifiers and PSKs provided in this embodiment of the present application. It may be understood that if the second device identifier obtained by the first node is “ID1”, the PSK corresponding to “ID1” is “PSK1”, and the first node may add information to the pairing request message indicating that the first node has PSK pairing capability.

[0354] [Table 5]

[0355] It may be understood that the first node sends a pairing request message to the second node, and correspondingly, the second node receives the pairing request message from the first node and obtains the message content in the pairing request message.

[0356] S202: The second node transmits a pairing response message to the first node in response to the pairing request message including information utilized to indicate that the first node has PSK pairing capability.

[0357] In particular, the pairing request message includes information used to indicate that the first node has PSK pairing capability. Therefore, the second node can learn based on the information that the first node has PSK pairing capability, which indicates that PSK-based pairing can be performed between the first node and the second node. Therefore, the second node transmits a pairing response message to the first node.

[0358] The pairing response message is used to indicate that pairing is to be performed by utilizing the first PSK shared by the first node and the second node. In particular, there are two possible cases:

[0359] Case 1: The pairing response message includes information indicating a pairing mode. For example, the pairing response message includes "pairing mode 05," which indicates to the first node that the pairing corresponds to PSK-based pairing, i.e., that the pairing is performed by utilizing a first PSK shared by the first node and the second node.

[0360] Case 2: The pairing response message includes information indicating that the second node has PSK pairing capability, and indicates to the first node that pairing will be performed by utilizing the first PSK shared by the first node and the second node. In particular, the pairing response message including information indicating that the second node has PSK pairing capability may have the following several implementation solutions.

[0361] Implementation Solution 1: The pairing response message includes an I / O Capability IOC field, which includes information used to indicate whether the second node has PSK pairing capability. For example, a value of 0x05 in the IOC field in the pairing response message may indicate that the second node has PSK pairing capability. Correspondingly, a value of another IOC field may indicate that the first node does not have PSK pairing capability, thereby indicating that the first node cannot perform PSK-based pairing. Furthermore, a value of another IOC field may specifically indicate the I / O capability of the second node. For example, a value of 0x01 in the IOC field may indicate that the I / O capability of the second node is display-only.

[0362] Implementation Solution 2: The pairing response message includes an IOC field, and one part of the bits in the IOC field includes the PSK capability value of the second node. The PSK capability value of the second node is used to indicate whether the second node has PSK pairing capability. For example, two bits in the IOC field include the PSK capability value of the first node. A PSK capability value of "01" indicates that the second node has PSK pairing capability or that a first PSK shared with the first node exists. Therefore, PSK-based pairing can be supported. Optionally, a PSK capability value of "00" indicates that the second node does not have information about PSK pairing capability or that a first PSK shared with the first node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another pairing mode.

[0363] It can be understood that in this embodiment of the present application, an example in which one portion of bits is 2 bits is used. In a specific implementation, one portion of bits can be other bits, for example, 3 bits. "000" indicates no PSK pairing capability, "001" indicates PSK pairing capability, and "002" to "111" are used as reserved values.

[0364] Optionally, another portion of the bits in the IOC field may be used to indicate the I / O capability of the second node, so that the first node can determine another pairing mode based on the I / O capability of the first node. For example, the value of the 6 bits in the IOC field is 0x04, indicating that the I / O capability of the second node is Keyboard Display. If the I / O capability of the first node is Display Only, matching may be performed between the first node and the second node in Passkey entry (PE) mode.

[0365] Implementation Solution 3: The pairing response message includes a PSK capability field, which includes the PSK capability value of the second node. The PSK capability value of the second node is used to indicate whether the second node has PSK pairing capability. For example, a PSK capability value of "0x01" indicates that the second node has PSK pairing capability or that a first PSK shared with the first node exists. Therefore, PSK-based pairing may be supported. Optionally, a PSK capability value of "0x00" may indicate that the second node does not have information about PSK pairing capability or that a first PSK shared with the first node does not exist. In this case, PSK-based pairing is not supported, and pairing must be performed in another mode.

[0366] Optionally, the pairing response message further includes an IOC field, which may be used to indicate the I / O capability of the second node, so that the first node can determine the pairing mode based on the I / O capability of the second node. For example, the value in the IOC field is 0x04, which indicates that the I / O capability of the first node is KeyboardDisplay.

[0367] Optionally, before sending the pairing response message, the second node first determines whether there is a first PSK shared with the first node. If the second node determines to share the first PSK with the first node, the pairing response message includes information indicating to perform PSK-based pairing. Correspondingly, if the first PSK shared with the second node does not exist on the second node, a pairing failure message may be sent to the second node, or information indicating no PSK pairing capability may be carried in the pairing response message, or the input / output capabilities of the second node may be carried in the pairing response message to determine another pairing mode.

[0368] Further, optionally, the second node stores a correspondence between the device identifier of at least one node and the corresponding PSK. The second node may obtain the device identifier of the first node (for ease of explanation, the device identifier of the first node is referred to as the first device identifier) ​​and determine, based on the first device identifier, whether a first PSK corresponding to the first device identifier exists on the second node. If the first PSK corresponding to the first device identifier exists on the second node, it indicates that a first PSK shared with the first node exists on the second node.

[0369] Optionally, when the pairing request message further includes the I / O capabilities of the first node, the second node may determine a first pairing mode based on the I / O capabilities of the first node and the I / O capabilities of the second node. For example, see FIG. 6. FIG. 6 is a possible manner of determining a first pairing mode according to an embodiment of the present application. Area 601 is the I / O capabilities of the first node, and area 602 is the I / O capabilities of the second node. It can be understood that the first pairing mode is determined based on the I / O capabilities of the first node and the I / O capabilities of the second node, and the first pairing mode may be Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE). For example, if the I / O capability of the first node is DisplayYesNo and the I / O capability of the second node is DisplayYesNo, the corresponding pairing mode is a numeric comparison mode.

[0370] Note that the out-of-band mode usually needs to be completed based on another device, so a corresponding OOB Data Flag needs to be carried in the pairing request message to indicate that the out-of-band mode is utilized for pairing.

[0371] Further, optionally, when multiple pairing modes are supported between the first node and the second node, the second node may determine a pairing mode based on the pairing request message and preset pairing mode priority information to send a response message indicating a different pairing mode to the first node. The second node may preferentially select PSK-based pairing or select a pairing mode with a higher priority based on the pairing mode priority. For example, the pairing mode priority information may indicate that when the first node and the second node share a PSK, pairing performed by utilizing the PSK shared by the first node and the second node has the highest priority among the multiple pairing modes. In another example, the pairing mode priority information may indicate that the priority of PSK-based pairing is 2, the priority of the numeric comparison mode is 3, and the priority of the passkey entry mode is 1. When both the first node and the second node have PSK pairing capability, if the pairing mode corresponding to the I / O capability of the first node and the I / O capability of the second node is a passkey entry mode, the second node may select the passkey entry mode for pairing because the priority of the passkey entry mode is higher than the priority of the PSK-based pairing. Correspondingly, if the pairing mode corresponding to the I / O capability of the first node and the I / O capability of the second node is a numeric comparison mode, the second node may select the PSK-based pairing because the priority of the PSK-based pairing is higher than the priority of the numeric comparison mode.

[0372] It can be understood that the second node sends a pairing response message to the first node, and correspondingly, the first node receives the pairing response message fed back by the second node to obtain the message content in the pairing response message.

[0373] Step S203: The second node authenticates the first node based on the first PSK.

[0374] In particular, a first node shares a first PSK with a second node. Therefore, the second node can authenticate the first node by using the first PSK. In particular, there are several possible schemes:

[0375] Scheme 1: The second node sends first authentication data to the first node. The first authentication data is encrypted using or derived from the first PSK. Ta The authentication data may be encrypted by utilizing a session key. If the first node can decrypt the authentication data and feed back the corresponding response data, the second node successfully authenticates the first node.

[0376] Method 2: The second node receives a first authentication parameter from the first node. The first authentication parameter is generated by the first node based on the first PSK. For example, the first authentication parameter C1 is generated by the first node based on the first PSK by using a key derivation algorithm KDF, e.g., C1 = KDF(first PSK). Since the second node also has the first PSK, the second node can verify the first authentication parameter in a corresponding manner. For example, the second node can determine whether the first PSK on the first node matches the first PSK on the second node based on KDF1(first PSK) and the first authentication parameter C1 to authenticate the identity of the first node. Furthermore, the second node generates a second check parameter check2 based on the first PSK on the second node, e.g., check2 = KDF(first PSK). If the second check parameter is the same as the first authentication parameter, the first PSK on the first node matches the first PSK on the second node, and therefore the identity of the first node can be authenticated.

[0377] Optionally, the parameters participating in the generation of the first authentication parameter may further include other parameters exchanged between the first node and the second node, such as one or more of a freshness parameter, a public key, a configuration parameter, and a pairing message. See the examples below for details.

[0378] Case 1: A second node sends a freshness parameter to a first node (for ease of explanation, the freshness parameter sent by the second node is referred to as a second freshness parameter). The freshness parameter may include at least one of a NONCE, a counter, a sequence number, etc. obtained (or generated) by the second node. The first node generates a first authentication parameter C1 based on the second freshness parameter N2 and the first PSK, e.g., C1 = KDF(N2, first PSK). The second node receives the first authentication parameter C1 from the first node and generates a second check parameter check2 by utilizing the same method, e.g., check2 = KDF(N2, first PSK). If the second check parameter is the same as the first authentication parameter, the first PSK on the first node matches the first PSK on the second node, and therefore the identity of the first node can be authenticated.

[0379] Case 2: A shared key is generated (or obtained) in advance between the second node and the first node. The shared key is generated through negotiation between the first node and the second node by exchanging a first public key and a second public key. The first node generates a first authentication parameter C1 based on a second freshness parameter N2, a first PSK, a first public key PK1, and a second public key PK2, e.g., C1=KDF(N2, first PSK, PK1, PK2). The second node receives the first authentication parameter C1 from the first node and generates a second check parameter check2 by using the same method, e.g., check2=KDF(N2, first PSK, PK1, PK2). If the second check parameter is the same as the first authentication parameter, the first PSK on the first node matches the first PSK on the second node, and therefore the identity of the first node can be authenticated.

[0380] Step S204: The first node authenticates the second node based on the first PSK.

[0381] In particular, the first node shares a first PSK with the second node. Therefore, the first node can authenticate the second node by utilizing the first PSK. The authentication method is briefly described below. For a detailed description, please refer to the corresponding description on the second node side in step S203. The first node can authenticate the second node based on the first PSK in the following manner.

[0382] Manner 1: The first node sends second authentication data to the second node. The second authentication data may be encrypted by using the first PSK or by using a session key derived (or derived) from the first PSK. If the second node can decrypt the authentication data and feed back corresponding response data, the first node successfully authenticates the second node.

[0383] Manner 2: The first node receives a second authentication parameter from the second node. The second authentication parameter is generated by the second node based on the first PSK. For example, the second authentication parameter C2 is generated by the second node based on the first PSK by using the key derivation algorithm KDF, e.g., C2 = KDF(first PSK). Since the first node also has the first PSK, the first node can verify the second authentication parameter in a corresponding manner. For example, the first node can determine whether the first PSK on the second node matches the first PSK on the first node based on KDF(first PSK) and the second authentication parameter C2 to authenticate the identity of the second node. Furthermore, the first node can generate a first check parameter check1 based on the first PSK on the first node, e.g., check1 = KDF(first PSK). If the first check parameter is the same as the second authentication parameter, the first PSK on the second node matches the first PSK on the first node, and therefore the identity of the second node can be authenticated.

[0384] Optionally, the parameters participating in the generation of the second authentication parameter may further include other parameters exchanged between the first node and the second node, such as one or more of a freshness parameter, a public key, a configuration parameter, and a pairing message. See the examples below for details.

[0385] Case 1: A first node sends a freshness parameter to a second node (for ease of explanation, the freshness parameter sent by the first node is referred to as the first freshness parameter). The freshness parameter may include at least one of a NONCE, a counter, a sequence number, etc. obtained (or generated) by the first node. The second node generates a second authentication parameter C2 based on the first freshness parameter N1 and the first PSK, e.g., C2=KDF(N1, first PSK). The first node receives the second authentication parameter C2 from the second node and generates a first check parameter check1 by utilizing the same method, e.g., check1=KDF(N1, first PSK). If the first check parameter is the same as the second authentication parameter, the first PSK on the second node matches the first PSK on the first node, and therefore the identity of the second node can be authenticated.

[0386] It should be noted that, for a clearer explanation of the solution, multiple steps are used to describe how to verify the authentication parameters. In actual processing, the authentication parameters can also be verified in one step. For example, when the second authentication parameter C2 is verified, the first check parameter check1 is only an intermediate result, that is, the first node can directly verify whether C2 is the same as KDF(N1, first PSK).

[0387] Case 2: A shared key is generated (or obtained) in advance between a first node and a second node. The shared key is generated through negotiation between the first node and the second node by exchanging a first public key and a second public key. The second node generates a second authentication parameter C2 based on a first freshness parameter N1, a first PSK, a first public key PK1, and a second public key PK2, e.g., C2=KDF1(N1, first PSK, PK1, PK2). The first node receives the second authentication parameter C2 from the second node and generates a first check parameter check1 by using the same method, e.g., check1=KDF1(N1, first PSK, PK1, PK2). If the first check parameter is the same as the second authentication parameter, the first PSK on the second node matches the first PSK on the first node, and therefore the identity of the second node can be authenticated.

[0388] Optionally, when the first pairing request message includes the PSK capability value of the first node, the second node may authenticate the validity of the PSK capability value of the first node to avoid tampering with the PSK capability value of the first node. In particular, the second node receives a third authentication parameter from the first node. The third authentication parameter is generated by the first node based on the PSK capability value of the first node. The second node generates a fourth check parameter based on the PSK capability value of the first node obtained from the pairing request message, and determines the validity of the PSK capability value of the first node based on the fourth check parameter and the third authentication parameter. For example, in the first pairing request message, if the PSK capability value of the first node is “01”, the first node generates a third authentication parameter C3 by utilizing a KDF, e.g., C3=KDF(“01”). Correspondingly, the second node generates a fourth check parameter check4=KDF("01"). If the third authentication parameter C3 is equal to the fourth check parameter check4, the authenticity authentication of the first node's PSK capability value is successful.

[0389] Optionally, if the first response request message includes the second node's PSK capability value, the second node may authenticate the validity of the second node's PSK capability value. In particular, the first node receives a fourth authentication parameter from the second node. The fourth authentication parameter is generated by the second node based on the second node's PSK capability value. The first node generates a third check parameter based on the second node's PSK capability value obtained from the pairing response message, and determines the validity of the second node's PSK capability value based on the third check parameter and the fourth authentication parameter. For example, in the first pairing response message, if the second node's PSK capability value is "01", the second node generates a fourth authentication parameter C4 by utilizing the KDF, e.g., C4=KDF("01"). Correspondingly, the first node generates a third check parameter check3=KDF("01"). If the fourth authentication parameter C4 is equal to the third check parameter check3, the authenticity of the PSK capability value of the second node is successful.

[0390] Furthermore, optionally, the parameters participating in the generation of the third authentication parameter C3 and the fourth authentication parameter C4 may further include another parameter, for example, one or more parameters of the shared key Kdh, the first random number N1, the second random number N2, the first node's PSK capability value “01”, the first public key PK1, and the second public key PK2 by utilizing a cryptographic algorithm f3, and may be, for example, C3=f3(Kdh, N1, N2, “01”, PK1, PK2). Correspondingly, the fourth authentication parameter is generated based on the shared key Kdh, the first random number N1, the second random number N2, the second node's PSK capability value “01”, the first public key PK1, and the second public key PK2 by utilizing the cryptographic algorithm f3, and may be, for example, C4=f3(Kdh, N1, N2, “01”, PK1, PK2).

[0391] It may be understood that step S203 and step S204 may correspond to authentication phase 1 in the Bluetooth pairing process. The above verification of the validity of the PSK capability values ​​between the first node and the second node may correspond to authentication phase 2 in the Bluetooth pairing process. In this case, the third authentication parameter is verification parameter verification E1 in authentication phase 2, and the fourth authentication parameter is verification parameter verification E2 in authentication phase 2.

[0392] In the method shown in FIG. 2 , the PSK is a secret value shared by the first node and the second node, and the PSK shared with the second node is predefined or configured on the first node. Thus, the pairing request message may include information indicating that the first node has PSK pairing capability. Correspondingly, the PSK shared with the first node (referred to as the first PSK for ease of explanation) is also predefined or preconfigured on the second node. The second node may authenticate the first node based on the first PSK and determine that the first node's identity is trusted, and therefore, subsequent pairing can be successful. In this way, the identity of the node for which the PSK is preconfigured or defined is typically trusted. This avoids successful pairing between the first node or second node and an untrusted node, improving the security of the node pairing process.

[0393] 7 is a schematic flowchart of a Bluetooth pairing method according to an embodiment of the present application. The method includes, but is not limited to, the following steps:

[0394] Step S701: A first node sends a pairing request message to a second node.

[0395] In particular, the pairing request message includes information utilized to indicate the pairing capabilities of the first node. The pairing capabilities of the first node include whether the first node has PSK pairing capabilities. Furthermore, optionally, the pairing capabilities of the first node further include the I / O capabilities of the first node.

[0396] For example, as shown in FIG. 3, the IOC field in the pairing request message 301 includes information indicating that the first node has PSK pairing capability.

[0397] 4, one portion of the bits in the IOC field in the pairing request message 401 includes a PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability, and another portion of the bits in the IOC field includes the I / O capability of the first node.

[0398] In yet another example, as shown in Figure 5, the PSK capability field in the pairing request message 501 includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability. 401 The IOC field in contains the I / O capabilities of the first node.

[0399] It may be understood that the first node sends a pairing request message to the second node, and correspondingly, the second node receives the pairing request message from the first node and obtains the message content in the pairing request message.

[0400] Step S702: The second node determines a pairing mode based on the information about the pairing capability of the first node and the information about the pairing capability of the second node.

[0401] In particular, the pairing mode may include modes such as PSK-based pairing, Numeric Comparison NC, Just Work JW, or Passkey Entry PE. The second node determining the pairing mode based on the information about the pairing capabilities of the first node and the information about the pairing capabilities of the second node may include at least some of the following cases:

[0402] Case 1: The pairing request message includes information indicating that the first node has PSK pairing capability. If the second node determines to share the first PSK with the first node, the second node performs pairing by utilizing the first PSK shared by the first node and the second node. In particular, the first node has PSK pairing capability. If the second node has the first PSK shared with the first node, it is determined that the pairing mode is PSK-based pairing.

[0403] The second node may obtain the device identifier of the first node, and if a first PSK corresponding to the device identifier of the first node exists on the second node, indicating that a first PSK shared with the first node exists on the second node, and the second node has PSK pairing capability.

[0404] It can be seen that in this case, PSK-based pairing is preferred: if both the first node and the second node have PSK pairing capability, pairing is performed by utilizing a shared first PSK.

[0405] Case 2: The pairing request message includes information indicating that the first node does not have PSK pairing capability or that the second node does not have PSK pairing capability (or that the first PSK shared with the first node does not exist on the second node), and the pairing request message further includes the I / O capability of the first node. In this case, the second node determines the pairing mode based on the I / O capability of the first node and the I / O capability of the second node. For example, as shown in FIG. 6, if the I / O capability of the first node is DisplayYesNo and the I / O capability of the second node is DisplayYesNo, the corresponding pairing mode is the numeric comparison mode.

[0406] Case 3: The pairing request message includes information indicating that the first node has PSK pairing capability, and a first PSK shared with the first node exists on the second node. The pairing request message further includes the I / O capabilities of the first node. The second node determines a first pairing mode based on the I / O capabilities of the first node and the second node, and determines the pairing mode based on the priority of the first pairing mode and the priority of the PSK-based pairing. For example, the priority of the PSK-based pairing is 2, the priority of the numeric comparison mode is 3, and the priority of the passkey entry mode is 1. When both the first node and the second node have PSK pairing capability, if the pairing mode corresponding to the I / O capabilities of the first node and the second node is the passkey entry mode, the second node may select the passkey entry mode for pairing because the priority of the passkey entry mode is higher than the priority of the PSK-based pairing. Correspondingly, if the pairing mode corresponding to the I / O capabilities of the first node and the second node is the numeric comparison mode, the second node may select the PSK-based pairing because the priority of the PSK-based pairing is higher than the priority of the numeric comparison mode.

[0407] Optionally, the second node may choose to support a pairing mode with relatively high security. For example, the second node may support only a PSK-based pairing mode, a numeric comparison mode, and a passkey entry mode. For a node determined to be in Just Work mode based on I / O capabilities, the second node may send a pairing failure message to prevent the second node from pairing with an untrusted node in Just Work mode.

[0408] Step S703: The second node sends a pairing response message to the first node.

[0409] In particular, the pairing response message includes information utilized to indicate the pairing capabilities of the second node, including whether the second node has PSK pairing capabilities, and further including the I / O capabilities of the second node.

[0410] For example, the IOC field in the pairing response message includes information indicating that the second node has PSK pairing capability.

[0411] In another example, one portion of the bits in the IOC field in the pairing response message includes a PSK capability value of the second node, which is used to indicate whether the second node has PSK pairing capability, and another portion of the bits in the IOC field includes the I / O capability of the second node.

[0412] In yet another example, the PSK capability field in the pairing response message includes a PSK capability value of the second node, and the PSK capability value is utilized to indicate whether the second node has PSK pairing capability. The IOC field in the pairing response message includes the I / O capability of the first node.

[0413] It may be understood that the pairing capability of the second node is associated with the pairing mode selected by the second node. If the pairing mode determined by the second node is PSK-based pairing, the pairing response message includes information indicating that the second node has PSK capability. Correspondingly, if the pairing mode determined by the second node is determined based on the I / O capabilities of the first node and the second node, the pairing response message includes the I / O capabilities of the second node.

[0414] It can be understood that the second node sends a pairing response message to the first node, and correspondingly, the first node receives the pairing response message fed back by the second node to obtain the message content in the pairing response message.

[0415] Step S704: The second node performs pairing with the first node based on the pairing mode.

[0416] In particular, if the second node determines that the pairing mode is PSK-based pairing, the second node authenticates the first node by using the first PSK shared with the first node. For detailed processing, please refer to the specific description of step S203. The details will not be described again here.

[0417] If the second node determines that the pairing mode is a first pairing mode determined based on the I / O capabilities of the first node and the I / O capabilities of the second node, pairing is performed according to a corresponding pairing procedure.

[0418] Step S705: The first node determines a pairing mode based on the information about the pairing capability of the first node and the information about the pairing capability of the second node.

[0419] In particular, the pairing mode may include modes such as PSK-based pairing, numeric comparison, Just Work, or passkey entry. The first node determining the pairing mode based on the information about the pairing capabilities of the first node and the information about the pairing capabilities of the second node may include at least some of the following cases:

[0420] Case 1: The pairing response message includes information indicating that the second node has PSK pairing capability. If the first node also has PSK pairing capability (or a PSK shared with the second node exists on the first node), the first node performs pairing by utilizing the first PSK shared by the first node and the second node.

[0421] It can be seen that in this case, PSK-based pairing is preferred: if both the first node and the second node have PSK pairing capability, pairing is performed by utilizing a shared first PSK.

[0422] Case 2: The pairing response message includes information indicating that the second node does not have PSK pairing capability or that the first node does not have PSK pairing capability (or that the first PSK shared with the second node does not exist on the first node), and the pairing response message further includes the I / O capability of the second node. In this case, the first node determines the pairing mode based on the I / O capability of the first node and the I / O capability of the second node. For example, as shown in FIG. 6, if the I / O capability of the first node is DisplayYesNo and the I / O capability of the second node is DisplayYesNo, the corresponding pairing mode is the numeric comparison mode.

[0423] Case 3: The pairing response message includes information indicating that the second node has PSK pairing capability, and a first PSK shared with the second node resides on the first node. The pairing response message further includes the I / O capabilities of the second node. The first node determines a first pairing mode based on the I / O capabilities of the first node and the I / O capabilities of the second node, and determines the pairing mode based on a priority of the first pairing mode and a priority of PSK-based pairing.

[0424] Optionally, the first node may choose to support a pairing mode with relatively high security. For example, the first node may support only a PSK-based pairing mode, a numeric comparison mode, and a passkey entry mode. For a node determined to be in Just Work mode based on I / O capabilities, the first node may send a pairing failure message to prevent the first node from pairing with an untrusted node in Just Work mode.

[0425] In a possible solution, the protocol specifies that the method used by the second node to determine the pairing mode is also used by the first node to determine the pairing mode, and therefore the methods for determining the pairing mode by the first node and the second node are the same.

[0426] Step S706: The first node performs pairing with the second node based on the pairing mode.

[0427] In particular, if the first node determines that the pairing mode is PSK-based pairing, the first node authenticates the second node by using the first PSK shared with the second node. For detailed processing, please refer to the specific description of step S204. The details will not be described again here.

[0428] If the second node determines that the pairing mode is a first pairing mode determined based on the I / O capabilities of the first node and the I / O capabilities of the second node, pairing is performed according to a corresponding pairing procedure.

[0429] 7, the pairing request message includes information about the pairing capabilities of the first node, and the pairing response message includes information about the pairing capabilities of the second node. The first node and the second node may determine a corresponding pairing mode based on their requirements and based on the information about the pairing capabilities of the first node and the information about the pairing capabilities of the second node. For example, the second node may determine a pairing mode that meets the requirements of the second node by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0430] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0431] The above method embodiment shown in Figure 2 includes many possible implementation solutions. The following will separately illustrate some of the implementation solutions with reference to Figures 8, 9A and 9B, and 10A and 10B. Please note that for explanations of related concepts, operations, or logical relationships not described in Figures 8, 9A and 9B, and 10A and 10B, please refer to the corresponding explanations in the embodiment shown in Figure 2. Therefore, the details will not be described again.

[0432] 8 is a schematic flowchart of a Bluetooth pairing method according to an embodiment of the present application. The method includes, but is not limited to, the following steps:

[0433] Step S801: A first node determines that there is a first PSK shared with a second node.

[0434] In particular, the first node obtains a second device identifier of the second node, and if it is determined based on the second device identifier that a first PSK corresponding to the second device identifier exists on the first node, this indicates that a first PSK shared with the second node exists on the first node.

[0435] Furthermore, if the first PSK corresponding to the second device identifier exists on the first node, it indicates that the first node has PSK pairing capability.

[0436] Step S802: The first node sends a pairing request message to the second node.

[0437] In particular, the pairing request message includes information that is used to indicate that the first node has PSK pairing capability.

[0438] It may be understood that the first node sends a pairing request message to the second node, and correspondingly, the second node receives the pairing request message from the first node and obtains the message content in the pairing request message.

[0439] Step S803: The second node determines that there is a first PSK shared with the first node.

[0440] Specifically, the second node obtains a first device identifier of the first node. If it is determined based on the first device identifier that a first PSK corresponding to the first device identifier exists on the second node, this indicates that a first PSK shared with the first node exists on the second node. Both the first node and the second node have PSK pairing capability. Thus, the pairing is No. 1 This may be accomplished by utilizing a first PSK shared by the first node and the second node.

[0441] Optionally, if the first PSK shared with the first node does not exist on the second node, the second node may send a pairing failure message to the first node.

[0442] Step S804: The second node sends a pairing response message to the first node.

[0443] In particular, the pairing response message is utilized to indicate that pairing is performed by utilizing a first PSK shared by the first node and the second node.

[0444] It can be understood that the second node sends a pairing response message to the first node, and correspondingly, the first node receives the pairing response message fed back by the second node to obtain the message content in the pairing response message.

[0445] Step S805: The first node sends the first freshness parameter to the second node.

[0446] In particular, the first freshness parameter may be at least one of a NONCE, a counter, a sequence number, etc. obtained (or generated) by the first node. The freshness parameter is utilized by the second node to generate a second authentication parameter, and thus the first node authenticates the second node based on the second authentication parameter.

[0447] It can be understood that the first node transmits the first freshness parameter to the second node, and correspondingly, the second node receives the first freshness parameter from the first node.

[0448] Step S806: The second node sends the second freshness parameter to the first node.

[0449] In particular, the second freshness parameter may be at least one of a NONCE, a counter, a sequence number, etc. obtained (or generated) by the second node. The freshness parameter is utilized by the first node to generate the first authentication parameter, and thus the second node authenticates the first node based on the first authentication parameter.

[0450] It can be understood that the second node transmits the second freshness parameter to the first node, and correspondingly, the first node receives the second freshness parameter from the second node.

[0451] Step S807: The first node generates a first authentication parameter based on the first PSK, the second freshness parameter, the first public key, and the second public key.

[0452] In particular, a shared key is pre-generated (or obtained) between the second node and the first node, and the shared key is generated through negotiation between the first node and the second node by exchanging a first public key and a second public key.

[0453] The first node generates a first authentication parameter C1 based on the second freshness parameter N2, the first PSK, the first public key PK1, and the second public key PK2, e.g., C1=KDF(N2, first PSK, PK1, PK2), where KDF is a key derivation algorithm that is pre-negotiated or specified in the protocol.

[0454] Step S808: The second node generates a first authentication parameter based on the first PSK, the first freshness parameter, the first public key, and the second public key.

[0455] In particular, the second node generates a first authentication parameter C2 based on the first freshness parameter N1, the first PSK, the first public key PK1, and the second public key PK2, for example, C2=KDF(N1, first PSK, PK1, PK2).

[0456] Step S809: The second node sends the second authentication parameters to the first node.

[0457] It may be understood that the second node transmits the second authentication parameters to the first node, and correspondingly, the first node receives the second authentication parameters from the second node.

[0458] Step S810: The first node sends a first authentication parameter to the second node.

[0459] It may be understood that the first node transmits the first authentication parameter to the second node, and correspondingly, the second node receives the first authentication parameter from the first node.

[0460] Step S811: The first node determines that authentication to the second node is successful based on the first PSK, the first freshness parameter, the first public key, the second public key, and the second authentication parameter.

[0461] In particular, the first node receives the second authentication parameter C2 from the second node and generates the first check parameter check1 by utilizing the same method, for example, check1=KDF1(N1, first PSK, PK1, PK2). If the first check parameter is the same as the second authentication parameter, the first PSK on the second node matches the first PSK on the first node, and therefore the identity of the second node can be authenticated.

[0462] Step S812: The second node determines that authentication to the first node is successful based on the first PSK, the second freshness parameter, the first public key, the second public key, and the first authentication parameter.

[0463] In particular, the second node receives the first authentication parameter C1 from the first node and generates the second check parameter check2 by utilizing the same method, for example, check2=KDF(N2, first PSK, PK1, PK2). If the second check parameter is the same as the first authentication parameter, the first PSK on the first node matches the first PSK on the second node, and therefore the identity of the first node can be authenticated.

[0464] 9A and 9B are schematic flowcharts of a Bluetooth pairing method according to an embodiment of the present application, including but not limited to the following steps:

[0465] Step S901: The first node sends a pairing request message to the second node.

[0466] In particular, the pairing request message includes information utilized to indicate whether the first node has PSK pairing capability. Additionally, optionally, the pairing request message further includes the I / O capabilities of the first node.

[0467] For example, as shown in Figure 4, one portion of the bits in the IOC field in the pairing request message 401 contains the PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability, and another portion of the bits in the IOC field contains the I / O capability of the first node.

[0468] 5, the PSK capability field in the pairing request message 501 includes a PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability, and the IOC field in the pairing request message 501 includes the I / O capability of the first node.

[0469] It may be understood that the first node sends a pairing request message to the second node, and correspondingly, the second node receives the pairing request message from the first node and obtains the message content in the pairing request message.

[0470] Step S902: If the first node does not have PSK pairing capability or the first PSK shared with the first node does not exist on the second node, the second node determines a pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node.

[0471] In particular, the pairing request message includes information about whether the first node has PSK pairing capability. If the first node does not have PSK pairing capability, the second node determines a pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node.

[0472] The second node may obtain a first device identifier of the first node. If it is determined based on the first device identifier that a first PSK corresponding to the first device identifier does not exist on the second node, indicating that a first PSK shared with the first node does not exist on the second node, the second node may determine a pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node.

[0473] Step S903: If the first node has PSK pairing capability and the first PSK shared with the first node exists on the second node, the second node sends a pairing response message to the first node.

[0474] In particular, the pairing response message is utilized to indicate that pairing is performed by utilizing a first PSK shared by the first node and the second node.

[0475] In this case, it can be seen that PSK-based pairing is preferred: if both the first node and the second node have PSK pairing capability, pairing is performed by utilizing a shared first PSK.

[0476] It can be understood that the second node sends a pairing response message to the first node, and correspondingly, the first node receives the pairing response message fed back by the second node to obtain the message content in the pairing response message.

[0477] Step S904: The first node sends the first freshness parameter to the second node.

[0478] In particular, the first freshness parameter may be at least one of a NONCE, a counter, a sequence number, etc. obtained (or generated) by the first node. The freshness parameter is utilized by the second node to generate a second authentication parameter, and thus the first node authenticates the second node based on the second authentication parameter.

[0479] It can be understood that the first node transmits the first freshness parameter to the second node, and correspondingly, the second node receives the first freshness parameter from the first node.

[0480] Step S905: The second node sends the second freshness parameter to the first node.

[0481] In particular, the second freshness parameter may be at least one of a NONCE, a counter, a sequence number, etc. obtained (or generated) by the second node. The freshness parameter is utilized by the first node to generate the first authentication parameter, and thus the second node authenticates the first node based on the first authentication parameter.

[0482] It can be understood that the second node transmits the second freshness parameter to the first node, and correspondingly, the first node receives the second freshness parameter from the second node.

[0483] Step S906: The first node generates a first authentication parameter based on the first PSK, the second freshness parameter, the first public key, and the second public key.

[0484] In particular, a shared key is pre-generated (or obtained) between the second node and the first node, and the shared key is generated through negotiation between the first node and the second node by exchanging a first public key and a second public key.

[0485] The first node generates a first authentication parameter C1 based on the second freshness parameter N2, the first PSK, the first public key PK1, and the second public key PK2, e.g., C1=KDF(N2, first PSK, PK1, PK2), where KDF is a key derivation algorithm that is pre-negotiated or specified in the protocol.

[0486] Step S907: The second node generates a first authentication parameter based on the first PSK, the first freshness parameter, the first public key, and the second public key.

[0487] In particular, a shared key is pre-generated (or obtained) between the second node and the first node, and the shared key is generated through negotiation between the first node and the second node by exchanging a first public key and a second public key.

[0488] The second node generates a first authentication parameter C2 based on the first freshness parameter N1, the first PSK, the first public key PK1, and the second public key PK2, e.g., C2=KDF(N1, first PSK, PK1, PK2), where KDF is a key derivation algorithm that is pre-negotiated or specified in the protocol.

[0489] Step S908: The second node sends the second authentication parameters to the first node.

[0490] It may be understood that the second node transmits the second authentication parameters to the first node, and correspondingly, the first node receives the second authentication parameters from the second node.

[0491] Step S909: The first node sends the first authentication parameter to the second node.

[0492] It may be understood that the first node transmits the first authentication parameter to the second node, and correspondingly, the second node receives the first authentication parameter from the first node.

[0493] Step S910: The first node determines that authentication to the second node is successful based on the first PSK, the first freshness parameter, the first public key, the second public key, and the second authentication parameter.

[0494] In particular, the first node receives the second authentication parameter C2 from the second node and generates the first check parameter check1 by utilizing the same method, for example, check1=KDF1(N1, first PSK, PK1, PK2). If the first check parameter is the same as the second authentication parameter, the first PSK on the second node matches the first PSK on the first node, and therefore the identity of the second node can be authenticated.

[0495] Step S911: The second node determines that authentication to the first node is successful based on the first PSK, the second freshness parameter, the first public key, the second public key, and the first authentication parameter.

[0496] In particular, the second node receives the first authentication parameter C1 from the first node and generates the second check parameter check2 by utilizing the same method, for example, check2=KDF(N2, first PSK, PK1, PK2). If the second check parameter is the same as the first authentication parameter, the first PSK on the first node matches the first PSK on the second node, and therefore the identity of the first node can be authenticated.

[0497] Step S912: The first node generates a third authentication parameter based on the PSK capability value of the first node.

[0498] For example, in the first pairing request message, if the PSK capability value of the first node is “01”, the first node generates a third authentication parameter C3 by utilizing the KDF, for example, C3=KDF(“01”).

[0499] Optionally, the parameters participating in the generation of the third authentication parameter C3 may further include another parameter, for example, one or more of the shared key Kdh, the first random number N1, the second random number N2, the first node's PSK capability value “01”, the first public key PK1, and the second public key PK2, by using a cryptographic algorithm f3, and the third authentication parameter C3 may be generated based on the shared key Kdh, the first random number N1, the second random number N2, the first node's PSK capability value “01”, the first public key PK1, and the second public key PK2, for example, C3=f3(Kdh, N1, N2, “01”, PK1, PK2). Furthermore, optionally, step S1212 may correspond to authentication phase 2 in the Bluetooth pairing process. In this case, the third authentication parameter is a verification parameter verification E1 in authentication phase 2.

[0500] Step S913: The second node generates a fourth authentication parameter based on the PSK capability value of the second node.

[0501] For example, in the first pairing response message, if the PSK capability value of the second node is “01”, the second node generates a fourth authentication parameter C4 by utilizing the KDF, for example, C4=KDF(“01”).

[0502] Optionally, the parameters participating in the generation of the fourth authentication parameter C4 may further include another parameter, for example, one or more of the shared key Kdh, the first random number, the second random number, the first public key, and the second public key. For example, the fourth authentication parameter may be generated based on the shared key Kdh, the first random number N1, the second random number N2, the second node's PSK capability value “01”, the first public key PK1, and the second public key PK2 by using the cryptographic algorithm f3, and may be, for example, C4=f3(Kdh, N1, N2, “01”, PK1, PK2). Furthermore, optionally, step S1213 may correspond to authentication phase 2 in the Bluetooth pairing process. In this case, the fourth authentication parameter is a verification parameter verification E2 in authentication phase 2.

[0503] Step S914: The second node sends the third authentication parameter to the first node.

[0504] It may be understood that the second node transmits the third authentication parameter to the first node, and correspondingly, the first node receives the third authentication parameter from the second node.

[0505] Step S915: The first node sends the fourth authentication parameter to the second node.

[0506] It can be understood that the first node transmits the fourth authentication parameter to the second node, and correspondingly, the second node receives the fourth authentication parameter from the first node.

[0507] Step S916: The first node verifies the fourth authentication parameter based on the PSK capability value of the second node.

[0508] In particular, the first node may generate a third check parameter check3=KDF(PSK capability value of the second node). If the fourth authentication parameter C4 is equal to the third check parameter check3, the authenticity of the PSK capability value of the second node is successful.

[0509] Optionally, if the fourth authentication parameter C4 satisfies the formula C4=f3(Kdh, N1, N2, the PSK capability value of the second node, PK1, PK2), the first node may generate a corresponding third check parameter check3 by using the same parameters, for example, check3=f3(Kdh, N1, N2, the PSK capability value of the second node, PK1, PK2). If the fourth authentication parameter C4 is equal to the third check parameter check3, the authenticity authentication of the PSK capability value of the second node is successful.

[0510] Step S917: The second node verifies the third authentication parameter based on the PSK capability value of the first node.

[0511] In particular, the second node may generate a fourth check parameter check4=KDF(PSK capability value of the first node). If the third authentication parameter C3 is equal to the fourth check parameter check4, the authenticity of the PSK capability value of the first node is successful.

[0512] Optionally, if the third authentication parameter C3 satisfies the formula C3=f3(Kdh, N1, N2, the PSK capability value of the first node, PK1, PK2), the second node may generate a corresponding check parameter check4 by using the same parameters, for example, check4=f3(Kdh, N1, N2, the PSK capability value of the first node, PK1, PK2). If the third authentication parameter C3 is equal to the fourth check parameter check4, the authenticity authentication of the PSK capability value of the first node is successful.

[0513] 10A and 10B are schematic flowcharts of a Bluetooth pairing method according to an embodiment of the present application, including but not limited to the following steps:

[0514] Step S1001: A first node determines that there is a first PSK shared with a second node.

[0515] For a specific explanation, please refer to the explanation of step S1201.

[0516] Step S1002: The first node sends a pairing request message to the second node.

[0517] For a specific explanation, please refer to the explanation of step S1202.

[0518] Step S1003: The second node determines a first pairing mode based on the input / output capability of the first node and the input / output capability of the second node.

[0519] For example, see FIG. 6. FIG. 6 is a possible manner of determining a first pairing mode according to this embodiment of the present application. Area 601 is the I / O capability of the first node, and area 902 is the I / O capability of the second node. It can be understood that the first pairing mode is determined based on the I / O capability of the first node and the I / O capability of the second node, and the first pairing mode can be numeric comparison (NC), just work (JW), or passkey entry (PE). For example, if the I / O capability of the first node is display yes no (DisplayYesNo) and the I / O capability of the second node is display yes no (DisplayYesNo), the corresponding pairing mode is numeric comparison.

[0520] Step S1004: The second node determines that the first PSK shared with the first node exists on the second node.

[0521] Specifically, the second node obtains a first device identifier of the first node. If it is determined based on the first device identifier that a first PSK corresponding to the first device identifier exists on the second node, this indicates that a first PSK shared with the first node exists on the second node. Both the first node and the second node have PSK pairing capability. Thus, the pairing is No. 1 This may be accomplished by utilizing a first PSK shared by the first node and the second node.

[0522] Step S1005: The second node determines the PSK-based pairing based on the priority of the first pairing mode and the priority of the PSK-based pairing.

[0523] For example, the priority of PSK-based pairing is 2, and the priority of numeric comparison mode is 3. When both the first node and the second node have PSK pairing capability, if the pairing mode corresponding to the I / O capability of the first node and the I / O capability of the second node is numeric comparison mode, the second node may select PSK-based pairing because the priority of PSK-based pairing is higher than the priority of numeric comparison mode.

[0524] Step S1006: The second node sends a pairing response message to the first node.

[0525] In particular, the pairing response message is utilized to indicate that pairing is performed by utilizing a first PSK shared by the first node and the second node.

[0526] It can be understood that the second node sends a pairing response message to the first node, and correspondingly, the first node receives the pairing response message fed back by the second node to obtain the message content in the pairing response message.

[0527] Step S1007: The first node sends the first freshness parameter to the second node.

[0528] For a specific explanation, please refer to the explanation of step S904.

[0529] Step S1008: The second node sends the second freshness parameter to the first node.

[0530] For a specific explanation, please refer to the explanation of step S905.

[0531] Step S1009: The first node generates a first authentication parameter based on the first PSK, the second freshness parameter, the first public key, and the second public key.

[0532] For a specific explanation, please refer to the explanation of step S906.

[0533] Step S1010: The second node generates a first authentication parameter based on the first PSK, the first freshness parameter, the first public key, and the second public key.

[0534] For a specific explanation, please refer to the explanation of step S907.

[0535] Step S1011: The second node sends second authentication parameters to the first node.

[0536] It may be understood that the second node transmits the second authentication parameters to the first node, and correspondingly, the first node receives the second authentication parameters from the second node.

[0537] Step S1012: The first node sends the first authentication parameter to the second node.

[0538] It may be understood that the first node transmits the first authentication parameter to the second node, and correspondingly, the second node receives the first authentication parameter from the first node.

[0539] Step S1013: The first node determines that authentication to the second node is successful based on the first PSK, the first freshness parameter, the first public key, the second public key, and the second authentication parameter.

[0540] For a specific explanation, please refer to the explanation of step S910.

[0541] Step S1014: The second node determines that authentication to the first node is successful based on the first PSK, the second freshness parameter, the first public key, the second public key, and the first authentication parameter.

[0542] For a specific explanation, please refer to the explanation of step S911.

[0543] Step S1015: The first node generates a third authentication parameter based on the PSK capability value of the first node.

[0544] For a specific explanation, please refer to the explanation of step S912.

[0545] Step S1016: The second node generates a fourth authentication parameter based on the PSK capability value of the second node.

[0546] For a specific explanation, please refer to the explanation of step S913.

[0547] Step S1017: The second node sends the third authentication parameter to the first node.

[0548] It may be understood that the second node transmits the third authentication parameter to the first node, and correspondingly, the first node receives the third authentication parameter from the second node.

[0549] Step S1018: The first node sends the fourth authentication parameter to the second node.

[0550] It can be understood that the first node transmits the fourth authentication parameter to the second node, and correspondingly, the second node receives the fourth authentication parameter from the first node.

[0551] Step S1019: The first node verifies the fourth authentication parameter based on the PSK capability value of the second node.

[0552] For a specific explanation, please refer to the explanation of step S916.

[0553] Step S1020: The second node verifies the third authentication parameter based on the PSK capability value of the first node.

[0554] For a specific explanation, please refer to the explanation of step S917.

[0555] The method in the embodiment of the present application is described in detail above, and the apparatus in the embodiment of the present application is provided below.

[0556] 11 is a schematic diagram of the structure of a Bluetooth pairing device 110 according to an embodiment of the present application. The device 110 may be a node or a component in a node, such as a chip or an integrated circuit. The device 110 may include a receiving unit 1101, a transmitting unit 1102, and a processing unit 1103. The Bluetooth pairing device 110 is configured to implement the above-mentioned Bluetooth pairing method, for example, the Bluetooth pairing method in any embodiment shown in FIGS. 2, 7, 8, 9A and 9B, or 10A and 10B.

[0557] It may be understood that in the device embodiments of the present application, the division into multiple units or modules is merely a logical division based on function and does not limit the specific structure of the device. In a specific implementation, some functional modules may be subdivided into smaller functional modules, and some functional modules may also be combined into one functional module. However, regardless of whether these functional modules are subdivided or combined, the general procedures performed by the device 110 in the Bluetooth pairing process remain the same. For example, the receiving unit 1101 and the transmitting unit 1102 in the device 110 may also be combined into a communication unit. Typically, each unit corresponds to a respective program code (or program instruction). When the program code corresponding to a unit is executed on a processor, the unit performs a corresponding procedure to implement the corresponding function.

[0558] In some possible implementations, the Bluetooth pairing device 110 may be the second node in the embodiments shown in Figures 2, 8, 9A and 9B, or 10A and 10B. The unit is described as follows.

[0559] The receiving unit 1101 is configured to receive a pairing request message from a first node, the pairing request message including information used to indicate whether the first node has pre-shared key (PSK) pairing capability.

[0560] The transmitting unit 1102 is configured to transmit a pairing response message to the first node in response to the pairing request message including information utilized to indicate that the first node has PSK pairing capability, the pairing response message being utilized to indicate that the first node will perform pairing by utilizing a first PSK shared by the first node and the second node.

[0561] The processing unit 1103 is configured to authenticate the first node based on the first PSK.

[0562] It can be understood that a PSK is a secret value shared by a first node and a second node, and the PSK shared with the second node is predefined or configured on the first node. Accordingly, device 110 may include information in the pairing request message indicating that the first node has PSK pairing capability. Correspondingly, the first PSK shared with the first node is also predefined or preconfigured on the second node. Device 110 may authenticate the first node based on the first PSK and determine that the first node's identity is trusted, and thus subsequent pairing can be successful. In this manner, the identity of a node for which a PSK is preconfigured or defined is typically trusted. This avoids successful pairing between device 110 and an untrusted node, improving the security of the node pairing process.

[0563] In a possible implementation, the processing unit 1103 may include: The second node decides to share the first PSK with the first node It is further configured as follows.

[0564] In another possible implementation, the processing unit comprises, inter alia: Obtain a first device identifier for the first node; Determine that a first PSK exists that corresponds to a first device identifier. It is configured as follows.

[0565] In yet another possible implementation, the pairing request message includes an input / output capability IOC field, which includes information utilized to indicate whether the first node has PSK pairing capability.

[0566] In yet another possible implementation, one portion of the bits in the IOC field contains a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0567] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0568] In yet another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0569] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0570] In yet another possible implementation, the processing unit 1103 is further configured to determine a pairing response message based on the pairing request message and preset pairing mode priority information, where the pairing mode priority information indicates that when the first node and the second node share a PSK, the pairing implemented by utilizing the PSK shared by the first node and the second node has the highest priority among multiple pairing modes.

[0571] In yet another possible implementation, the receiving unit 1101 is further configured to receive a first authentication parameter from the first node.

[0572] The processing unit 1103 is further configured to verify the first authentication parameter based on the first PSK.

[0573] In yet another possible implementation, the processing unit 1103 is further configured to generate a second authentication parameter based on the first PSK.

[0574] The sending unit is further configured to send the second authentication parameter to the first node.

[0575] In yet another possible implementation, the receiving unit 1101 is further configured to receive a third authentication parameter from the first node.

[0576] The processing unit 1103 is further configured to generate a fourth check parameter based on the PSK capability value of the first node.

[0577] The processing unit 1103 is further configured to determine, based on the fourth check parameter and the third authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0578] The processing unit 1103 is further configured to generate a fourth authentication parameter based on the PSK capability value of the second node.

[0579] The sending unit 1102 is further configured to send a fourth authentication parameter to the first node.

[0580] Please note that for the implementation of each unit, please refer to the corresponding description in the embodiment shown in Figures 2, 8, 9A and 9B, or 10A and 10B.

[0581] In some possible implementations, the Bluetooth pairing device 110 may be the first node in the embodiments shown in Figures 2, 8, 9A and 9B, or 10A and 10B. The unit is described as follows.

[0582] The sending unit 1102 is configured to send a pairing request message to the second node, the pairing request message including information used to indicate that the first node has pre-shared key (PSK) pairing capability.

[0583] The receiving unit 1101 is configured to receive a pairing response message fed back by the second node, which is used to indicate that pairing is performed by using a first PSK shared by the first node and the second node.

[0584] The processing unit 1103 is configured to authenticate the second node based on the first PSK.

[0585] It can be understood that a PSK is a secret value shared by a first node and a second node, and the PSK shared with the second node is predefined or configured on the first node. Thus, the second node may indicate in the pairing request message that the first node has PSK pairing capability. Correspondingly, the PSK shared with the first node (referred to as the first PSK for ease of explanation) is also predefined or preconfigured on the second node. Device 110 may authenticate the second node based on the first PSK and determine that the identity of the second node is trusted, and therefore, subsequent pairing can be successful. In this way, the identity of a node for which a PSK is preconfigured or defined is typically trusted. This avoids successful pairing between device 110 and an untrusted node, improving the security of the node pairing process.

[0586] In a possible implementation, the processing unit 1103 is further configured to determine that the second node shares the first PSK with the first node.

[0587] In another possible implementation, the processing unit 1103 may, inter alia: Obtain a second device identifier for the second node; Determining that a first PSK exists that corresponds to a second device identifier It is configured as follows.

[0588] In yet another possible implementation, the pairing request message includes an input / output capability IOC field, which includes information utilized to indicate whether the first node has PSK pairing capability.

[0589] In yet another possible implementation, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0590] Another portion of the bits in the IOC field is used to indicate the output capabilities of the first node.

[0591] In yet another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0592] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0593] In yet another possible implementation, the receiving unit 1101 is further configured to receive second authentication parameters from the second node.

[0594] The processing unit 1103 is further configured to verify the second authentication parameter based on the first PSK.

[0595] In yet another possible implementation, the processing unit 1103 is further configured to generate a first authentication parameter based on the first PSK.

[0596] The sending unit 1102 is further configured to send the first authentication parameter to the second node.

[0597] In yet another possible implementation, the pairing response message includes a PSK capability value of the second node, which is utilized to indicate that the second node has PSK pairing capability.

[0598] The receiving unit 1101 is further configured to receive a fourth authentication parameter from the second node.

[0599] The processing unit 1103 is further configured to generate a third check parameter based on the PSK capability value of the second node.

[0600] The processing unit 1103 is further configured to determine, based on the third check parameter and the fourth authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0601] The processing unit 1103 is further configured to generate a third authentication parameter based on the PSK capability value of the first node.

[0602] The sending unit 1102 is further configured to send a third authentication parameter to the second node.

[0603] Please note that for the implementation of each unit, please refer to the corresponding description in the embodiment shown in Figures 2, 8, 9A and 9B, or 10A and 10B.

[0604] In some possible implementations, the Bluetooth pairing device 110 may be the second node in the embodiment shown in Figure 7. The unit is described as follows.

[0605] The receiving unit 1101 is configured to receive a pairing request message from a first node, the pairing request message including information used to indicate the pairing capability of the first node, the pairing capability of the first node including whether the first node has the pre-shared key (PSK) pairing capability and input / output capability of the first node.

[0606] The processing unit 1103 is configured to determine a pairing mode based on the information about the pairing capability of the first node and the information about the pairing capability of the second node, where the pairing capability of the second node includes whether the second node has PSK pairing capability and input / output capability of the second node, and the pairing mode includes PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0607] The sending unit 1102 is configured to send a pairing response message to the first node, the pairing response message including information used to indicate the pairing capability of the second node.

[0608] The processing unit 1103 is further configured to perform pairing with the first node based on the pairing mode.

[0609] It can be understood that the pairing request message includes information about the pairing capabilities of the first node, and device 110 may determine a corresponding pairing mode based on the requirements and whether the first node has the PSK pairing capabilities and input / output capabilities of the first node. For example, device 110 may determine a pairing mode that meets the requirements of the second node by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0610] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0611] In a possible implementation, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability.

[0612] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0613] In another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0614] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0615] In yet another possible implementation, the processing unit 1103 may, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; Performing pairing by utilizing a first PSK shared by the first node and the second node It is configured as follows.

[0616] In yet another possible implementation, the processing unit 1103 may, inter alia: Obtain a first device identifier for the first node; Determine that a first PSK exists that corresponds to a first device identifier. It is configured as follows.

[0617] In yet another possible implementation, the processing unit 1103 may, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0618] In yet another possible implementation, the processing unit 1103 may, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0619] In yet another possible implementation, the receiving unit 1101 is further configured to receive a first authentication parameter from the first node.

[0620] The processing unit is further configured to verify the first authentication parameter based on the first PSK.

[0621] In yet another possible implementation, the processing unit is further configured to generate a second authentication parameter based on the first PSK.

[0622] The sending unit is further configured to send the second authentication parameter to the first node.

[0623] In yet another possible implementation, the receiving unit 1101 is further configured to receive a first freshness parameter sent by the first node.

[0624] The processing unit 1103 is further configured to generate a second authentication parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0625] In yet another possible implementation, the sending unit 1102 is further configured to send a second freshness parameter to the first node.

[0626] The processing unit 1103 is further configured to generate a second check parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK.

[0627] The processing unit 1103 is further configured to: the second node determine, based on the second check parameter and the first authentication parameter, that the first authentication parameter has been successfully verified.

[0628] In yet another possible implementation, the receiving unit 1101 is further configured to receive a third authentication parameter from the first node.

[0629] The processing unit 1103 is further configured to generate a fourth check parameter based on the PSK capability value of the first node.

[0630] The processing unit 1103 is further configured to determine, based on the fourth check parameter and the third authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0631] The processing unit 1103 is further configured to generate a fourth authentication parameter based on the PSK capability value of the second node.

[0632] The sending unit 1102 is further configured to send a fourth authentication parameter to the first node.

[0633] Please note that for the implementation of each unit, please refer to the corresponding description of the embodiment shown in FIG.

[0634] In some possible implementations, the Bluetooth pairing device 110 may be the first node in the embodiment shown in Figure 7. The unit is described as follows.

[0635] The sending unit 1102 is configured to send a pairing request message to the second node, the pairing request message including information used to indicate the pairing capability of the first node, the pairing capability of the first node including whether the first node has the pre-shared key (PSK) pairing capability and input / output capability of the first node.

[0636] The receiving unit 1101 is configured to receive a pairing response message from the second node, the pairing response message including information used to indicate the pairing capability of the second node, the pairing capability of the second node including whether the second node has the pre-shared key (PSK) pairing capability and input / output capability of the second node.

[0637] The processing unit 1103 is configured to determine a pairing mode based on the information about the pairing capability of the first node and the information about the pairing capability of the second node, where the pairing mode includes PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE).

[0638] The processing unit 1103 is further configured to perform pairing with the second node based on the pairing mode.

[0639] It can be understood that the pairing request message includes information about the pairing capability of the first node, and the pairing response message includes information about the pairing capability of the second node. The device 110 may determine a corresponding pairing mode based on the requirements and based on the information about the pairing capability of the first node and the information about the pairing capability of the second node. For example, the device 110 may determine a pairing mode that meets the requirements by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0640] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0641] In a possible implementation, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability.

[0642] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0643] In another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0644] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0645] In yet another possible implementation, the processing unit 1103: The second node determines to share the first PSK with the first node; determining, based on information about the pairing capability of the second node, that the first node has PSK pairing capability; Performing pairing by utilizing a first PSK shared by the first node and the second node It is further configured as follows.

[0646] In yet another possible implementation, the processing unit obtains a second device identifier of the second node; Determining that a first PSK exists that corresponds to a second device identifier It is further configured as follows.

[0647] In yet another possible implementation, the processing unit 1103 may, inter alia: determining, based on information regarding the pairing capability of the second node, that the second node does not have PSK pairing capability; determining a pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, the pairing mode being Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); It is configured as follows.

[0648] In yet another possible implementation, the processing unit 1103 may, inter alia: determining, based on information about the pairing capability of the second node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0649] In yet another possible implementation, the receiving unit 1101 is further configured to receive second authentication parameters from the second node.

[0650] The processing unit 1103 is further configured to verify the second authentication parameter based on the first PSK.

[0651] In yet another possible implementation, the processing unit 1103 is further configured to generate a first authentication parameter based on the first PSK.

[0652] The sending unit is further configured to send the first authentication parameter to the second node.

[0653] In yet another possible implementation, the receiving unit 1101 is further configured to receive a second freshness parameter sent by a second node.

[0654] The processing unit 1103 is further configured to generate a first authentication parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node.

[0655] In yet another possible implementation, the sending unit 1102 is further configured to send the first freshness parameter to the second node.

[0656] The processing unit 1103 is further configured to generate a first check parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK.

[0657] The processing unit 1103 is further configured to: the second node determine, based on the first check parameter and the second authentication parameter, that the second authentication parameter has been successfully verified.

[0658] In yet another possible implementation, the receiving unit 1101 is further configured to receive a third authentication parameter from the first node.

[0659] The processing unit 1103 is further configured to generate a fourth check parameter based on the PSK capability value of the first node.

[0660] The processing unit 1103 is further configured to determine, based on the fourth check parameter and the third authentication parameter, that the authenticity authentication for the PSK capability value of the first node is successful.

[0661] The processing unit 1103 is further configured to generate a fourth authentication parameter based on the PSK capability value of the second node.

[0662] The sending unit 1102 is further configured to send a fourth authentication parameter to the first node.

[0663] Please note that for the implementation of each unit, please refer to the corresponding description of the embodiment shown in FIG.

[0664] 12 is a schematic diagram of the structure of a communication device 120 according to an embodiment of the present application. The communication device 120 may be a node or a component in a node, for example, a chip or an integrated circuit. The device 120 may include at least one memory 1201 and at least one processor 1202, and may optionally further include a bus 1203. Furthermore, optionally, a communication interface 1204 may be included. The memory 1201, the processor 1202, and the communication interface 1204 are connected through the bus 1203.

[0665] The memory 1201 is configured to provide storage space, which may store data such as an operating system and computer programs, etc. The memory 1201 may be one or a combination of random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), compact disc read-only memory (CD-ROM), etc.

[0666] The processor 1202 is a module that performs arithmetic and / or logical operations and may be one or a combination of processing modules such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor unit (MPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and a complex programmable logic device (CPLD), among others.

[0667] The communication interface 1204 is configured to receive data sent by an external device and / or transmit data to an external device, and may be a wired link interface such as an Ethernet cable, or may be a wireless (e.g., Wi-Fi, Bluetooth, or general wireless transmission) link interface. Optionally, the communication interface 1204 may further include a transmitter (e.g., a radio frequency transmitter or antenna), a receiver, etc. coupled to the interface.

[0668] The processor 1202 in the device 120 is configured to read a computer program stored in the memory 1201 and to implement the above-mentioned Bluetooth pairing methods, for example, the Bluetooth pairing methods described in any of the embodiments shown in Figures 2, 7, 8, 9A and 9B, or 10A and 10B.

[0669] In some possible implementations, the Bluetooth pairing device 110 may be the first node in the embodiments shown in Figures 2, 8, 9A and 9B, or 10A and 10B. receiving a pairing request message from the first node through the communication interface 1204, the pairing request message including information utilized to indicate whether the first node has pre-shared key (PSK) pairing capability; transmitting, via communication interface 1204, a pairing response message to the first node in response to the pairing request message including information utilized to indicate that the first node has PSK pairing capability, the pairing response message utilized to indicate that pairing will be performed by utilizing a first PSK shared by the first node and the second node; authenticating the first node based on the first PSK; 12. The computer system 1200 is configured to read a computer program stored in the memory 1201 to perform the operations of

[0670] It can be understood that a PSK is a secret value shared by a first node and a second node, and the PSK shared with the second node is predefined or configured on the first node. Accordingly, device 120 may include information in the pairing request message indicating that the first node has PSK pairing capability. Correspondingly, the first PSK shared with the first node is also predefined or preconfigured on the second node. Device 120 may authenticate the first node based on the first PSK and determine that the first node's identity is trusted, and thus subsequent pairing can be successful. In this manner, the identity of a node for which a PSK is preconfigured or defined is typically trusted. This avoids successful pairing between the device and an untrusted node, improving the security of the node pairing process.

[0671] In a possible implementation, the processor 1202 may: The second node decides to share the first PSK with the first node It is further configured as follows.

[0672] In another possible implementation, the processor 1202 may, inter alia: Obtain a first device identifier for the first node; Determine that a first PSK exists that corresponds to a first device identifier. It is configured as follows.

[0673] In yet another possible implementation, the pairing request message includes an input / output capability IOC field, which includes information utilized to indicate whether the first node has PSK pairing capability.

[0674] In yet another possible implementation, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0675] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0676] In yet another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0677] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0678] In yet another possible implementation, the processor 1202 is further configured to determine a pairing response message based on the pairing request message and preset pairing mode priority information, where the pairing mode priority information indicates that when the first node and the second node share a PSK, a pairing implemented by utilizing the PSK shared by the first node and the second node has the highest priority among multiple pairing modes.

[0679] In yet another possible implementation, the processor 1202: receiving a first authentication parameter from the first node through the communication interface 1204; Verifying a first authentication parameter based on the first PSK It is further configured as follows.

[0680] In yet another possible implementation, the processor 1202: generating second authentication parameters based on the first PSK; Sending the second authentication parameters to the first node through the communication interface 1204. It is further configured as follows.

[0681] In yet another possible implementation, the processor 1202: receiving a third authentication parameter from the first node through the communication interface 1204; generating a fourth check parameter based on the PSK capability value of the first node; determining that the authenticity of the PSK capability value of the first node is successful based on the fourth check parameter and the third authentication parameter; generating a fourth authentication parameter based on the PSK capability value of the second node; Sending the fourth authentication parameter to the first node through the communication interface 1204. It is further configured as follows.

[0682] Please note that for the implementation of each unit, please refer to the corresponding description in the embodiment shown in Figures 2, 8, 9A and 9B, or 10A and 10B.

[0683] In some possible implementations, the Bluetooth pairing device 120 may be the first node in the embodiments shown in Figures 2, 8, 9A and 9B, or 10A and 10B. A processor 1202 in the device 120 may: sending a pairing request message to the second node via the communication interface 1204, the pairing request message including information utilized to indicate that the first node has pre-shared key (PSK) pairing capability; receiving a pairing response message fed back by the second node through the communication interface 1204, the pairing response message being utilized to indicate that pairing will be performed by utilizing a first PSK shared by the first node and the second node; authenticating the second node based on the first PSK; 12. The computer system 1200 is configured to read a computer program stored in the memory 1201 to perform the operations of

[0684] It can be understood that a PSK is a secret value shared by a first node and a second node, and the PSK shared with the second node is predefined or configured on the first node. Thus, the second node may indicate in the pairing request message that the first node has PSK pairing capability. Correspondingly, the PSK shared with the first node (referred to as the first PSK for ease of explanation) is also predefined or preconfigured on the second node. Device 120 may authenticate the second node based on the first PSK and determine that the identity of the second node is trusted, and therefore, subsequent pairing can be successful. In this way, the identity of a node for which a PSK is preconfigured or defined is typically trusted. This avoids successful pairing between device 120 and an untrusted node, improving the security of the node pairing process.

[0685] In a possible implementation, the processor 1202 is further configured to determine that the second node shares the first PSK with the first node.

[0686] In another possible implementation, the processor 1202 may, inter alia: Obtain a second device identifier for the second node; Determining that a first PSK exists that corresponds to a second device identifier It is configured as follows.

[0687] In yet another possible implementation, the pairing request message includes an input / output capability IOC field, which includes information utilized to indicate whether the first node has PSK pairing capability.

[0688] In yet another possible implementation, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is utilized to indicate whether the first node has PSK pairing capability.

[0689] Another portion of the bits in the IOC field is used to indicate the output capabilities of the first node.

[0690] In yet another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0691] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0692] In yet another possible implementation, the processor 1202: receiving second authentication parameters from the second node through the communication interface 1204; Verify the second authentication parameter based on the first PSK It is further configured as follows.

[0693] In yet another possible implementation, the processor 1202: generating first authentication parameters based on the first PSK; Sending the first authentication parameter to the second node through the communication interface 1204 It is further configured as follows.

[0694] In yet another possible implementation, the pairing response message includes a PSK capability value of the second node, which is utilized to indicate that the second node has PSK pairing capability. receiving a fourth authentication parameter from the second node through the communication interface 1204; generating a third check parameter based on the PSK capability value of the second node; determining that the authenticity of the PSK capability value of the first node is successful based on the third check parameter and the fourth authentication parameter; generating a third authentication parameter based on the PSK capability value of the first node; Sending the third authentication parameter to the second node through the communication interface 1204. It is further configured as follows.

[0695] Please note that for the implementation of each module, please refer to the corresponding description in the embodiment shown in Figures 2, 8, 9A and 9B, or 10A and 10B.

[0696] In some possible implementations, the Bluetooth pairing device 120 may be the second node in the embodiment shown in Figure 7. The processor 1202 in the device 120: receiving a pairing request message from the first node through the communication interface 1204, the pairing request message including information utilized to indicate the pairing capabilities of the first node, the pairing capabilities of the first node including whether the first node has pre-shared key (PSK) pairing capabilities and input / output capabilities of the first node; determining a pairing mode based on information regarding the pairing capabilities of the first node and information regarding the pairing capabilities of the second node, wherein the pairing capabilities of the second node include whether the second node has PSK pairing capability and input / output capability of the second node, and the pairing mode includes PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); transmitting a pairing response message to the first node via the communication interface 1204, the pairing response message including information utilized to indicate the pairing capabilities of the second node; Performing pairing with the first node based on a pairing mode; 12. The computer system 1200 is configured to read a computer program stored in the memory 1201 to perform the operations of

[0697] It can be understood that the pairing request message includes information about the pairing capabilities of the first node, and device 120 may determine a corresponding pairing mode based on the requirements and whether the first node has the PSK pairing capabilities and input / output capabilities of the first node. For example, device 120 may determine a pairing mode that meets the requirements of the second node by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0698] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0699] In a possible implementation, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability.

[0700] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0701] In another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0702] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0703] In yet another possible implementation, the processor 1202 may, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; Performing pairing by utilizing a first PSK shared by the first node and the second node It is configured as follows.

[0704] In yet another possible implementation, the processor 1202 may, inter alia: Obtain a first device identifier for the first node; Determine that a first PSK exists that corresponds to a first device identifier. It is configured as follows.

[0705] In yet another possible implementation, the processor 1202 may, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0706] In yet another possible implementation, the processor 1202 may, inter alia: determining, based on information regarding the pairing capability of the first node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0707] In yet another possible implementation, the processor 1202: receiving a first authentication parameter from the first node through the communication interface 1204; Verifying a first authentication parameter based on the first PSK It is further configured as follows.

[0708] In yet another possible implementation, the processor 1202: generating second authentication parameters based on the first PSK; Sending the second authentication parameters to the first node through the communication interface 1204. It is further configured as follows.

[0709] In yet another possible implementation, the processor 1202: receiving, via the communication interface 1204, a first freshness parameter sent by the first node; generating a second authentication parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node; It is further configured as follows.

[0710] In yet another possible implementation, the processor 1202: sending the second freshness parameter to the first node through the communication interface 1204; generating a second check parameter based on the second freshness parameter, the first public key, the second public key, and the first PSK; determining, based on the second check parameter and the first authentication parameter, that the first authentication parameter has been successfully verified; It is further configured as follows.

[0711] In yet another possible implementation, the processor 1202: receiving a third authentication parameter from the first node through the communication interface 1204; generating a fourth check parameter based on the PSK capability value of the first node; determining that the authenticity of the PSK capability value of the first node is successful based on the fourth check parameter and the third authentication parameter; generating a fourth authentication parameter based on the PSK capability value of the second node; Sending the fourth authentication parameter to the first node through the communication interface 1204. It is further configured as follows.

[0712] Please note that for the implementation of each module, please refer to the corresponding description of the embodiment shown in FIG.

[0713] In some possible implementations, the Bluetooth pairing device 120 may be the first node in the embodiment shown in Figure 7. The processor 1202 in the device 120 sending a pairing request message to the second node through the communication interface 1204, the pairing request message including information utilized to indicate the pairing capabilities of the first node, the pairing capabilities of the first node including whether the first node has pre-shared key (PSK) pairing capabilities and input / output capabilities of the first node; receiving a pairing response message from the second node through communication interface 1204, the pairing response message including information utilized to indicate pairing capabilities of the second node, the pairing capabilities of the second node including whether the second node has PSK pairing capabilities and input / output capabilities of the second node; determining a pairing mode based on information regarding pairing capabilities of the first node and information regarding pairing capabilities of the second node, the pairing mode including PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); performing pairing with a second node based on a pairing mode; 12. The computer system 1200 is configured to read a computer program stored in the memory 1201 to perform the operations of

[0714] It can be understood that the pairing request message includes information about the pairing capability of the first node, and the pairing response message includes information about the pairing capability of the second node. Apparatus 120 may determine a corresponding pairing mode based on the requirements and based on the information about the pairing capability of the first node and the information about the pairing capability of the second node. For example, apparatus 120 may determine a pairing mode that meets the requirements by utilizing a method such as preferentially selecting PSK-based pairing or selecting a pairing mode based on the priority of each mode.

[0715] In particular, for NoInputNoOutput Bluetooth nodes, DisplayOnly Bluetooth nodes, or DisplayYesNo Bluetooth nodes, PSK-based pairing is preferentially selected, thus avoiding pairing with untrusted nodes and improving the communication security of the nodes.

[0716] In a possible implementation, the pairing request message includes an input / output capability IOC field, and one portion of the bits in the IOC field includes a PSK capability value of the first node, which is used to indicate whether the first node has PSK pairing capability.

[0717] Another portion of the bits in the IOC field is used to indicate the input / output capabilities of the first node.

[0718] In another possible implementation, the pairing request message includes a PSK capability field, the PSK capability field includes a PSK capability value of the first node, and the PSK capability value of the first node is utilized to indicate whether the first node has PSK pairing capability.

[0719] The pairing request message further includes an input / output capability IOC field, which is used to indicate the input / output capability of the first node.

[0720] In yet another possible implementation, the processor 1202: The second node determines to share the first PSK with the first node; determining, based on information about the pairing capability of the second node, that the first node has PSK pairing capability; Performing pairing by utilizing a first PSK shared by the first node and the second node It is further configured as follows.

[0721] In yet another possible implementation, the processor 1202: Obtain a second device identifier for the second node; Determining that a first PSK exists that corresponds to a second device identifier It is further configured as follows.

[0722] In yet another possible implementation, the processor 1202 may, inter alia: determining, based on information regarding the pairing capability of the second node, that the second node does not have PSK pairing capability; determining a pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, the pairing mode being Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); It is configured as follows.

[0723] In yet another possible implementation, the processor 1202 may, inter alia: determining, based on information about the pairing capability of the second node, that the first node has PSK pairing capability; The second node determines to share the first PSK with the first node; determining a first pairing mode based on the input / output capabilities of the first node and the input / output capabilities of the second node, wherein the first pairing mode is Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); determining a pairing mode based on a priority of the first pairing mode and a priority of the PSK-based pairing; It is configured as follows.

[0724] In yet another possible implementation, the processor 1202 may, inter alia: receiving second authentication parameters from the second node through the communication interface 1204; Verify the second authentication parameter based on the first PSK It is configured as follows.

[0725] In yet another possible implementation, the processor 1202 may, inter alia: generating first authentication parameters based on the first PSK; Sending the first authentication parameter to the second node through the communication interface 1204 It is configured as follows.

[0726] In yet another possible implementation, the processor 1202: receiving, via the communication interface 1204, a second freshness parameter sent by the second node; generating a first authentication parameter based on a second freshness parameter, a first public key, a second public key, and a first PSK, where the first public key and the second public key are parameters for generating a shared key between the first node and the second node; It is further configured as follows.

[0727] In yet another possible implementation, the processor 1202: sending the first freshness parameter to the second node through the communication interface 1204; generating a first check parameter based on the first freshness parameter, the first public key, the second public key, and the first PSK; determining, based on the first check parameter and the second authentication parameter, that the second authentication parameter has been successfully verified; It is further configured as follows.

[0728] In yet another possible implementation, the processor 1202: receiving a third authentication parameter from the first node through the communication interface 1204; generating a fourth check parameter based on the PSK capability value of the first node; determining that the authenticity of the PSK capability value of the first node is successful based on the fourth check parameter and the third authentication parameter; generating a fourth authentication parameter based on the PSK capability value of the second node; Sending the fourth authentication parameter to the first node through the communication interface 1204. It is further configured as follows.

[0729] Please note that for the implementation of each module, please refer to the corresponding description of the embodiment shown in FIG.

[0730] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program, which, when executed on one or more processors, performs the method in any of the embodiments shown in Figures 2, 7, 8, 9A and 9B, or 10A and 10B.

[0731] An embodiment of the present application further provides a chip system, which includes at least one processor, a memory, and an interface circuit, wherein the interface circuit is configured to provide information input and output to the at least one processor, and the at least one memory stores a computer program, which, when executed on the one or more processors, performs the method in any of the embodiments shown in Figures 2, 7, 8, 9A and 9B, or 10A and 10B.

[0732] An embodiment of the present application further provides an intelligent cockpit product. The intelligent cockpit product includes a first node (e.g., a cockpit domain controller CDC of an automobile). The first node is the first node in any of the embodiments shown in FIGS. 2, 7, 8, 9A and 9B, or 10A and 10B. Furthermore, the intelligent cockpit product includes a second node (e.g., at least one of a camera, a screen, a microphone, a speaker, a radar, an electronic key, and a passive entry / passive start system controller). The second node is the second node in any of the embodiments shown in FIGS. 2, 7, 8, 9A and 9B, or 10A and 10B.

[0733] An embodiment of the present application further provides a vehicle. The vehicle includes a first node (e.g., a cockpit domain controller (CDC) of an automobile). The vehicle further includes a second node (e.g., at least one of a camera, a screen, a microphone, a speaker, a radar, an electronic key, and a passive entry / passive start system controller). The first node is the first node in any of the embodiments shown in FIGS. 2, 7, 8, 9A and 9B, or 10A and 10B, and the second node is the second node in any of the embodiments shown in FIGS. 2, 7, 8, 9A and 9B, or 10A and 10B.

[0734] An embodiment of the present application further provides a computer program product. When the computer program product is executed on one or more processors, the Bluetooth pairing method described in any of the embodiments shown in Figures 2, 7, 8, 9A and 9B, or 10A and 10B can be implemented. Alternatively, the vehicle can be replaced with an intelligent terminal or a transportation vehicle such as an unmanned aerial vehicle or a robot.

[0735] All or part of the above embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement an embodiment, all or part of the embodiment may be implemented in the form of a computer instruction product. When computer instructions are loaded and executed on a computer, procedures or functions according to the embodiments of the present application are implemented in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or another programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted using a computer-readable storage medium. The computer-readable storage medium may be any available medium accessible by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk drive, or a magnetic tape), an optical medium (e.g., a DVD), a semiconductor medium (e.g., a solid-state disk (SSD)), etc.

[0736] Sequence adjustment, combination or deletion may be performed on the steps in the method embodiments of the present application based on actual requirements.

[0737] The modules in the device embodiments of the present application can be combined, divided or deleted based on actual requirements.

Claims

1. A pairing method applied to a second node, said method comprising: receiving, by the second node, a pairing request message from the first node, the pairing request message including information indicating whether the first node has pre-shared key (PSK) capability and the input / output capabilities of the first node; transmitting, by the second node, a pairing response message to the first node in response to the pairing request message, the pairing response message including information indicating whether the second node has PSK capability and the input / output capabilities of the second node; The priority of using PSK for authentication is higher than that of an authentication method corresponding to the input / output capabilities; determining, by the second node, in response to the pairing request message indicating that the first node has the capability to pair using the PSK and the pairing response message indicating that the second node has the capability to pair using the PSK, to preferentially use the PSK to authenticate the first node; authenticating, by the second node, the first node based on the PSK; A method comprising:

2. the pairing response message includes a first field, the second node's capability to pair using the PSK being indicated by the first field being set to a value from a first group of values, and the second node's input / output capability being indicated by the first field being set to a value from a second group of values; The method of claim 1.

3. the pairing response message includes a first field; a bit in a first portion of the first field indicating whether the second node has the capability to pair using the PSK; bits of a second portion of the first field indicate the input / output capabilities of the second node; The method of claim 1.

4. the pairing response message includes a first field and a second field; the first field indicates whether the second node has the capability to pair using the PSK; the second field indicates the input / output capabilities of the second node; The method of claim 1.

5. Prior to the step of sending a pairing response message to the first node, the method further comprises: determining, by the second node, that the second node shares the PSK with the first node. The method according to any one of claims 1 to 4.

6. the pairing request message includes an Input / Output Capabilities (IOC) field, the IOC field indicating whether the first node has the capability to pair using the PSK; The method according to any one of claims 1 to 5.

7. Some bits of the IOC field include a PSK capability value of the first node, and the PSK capability value of the first node indicates whether the first node has the capability to pair using the PSK; The other bits of the IOC field indicate the input / output capabilities of the first node. The method of claim 6.

8. the pairing request message includes a PSK capability field, the PSK capability field including a PSK capability value of the first node, the PSK capability value of the first node being utilized to indicate whether the first node has the capability to pair using the PSK; The pairing request message further includes an input / output capability (IOC) field, the IOC field being used to indicate the input / output capability of the first node. The method according to any one of claims 1 to 7.

9. Prior to the step of transmitting, by the second node, a pairing response message to the first node, the method further comprises: determining, by the second node, the pairing response message based on the pairing request message and preset pairing mode priority information, wherein the pairing mode priority information indicates that, when the first node and the second node share a PSK, pairing performed using the PSK shared by the first node and the second node has the highest priority among a plurality of pairing modes; The method of claim 8.

10. The step of authenticating, by the second node, the first node based on the PSK comprises: receiving, by the second node, first authentication parameters from the first node; verifying, by the second node, the first authentication parameter based on the PSK; Including, The method according to any one of claims 1 to 9.

11. The method comprises: generating, by the second node, second authentication parameters based on the PSK; transmitting, by the second node, the second authentication parameters to the first node; further comprising: The method of claim 10.

12. the pairing request message includes a first PSK capability value of the first node, the first PSK capability value indicating whether the first node has the capability to pair using the PSK, and after the step of authenticating the first node based on the PSK by the second node, the method further comprises: receiving, by the second node, a third authentication parameter from the first node, the third authentication parameter being generated based on the first PSK capability value; generating, by the second node, a fourth check parameter based on the first PSK capability value; determining, by the second node, that authentication for the first PSK capability value is successful based on the fourth check parameter and the third authentication parameter; further comprising: The method according to any one of claims 1 to 11.

13. The method comprises: generating, by the second node, a fourth authentication parameter based on a second PSK capability value of the second node, the second PSK capability value indicating whether the second node has the capability to pair using the PSK; transmitting, by the second node, the fourth authentication parameter to the first node; further comprising: The method according to any one of claims 1 to 12.

14. A node pairing apparatus comprising a unit configured to perform the steps of the method according to any one of claims 1 to 13.

15. A computer readable medium storing a computer program which, when executed on one or more processors, performs the method of any one of claims 1 to 13.

Images