Out-of-band pairing and provisioning for Bluetooth devices

Abstract

A system and method for allowing a new device to join an existing network is disclosed. The new devices include multicolor lamps, such as RGB LEDs. An out-of-band (OOB) message is encoded using transitions between different LED states. In addition, the OOB message may be formatted using a TLV (Type-Length-Value). Cyclic redundancy codes and forward error correction may also be included in the OOB message. The OOB message may be readily incorporated in a Bluetooth LE secure connection or into a Bluetooth grid provisioning.

Description

[0001] This application claims priority to U.S. Patent Application Serial No. 18 / 924792, filed October 23, 2024, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure describes systems and methods for allowing new devices to securely join Bluetooth networks. Background Technology

[0003] The surge in network-connected devices has led to increased use of smart networks, especially Bluetooth networks.

[0004] One issue associated with all of these Bluetooth networks is the need for security. Communication over a Bluetooth network should be encrypted so that other eavesdropping devices cannot decode network traffic. In other words, these devices must have encryption keys or passwords that allow them to decode encrypted communication over the network.

[0005] In Bluetooth LE, the process of creating this cryptographic bond between a new device and a network device is called pairing. The pairing process forms an encryption key shared by both devices and is a prerequisite for protecting the connection between them from eavesdropping and manipulation of transmitted data. The key created during the pairing process will only be used to protect communication between the two devices and will not be used in a wider range. This one-to-one bond can be considered a dual-device network.

[0006] In Bluetooth meshes, this equivalent process is called provisioning. During provisioning, a new mesh device becomes part of the network by securely distributing an initial set of credentials to it.

[0007] Pairing can be certified or uncertified. In the case of uncertification, there is no protection against man-in-the-middle attacks. Even if an uncertified pairing process prevents passive eavesdropping by a malicious third party, it cannot prevent an active attacker from inserting themselves as a proxy between the two devices, a proxy that could manipulate the business passing through it.

[0008] Authentication pairing requires some pre-shared credentials unknown to a third party, or the exchange of dynamically generated authentication data transmitted out of band. The term "out-of-band" or OOB means that the data is not carried over the Bluetooth communication channel, but through some other channel.

[0009] Typical examples of pre-shared credentials include QR codes printed on devices or static NFC tags with hard-coded data. The data is encoded into the device itself (e.g., on a flash storage device), and that same QR or NFC representation of the data can be read by other devices, provided it has the appropriate hardware to do so, such as a camera or NFC reader. Pre-shared credentials are typically static in nature (generated once and not changed afterwards).

[0010] Typical examples of dynamically generated authentication data include numeric or alphanumeric passwords, which are generated and displayed on one device and read by another device or entered by a user into another device, such as via a physical or virtual keyboard.

[0011] Static credentials are at risk of being leaked, in which case they no longer provide any security. Dynamically created authentication data is better in this regard, as it is recreated whenever needed and therefore is not leaked beforehand.

[0012] However, dynamically created authentication data needs to be transferred between devices in some way. This means one device needs a means to output codes in a certain way, while another device needs a means to read and interpret codes, or allow users to input codes. The hardware required to display numeric or alphanumeric codes can be bulky and expensive, especially if the devices have no other need for such displays. User input can be unreliable or uncomfortable for users, especially when the password is an unnatural mix of numbers and characters.

[0013] All of these scenarios also apply to the supply process. Furthermore, none of these scenarios are straightforward.

[0014] Therefore, there is a need for an improved system and method that allows new devices to securely join Bluetooth LE or Bluetooth mesh networks. Furthermore, it would be beneficial if the system and method were easy to implement, and thus easy to implement with battery-powered devices. Summary of the Invention

[0015] A system and method for allowing new devices to join existing networks are disclosed. The new devices include multi-color LEDs, such as RGB LEDs. Out-of-band (OOB) messages are encoded using transitions between different LED states. Furthermore, the OOB messages can be formatted using TLV (Type-Length-Value). Cyclic redundancy codes and forward error correction can also be included in the OOB messages. The OOB messages can be easily integrated into Bluetooth LE secure connections or into Bluetooth mesh provisioning.

[0016] According to one embodiment, a method for allowing a joining device to join a Bluetooth network is disclosed. The method includes: transmitting an out-of-band (OOB) message from the joining device containing device-specific information associated with the joining device, wherein the joining device utilizes a multicolor light transmitter to transmit the OOB message, and wherein the OOB message is encoded via state transitions of the multicolor light transmitter; receiving the OOB message at the network device; and performing a joining process using the information in the OOB message. In some embodiments, the multicolor light transmitter includes red, green, and blue (RGB) LEDs, wherein at least eight LED states are present. In some embodiments, eight LED states are used, resulting in seven possible transitions, and all data in the OOB message is encoded using base-7. In some embodiments, each color component of the RGB LEDs has at least three states: an on state, an off state, and at least one state between the on and off states; and wherein at least 27 LED states are present. In some embodiments, prior to transmitting the OOB message, the joining device transmits a calibration sequence to allow the network device to calibrate a camera. In some embodiments, the OOB message is constructed as multiple TLVs (Type-Length-Value). In some embodiments, the OOB message includes cyclic redundancy code. In some embodiments, the OOB message is encoded using a forward error correction (FEC) mechanism. In some embodiments, the network device queries the GATT service in the joining device to determine whether the joining device is capable of transmitting the OOB message.

[0017] In some embodiments, the Bluetooth network includes a Bluetooth LE network, and the joining process includes an LE secure connection pairing process. In some embodiments, the network device sends a GATT request to the joining device to initiate the transmission of the OOB message.

[0018] In some embodiments, the Bluetooth network includes a Bluetooth mesh network, and the joining process includes a provisioning process. In some embodiments, the joining device sends the OOB message to the network device after the network device sends a provisioning start PDU to the joining device.

[0019] According to another embodiment, a Bluetooth system is disclosed. The system includes: a network device including a camera; and a joining device including a multicolor light transmitter; wherein the joining device is configured to transmit OOB messages using the multicolor light transmitter; wherein data is encoded via state transitions of the multicolor light transmitter; wherein the network device is configured to receive the OOB messages using the camera; and wherein the network device performs a joining process using information in the OOB messages. In some embodiments, the OOB messages transmitted by the joining device are constructed as multiple TLVs (Type-Length-Value). In some embodiments, the multicolor light transmitter includes RGB LEDs, wherein at least eight LED states are present. In some embodiments, eight LED states are used, resulting in seven possible transitions, and all data in the OOB messages transmitted by the joining device is encoded using base-7. In some embodiments, the OOB messages include cyclic redundancy codes. In some embodiments, the OOB messages are encoded using a forward error correction (FEC) mechanism. Attached Figure Description

[0020] For a better understanding of this disclosure, reference is made to the accompanying drawings, wherein similar elements are indicated by similar numbers, wherein: Figure 1 This is a block diagram of network devices that are part of a network. Figure 2 This is a block diagram of a new device that we want to add to the network; Figure 3 The status of the RGB LEDs is shown; Figure 4 This illustrates one possible encoding scheme using RGB LEDs; Figure 5 The sequence used to generate and transmit OOB messages is shown; Figure 6 The sequence for receiving and decoding OOB messages is shown; Figures 7A-7C The pairing process using a Bluetooth LE secure connection is shown; and Figures 8A-8C The supply process using Bluetooth mesh is shown. Detailed Implementation

[0021] According to one embodiment, the systems and methods described herein typically involve two devices: a new device wishing to join the network, also referred to as a joining device; and a device already on the network and capable of being near the joining device, also referred to as a network device. The system and methods require that the typically resource-constrained connecting device comprises a single RGB LED. Furthermore, the network device includes components for viewing the output from the RGB LED, such as a camera.

[0022] A network can include multiple network devices. These network devices can be of various types, such as door locks, lights, light switches, appliances, thermostats, telephones, and personal computers. One of these network devices can be used to facilitate the onboarding process for new devices. Figure 1 A block diagram of a representative network device 10 is shown. In some embodiments, network device 10 may be a mobile device, such as a mobile phone or a tablet.

[0023] Network device 10 has a processing unit 20 and an associated memory device 25. The memory device 25 contains instructions that, when executed by the processing unit 20, enable the network device 10 to perform the functions described herein. The memory device 25 may be non-volatile memory, such as flash ROM, electrically erasable ROM, or other suitable devices. In other embodiments, the memory device 25 may be volatile memory, such as RAM or DRAM. In some embodiments, the memory device 25 may be packaged together with the processing unit 20. The processing unit 20 may be any suitable device, including but not limited to a general-purpose processor, a dedicated processor, an embedded controller, or a personal computer (PC).

[0024] The network device 10 also includes a Bluetooth network interface 30, which is a wireless interface including an antenna 35. This Bluetooth network interface 30 is used for communication via a Bluetooth network.

[0025] Network device 10 may include a data storage device 40, which stores data received by Bluetooth network interface 30 and data to be transmitted by Bluetooth network interface 30. This data storage device 40 is conventionally volatile memory. Processing unit 20 has the capability to read and write to data storage device 40 in order to communicate with other devices in the network. Although not shown, network device 10 also has a power supply device, which may be a battery or a connection to a permanent power source, such as a wall socket.

[0026] Although memory device 25 is disclosed, these instructions can be stored on any computer-readable medium. For example, read-only memory (ROM), random access memory (RAM), magnetic storage devices such as hard disk drives, or optical storage devices such as CDs or DVDs can be used. Furthermore, these instructions can be downloaded to memory device 25, for example, via a network connection (not shown), via a CD-ROM, or via another mechanism. These instructions can be written in any programming language, and the language is not limited to this disclosure. Therefore, in some embodiments, multiple computer-readable media containing the instructions described herein may be present. Figure 1As shown, the first computer-readable medium can communicate with the processing unit 20. The second computer-readable medium can be a CD-ROM or a different memory device located remotely from the network device 10. Instructions contained on the second computer-readable medium can be downloaded to the memory device 25 to allow the network device 10 to execute the instructions.

[0027] Network device 10 may also include a display element 60. In some embodiments, display element 60 may be an LED or LCD screen. In some embodiments, display element 60 is a touchscreen, allowing input to be provided to processing unit 20 via display element 60. In other embodiments, network device 10 may also communicate with a separate input device to allow user input. For example, the input device may be a keyboard.

[0028] Network device 10 also includes a camera 70. Camera 70 may include multiple pixels for capturing visual images. Although the term "camera" is used in this disclosure, it is understood that any photodetector may be used. Processing unit 20 communicates with camera 70 to sense any light. In some embodiments, network device 10 is capable of video recording to capture an entire sequence transmitted by joining devices.

[0029] In one embodiment, network device 10 may be a mobile phone or tablet computer. In some embodiments, the instructions described herein may be packaged into an application. Network device 10 may receive the application from a remote server. For example, in one embodiment, the application may be made available on a remote server such as a corporate server. In some embodiments, the application may be available on digital distribution platforms such as Google Play, the Microsoft Store, the Apple App Store, etc. Of course, in other embodiments, the software application may be pre-loaded onto network device 10.

[0030] Figure 2 A representative schematic diagram of joining device 100 is shown. Joining device 100 has a processing unit 120 and an associated memory device 125. The memory device 125 contains instructions that, when executed by the processing unit 120, enable joining device 100 to perform the functions described herein. The memory device 125 may be non-volatile memory, such as flash ROM, electrically erasable ROM, or other suitable devices. In other embodiments, memory device 125 may be volatile memory, such as RAM or DRAM. In some embodiments, memory device 125 may be packaged together with processing unit 120. Processing unit 120 may be any suitable device, including but not limited to general-purpose processors, special-purpose processors, embedded controllers, or personal computers (PCs).

[0031] The device 100 also includes a Bluetooth network interface 130, which is a wireless interface including an antenna 135.

[0032] Joining device 100 may include a data storage device 140, which stores data received by and to be transmitted by Bluetooth network interface 130. This data storage device 140 is conventionally volatile memory. Processing unit 120 has the capability to read and write to data storage device 140 for communication with other devices in the network. Although not shown, joining device 100 also has a power supply device, which may be a battery or a connection to a permanent power source, such as a wall socket.

[0033] Although memory device 125 is disclosed, these instructions can be stored on any computer-readable medium. For example, read-only memory (ROM), random access memory (RAM), magnetic storage devices such as hard disk drives, or optical storage devices such as CDs or DVDs can be used. Furthermore, these instructions can be downloaded to memory device 125, for example, via a network connection (not shown), via a CD-ROM, or via another mechanism. These instructions can be written in any programming language, and the language is not limited to this disclosure. Therefore, in some embodiments, multiple computer-readable media containing the instructions described herein may be present. Figure 2 As shown, the first computer-readable medium can communicate with the processing unit 120. The second computer-readable medium can be a CD-ROM or a different memory device located remotely from the insertion device 100. Instructions contained on the second computer-readable medium can be downloaded to the memory device 125 to allow the instructions to be executed by the insertion device 100.

[0034] The incorporating device 100 may also include a light source 170. The light source 170 may include one or more multicolor light-emitting diodes (LEDs), such as red-green-blue (RGB) LEDs, which emit light that can be seen outside the incorporating device 100. The light may be emitted in the visible spectrum.

[0035] Note that network device 10 and joining device 100 do not share a clock, so any communication that relies on pulse width or duration may be problematic. A better approach would likely be to rely on transitions between states rather than the duration of any particular state.

[0036] For example, using RGB LEDs, there are eight possible LED states that the device 100 can generate when each of the color components is fully on or fully off: - White; - Yellow; - Magenta; - red; - Cyan; - green; - Blue; and - close.

[0037] exist Figure 3 The diagram shows the configuration of the channels for the RGB LEDs in the connection device 100 used to generate each of these outputs.

[0038] Because there are eight LED states, there are seven possible transitions from each LED state. Therefore, there are seven symbols in this encoding, each of which can be assigned a value between 0 and 6. In this way, all the data to be transmitted can be encoded as a base-7 stream. Figure 4 This illustrates one possible encoding for LED state transitions.

[0039] To demonstrate this encoding scheme, assume the current LED state is red. Further assume there is a need to transmit a sequence of four base-7 numbers (1, 2, 5, 0), corresponding to the decimal value 476 (1 * 7^2). 3 + 2*7 2 + 5*7 1 +0*7 0 This will be encoded as follows: red Blue (code 1); blue Blue (code 2); green Yellow (code 5); and yellow Close (code 0).

[0040] Note that this base-7 encoding allows approximately 2.8 bits to be encoded in each transition. Therefore, a 128-bit digital sequence can be transmitted using approximately 46 LED state transitions. Similarly, a 256-bit digital sequence can be transmitted using approximately 92 LED state transitions.

[0041] Note that if the joining device 100 has two RGB LEDs, the number of transmissions can be reduced. If we assume that both RGB LEDs must change state during each transition, there are 7*7=49 different values ​​for each LED state transition. A joining device 100 with three RCB LEDs can generate 7*7*7=343 different values ​​for each LED state transition. However, using multiple RGB LEDs requires them to be spaced far enough apart so that the network device 10 can distinguish them. Furthermore, a calibration sequence can be used to allow the network device 10 to determine the correct orientation of the multiple LEDs. For example, LEDs might appear from left to right in one orientation, but if the joining device 100 is rotated, they might appear from right to left. The unique sequence transmitted by the joining device 100 can be used to ensure correct orientation.

[0042] Furthermore, while this disclosure describes the use of seven possible transitions and the transmission of data using base-7, other embodiments are possible. For example, in one embodiment, only five LED states are used, allowing four possible transitions. This means that all data will be transmitted using base-4, which is a simple transition from a typical binary stream.

[0043] In another embodiment, finer-grained control of the RGB LED states allows for the use of intermediate intensities for each color component. For example, using three intensities (fully off; half; and fully on) would allow 27 LED states instead of 8, and thus 26 transitions instead of 7. In such a scheme, base-26 encoding would be used to transmit data, and fewer transitions would be required compared to using base-7 encoding.

[0044] In some embodiments, it may be desirable to include forward error correction capabilities. This can be applied to such an encoding scheme. For example, a generator matrix can be used to convert 6 data symbols (all base-7) into 8 encoded symbols. In one embodiment, the generator matrix can be as follows: The corresponding parity check matrix can be: The encoding process for this code is essentially matrix multiplication. For decoding, such small code can be easily decoded using parity decoding because only 48 parities need to be checked if parity fails. Other codes may also be used depending on the expected number and type of transmission errors.

[0045] Therefore, device 100 uses a generator matrix to generate 8 encoded data symbols for every six data symbols. Network device 10 uses a parity check matrix to detect and correct transmission errors.

[0046] The matrix described above can be used to correct a single error within the eight received coded symbols, and therefore can be used when the symbol error probability is relatively low. When using this code, the transmission efficiency is 0.75, because six of the eight transmitted symbols carry data, while the two error-correcting symbols are overhead.

[0047] Note that even when using more complex code, the encoding used for error correction can often be easily done on a resource-constrained device, such as the one to which device 100 is likely located. Decoding typically requires more resources, but in this arrangement, network device 10 is usually a device with ample computing resources, such as a mobile phone or tablet.

[0048] In some embodiments, performing a calibration sequence may be beneficial. The calibration sequence can be, for example, a conversion stream sent by the joining device 100 that causes the RGB LEDs to alternate between a given sequence of states, such as from white to off and back. The network device 10 can use the intensity difference between the white and off LED states to set the camera exposure and use the hue of the white signal to set the camera white balance. As mentioned above, if the joining device 100 has multiple RGB LEDs, the calibration sequence for each RGB LED can be different to allow the network device 10 to determine the correct orientation.

[0049] Therefore, in some embodiments, joining device 100 may transmit a calibration sequence, followed by an encryption key. The length of this key is protocol-dependent. For mesh provisioning, the maximum length of the authentication data is 128 or 256 bits, depending on the protocol version used. However, in some embodiments, if the full data length is not required for the desired level of security, joining device 100 may transmit fewer bits.

[0050] However, in other embodiments, creating a more explicit structure may be beneficial. This allows for some flexibility in the size of the strings transmitted by joining device 100, and also allows the scheme to work with future protocol versions.

[0051] A well-known method for storing or transmitting variable-length data is to use the Type-Length-Value (TLV) format. In this TLV format, the transmitted data always includes the type of information being transmitted, the length of the data to be transmitted (if any), and the data itself (if any).

[0052] The following compact TLV definition can be used here: - The TLV is constructed using the same base-7 notation as the data encoding. In other words, it uses base-7 numbers; - Type: A base-7 symbol is used to indicate the type that follows; - Length: Zero or more symbols indicate the length of the data to be followed; the number of symbols used to represent the length may depend on the type; - Data: Zero or more symbols represent the data contained in the TLV.

[0053] Using this format, the following TLV sets can be created: TLV Type symbol Data length symbol Notes Terminator 0 zero No related data short data 1 two Up to 49 data symbols follow. Long data 2 three 50 to 392 data symbols followed. Data CRC32 3 zero The 12 associated symbols always follow. Other types of symbols have not yet been defined, but they can be used to extend messaging functionality in the future.

[0054] Note that although the TLVs are defined using base-7 above, it is understood that these TLVs can also be used with different numeric bases if needed.

[0055] The OOB message transmitted from joining device 100 to network device 10 will include one or more successively transmitted TLVs.

[0056] The following TLVs are defined as being included in OOB messages: - The terminator TLV consists only of the type symbol, without length or data symbols, and is used to indicate the end of the OOB message. Any hexadecimal digits following the terminator TLV will be ignored.

[0057] - The short data TLV type symbol is followed by two data length symbols, meaning that if the two base-7 symbols can record 49 different values, the indicated length range can be from 1 to 49. Note that this is more than enough for encoding 128 bits of authentication data, since 46 heptadecimal digits translate to approximately 128 bits.

[0058] - A long data TLV is followed by three data length symbols, which allows 343 distinct values ​​to be recorded. Assuming that a short data TLV can already be used to carry up to 49 data symbols, a long data TLV can be used to carry 50 to 392 symbols, with three length symbols representing values ​​from 50 to 392 instead of 1 to 343.

[0059] - There is no data length symbol after the data CRC32 TLV because the length of the associated data is constant. Twelve data symbols follow it; these are sufficient to record a 32-bit CRC (Cyclic Redundancy Check) value, which the receiver can use to check the integrity of the data TLV immediately preceding it.

[0060] When encoding length and data, as long as the order of the two devices is consistent, the encoding can be least significant bit first (little-endian) or most significant bit first (big-endian).

[0061] As an example, consider an OOB message that carries a very short (and practically insecure) 16-bit hexadecimal authentication value of 0xABCC without a CRC. This would be constructed as follows (in most significant bit order): - The hexadecimal string "ABCC" corresponds to the bit string "1010101111001100". - This corresponds to the six-character base-7 string "242136". - It can be encoded as a short data TLV (type 1, length 06), as "106242136". - This will be followed by a single zero digit as the terminator TLV. This results in the complete OOB message "1062421360". The data structure used has been defined, and the process by which device 100 sends authentication data to network device 10 will be defined and... Figure 5 As shown in box 500, joining device 100 generates a random bit string of sufficient length (e.g., 128 or 256 bits) to be used as authentication data. Optionally, as shown in box 510, joining device 100 computes a 32-bit Cyclic Redundancy Check (CRC) sum on the authentication data. Next, as shown in box 520, joining device 100 encodes the bit string into a heptadecimal number string. This is simply a base-2 to base-7 number conversion and can be easily implemented even on limited hardware. Furthermore, if a CRC is computed, the device will also encode the bit string into a heptadecimal number string. Next, as shown in box 530, joining device 100 constructs two or three TLVs, which are: - Short data TLV or long data TLV, depending on how long the encoded authentication data string is; - Optionally, it includes CRC32 TLV data encoded from the calculated CRC value. - Terminator TLV Next, as shown in box 540, joining device 100 will construct the OOB message to be sent by concatenating the above TLVs together into a string of 7-digit numbers.

[0062] Note that if forward error correction is used, the joining device 100 will apply an FEC encoder to the heptadecimal OOB message string, producing a new heptadecimal string containing the FEC encoding of the original OOB message. As shown in box 550, this is performed after the OOB message is formed.

[0063] Finally, as shown in box 560, once the process of constructing the OOB message is complete, regardless of FEC encoding, the OOB message is transmitted by switching the color of light source 170 as needed to generate the desired string. Once the transmission is complete, if light source 170 is not yet turned off, the joining device 100 turns off light source 170.

[0064] When network device 10 receives an OOB message from joining device 100 via its camera 70, it performs a decoding process, such as... Figure 6 As shown in box 600, network device 10 first captures OOB messages transmitted from joining device 100 using camera 70. Next, as shown in box 610, network device 10 decodes the received string using the corresponding FEC decoder if a forward error correction method is used by the transmitter. If a transmission error is detected, it is corrected if possible. If there are too many errors to correct, the OOB message is discarded.

[0065] Next, as shown in box 620, network device 10 interprets the OOB message as a concatenation of TLVs and identifies the boundaries of each TLV in the OOB message based on the type and length information contained within the TLVs. Note that if this cannot be done, the OOB message will be discarded. The network device should find two or three TLVs in the OOB message, where: - The first TLV is either a short data TLV or a long data TLV. - The middle TLV is the data CRC32 TLV (when there are three TLVs), and - Ultimately, TLV became the terminator TLV.

[0066] As shown in box 630, network device 10 converts data found in the short data TLV or long data TLV from hexadecimal numbers to binary numbers. As described above, this is a simple number conversion from base-7 to base-2.

[0067] As shown in box 640, if the optional data CRC32 TLV appears in the OOB message, network device 10 will convert the data carried in the data CRC32 TLV from hexadecimal numbers to binary numbers. Finally, as shown in box 650, if the data CRC32 TLV appears in the OOB message, network device 10 will check whether the binary CRC matches the binary authentication data. If they do not match, the OOB message will be discarded.

[0068] Once this process is complete, network device 10 can utilize the authentication data during the pairing process. This will be described for Bluetooth LE and Bluetooth mesh.

[0069] Note that, as mentioned above, the process can be performed using numbers other than base-7. For example, in some embodiments, base 4 is used for ease of conversion to binary. Furthermore, if multiple LEDs are used, or if more than two color states are used, a base greater than 7 can be used.

[0070] refer to Figures 7A-7C Bluetooth LE secure pairing is a multi-stage process. For pairing to occur, the two devices must establish a connection. If the joining device 100 is a peripheral device, this is typically initiated by the network device 10. The network device 10 can acquire knowledge that the joining device 100 supports the OOB method in various ways. In one embodiment, after establishing a connection, the network device can perform service discovery using the joining device's GATT service. The network device can then locate and obtain a service that provides information about the joining device's OOB capabilities (see line 700). In some embodiments, this same service can also be used to negotiate parameters related to OOB data, such as the size of random data or other parameters. The network device can also use this service to trigger the transmission of calibration sequences, stop calibration sequences, and initiate OOB transmissions.

[0071] Next, as described above, network device 10 can use the GATT service associated with the OOB method to initiate a calibration sequence (see line 701). In response, joining device 100 can begin transmitting the calibration sequence (see line 702). Network device 10 adjusts its camera settings based on the calibration sequence (see line 703). When complete, network device 10 is successfully calibrated. In some embodiments, network device 10 can use the GATT service to terminate the transmission of the calibration sequence. In other embodiments, when joining device 100 receives a command to start OOB transmission from network device 10 (via the GATT service), it can stop transmitting the calibration sequence (see line 704).

[0072] Network device 10 can again utilize the GATT service to instruct joining device 100 to transmit the joining device's Bluetooth address, random data, and corresponding acknowledgment value (see line 704). In response, joining device 100 stops transmitting the calibration sequence if it has not already done so. Both joining device 100 and network device 10 include ephemeral elliptic curve keys that allow the creation of public and private keys. The public key can be used by any other device and allows decryption of strings encrypted using the corresponding private key. Joining device 100 generates an EC key pair (see line 705) and then generates random data (see line 706). This random number (rb) can be of fixed length, such as 128 bytes. Note that this random data is device-unique, as it is currently known only to that device. Joining device 100 then calculates the acknowledgment value based on the EC public key (PKb) and the random data (see line 707).

[0073] Joining device 100 then constructs an OOB message as described above, which includes the device's Bluetooth address (B), random data (rb), and acknowledgment value (Cb). This combination of Bluetooth address (B), random data (rb), and acknowledgment value (Cb) can be referred to as device unique information. Therefore, joining device 100 can transmit an OOB message with two TLVs, either a short data TLV or a long data TLV, followed by a terminator TLV (see line 708). Optionally, joining device 100 can generate a CRC; in this case, the OOB message will also contain a data CRC32 TLV before the terminator TLV. Finally, as described above, joining device 100 can utilize FEC. The use of CRC and FEC can be negotiated based on parameters found in the joining device's GATT service.

[0074] Network device 10 then uses the camera to receive OOB messages and decodes the TLV to obtain random data and acknowledgment values ​​(see line 709).

[0075] At this point, the pairing process can begin. All subsequent transmissions are performed using the Bluetooth network. The pairing process begins with network device 10 transmitting a pairing request using Bluetooth (see line 710). This pairing request includes an indication that the network device already has OOB data from the remote device. Joining device 100 then replies, transmitting a pairing response (see line 711). Note that because OOB data only travels from joining device 100 to network device 10, the pairing response indicates that it does not have OOB data from the remote device.

[0076] At this time, as Figure 7B As shown, an EC public key exchange is performed. Network device 10 generates its own EC key pair (see line 712). Network device 10 transmits its public key (PKa) to the joining device (see line 713). Joining device 100 responds by transmitting its public key (PKb) to network device 10 (see line 714). The two devices can now use their own private keys and the public keys of other nodes to compute the ECDH secret (see line 715).

[0077] Network device 10 then verifies the acknowledgment value it received from joining device 100 in the OOB message (see line 716). This is done using the in-band received public key (PKb) and the out-of-band received random data (rb). If the acknowledgment value received in the OOB message matches the acknowledgment value generated by network device 10 using the public key and random data (see line 717), the pairing process can continue. Otherwise, the pairing process may terminate. Network device 10 then selects a new random nonce (Na) (see line 718). This new random nonce (Na) is transmitted to joining device 100 (see line 719).

[0078] Then, device 100 selects a random time (Nb) (see line 720). This random time (Nb) is then transmitted to network device 10 (see line 721).

[0079] Once the random moments are exchanged, the remainder of the pairing process can be performed as follows: Figure 7C The process proceeds as shown in the diagram. Both devices can now calculate the Long-Term Key (LTK) and MacKey (see line 722). Network device 10 calculates the confirmation value (Ea) (see line 723). This confirmation value (Ea) can be calculated based on the values ​​of MacKey, Na, Nb, the two Bluetooth addresses, and rb. Ea is then transmitted to joining device 100 (see line 724). Joining device 100 also locally calculates the expected value of Ea (see line 725). It then compares its locally calculated Ea value with the value received from network device 10 (see line 726). Joining device 100 calculates the confirmation value (Eb) (see line 727). This confirmation value (Eb) is also calculated based on the values ​​of MacKey, Na, Nb, the two Bluetooth addresses, and rb. Eb is then transmitted to network device 10 (see line 728). Network device 10 also locally calculates the expected value of Eb (see line 729). It then compares its locally calculated Eb value with the value received from joining device 100 (see line 730). If both checks are correct, the long-term key can now be used for that connection and any subsequent connections (see line 731).

[0080] Note that there are some changes to the pairing process described above. For example, while the Bluetooth LE specification requires random data and acknowledgment values ​​to be 128 bits, joining device 100 can transmit shorter lengths of random data, such as 64 bits. Both devices need to be aware of this modification, which can be achieved using settings included in the GATT service of joining device 100. In this case, both devices will pad the random data with 64 zeros to obtain a 128-bit value.

[0081] The method of incorporating OOB messages into Bluetooth LE secure connections has already been described; the following will refer to... Figures 8A-8C This describes its use with Bluetooth mesh provisioning. Note that most of this process is the same as that typically used with Bluetooth mesh. Only the included instructions and OOB messages differ.

[0082] First, the joining device transmits an un-provisioned device beacon (see line 800) to indicate that it can provision using broadcast advertising. Alternatively or additionally, joining device 100 may indicate its availability for GATT-based provisioning by advertising its GATT provisioning service. Additionally, joining device 100 provides an indication that it supports this OOB method. This can be achieved by setting a reserved (RFU) bit for future use, or by setting the "Other" bit in the OOB information field of the un-provisioned device beacon. Note that similar bits can also be set in the service advertisement for the GATT provisioning service. Note that, optionally, an LE connection can also be established (see line 801).

[0083] If network device 10 chooses to use GATT provisioning services to provision joining device 100, then after the connection is established, the network device can perform service discovery of the joining device's GATT services, locate and obtain services that provide information about the joining device's OOB capabilities, and negotiate parameters related to OOB data, such as the size of random data or other parameters in the same manner as described above for LE pairing (see line 802).

[0084] Recognizing that joining device 100 supports the OOB method, network device 10 establishes a mesh provisioning session using the selected provisioning method (GATT-based or ad-based) (see line 803). Network device 10 sends an invitation PDU to the joining device (see line 804). Joining device 100 responds with a capability PDU (see line 805). The capability PDU may include indications that OOB authentication is supported.

[0085] Network device 10 then responds with a start PDU (see line 806). In this start PDU, the network device selects OOB authentication.

[0086] In response, network device 100 begins transmitting the aforementioned calibration sequence (see line 807). Network device 10 adjusts its camera settings based on the calibration sequence. When complete, network device 10 is successfully calibrated (see line 808).

[0087] Once completed, the EC key exchange can proceed. Network device 10 transmits its supply public key to joining device 100 (see line 809). Receiving the supply public key from network device 10 causes joining device 100 to stop transmitting the calibration sequence (see line 810). Furthermore, joining device 100 responds with its supply public key (see line 811). Once the public keys have been exchanged, both devices can independently compute the ECDH shared secret that will be used in subsequent transactions (see line 812).

[0088] At this time, as Figure 8BAs shown, joining device 100 prepares an OOB message. First, joining device 100 generates random data that will be used as the OOB authentication value (see line 813). Joining device 100 then constructs the OOB message using the OOB authentication value. As mentioned above, this is device-specific information. In some embodiments, the OOB message includes two TLVs: a short data or long data TLV for the OOB authentication value, and a terminator TLV. In other embodiments, joining device 100 may include a CRC, in which case a third TLV, a data CRC32 TLV, will also be transmitted before the terminator TLV. Joining device 100 then transmits the OOB message (see line 814). This OOB message is then received by network device 10 using a camera (see line 815).

[0089] Upon receiving an OOB message, network device 10 selects a random value (see line 816) and calculates an acknowledgment value from the ECDH shared secret, a copy of the messages exchanged so far, the received OOB authentication value, and the selected random value (see line 817). It then transmits an acknowledgment PDU to joining device 100 (see line 818). The acknowledgment PDU includes the acknowledgment value used by network device 10. Joining device 100 selects its own random value (see line 819) and uses that random value, the shared ECDH secret, the same copy of the messages as described above, and the OOB authentication value to calculate its own acknowledgment value (see line 820). Joining device 100 then also responds with an acknowledgment PDU (see line 821). Figure 8C As shown, network device 10 then transmits a random PDU containing a random value it has selected (see line 822). Joining device 100 uses the random value it received in the random PDU to locally calculate the expected acknowledgment value for network device 10 (see line 823). This locally calculated acknowledgment value is then compared to the acknowledgment value sent by network device 10 in an earlier acknowledgment PDU (see line 824). Joining device 100 then also transmits a random PDU containing its previously selected random value (see line 825). Network device 10 then locally calculates the expected acknowledgment value for joining device 100 (see line 826) and compares it to data received in an earlier acknowledgment PDU sent by joining device 100 (see line 827). Since the OOB authentication value is input to the acknowledgment value calculation, a device that does not have access to the correct value is likely to receive an incorrect answer. Therefore, comparing the locally calculated value with the received value can be used to authenticate other devices.

[0090] Then, the two devices use the ECDH shared secret, the same message copy as described above, and a random number to calculate the session key (see line 828). Finally, network device 10 transmits a provisioning data PDU encrypted with the session key to the joining device (see line 829). Joining device 100 responds with a provisioning completion PDU (see line 830). At this point, the provisioning session is complete and can be torn down (see line 831). Furthermore, if an LE connection had been previously established, it can be torn down at this time (see line 832).

[0091] As mentioned above, as long as both devices are aware of this modification, shorter authentication data can be used in OOB messages.

[0092] This system and method offer several advantages. First, it allows information to be transferred from joining devices to network devices without user intervention. Note that users are not required to manually enter any information into the network devices. Furthermore, users are not required to scan the QR code accompanying the newly joined device.

[0093] The ability to eliminate QR codes simplifies the manufacturing process because manufacturers no longer need to ensure the correct QR code accompanies the device throughout the manufacturing process. This also makes it easier for users to resell the device. In some implementations, users must retain the QR code, otherwise the device cannot join any other network.

[0094] Furthermore, this system and method allow for increased security. The OOB messages described herein can only be received within line of sight. In contrast, RF communication can penetrate walls and is more easily intercepted by malicious actors. Additionally, QR codes / serial numbers can be peeked simply by opening the box containing the new device in a store.

[0095] This disclosure is not limited to the specific embodiments described herein. In fact, various other embodiments and modifications of this disclosure will be apparent to those skilled in the art from the foregoing description and drawings, in addition to those described herein. Therefore, such other embodiments and modifications are intended to fall within the scope of this disclosure. Furthermore, although this disclosure has been described herein in the context of a specific implementation in a specific environment for a specific purpose, those skilled in the art will recognize that its usefulness is not limited thereto, and that this disclosure can be advantageously implemented in any number of environments for any number of purposes. Therefore, the claims set forth below should be interpreted in accordance with the full scope and spirit of this disclosure as described herein.

Claims

1. A method for allowing a device to join a Bluetooth network, the method comprising: Out-of-band (OOB) messages containing device-specific information associated with the joining device are transmitted from the joining device, wherein the joining device utilizes a multicolor light transmitter to transmit the OOB messages, and wherein the OOB messages are encoded by state transitions of the multicolor light transmitter; The OOB message is received at the network device. and Use the information in the OOB message to perform the join process.

2. The method according to claim 1, wherein, The multicolor light transmitter includes red, green, and blue (RGB) LEDs, with at least 8 LED states present.

3. The method according to claim 2, wherein, Using 8 LED states, this produces 7 possible transitions, and all data in the OOB message is encoded using base-7.

4. The method according to claim 1, wherein, Each color component of the RGB LED has at least three states: an on state, an off state, and at least one state between the on state and the off state; and there are at least 27 LED states.

5. The method according to claim 1, wherein, Before transmitting the OOB message, the joining device transmits a calibration sequence to allow the network device to calibrate the camera.

6. The method according to claim 1, wherein, The OOB message is constructed as multiple TLVs (type-length-value).

7. The method according to claim 1, wherein, The OOB message includes a cyclic redundancy code.

8. The method according to claim 1, wherein, The OOB message is encoded using a forward error correction (FEC) mechanism.

9. The method according to claim 1, wherein, The network device queries the GATT service in the joining device to determine whether the joining device can transmit the OOB message.

10. The method according to claim 1, wherein, The Bluetooth network includes a Bluetooth LE network, and the joining process includes an LE secure connection pairing process.

11. The method according to claim 10, wherein, The network device sends a GATT request to the joining device to initiate the transmission of the OOB message.

12. The method according to claim 1, wherein, The Bluetooth network includes a Bluetooth mesh network, and the joining process includes a supply process.

13. The method according to claim 12, wherein, After the network device transmits the Supply Start PDU to the joining device, the joining device transmits the OOB message to the network device.

14. A Bluetooth system, comprising: Network equipment including cameras; and Including the addition of multicolor light transmitters; The joining device is configured to use the multicolor light transmitter to transmit OOB messages; The data is encoded through the state transitions of the multicolor light transmitter; The network device is configured to receive the OOB message using the camera; and The network device uses the information in the OOB message to perform the join process.

15. The system according to claim 14, wherein, The OOB message transmitted by the joining device is constructed as multiple TLVs (Type-Length-Value).

16. The system of claim 14, wherein, The multicolor light transmitter includes RGB LEDs, with at least 8 LED states present.

17. The system according to claim 16, wherein, Using 8 LED states, this generates 7 possible transitions, and all data in the OOB message transmitted by the joining device is encoded using base-7.

18. The system according to claim 14, wherein, The OOB message includes a cyclic redundancy code.

19. The system according to claim 14, wherein, The OOB message is encoded using a forward error correction (FEC) mechanism.

Images