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 been widely used in people's lives. While enjoying convenient communication, people are also threatened by security vulnerability and privacy leakage. An intelligent vehicle is used as an example. With the wide application of vehicle communication, communication can be implemented between the vehicle and another device and between components within the 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 of two Bluetooth nodes, there are four modes: Numeric comparison, Just work, Passkey entry, and Out of band. The pairing mode is associated with the input / output capability of the node. For NoInputNoOutput, DisplayOnly, or DisplayYesNo nodes, in most cases, only Just work 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., the headset is connected 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 greatly threatens the privacy of users and the security of the vehicle. Especially for an in-vehicle communication system, this situation may 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 DISCLOSURE The 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 utilized 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 second node will effect 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 to determine that the identity of the first node is trustworthy, and thus the 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 be paired 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 is also connected in just work mode. In such pairing, an attacker can easily attack the second node by exploiting the first node, since the just work mode has low security. 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 includes:

[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, the IOC field including information utilized to indicate whether the first node has PSK pairing capability.

[0019] The above describes the data format of the pairing request message. It can be understood that the value of the IOC field can 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 can indicate that the first node has PSK pairing capability.

[0020] In yet another possible implementation of the first aspect, a 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 utilized to indicate the input / output capabilities of the first node.

[0022] The above describes another data form of the pairing request message. It can be understood that one part of the bits in the IOC field includes the PSK capability value of the first node. For example, the IOC field may include 8 bits. Two bits include 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 there is a first PSK shared with the second node. Thus, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported and pairing needs to be performed in another mode.

[0023] In addition, another part of the bits in the IOC field is utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

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

[0026] The above describes yet another data form 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 there is a first PSK shared with the second node. Thus, PSK-based pairing can be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported and pairing needs to be performed in another mode.

[0027] Furthermore, the IOC field is utilized 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, the 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 a first authentication parameter is generated by the first node based on a first PSK. Since the second node also has the first PSK, the second node may verify the first authentication parameter 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, it indicates that the identity of the first node is trustworthy. This avoids successful pairing between the second node and an untrusted node, improving the security of the node pairing process.

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

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

[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 second node's PSK capability value.

[0052] The second node sends a 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 that is utilized 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, the pairing response message being utilized to indicate that pairing is accomplished 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 to determine that the identity of the second node is trustworthy, and thus the 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 first node and an untrustworthy 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 be paired 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 is also connected in just work mode. In such pairing, an attacker can easily attack the second node by exploiting the first node, since the just work mode has low security. 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 shares 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, the IOC field including information utilized to indicate whether the first node has PSK pairing capability.

[0067] The above describes the data format of the pairing request message. It can be understood that the value of the IOC field can 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 can indicate that the first node has PSK pairing capability.

[0068] In yet another possible implementation of the second aspect, a 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 utilized to indicate the input / output capabilities of the first node.

[0070] The above describes another data form of the pairing request message. It can be understood that one part of the bits in the IOC field includes the PSK capability value of the first node. For example, the IOC field may include 8 bits. Two bits include 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 there is a first PSK shared with the second node. Thus, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported and pairing needs to be performed in another mode.

[0071] In addition, another part of the bits in the IOC field is utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

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

[0074] The above describes yet another data form 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 there is a first PSK shared with the second node. Thus, PSK-based pairing can be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported and pairing needs to be performed in another mode.

[0075] Furthermore, the IOC field is utilized 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, and a second authentication parameter is generated by the second node based on a first PSK. Since the first node also has a first PSK, the first node may verify the second authentication parameter 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, it indicates that the identity of the second node is trustworthy. This avoids successful pairing between the first node and an untrusted node, improving the security of the node pairing process.

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

[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 a 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 second node's PSK capability value.

[0098] The second node sends a 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 is 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, comprising:

[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. Thus, the apparatus 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 apparatus may authenticate the first node based on the first PSK to determine that the identity of the first node is trusted, and thus the subsequent pairing can be successful. In this way, the identity of the node for which the PSK is preconfigured or defined is usually trusted. This avoids successful pairing between the apparatus and an untrusted node, improving the security of the node pairing process.

[0102] In a possible implementation of the third aspect, the processing unit comprises: The second node decides to share the first PSK with the first node The method 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 of a 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, the IOC field including information utilized to indicate whether the first node has PSK pairing capability.

[0105] In yet another possible implementation of the third aspect, the pairing request message includes an input / output capability IOC field, and a 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 utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

[0108] The pairing request message further includes an input / output capability IOC field, where the IOC field is utilized 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 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 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 a 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 validity 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 a second node, the pairing response message being utilized to indicate that pairing is performed by utilizing a first PSK shared by the first node and the second node; a processing unit configured to authenticate the second node based on the first PSK; A Bluetooth pairing device is disclosed, comprising:

[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 to determine that the identity of the second node is trusted, and thus the subsequent pairing can be successful. In this way, the identity of the node for which the PSK is preconfigured or defined is usually trusted. This avoids successful pairing between the device and an untrusted node, improving 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, the IOC field including information utilized to indicate whether the first node has PSK pairing capability.

[0124] In yet another possible implementation of the fourth aspect, a 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 utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

[0127] The pairing request message further includes an input / output capability IOC field, where the IOC field is utilized 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 parameters 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, which 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 validity 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 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.

[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 utilized 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 a 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.

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

[0147] The above describes the data format of the pairing request message. It can be understood that one part of the bits in the IOC field includes the PSK capability value of the first node. For example, the IOC field may include 8 bits. Two bits include 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 there is a first PSK shared with the second node. Therefore, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported, and pairing needs to be performed in another mode.

[0148] In addition, another part of the bits in the IOC field is utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

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

[0151] The above describes another data form 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 there is a first PSK shared with the second node. Thus, PSK-based pairing can be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported and pairing needs to be performed in another mode.

[0152] Furthermore, the IOC field is utilized 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 the information regarding the pairing capabilities of the first node and the 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 the information regarding 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 the information regarding the pairing capabilities of the first node and the 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 the information regarding 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, the first pairing mode being 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 the information regarding the pairing capabilities of the first node and the 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 the information regarding 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, the first pairing mode being 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 includes:

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

[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 second node's PSK capability value.

[0190] The second node sends a 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 utilized 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 including information utilized to indicate the 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.

[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, the pairing mode including 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 capability of the first node, and the pairing response message includes information about the pairing capability 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 capability of the first node and the information about the pairing capability 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 a 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.

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

[0200] The above describes the data format of the pairing request message. It can be understood that one part of the bits in the IOC field includes the PSK capability value of the first node. For example, the IOC field may include 8 bits. Two bits include 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 there is a first PSK shared with the second node. Therefore, PSK-based pairing may be supported. In another example, "00" indicates that the first node does not have PSK pairing capability or there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported, and pairing needs to be performed in another mode.

[0201] In addition, another part of the bits in the IOC field is utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

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

[0204] The above describes yet another data form 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 there is a first PSK shared with the second node. Thus, PSK-based pairing can be supported. In another example, 0x00 indicates that the first node does not have PSK pairing capability or that there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported and pairing needs to be performed in another mode.

[0205] Furthermore, the IOC field is utilized 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 the information regarding the pairing capabilities of the first node and the information regarding the pairing capabilities of the second node includes:

[0215] The first node determines, based on information regarding 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, where the pairing mode is 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 the information regarding the pairing capabilities of the first node and the 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, the first pairing mode being Numeric Comparison NC, Just Work JW, or Passkey Entry PE.

[0221] The first node determines a 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 includes:

[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 a 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 second node's PSK capability value.

[0242] The second node sends a 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 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 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 capability of the second node including whether the second node has PSK pairing capability and input / output capability of the second node, and the pairing mode including 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 a pairing capability of the second node; A Bluetooth pairing device is disclosed, comprising:

[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 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 apparatus 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.

[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 a 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.

[0248] Another portion of the bits in the IOC field is utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

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

[0251] In yet another possible implementation of the seventh aspect, the processing unit is, 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, inter alia: Obtain a first device identifier of a 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, 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 an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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, 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 an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 a 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: 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 validity 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 a second node, the pairing response message including information utilized to indicate a pairing capability of the second node, the pairing capability of the second node including whether the second node has PSK pairing capability and input / output capability of the second 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, the pairing mode including PSK-based pairing, Numeric Comparison (NC), Just Work (JW), or Passkey Entry (PE); A Bluetooth node pairing apparatus is disclosed, comprising:

[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 a 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.

[0274] Another portion of the bits in the IOC field is utilized 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 capabilities field, the PSK capabilities field includes a PSK capabilities value of the first node, and the PSK capabilities value of the first node is utilized to indicate whether the first node has PSK pairing capabilities.

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

[0277] In yet another possible implementation of the eighth aspect, the processing unit comprises: The second node determines to share the first PSK with the first node; determining that the first node has PSK pairing capability based on information regarding the pairing capability of the second node; Performing pairing by utilizing a first PSK shared by the first node and the second node. The method 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 The method is further configured as follows.

[0279] In yet another possible implementation of the eighth aspect, the processing unit is, 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, inter alia: determining that the first node has PSK pairing capability based on information regarding the pairing capability of the second node; The second node determines to share the first PSK with the first node; determining a first pairing mode based on an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 a second authentication parameter 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 parameters 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 validity 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 an apparatus 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 an apparatus 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, which stores a computer program, which, 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 as 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.

[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, and when the computer program is executed on the one or more processors, the method described in the first aspect or any one of the possible implementations of the first aspect is performed, or the method described in the fifth aspect or any one of the possible implementations of the fifth aspect is performed.

[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, and when the computer program is executed on the one or more processors, the method described in the second aspect or any one of the possible implementations of the second aspect is performed, or the method described in the sixth aspect or any one of the possible implementations of the sixth aspect is performed.

[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 an apparatus 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] Further, 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). 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 description of the drawings]

[0303] The following describes the accompanying drawings which are utilized 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; [Diagram 2] 2 is a flowchart of a Bluetooth pairing method according to an embodiment of the present application. [Diagram 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. 13 is a schematic diagram of a frame structure of another pairing request message according to an embodiment of the present application; [Diagram 5] FIG. 13 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] 2 is a schematic diagram of the structure of another Bluetooth pairing device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0305] Hereinafter, the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application. Please note that in this application, words such as "example" or "for example" are used to indicate giving 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 the related concept 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 modules such as 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, such as a router, a repeater, a bridge, or a switch, or may be a terminal device, such as 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 (e.g., 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 kind 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 the 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 some parameters to derive a key through agreement. The cryptographic algorithm used for key agreement is called a key agreement algorithm, and 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 the SM algorithms (such as SM1, SM2, SM3, and SM4).

[0314] 4.Bluetooth pairing process

[0315] Bluetooth is a short-range wireless communication technology, which can be utilized for wireless information exchange between nodes. Pairing needs to be performed first between nodes that communicate with each other by utilizing Bluetooth. The pairing process aims to generate a link key between two Bluetooth nodes, which is utilized to authenticate each other's identity and encrypt exchanged data. In practical applications, generally, the two nodes do not perform encryption by utilizing the link key directly, but export a session key by utilizing 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 utilized, the two Bluetooth nodes will export a link key when they input the same password PIN. This method requires that both nodes 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 capability can be "No Input", "Yes / No" (which can also be represented as "YesNo"), or "Keyboard", which will be explained in detail below.

[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 that the node has another mechanism that can indicate "Yes" or "No."

[0321] (3) "Keyboard" indicates that the node has at least one numeric keyboard capable of entering 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 by which it 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 capability 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 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. Thus, 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 may also be called freshness or fresh parameter, and may include at least one of NONCE (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. Thus, 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 to more clearly describe 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] FIG. 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 regarded as a first node, and a smartphone 102 may be regarded 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 point and connects to the CDC101 by using the attacker's mobile phone, the numeric comparison mode cannot prevent the attacker from connecting to the CDC101, so the CDC101 will be successfully connected to the attacker's mobile phone, compromising the security of the vehicle.

[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 a 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. Thus, the security of the Bluetooth headset is threatened. Thus, the existing pairing method 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 that is utilized to indicate whether the first node has pre-shared key (PSK) pairing capability. If the first PSK shared with the second node is present on the first node, then the first node has PSK pairing capability. Correspondingly, if the first PSK shared with the second node is not present on the first node, then the first node does not have PSK pairing capability.

[0339] The pairing request message including information utilized 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, and the IOC field includes information used to indicate whether the first node has PSK pairing capability. For example, see 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), an 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). 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 key length supported (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 of a binary number, which is equivalent to the left-most bit of a decimal number. Correspondingly, the least significant bit (LSB) is the least significant weighted bit of a binary number, which is equivalent to the right-most bit of a decimal number.

[0341] The IOC field is utilized 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 can indicate that the first node has PSK pairing capability. Correspondingly, when the value of the IOC field is another value, it can 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 can be specifically indicated. For example, when the value of the IOC field is 0x01, it can indicate that the I / O capability of the first node is DisplayOnly.

[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. The pairing request message 701 includes fields such as Code, IOC, OOB data flag, 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 there is a first PSK shared with the second node. Thus, PSK-based pairing may be supported. In another example, a PSK capability value of "00" indicates that the first node does not have PSK pairing capability or that there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported, and pairing needs to be performed in another mode.

[0345] [Table 3]

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

[0347] See Figure 4. Optionally, another part of the bits in the IOC field may be utilized 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 utilized 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, Maximum 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, and the PSK capability value of the first node is used to indicate whether the first node has PSK pairing capability. Table 4 shows another possible PSK capability value and a corresponding description of the value 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 there is a first PSK shared with the second node. Thus, 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 there is no first PSK shared with the second node. In this case, PSK-based pairing is not supported and pairing needs to be performed in another mode.

[0350] [Table 4]

[0351] See Figure 4. Optionally, the IOC may be utilized 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, the value in the IOC field is 0x01, indicating 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 embodiment 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 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 a node's identification (ID), a media access control (MAC) address, a domain name, a domain address, or another user-defined identifier. The first node may obtain a second node's device identifier (for ease of description, the second node's device identifier is referred to as a second device identifier) ​​and determine whether a first PSK corresponding to the second device identifier exists on the first node based on the second device identifier. 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 indicating that the first node has PSK pairing capability to the pairing request message.

[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 that is used to indicate that the first node has PSK pairing capability. Thus, the second node may learn based on the information that the first node has PSK pairing capability, which indicates that PSK-based pairing may be performed between the first node and the second node. Thus, the second node transmits a pairing response message to the first node.

[0358] The pairing response message is used to indicate that pairing is 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 corresponds to PSK-based pairing, i.e., indicates to the first node that pairing is to be 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 to perform pairing 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 several implementation solutions as follows.

[0361] Implementation solution 1: The pairing response message includes an I / O capability IOC field, and the IOC field includes information used to indicate whether the second node has PSK pairing capability. For example, when the value of the IOC field in the pairing response message is 0x05, it may indicate that the second 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, thereby indicating that the first node cannot perform PSK-based pairing. Furthermore, when the value of the IOC field is another value, the I / O capability of the second 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 second node is DisplayOnly.

[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, and 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, and a PSK capability value of "01" indicates that the second node has PSK pairing capability or that there is a first PSK shared with the first node. Thus, PSK-based pairing can be supported. Optionally, if the PSK capability value is "00", it indicates that the second node does not have information about PSK pairing capability or that there is no first PSK shared with the first node. In this case, PSK-based pairing is not supported, and pairing needs to be performed in another pairing mode.

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

[0364] Optionally, another part of the bits in the IOC field may be utilized 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 KeyboardDisplay. If the I / O capability of the first node is DisplayOnly, 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 a PSK capability value of the second node, and 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 there is a first PSK shared with the first node. Thus, PSK-based pairing may be supported. Optionally, if the PSK capability value is "0x00", it may indicate that the second node does not have information about PSK pairing capability or that there is no first PSK shared with the first node. In this case, PSK-based pairing is not supported and pairing needs to 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, indicating 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 is carried in the pairing response message, or the input / output capability of the second node is 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 the first PSK shared with the first node exists on the second node.

[0369] Optionally, when the pairing request message further includes the I / O capability of the first node, the second node may determine a first pairing mode based on the I / O capability of the first node and the I / O capability 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 capability of the first node, and area 602 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 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 the use of the out-of-band mode 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 the 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 the PSK-based pairing or select a pairing mode with a higher priority based on the priority of the pairing mode. For example, the pairing mode priority information indicates that when the first node and the second node share a PSK, the 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 be that 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 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 may 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, the first node shares a first PSK with the second node. Thus, the second node can authenticate the first node by utilizing the first PSK. In particular, there can be several schemes:

[0375] Scheme 1: The second node sends first authentication data to the first node. The first authentication data may be encrypted by utilizing the first PSK or by utilizing a session key derived (or derived) from the first PSK. If the first node can decrypt the authentication data and feed back 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 utilizing a key derivation algorithm KDF, for example, C1=KDF(first PSK). Since the second node also has the first PSK, the second node may verify the first authentication parameter in a corresponding manner. For example, the second node may 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 may generate a second check parameter check2 based on the first PSK on the second node, for example, 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. For details, see the examples below.

[0378] Case 1: The second node sends a freshness parameter to the first node (for ease of description, the freshness parameter sent by the second node is referred to as the second freshness parameter). The freshness parameter may include at least one of 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 thus the identity of the first node can be authenticated.

[0379] Case 2: A shared key is pre-generated (or obtained) 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 the first public key and the second public key. 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). 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, 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 utilizing the first PSK or may be encrypted by utilizing 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 utilizing a key derivation algorithm KDF, for example, C2=KDF(first PSK). Since the first node also has the first PSK, the first node may verify the second authentication parameter in a corresponding manner. For example, the first node may 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 may generate a first check parameter check1 based on the first PSK on the first node, for example, 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 parameters 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. For details, see the examples below.

[0385] Case 1: A first node sends a freshness parameter to a second node (for ease of description, 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 thus the identity of the second node can be authenticated.

[0386] In order to explain the solution more clearly, it should be noted that multiple steps are used to explain 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 pre-generated (or obtained) 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 the first freshness parameter N1, the first PSK, the first public key PK1, and the 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 utilizing 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 KDF, for example, 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 PSK capability value of the first node is successful.

[0389] Optionally, when the first response request message includes the PSK capability value of the second node, the second node may authenticate the validity of the PSK capability value of the second node. 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 PSK capability value of the second node. The first node generates a third check parameter based on the PSK capability value of the second node obtained from the pairing response message, and determines the validity of the PSK capability value of the second node based on the third check parameter and the fourth authentication parameter. 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 KDF, for example, 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 authentication 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, the second random number, the first public key, and the second public key. For example, the third authentication parameter C3 is generated based on the shared key Kdh, the first random number N1, the second random number N2, the PSK capability value "01" of the first node, the first public key PK1, and the second public key PK2 by utilizing the 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 ​​of 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 to determine that the identity of the first node is trustworthy, and thus the 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 first node or the second node and an untrustworthy 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 utilized 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] 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. The IOC field in the pairing request message 701 includes the I / O capability 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 capability of the first node and the information about the pairing capability 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 a 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, 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 the second node does not have PSK pairing capability (or 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 a 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 an I / O capability of the first node. The second node determines a first pairing mode based on the I / O capability of the first node and the I / O capability of the second node, and determines a pairing mode based on a priority of the first pairing mode and a 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 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 capabilities of the first node and the I / O capabilities of 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 PSK-based pairing mode, numeric comparison mode, and 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 utilized to indicate whether the second node has PSK pairing capability, and another portion of the bits in the IOC field includes the I / O capabilities of the second node.

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

[0414] It may 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 utilizing the first PSK shared with the first node. For detailed processing, please refer to the specific description of step S203. Here, the details will not be described again.

[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 regarding the pairing capabilities of the first node and the information regarding 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 the first node does not have PSK pairing capability (or 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 a 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 is present 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 as a 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, according to the protocol provisions, the scheme used by the second node to determine the pairing mode is also used by the first node to determine the pairing mode, and thus the schemes 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 utilizing the first PSK shared with the second node. For detailed processing, please refer to the specific description of step S204. Here, the details will not be described again.

[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] In the embodiment shown in Figure 7, 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 first node and the second node may determine the 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 second node may determine the pairing mode that meets the requirements of the second node by utilizing a method such as preferentially selecting PSK-based pairing or selecting the 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 Fig. 2 includes many possible implementation solutions. The following separately shows some of the implementation solutions with reference to Fig. 8, Fig. 9A and Fig. 9B, and Fig. 10A and Fig. 10B. Please note that for the explanation of related concepts, operations, or logical relationships that are not described in Fig. 8, Fig. 9A and Fig. 9B, and Fig. 10A and Fig. 10B, please refer to the corresponding explanation in the embodiment shown in Fig. 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, it 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 is present 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 utilized 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] In particular, 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, it 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, pairing may be performed by utilizing the first PSK shared by the second 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 accomplished by utilizing a first PSK shared by the first node and the second node.

[0444] It may 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, such that the first node authenticates the second node based on the second authentication parameter.

[0447] It may 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 a first authentication parameter, and thus the second node authenticates the first node based on the first authentication parameter.

[0450] It may 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 during 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 parameters to the second node, and correspondingly, the second node receives the first authentication parameters 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, 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 thus 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, 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 thus 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. The method includes, but is not limited to, the following steps:

[0465] Step S901: A first node sends a pairing request message to a 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 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.

[0468] 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, 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, then 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.

[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 accomplished 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, the pairing is performed by utilizing a shared first PSK.

[0476] It may 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 a 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, such that the first node authenticates the second node based on the second authentication parameter.

[0479] It may 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 a 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 a first authentication parameter, and thus the second node authenticates the first node based on the first authentication parameter.

[0482] It may 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 during 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 during 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 parameters to the second node.

[0492] It may be understood that the first node transmits the first authentication parameters to the second node, and correspondingly, the second node receives the first authentication parameters 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, 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 thus 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, 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 thus 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, the second random number, the first public key, and the second public key. For example, the third authentication parameter C3 is generated based on the shared key Kdh, the first random number N1, the second random number N2, the PSK capability value "01" of the first node, the first public key PK1, and the second public key PK2 by utilizing the encryption algorithm f3, and may be, for example, C3=f3(Kdh, N1, N2, "01", PK1, PK2). Furthermore, optionally, step S1212 may correspond to the authentication phase 2 in the Bluetooth pairing process. In this case, the third authentication parameter is the verification parameter verification E1 in the 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 is generated based on the shared key Kdh, the first random number N1, the second random number N2, the PSK capability value "01" of the second node, 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). Furthermore, optionally, step S1213 may correspond to the authentication phase 2 in the Bluetooth pairing process. In this case, the fourth authentication parameter is the verification parameter verification E2 in the 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 a fourth authentication parameter to the second node.

[0506] It may 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 authentication 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 utilizing 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 authentication 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 utilizing 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. The method includes, but is 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 detailed 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 DisplayYesNo and the I / O capability of the second node is 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] In particular, 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, it 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, pairing may be performed by utilizing the first PSK shared by the second 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 the 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 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.

[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 accomplished by utilizing a first PSK shared by the first node and the second node.

[0526] It may 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 detailed 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 detailed 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 a first authentication parameter to the second node.

[0538] It may be understood that the first node transmits the first authentication parameters to the second node, and correspondingly, the second node receives the first authentication parameters 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 detailed 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 may 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 a structure of a Bluetooth pairing device 110 according to an embodiment of the present application. The device 110 may be a node, or may be a component in a node, such as a chip or an integrated circuit. The device 110 may include a receiving unit 1101, a sending unit 1102, and a processing unit 1103. The Bluetooth pairing device 110 is configured to implement the above Bluetooth pairing method, such as the Bluetooth pairing method in any embodiment shown in FIG. 2, FIG. 7, FIG. 8, FIG. 9A and FIG. 9B, or FIG. 10A and FIG. 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 functions, 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 are 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 the unit is executed on the processor, the unit executes the 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 includes information used to indicate whether the first node has a pre-shared key (PSK) pairing capability.

[0560] The sending unit 1102 is configured for the second node to send 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 second 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. Thus, the 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. The device 110 may authenticate the first node based on the first PSK to determine that the identity of the first node is trusted, and thus the subsequent pairing can be successful. In this way, the identity of the node for which the PSK is preconfigured or defined is usually trusted. This avoids successful pairing between the 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 The method is further configured as follows.

[0564] In another possible implementation, the processing unit comprises, inter alia: Obtain a first device identifier of a 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 capabilities IOC field, which includes information utilized to indicate whether the first node has PSK pairing capabilities.

[0566] In yet another possible implementation, a 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.

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

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

[0569] The pairing request message further includes an input / output capability IOC field, where the IOC field is utilized 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 a 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 validity 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 utilized 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. The pairing response message is used to indicate that pairing is performed by utilizing 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. The device 110 may authenticate the second node based on the first PSK to determine that the identity of the second node is trustworthy, and thus the 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 device 110 and an untrustworthy 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 capabilities IOC field, which includes information utilized to indicate whether the first node has PSK pairing capabilities.

[0589] In yet another possible implementation, the pairing request message includes an input / output capabilities IOC field, and a 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 utilized to indicate the output capabilities of the first node.

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

[0592] The pairing request message further includes an input / output capability IOC field, where the IOC field is utilized 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 a 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 parameters 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 validity 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 includes information used to indicate the pairing capability of the first node, and the pairing capability of the first node includes whether the first node has a pre-shared key PSK pairing capability and an 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 utilized 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 regarding the pairing capabilities of the first node, and the apparatus 110 may determine a corresponding pairing mode based on the requirements and based on whether the first node has the PSK pairing capabilities and input / output capabilities of the first node. For example, the apparatus 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 a 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.

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

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

[0614] The pairing request message further includes an input / output capability IOC field, where the IOC field is utilized 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 of a 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 an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 a 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: 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 validity 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 utilized 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 includes information used to indicate the pairing capability of the second node, and the pairing capability of the second node includes 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, the pairing mode including 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 apparatus 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 apparatus 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 a 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.

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

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

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

[0645] In yet another possible implementation, the processing unit 1103 may: The second node determines to share the first PSK with the first node; determining that the first node has PSK pairing capability based on information regarding the pairing capability of the second node; Performing pairing by utilizing a first PSK shared by the first node and the second node. The method 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 The method 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 that the first node has PSK pairing capability based on information regarding the pairing capability of the second node; The second node determines to share the first PSK with the first node; determining a first pairing mode based on an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 a 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 parameters 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: 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 validity 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 a 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, such as 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 further included. The memory 1201, the processor 1202, and the communication interface 1204 are connected through the bus 1203.

[0665] Memory 1201 is configured to provide a storage space, which may store data such as an operating system and computer programs, etc. 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] 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 is configured to implement the above-mentioned Bluetooth pairing method, for example the Bluetooth pairing method 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 via 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 the communications 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 effecting pairing by utilizing a first PSK shared by the first node and the second node; authenticating the first node based on the first PSK; The computer program product 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. Thus, the 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. The device 120 may authenticate the first node based on the first PSK to determine that the identity of the first node is trusted, and thus the subsequent pairing can be successful. In this way, the identity of the node for which the PSK is preconfigured or defined is usually trusted. This avoids successful pairing between the device and an untrusted node, improving the security of the node pairing process.

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

[0672] In another possible implementation, the processor 1202 may, inter alia: Obtain a first device identifier of a 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 capabilities IOC field, which includes information utilized to indicate whether the first node has PSK pairing capabilities.

[0674] In yet another possible implementation, the pairing request message includes an input / output capabilities IOC field, and a 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 utilized to indicate the input / output capabilities of the first node.

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

[0677] The pairing request message further includes an input / output capability IOC field, where the IOC field is utilized 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, the 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 may: receiving a first authentication parameter from a first node via a communication interface 1204; Verifying a first authentication parameter based on the first PSK The method is further configured as follows.

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

[0681] In yet another possible implementation, the processor 1202 may: receiving a third authentication parameter from the first node via the communication interface 1204; generating a fourth check parameter based on the PSK capability value of the first node; determining that the authenticity authentication 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. The method 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 performing pairing by utilizing a first PSK shared by the first node and the second node; authenticating the second node based on the first PSK; The computer program product 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. The device 120 may authenticate the second node based on the first PSK to determine that the identity of the second node is trustworthy, and thus the 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 device 120 and an untrustworthy 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 capabilities IOC field, which includes information utilized to indicate whether the first node has PSK pairing capabilities.

[0688] In yet another possible implementation, the pairing request message includes an input / output capabilities IOC field, and a 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 utilized to indicate the output capabilities of the first node.

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

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

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

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

[0694] In yet another possible implementation, 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. receiving a fourth authentication parameter from the second node via the communication interface 1204; generating a third check parameter based on the PSK capability value of the second node; determining that the authenticity authentication 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. The method 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 FIG. 7. The processor 1202 in the device 120 may: receiving a pairing request message from the first node through the communication interface 1204, 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 input / output capability of the first node; determining 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 capability of the second node including whether the second node has PSK pairing capability and input / output capability of the second node, and the pairing mode including PSK based pairing, Numeric Comparison NC, Just Work JW, or Passkey Entry PE; transmitting a pairing response message to the first node over the communication interface 1204, the pairing response message including information utilized to indicate a pairing capability of the second node; Performing pairing with the first node based on a pairing mode; The computer program product 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 regarding the pairing capabilities of the first node, and the 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, the 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 a 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.

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

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

[0702] The pairing request message further includes an input / output capability IOC field, where the IOC field is utilized 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 of a 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 an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 may: receiving a first authentication parameter from a first node via a communication interface 1204; Verifying a first authentication parameter based on the first PSK The method is further configured as follows.

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

[0709] In yet another possible implementation, the processor 1202 may: receiving a first freshness parameter sent by a first node through a communication interface 1204; 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; The method is further configured as follows.

[0710] In yet another possible implementation, the processor 1202 may: transmitting the second freshness parameter to the first node via 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; The method is further configured as follows.

[0711] In yet another possible implementation, the processor 1202 may: receiving a third authentication parameter from the first node via the communication interface 1204; generating a fourth check parameter based on the PSK capability value of the first node; determining that the authenticity authentication 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. The method 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 FIG. 7. The processor 1202 in the device 120 may: sending a pairing request message to the second node through the communication interface 1204, 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 input / output capability of the first node; receiving a pairing response message from the second node through the 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 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); performing pairing with a second node based on a pairing mode; The computer program product 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. The 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, the 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 a 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.

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

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

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

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

[0721] In yet another possible implementation, the processor 1202 may: Obtain a second device identifier for the second node; Determining that a first PSK exists that corresponds to a second device identifier The method 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 that the first node has PSK pairing capability based on information regarding the pairing capability of the second node; The second node determines to share the first PSK with the first node; determining a first pairing mode based on an input / output capability of the first node and an input / output capability of the second node, the first pairing mode being a Numeric Comparison (NC), a Just Work (JW), or a 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 via 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 a first authentication parameter based on the first PSK; Transmitting the first authentication parameters to the second node through the communication interface 1204. It is configured as follows.

[0726] In yet another possible implementation, the processor 1202 may: 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; The method is further configured as follows.

[0727] In yet another possible implementation, the processor 1202 may: transmitting the first freshness parameter to the second node via 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; The method is further configured as follows.

[0728] In yet another possible implementation, the processor 1202 may: receiving a third authentication parameter from the first node via the communication interface 1204; generating a fourth check parameter based on the PSK capability value of the first node; determining that the authenticity authentication 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. The method 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. The computer-readable storage medium stores a computer program. When the computer program is executed on one or more processors, the method in any embodiment shown in Figure 2, Figure 7, Figure 8, Figure 9A and Figure 9B, or Figure 10A and Figure 10B is performed.

[0731] An embodiment of the present application further provides a chip system, which includes at least one processor, a memory, and an interface circuit, the interface circuit being configured to provide information input and output to the at least one processor, and the at least one memory storing 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 embodiment shown in FIG. 2, FIG. 7, FIG. 8, FIG. 9A and FIG. 9B, or FIG. 10A and FIG. 10B. In addition, 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 module such as a passive entry passive start system controller). The second node is the second node in any embodiment shown in FIG. 2, FIG. 7, FIG. 8, FIG. 9A and FIG. 9B, or FIG. 10A and FIG. 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). In addition, 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 module such as a passive entry passive start system controller). The first node is the first node in any embodiment shown in FIG. 2, FIG. 7, FIG. 8, FIG. 9A and FIG. 9B, or FIG. 10A and FIG. 10B, and the second node is the second node in any embodiment shown in FIG. 2, FIG. 7, FIG. 8, FIG. 9A and FIG. 9B, or FIG. 10A and FIG. 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 embodiment shown in Figure 2, Figure 7, Figure 8, Figure 9A and Figure 9B, or Figure 10A and Figure 10B can be implemented. Alternatively, the vehicle can be replaced with an intelligent terminal or a traffic vehicle such as an unmanned aerial vehicle or a robot.

[0735] All or part of the above embodiments may be implemented by utilizing software, hardware, firmware, or any combination thereof. When software is utilized to implement the embodiments, all or part of the embodiments may be implemented in the form of a computer instruction product. When the computer instructions are loaded and executed on a computer, the 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 by utilizing 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 a 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. 1. A Bluetooth node pairing method applied to a second node that supports Bluetooth, comprising: receiving, by the second node, a pairing request message from the first node, the pairing request message including information utilized to indicate whether the first node has pre-shared key (PSK) pairing capability; transmitting, by the second node, 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 the PSK pairing capability, 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, by the second node, the first node based on the first PSK; A Bluetooth node pairing method comprising:

2. Prior to the step of transmitting a pairing response message to the first node, the method further comprises: determining, by the second node, that the second node shares the first PSK with the first node; Further comprising: The method of claim 1.

3. the pairing request message includes an input / output capability IOC field, the IOC field including the information utilized to indicate whether the first node has PSK pairing capability; The method according to claim 1 or 2.

4. a portion of the bits in the IOC field includes 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 PSK pairing capability; Another portion of the bits in the IOC field is utilized to indicate the input / output capabilities of the first node. The method according to claim 3.

5. 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 PSK pairing capability; The pairing request message further includes an input / output capability IOC field, the IOC field being used to indicate an input / output capability of the first node. The method according to claim 1 or 2.

6. 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, the pairing mode priority information indicating 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 a highest priority among a plurality of pairing modes; Further comprising: The method according to claim 4 or 5.

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

8. The method comprises: generating, by the second node, second authentication parameters based on the first PSK; transmitting, by the second node, the second authentication parameters to the first node; Further comprising: The method of claim 7.

9. After the step of authenticating, by the second node, the first node based on the first PSK, the method further comprises: receiving, by the second node, a third authentication parameter from the first node; generating, by the second node, a fourth check parameter based on the PSK capability value of the first node; determining, by the second node based on the fourth check parameter and the third authentication parameter, that authentication of the PSK capability value of the first node is successful; generating, by the second node, a fourth authentication parameter based on the second node's PSK capability value; 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 8.

10. 1. A Bluetooth node pairing method applied to a first node supporting Bluetooth, the method comprising: sending, by the first node, 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; receiving, by the first node, a pairing response message fed back by the second node, the pairing response message being utilized to indicate performing pairing by utilizing a first PSK shared by the first node and the second node; authenticating, by the first node, the second node based on the first PSK; A Bluetooth node pairing method comprising:

11. Prior to the step of transmitting, by the first node, a pairing request message to a second node, the method further comprises: determining, by the first node, that the second node will share the first PSK with the first node; Further comprising: The method of claim 10.

12. the pairing request message includes an input / output capability IOC field, the IOC field including information utilized to indicate whether the first node has pairing capability; 12. The method according to claim 10 or 11.

13. a portion of the bits in the IOC field indicates 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 PSK pairing capability; Another portion of the bits in the IOC field are utilized to indicate the output capabilities of the first node. The method of claim 12.

14. 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 PSK pairing capability; 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.

12. The method according to claim 10 or 11.

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

16. The method comprises: generating, by the first node, a first authentication parameter based on the first PSK; transmitting, by the first node, the first authentication parameters to the second node; Further comprising: The method of claim 15.

17. The pairing response message includes a PSK capability value of the second node, the PSK capability value of the second node being utilized to indicate that the second node has the PSK pairing capability, and after the step of authenticating, by the first node, the second node based on the first PSK, the method further comprises: receiving, by the first node, a fourth authentication parameter from the second node; generating, by the first node, a third check parameter based on the PSK capability value of the second node; determining, by the first node based on the third check parameter and the fourth authentication parameter, that authentication of the PSK capability value of the first node is successful; generating, by the first node, a third authentication parameter based on the PSK capability value of the first node; transmitting, by the first node, the third authentication parameter to the second node; Further comprising: The method according to any one of claims 10 to 16.

18. A Bluetooth pairing device, comprising: 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 PSK pairing capability; and 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 the pre-shared key (PSK) pairing capability, the pairing response message utilized to indicate that the first node will perform pairing by utilizing a first PSK shared by the first node and a second node; a processing unit configured to authenticate the first node based on the first PSK; A Bluetooth pairing device comprising:

19. The processing unit comprises: The second node determines that it will share the first PSK with the first node. Further configured as follows:

20. The apparatus of claim 18.

20. the pairing request message includes an input / output capability IOC field, the IOC field including the information utilized to indicate whether the first node has PSK pairing capability; 20. Apparatus according to claim 18 or 19.

21. a portion of the bits in the IOC field includes 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 PSK pairing capability; Another portion of the bits in the IOC field are utilized to indicate the input / output capabilities of the first node.

21. The apparatus of claim 20.

22. 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 PSK pairing capability; 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.

20. Apparatus according to claim 18 or 19.

23. The processing unit is further configured to: determine the pairing response message based on the pairing request message and preset pairing mode priority information, the pairing mode priority information indicating 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 a plurality of pairing modes.

23. Apparatus according to claim 21 or 22.

24. The receiving unit is further configured to receive a first authentication parameter from the first node; the processing unit is further configured to verify the first authentication parameter based on the first PSK. Apparatus according to any one of claims 18 to 23.

25. The processing unit is further configured to generate a second authentication parameter based on the first PSK; the sending unit is further configured to send the second authentication parameters to the first node; 25. The apparatus of claim 24.

26. The receiving unit is further configured to receive a third authentication parameter from the first node; The processing unit is further configured to generate a fourth check parameter based on the PSK capability value of the first node; The processing unit is further configured to determine that authenticity authentication of the PSK capability value of the first node is successful based on the fourth check parameter and the third authentication parameter; The processing unit is further configured to generate a fourth authentication parameter based on the PSK capability value of the second node; the sending unit is further configured to send the fourth authentication parameter to the first node; Apparatus according to any one of claims 18 to 25.

27. A Bluetooth pairing device, comprising: 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 is 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 comprising:

28. the processing unit is further configured to determine that the second node shares the first PSK with the first node.

28. The apparatus of claim 27.

29. the pairing request message includes an input / output capability IOC field, the IOC field including information utilized to indicate whether the first node has PSK pairing capability; 29. Apparatus according to claim 27 or 28.

30. a portion of the bits in the IOC field includes 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 PSK pairing capability; Another portion of the bits in the IOC field are utilized to indicate the output capabilities of the first node.

30. The apparatus of claim 29.

31. 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 PSK pairing capability; 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.

29. Apparatus according to claim 27 or 28.

32. The receiving unit is further configured to receive a second authentication parameter from the second node; the processing unit is further configured to verify the second authentication parameter based on the first PSK. Apparatus according to any one of claims 27 to 31.

33. The processing unit is further configured to generate a first authentication parameter based on the first PSK; the sending unit is further configured to send the first authentication parameters to the second node; 33. The method of claim 32.

34. the pairing response message includes a PSK capability value of the second node, the PSK capability value of the second node being utilized to indicate that the second node has the PSK pairing capability; The receiving unit is further configured to receive a fourth authentication parameter from the second node; The processing unit is further configured to generate a third check parameter based on the PSK capability value of the second node; The processing unit is further configured to determine that authenticity authentication of the PSK capability value of the first node is successful based on the third check parameter and the fourth authentication parameter; The processing unit is further configured to generate a third authentication parameter based on the PSK capability value of the first node; the sending unit is further configured to send the third authentication parameter to the second node; The method according to any one of claims 27 to 33.

35. 10. A Bluetooth pairing device, comprising at least one processor and a communication interface, the at least one processor configured to invoke a computer program stored in at least one memory to enable the device to implement the method according to any one of claims 1 to 9.

36. 18. A Bluetooth pairing device, the Bluetooth pairing device comprising at least one processor and a communication interface, the at least one processor configured to invoke a computer program stored in at least one memory to enable the device to implement a method according to any one of claims 10 to 17.

37. A computer-readable storage medium, the computer-readable storage medium storing a computer program, the computer program, when executed on one or more processors, performing the method according to any one of claims 1 to 9.

38. A computer-readable storage medium, the computer-readable storage medium storing a computer program, the computer program, when executed on one or more processors, performing the method according to any one of claims 10 to 17.

39. A computer program product, which when said computer program product is executed on one or more processors performs the method according to any one of claims 1 to 9.

40. A computer program product, the method according to any one of claims 10 to 17 being performed when said computer program product is executed on one or more processors.

Images