Out-of-band pairing and provisioning for Bluetooth devices

Abstract

A system and method are disclosed by which a new device can join an existing network. The new device features a multi-colored light emitter, such as an RGB LED. Out-of-band (OOB) messages are encoded using transitions between the different LED states. The OOB message can also be formatted using type-length-value (TLV) codes. Cyclic redundancy codes and forward error correction can also be included in the OOB message. This OOB message can be easily integrated into Bluetooth LE Secure Connections or Bluetooth Mesh deployments.

Description

[0001] This application claims priority over US patent application number 18 / 924,792, filed on October 23, 2024, the disclosure of which is hereby incorporated in its entirety by reference. Area

[0002] This disclosure describes systems and methods to enable new devices to be securely connected to a Bluetooth network. background

[0003] The explosive growth of networked devices has led to increased use of intelligent (smart) networks, especially Bluetooth networks.

[0004] One problem associated with all these Bluetooth networks is the need for security. Communication over the Bluetooth network should be encrypted so that other devices eavesdropping on the network cannot decrypt the network traffic. In other words, these devices must possess a cryptographic key or password to decrypt encrypted communications over the network.

[0005] In Bluetooth LE, the process of establishing this cryptographic connection between the new device and the network device is called pairing. The pairing process generates a cryptographic key shared by both devices, which is essential for securing the connection between them against eavesdropping and attacks that manipulate the transmitted data. The key created during the pairing process is used only to secure communications between the two devices and not for any other purpose. This one-to-one connection can be considered a two-device network.

[0006] In Bluetooth Mesh, this equivalent process is called provisioning. During the provisioning process, the new mesh device is integrated into a network by securely distributing an initial set of login credentials to the new device.

[0007] Pairing can be authenticated or unauthenticated. In the unauthenticated case, there is no protection against man-in-the-middle attacks. Even if the unauthenticated pairing process is secured against passive eavesdropping by malicious third parties, it is not secure against an active attacker who acts as a proxy between the two devices and can manipulate the data traffic flowing through them.

[0008] Authenticated pairing requires either pre-shared login credentials unknown to third parties or an exchange of dynamically generated authentication data transmitted out-of-band (OOB). The term "out-of-band" or OOB means that the data is not transmitted over the Bluetooth communication channel, but instead over a different 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 within the device itself (for example, on flash memory), and the QR or NFC representation of the same data can be read by the other device, provided it has the appropriate hardware, such as a camera or an NFC reader. Pre-shared credentials are generally static (they are generated once and then not changed).

[0010] Typical examples of dynamically generated authentication data are numeric or alphanumeric passcodes that are generated and displayed on one device and read by the other device, or entered into the other device by a user via a physical or virtual keyboard.

[0011] Static login credentials pose the risk of being compromised, rendering them insecure. Dynamically generated authentication data is superior in this respect, as it is constantly regenerated as needed and therefore cannot be compromised in advance.

[0012] Dynamically generated authentication data must be communicated between devices in some way. This means that one device must have a means to output the code in some manner, and the other device must either have a means to read and interpret the code or to allow the user to enter the code. The hardware required to display a numeric or alphanumeric code can be bulky and expensive, especially if the device has no other use for such a display. User input can be unreliable or confusing for the user, particularly if the passcode is an unnatural mix of numbers and characters.

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

[0014] Therefore, an improved system and procedure are needed to enable a new device to securely join a Bluetooth LE network or a Bluetooth Mesh network. Furthermore, it would be advantageous if this system and procedure were easy to implement, so that it could be readily used by battery-powered devices. Summary

[0015] A system and method are disclosed by which a new device can join an existing network. The new device comprises a multi-colored light or light source, for example, an RGB LED. The out-of-band (OOB) messages are encoded using transitions between the different LED states. Furthermore, the OOB message can be formatted using TLVs (Type-Length-Value). Additionally, cyclic redundancy codes and forward error correction can be included in the OOB message. This OOB message can be easily integrated into Bluetooth LE Secure Connections or Bluetooth Mesh deployments.

[0016] According to one embodiment, a method is disclosed to enable a joining device to join a Bluetooth network. The method comprises: sending, from the joining device, an out-of-band (OOB) message containing device-specific information related to the joining device, wherein the joining device uses a multi-colored light emitter to transmit the OOB message, and wherein the OOB message is encoded by transitions to a state of the multi-colored light emitter; receiving, at the network device, the OOB message; and using information in the OOB message to perform a joining process. In some embodiments, the multi-colored light emitter comprises a red-green-blue LED (RGB LED) with at least eight LED states.In certain embodiments, 8 LED states are used, generating 7 possible transitions, and all data in the out-of-band (OOB) message is encoded using Base-7. In some embodiments, each color component of the RGB LED has at least three states: an on state, an off state, and at least one intermediate state, resulting in at least 27 LED states. In some embodiments, the joining device sends a calibration sequence before transmitting the OOB message to enable the network device to calibrate a camera. In some embodiments, the OOB message is structured as a plurality of TLVs (Type-Length-Value). In some embodiments, the OOB message contains a 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 GATT services in the joining device to determine whether the joining device is capable of sending the OOB message.

[0017] In some embodiments, the Bluetooth network comprises a Bluetooth LE network, and the joining process includes an LE Secure Connections pairing process. In certain embodiments, the network device sends a GATT request to the joining device to initiate the transmission of the out-of-band (OOB) message.

[0018] In some embodiments, the Bluetooth network comprises a Bluetooth Mesh network, and the joining process includes a provisioning process. In certain embodiments, the joining device sends the out-of-band (OOB) message to the network device after the network device has sent a provisioning start PDU to the joining device.

[0019] According to a further embodiment, a Bluetooth system is disclosed. The system comprises a network device with a camera, and an joining device comprises a multi-colored light emitter, wherein the joining device is configured to transmit an out-of-band (OOB) message using the multi-colored light emitter, the data being encoded by transitions with respect to a state of the multi-colored light emitter, wherein the network device is configured to receive the OOB message using the camera, and wherein information in the OOB message is used by the network device to perform a joining process. In some embodiments, the OOB message transmitted by the joining device is structured as a plurality of TLVs (Type-Length-Value). In some embodiments, the multi-colored light emitter comprises an RGB LED, wherein there are at least eight LED states.In certain embodiments, 8 LED states are used, generating 7 possible transitions, and all data in the out-of-band (OOB) message transmitted by the joining device is encoded using Base-7. In some embodiments, the OOB message includes a cyclic redundancy code. In some embodiments, the OOB message is encoded using a forward error correction (FEC) mechanism. Brief description of the drawings

[0020] For a better understanding of the present invention, reference is made to the accompanying drawings, in which identical elements are designated by the same reference numerals, and in which: Fig. Figure 1 is a block diagram of a network device that is part of the network; Fig. 2 is a block diagram of the new device that wants to join the network; Fig. Figure 3 shows the states of an RGB LED; Fig.Figure 4 shows a possible encoding scheme using an RGB LED; Fig. Figure 5 shows a sequence used to create and send an out-of-box (OOB) message; Fig. Figure 6 shows a sequence used to receive and decode an OOB message; Fig. Figures 7A-7C demonstrate the pairing process using Bluetooth LE Secure Connections; and Fig. Figures 8A-8C demonstrate the deployment process using Bluetooth Mesh. Detailed description

[0021] According to one embodiment, the system and method described herein typically comprise two devices: the new device that wishes to join the network, also referred to as the joining device, and a device that is currently in the network and may be located near the joining device, also referred to as the network device. This system and method require that the joining device, which typically has limited resources, has a single RGB LED. Furthermore, the network device has means for viewing the output from the RGB LED, such as a camera.

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

[0023] The network device 10 comprises a processing unit 20 and an associated storage device 25. This storage device 25 contains the instructions which, when executed by the processing unit 20, cause the network device 10 to perform the functions described herein. This storage device 25 may be non-volatile memory, such as a flash ROM, an electrically erasable ROM, or other suitable devices. In other embodiments, the storage device 25 may be volatile memory, such as RAM or DRAM. In certain embodiments, the storage device 25 may be assembled with the processing unit 20. The processing unit 20 may be any suitable device, including, but not limited to, a general-purpose processor, an application-specific 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 with an antenna 35. This Bluetooth network interface 30 is used for communication via the Bluetooth network.

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

[0026] Although a storage device 25 is disclosed, any computer-readable medium can be used to store these instructions. For example, read-only memory (ROM), random-access memory (RAM), a magnetic storage device such as a hard disk drive, or an optical storage device such as a CD or DVD can be used. Furthermore, these instructions can be downloaded to the storage device 25, for example, via a network connection (not shown), via a CD-ROM, or by some other mechanism. These instructions can be written in any programming language, and this language is not limited by this disclosure. Thus, in some embodiments, there can be multiple computer-readable media containing the instructions described herein. The first computer-readable medium can be, as in Fig.Figure 1 shows the processing unit 20 connected to the network device 10. The second computer-readable medium can be a CD-ROM or other storage device located remotely from the network device 10. The instructions contained on this second computer-readable medium can be downloaded to the storage device 25 to enable the network device 10 to execute the instructions.

[0027] The network device 10 can also include a display element 60. In some embodiments, the display element 60 can be an LED or LCD screen. In certain embodiments, the display element 60 is a touchscreen, so that input can be supplied to the processing unit 20 via the display element 60. In other embodiments, the network device 10 can also be connected to a separate input device to enable user input. The input device can, for example, be a keyboard.

[0028] The network device 10 also includes a camera 70. The camera 70 can have a plurality of pixels to capture visual images. Although the term "camera" is used in the disclosure, it should be understood that any photodetector can be used. The processing unit 20 communicates with the camera 70 to capture any light. In certain embodiments, the network device 10 is capable of creating video recordings to capture an entire sequence transmitted by the joining device.

[0029] In one specific embodiment, the network device 10 can be a mobile phone or a tablet computer. In certain embodiments, the instructions described herein can be packaged as an application. The network device 10 can receive the application from a remote server. For example, in one embodiment, an application can be provided on a remote server, such as a corporate server. In certain embodiments, the application can be available on a digital distribution platform, such as Google Play, the Microsoft Store, the Apple App Store, and others. Of course, in other embodiments, the software application can be pre-installed on the network device 10.

[0030] Fig.Figure 2 shows a representative schematic representation of the joining device 100. The joining device 100 comprises a processing unit 120 and an associated storage device 125. This storage device 125 contains the instructions which, when executed by the processing unit 120, cause the joining device 100 to perform the functions described herein. This storage device 125 can be non-volatile memory, such as a FLASH ROM, an electrically erasable ROM, or other suitable devices. In other embodiments, the storage device 125 can be volatile memory, such as RAM or DRAM. In certain embodiments, the storage device 125 can be packed with the processing unit 120.The processing unit 120 can be any suitable device, including, but not limited to, a general-purpose processor, an application-specific processor, an embedded controller, or a personal computer (PC).

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

[0032] The joining device 100 can include a data storage device 140, which stores data received from and data to be sent from the Bluetooth network interface 130. This data storage device 140 is traditionally a volatile memory. The processing unit 120 has the capability to read and write to the data storage device 140 in order to communicate with the other devices in the network. Although not shown, the joining device 100 also has a power supply, which can be a battery or a connection to a permanent power source, such as a wall outlet.

[0033] Although a storage device 125 is disclosed, any computer-readable medium can be used to store these instructions. For example, read-only memory (ROM), random-access memory (RAM), a magnetic storage device such as a hard disk drive, or an optical storage device such as a CD or DVD can be used. Furthermore, these instructions can be downloaded to the storage device 125, for example, via a network connection (not shown), via a CD-ROM, or by some other mechanism. These instructions can be written in any programming language, and the language is not limited by this disclosure. Thus, in some embodiments, there can be multiple computer-readable media containing the instructions described herein. The first computer-readable medium can be connected to the processing unit 120, as shown in Fig. Figure 2 shows that the second computer-readable medium can be a CD-ROM or other storage device located remotely from the joining device 100. The instructions contained on this second computer-readable medium can be downloaded to the storage device 125 to enable the joining device 100 to execute the instructions.

[0034] The adjoining device 100 may also include a light source 170. The light source 170 may include one or more multicolored light-emitting diodes (LEDs), for example red-green-blue (RGB) LEDs, which emit light that is visible outside the adjoining device 100. The light may be emitted in the visible spectrum.

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

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

[0037] The configuration of the RGB LED channels in the accompanying device 100 for generating each of these outputs is described in Fig. 3 shown.

[0038] Since there are eight LED states, there are seven possible transitions between each LED state. Therefore, there are seven symbols in this encoding, each of which can be assigned a numerical value between 0 and 6. In this way, all data to be transmitted can be encoded as a Base-7 stream. Fig. Figure 4 shows a possible encoding of the LED state transitions.

[0039] To illustrate this encoding scheme, assume the current LED state is red. Further assume that a sequence of four base-7 numbers (1, 2, 5, 0) is to be transmitted, corresponding to the decimal value 476 (1 * 7). 3 + 2 * 7 2 + 5 * 7 1 + 0 * 7 0 This would be coded as follows: Red -> Blue (for encoding 1); Blue -> Cyan (for encoding 2); Cyan -> Yellow (for coding 5); and Yellow -> Off (for encoding 0).

[0040] It should be noted that this base-7 encoding allows for approximately 2.8 bits to be encoded per transition. Thus, 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] It should be noted that the number of transmissions can be reduced if the joining device 100 has two RGB LEDs. Assuming that both RGB LEDs must change their state during each transition, there are 7 * 7 = 49 different values ​​per LED state transition. A joining device 100 with three RGB LEDs can generate 7 * 7 * 7 = 343 different values ​​per LED state transition. However, using multiple RGB LEDs requires that they be far enough apart for the network device 10 to distinguish between them. Furthermore, a calibration sequence can be used to help the network device 10 determine the correct orientation of the multiple LEDs. For example, the LEDs may appear to be oriented from left to right, but will be oriented from right to left when the joining device 100 is rotated.A unique sequence transmitted by the joining device 100 can be used to ensure correct alignment.

[0042] Although this disclosure describes the use of seven possible transitions and the transmission of data using base-7, other embodiments are also possible. In one embodiment, for example, only five LED states are used, thus allowing for four possible transitions. This means that all data would be transmitted using base-4, which is a simple conversion from a typical binary stream.

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

[0044] In certain embodiments, it may be desirable to provide a forward error correction function. This can be applied to this encoding scheme. For example, a generator matrix can be used to convert 6 data symbols (all base-7) into 8 coded symbols. In one embodiment, the generator matrix might look like this: [100000150100001600100024000100330000104200000151]

[0045] The corresponding parity check matrix can look like this: [1011111101123456]

[0046] The encoding process for this code is essentially a matrix multiplication operation. For decoding, a small code like this can easily be decoded using syndrome decoding, since only 48 syndromes need to be checked if the parity check fails. Depending on the expected number and type of transmission errors, other codes may also be used.

[0047] Thus, the joining device 100 uses the generator matrix to produce 8 coded data symbols for every six data symbols. The network device 10 uses the parity check matrix to detect and correct transmission errors.

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

[0049] It should be noted that encoding for error correction, even when using a more complex code, can usually be easily performed on a device with limited resources, such as the joining device 100 is likely to be. Decoding generally requires more resources, but in this arrangement, the network device 10 is often a device with abundant computing resources, such as a mobile phone or a tablet.

[0050] In some embodiments, it may be advantageous to perform a calibration sequence. The calibration sequence may, for example, be a stream of transitions sent by the joining device 100 that cause the RGB LED to cycle through a specific sequence of states, such as from white to off and back again. The network device 10 can use the intensity difference between the white and off LED states to adjust the camera's exposure and the hue of the white signal to adjust the camera's white balance. As mentioned above, if the joining device 100 has multiple RGB LEDs, the calibration sequence for each RGB LED may be different so that the network device 10 can determine the correct orientation.

[0051] Therefore, in certain embodiments, the joining device 100 can transmit the calibration sequence followed by the cryptographic key. The length of this key is protocol-dependent. For mesh deployment, the maximum length of the authentication data is either 128 or 256 bits, depending on the protocol version used. However, in certain embodiments, the joining device 100 can transmit fewer bits if the full data length is not required for the desired level of security.

[0052] In other embodiments, however, it may be advantageous to create a better-defined structure. This allows for some flexibility regarding the size of the string transmitted by the joining device 100 and enables the scheme to function with future protocol versions as well.

[0053] A well-known method for storing or transmitting variable-length data is the use of 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).

[0054] The following compact TLV definition can be used here: - A TLV is constructed using the same base-7 symbols with which the data is encoded. In other words, septenary digits are used; - Type: A base-7 symbol is used to represent the type of the following data; - Length: Zero or more symbols represent the length of the following data; 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.

[0055] Using this format, the following set of TLVs can be created: TLV Type symbol Data length symbols Notes Terminator 0 Zero No associated data ShortData 1 Two Up to 49 data symbols follow LongData 2 Three Between 50 and 392 data symbols follow. DataCRC32 3 Zero 12 associated symbol sequences always

[0056] The other type symbols are currently undefined and may be used later to extend message functionality.

[0057] It should be noted that although the above (provisioning)s are defined using base-7, these TLVs can also be used with a different numerical base if required.

[0058] An OOB message transmitted from joining device 100 to network device 10 contains one or more TLVs transmitted sequentially.

[0059] The following TLVs are defined for inclusion in out-of-band messages: The terminator TLV contains only the type symbol without length or data symbols and serves to indicate the end of the out-of-band (OOB) message. Any septenary digits following the terminator TLV should be ignored. The ShortData TLV type symbol is followed by two data length symbols, meaning that the specified length can range from 1 to 49, since two base-7 symbols can represent a total of 49 different values. It should be noted that this is more than sufficient for encoding 128-bit authentication data, as 46 septenary digits are approximately 128 bits. - The LongData TLV is followed by three data length symbols, allowing for the recording of 343 different values. Since the ShortData TLV can already be used to transmit up to 49 data symbols, the LongData TLV can be used to transmit 50 to 392 symbols, with the three length symbols representing values ​​from 50 to 392 instead of 1 to 343. - The DataCRC32 TLV is not followed by any data length symbols, as the length of the associated data is constant. Twelve data symbols follow; these are sufficient to record a 32-bit CRC (Cyclic Redundancy Code) value, which the receiver can use to verify the integrity of the immediately preceding data TLV.

[0060] When encoding lengths and data, encoding can be done with the least significant digit first (Little Endian) or with the most significant digit first (Big Endian), as long as both devices agree on the order.

[0061] As an example, consider an out-of-box (OOB) message that transmits the very short (and practically insecure) 16-bit hexadecimal authentication value 0xABCC without CRC. This would be structured as follows (in order of most significant digit first): - The hexadecimal digit sequence "ABCC" corresponds to the bit sequence "1010101111001100" - This corresponds to the six-digit septenary number sequence "242136" - This can be encoded as a ShortData-TLV (Type 1, Length 06) as "106242136". - This is followed by the Terminator TLV, which consists of a single-digit number "0". - The result is the complete OOB message "1062421360"

[0062] After the data structures used have been defined, the process used by the joining device 100 to send authentication data to the network device 10 is defined, and in Fig.Figure 5 illustrates this process. First, as shown in box 500, the joining device 100 generates a random bit sequence of sufficient length (for example, 128 or 256 bits) to serve as authentication data. As shown in box 510, the joining device 100 optionally computes a 32-bit cyclic redundancy checksum (CRC) for the authentication data. Next, as shown in box 520, the joining device 100 encodes the bit sequence as a sequence of septenary digits. This is simply a base-2 to base-7 number conversion and can be easily achieved even with limited hardware. If a CRC has been computed, the device also encodes this bit sequence as a sequence of septenary digits. Next, as shown in box 530, the joining device 100 creates two or three TLVs, namely: - either a ShortData TLV or a LongData TLV, depending on the length of the encoded authentication data sequence consisting of digits; - optionally a DataCRC32-TLV containing the encoding of the calculated CRC value; - a Terminator TLV.

[0063] Subsequently, the joining device 100, as shown in field 540, creates the OOB message to be sent by concatenating the above-mentioned TLVs into a string of septenary digits.

[0064] It should be noted that when using a forward error correction method, the joining device 100 applies an FEC encoder to the out-of-band (OOB) message string of septenary digits, resulting in a new string of septenary digits containing an FEC encoding of the original OOB message. This occurs after the OOB message is formed, as shown in field 550.

[0065] Finally, as shown in field 560, after completion of the OOB message creation process, regardless of whether the FEC is encoded or not, the OOB message is transmitted by switching the color of the light source 170 as needed to generate the desired string. After the transmission is complete, the joining device 100 switches off the light source 170, if it was not already switched off.

[0066] After receiving the OOB message from the joining device 100 via its camera 70, the network device 10 performs a decoding process which is Fig.Figure 6 illustrates this. First, the network device 10, using camera 70, captures the out-of-band (OOB) message transmitted by the joining device 100, as shown in box 600. Then, as shown in box 610, if the sender used a forward error correction (FEC) method, the network device 10 decodes the received string using the appropriate FEC decoder. If transmission errors are detected, they are corrected if possible. If there are too many errors to correct, the OOB message is discarded.

[0067] The network device 10 then interprets the OOB message as a concatenation of TLVs, as shown in field 620, and determines the boundaries of each TLV in the OOB message based on the type and length information contained in the TLVs. It should be noted that the OOB message is discarded if this is not possible. The network device should find either two or three TLVs in the OOB message, where: - the first TLV is either a ShortData TLV or a LongData TLV, - the middle TLV is a DataCRC32 TLV (if three TLVs are present), and - the last TLV is a Terminator TLV.

[0068] Network device 10 converts the data found in the ShortData TLV or LongData TLV from septal digits to binary digits, as shown in field 630. As mentioned above, this is a simple base-7 to base-2 conversion.

[0069] As shown in field 640, if the optional DataCRC32-TLV is present in the out-of-box (OOB) message, network device 10 converts the data contained in the DataCRC32-TLV from septal digits to binary digits. Finally, as shown in field 650, if the DataCRC32-TLV was present in the OOB message, network device 10 checks whether the binary CRC matches the binary authentication data. If it does not, the OOB message is discarded.

[0070] Once the process is complete, the network device 10 can use the authentication data during the pairing process. This is described in relation to both Bluetooth LE and Bluetooth Mesh.

[0071] It should be noted that the processes described above can also be performed with bases other than septal digits. For example, in some embodiments, base 4 is used to simplify the conversion to binary numbers. If multiple LEDs are used or more than two color states are employed, a base greater than 7 can also be used.

[0072] With reference to the Fig.7A-7C describes Bluetooth LE Secure Connections pairing as a multi-stage process. The two devices must establish a connection to perform the pairing process. This is typically initiated by the network device 10 if the joining device 100 is a peripheral device. The network device 10 can determine that the joining device 100 supports this out-of-band (OOB) procedure in several ways. In one embodiment, after establishing a connection, the network device can perform service discovery of the joining device's GATT services. The network device can then locate and retrieve the service that provides information about the joining device's OOB capabilities (see line 700).In some embodiments, the same service can also be used to negotiate parameters related to the out-of-band (OOB) data, such as the size of the random data or other parameters. This service can also be used by the network device to trigger the transmission of the calibration sequence, to stop the calibration sequence, and to initiate the start of the OOB transmission.

[0073] Subsequently, as mentioned above, the network device 10 can use the GATT services associated with the OOB procedure to initiate the calibration sequence (see line 701). In response, the joining device 100 can begin transmitting a calibration sequence (see line 702). The network device 10 adjusts its camera settings based on the calibration sequence (see line 703). Upon completion, the network device 10 is successfully calibrated. In some embodiments, the network device 10 can use the GATT service to terminate the transmission of the calibration sequence. In other embodiments, the joining device 100 can terminate the transmission of the calibration sequence when it receives a command from the network device 10 (via the GATT services) to start the OOB transmission (see line 704).

[0074] Network device 10 can again use the GATT services to instruct joining device 100 to transmit the joining device's Bluetooth address, random data, and a corresponding acknowledgment value (see line 704). In response, joining device 100 terminates the transmission of the calibration sequence, if it has not already done so. Both joining device 100 and network device 10 contain an ephemeral elliptic curve key (EC key) that allows the creation of a public key and a private key. The public key is available to any other device and allows decryption of a string 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 have a fixed length, for example, 128 bytes. It is important to note that this random data is independent of the device, as it is currently known only to that device. The joining device 100 then calculates the confirmation value based on the EC public key (PKb) and this random data (see line 707).

[0075] The joining device 100 then creates, as explained above, an out-of-band (OOB) message containing the device's Bluetooth address (B), random data (rb), and the acknowledgment value (Cb). This combination of the Bluetooth address (B), random data (rb), and acknowledgment value (Cb) can be referred to as device-specific information. Thus, the joining device 100 can transmit an OOB message with two TLVs: a ShortData TLV or a LongData TLV, followed by a Terminator TLV (see line 708). Optionally, the joining device 100 can generate a CRC; in this case, the OOB message would also contain a DataCRC32 TLV before the Terminator TV. Finally, the joining device 100 can use FEC, as explained above. The use of CRC and FEC can be negotiated based on parameters found in the joining device's GATT service.

[0076] The network device 10 then receives the OOB message using the camera and decodes the TLVs to obtain the random data and the confirmation value (see line 709).

[0077] At this point, the pairing process can begin. All transmissions after this point are performed using the Bluetooth network. This pairing process begins with network device 10 sending a pairing request using Bluetooth (see line 710). This pairing request includes an indication that the network device already has out-of-band (OOB) data from the remote device. The joining device 100 then responds by transmitting a pairing response (see line 711). It is important to note that the pairing response indicates that no OOB data is available from the remote device, as OOB data is only transmitted from the joining device 100 to network device 10.

[0078] At this point, as in Fig. Figure 7B shows an exchange of the EC public key. 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). The joining device 100 responds by transmitting its public key (PKb) to network device 10 (see line 714). Both devices can now calculate the ECDH secret using their own private key and the public key of the other node (see line 715).

[0079] Network device 10 then validates the acknowledgment value it received from joining device 100 in the out-of-band (OOB) message (see line 716). This is done using the public key (PKb) received in-band and the random data (rb) received out-of-band. If the acknowledgment value received in the OOB message matches the one generated by network device 10 using the public key and the random data (see line 717), the pairing process can continue. Otherwise, the pairing process can be terminated. 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).

[0080] The joining device 100 then selects a random nonce (Nb) (see line 720). This random nonce (Nb) is then transmitted to the network device 10 (see line 721).

[0081] After the random nonces have been exchanged, the rest of the pairing process can proceed as described in Fig.As shown in Figure 7C, the process continues. Both devices can now calculate the Long-Term Key (LTK) and the MacKey (see line 722). Network device 10 calculates an acknowledgment value (Ea) (see line 723). This acknowledgment value (Ea) can be calculated based on MacKey, Na, Nb, the two Bluetooth addresses, and the value of 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 value of Ea with the value received from network device 10 (see line 726). Joining device 100 calculates an acknowledgment value (Eb) (see line 727). This acknowledgment value (Eb) is also calculated based on MacKey, Na, Nb, the two Bluetooth addresses, and the value of rb. Eb is then transmitted to network device 10 (see line 728).Network device 10 also calculates the expected value of Eb locally (see line 729). It then compares its locally calculated value of Eb with the value received from connection device 100 (see line 730). If both checks are correct, the long-term key can now be used for this and all subsequent connections (see line 731).

[0082] It should be noted that there are some deviations from the pairing process described above. For example, although the Bluetooth LE specification prescribes 128 bits for the random data and the acknowledgment value, the joining device 100 can transmit shorter random data, such as 64 bits. Both devices must be aware of this change, which can be achieved by using settings in the GATT service of the joining device 100. In this case, both devices would pad the random data with 64 zeros to achieve the 128-bit value.

[0083] After describing how the OOB message can be integrated into Bluetooth LE Secure Connections, its deployment with Bluetooth Mesh is described below with reference to Fig.8A-8C described. It should be noted that much of this process is the same as that normally used in Bluetooth Mesh. Only the inclusion of displays and out-of-the-box (OOB) messages differ.

[0084] First, the joining device sends an out-of-band (OOB) device beacon (see line 800) to indicate that it can be deployed using broadcast advertisements. Alternatively or additionally, the joining device can indicate that it is available for GATT-based deployment through service advertising of its GATT deployment service. Furthermore, the joining device provides an indication that it supports this OOB method. This can be achieved by setting the "Reserved for Future Use" (RFU) bit or by setting the "Other" bit in the OOB information field of the out-of-band device beacon. Note that a similar bit can also be set in the service advertising of the GATT deployment service.It should be noted that an LE connection can also be established optionally (see line 801).

[0085] If the network device 10 chooses to use the GATT provisioning service to provision the joining device 100, the network device, after establishing a connection, can perform service discovery of the joining device's GATT services, locate and retrieve the service that provides information regarding the joining device's out-of-band (OOB) capabilities, and negotiate parameters related to the OOB data, such as the size of the random data or other parameters, in the same manner as described above for LE pairing (see line 802).

[0086] Network device 10 detects that joining device 100 supports this out-of-the-box (OOB) authentication method and establishes a mesh provisioning session using the selected provisioning method (either GATT-based or advertisement-based) (see line 803). Network device 10 sends an invite PDU to the joining device (see line 804). Joining device 100 responds with a capabilities PDU (see line 805). The capabilities PDU may contain an indication that OOB authentication is supported.

[0087] Network device 10 then responds with a start PDU (see line 806). In this start PDU, the network device selects out-of-band authentication.

[0088] In response, the joining device 100 begins transmitting the calibration sequence described above (see line 807). The network device 10 adjusts its camera settings based on the calibration sequence. Upon completion, the network device 10 is successfully calibrated (see line 808).

[0089] Once complete, the EC key exchange can take place. Network device 10 transmits its public provision key to joining device 100 (see line 809). Receiving the public provision key from network device 10 causes joining device 100 to terminate the transmission of the calibration sequence (see line 810). Additionally, joining device 100 responds with its public provision key (see line 811). Once the public keys have been exchanged, both devices can independently calculate a common ECDH secret, which is used in subsequent transactions (see line 812).

[0090] At this point, the joining device 100 prepares, as in Fig.As can be seen in line 8B, the OOB message is displayed. First, the entering device 100 generates random data (see line 813) to be used as the OOB authentication value. The entering device 100 then creates 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 ShortData TLV or a LongData TLV for the OOB authentication value and a Terminator TLV. In other embodiments, the joining device 100 may include a CRC, in which case a third TLV, the DataCRC32 TLV, is also transmitted before the Terminator TLV. The joining device 100 then sends the OOB message (see line 814). This OOB message is then received by the network device 10 using the camera (see line 815).

[0091] Upon receiving the OOB message, network device 10 selects a random value (see line 816) and calculates an acknowledgment value from the shared ECDH secret, the protocol of previously exchanged messages, the received OOB authentication value, and the selected random value (see line 817). It then transmits a Confirmation PDU to the joining device 100 (see line 818). The Confirmation PDU contains the acknowledgment value used by network device 10. The joining device 100 selects its own random value (see line 819) and calculates its own acknowledgment value (see line 820) using the random value, the shared ECDH secret, the same message protocol as above, and the OOB authentication value. The joining device 100 then also responds with an acknowledgment PDU (see line 821). As in Fig.As shown in Figure 8C, network device 10 then sends a random PDU containing its selected random value (see line 822). Joining device 100 uses the random value 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 value sent by network device 10 in the earlier acknowledgment PDU (see line 824). Joining device 100 then also sends a random PDU (see line 825) containing the previously selected random value. Network device 10 then locally calculates the expected acknowledgment value for joining device 100 (see line 826) and compares it to the data received in the acknowledgment PDU previously sent by joining device 100 (see line 827).Since the out-of-the-box authentication value is factored into the calculation of the confirmation value, it is highly unlikely that a device lacking access to the correct value would receive the correct result. Therefore, comparing the locally calculated value with the received value can be used to authenticate the other device.

[0092] The two devices then calculate a session key (see line 828) using the shared ECDH secret, the same message protocol as above, and random numbers. Finally, network device 10 transmits a provisioning data PDU to the joining device (see line 829), encrypted using the session key. The joining device 100 responds with a Provisioning Complete PDU (see line 830). At this point, the provisioning session is complete and can be terminated (see line 831). If an LE connection was previously established, it can also be terminated at this point (see line 832).

[0093] As explained above, authentication data of a shorter length can be used in the OOB message, as long as both devices are aware of this modification.

[0094] The present system and procedure offer many advantages. First, the transfer of information from the joining device to the network device is enabled without user intervention. It should be noted that the user does not need to manually enter any information into the network device. Furthermore, the user does not need to scan a QR code accompanying the newly joining device.

[0095] Eliminating the QR code simplifies the manufacturing process, as the manufacturer no longer needs to ensure the device has the correct QR code throughout the entire production process. It also makes reconfiguring the device easier for the user. In certain designs, the user must retain the QR code, otherwise the device cannot join other networks.

[0096] Furthermore, the present system and procedure offer enhanced security. The out-of-the-box (OOB) message described here can only be received within a line of sight. In contrast, RF communications can be transmitted through walls and are therefore more easily intercepted by a malicious actor. Additionally, QR codes and serial numbers can be easily viewed in the store simply by opening the packaging of the new device.

[0097] The scope of the present invention is not intended to be limited by the specific embodiments described herein. In fact, other various embodiments and modifications of the present invention, in addition to those described herein, will be apparent to the person skilled in the art from the foregoing description and the accompanying drawings. Therefore, such other embodiments and modifications are to fall within the scope of the present invention. Although the present invention has been described herein in connection with a particular implementation in a particular environment for a particular purpose, it will be clear to the person skilled in the art that its usefulness is not limited thereto and that the present invention can be advantageously implemented in any number of environments for any number of purposes.Consequently, the claims listed below should be interpreted taking into account the full scope and the basic idea of ​​the present invention described herein. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 18 / 924,792

[0001]

Claims

[1] Method to enable an joining device to join a Bluetooth network, the method comprising: Sending, from the joining device, an out-of-band message (OOB message) containing device-specific information related to the joining device, wherein the joining device uses a multi-colored light emitter to send the OOB message, and wherein the OOB message is encoded by transitions with respect to a state of the multi-colored light emitter; Received, at the network device, the out-of-band message; and Using information from the OOB message to conduct an accession process. [2] Method according to claim 1, wherein the multicoloured light emitter comprises a red-green-blue (RGB) LED, wherein there are at least 8 LED states. [3] Method according to claim 2, wherein 8 LED states are used to generate 7 possible transitions, and all data in the OOB message is encoded using base-7. [4] 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 wherein there are at least 27 LED states. [5] Method according to claim 1, wherein the joining device sends a calibration sequence prior to sending the OOB message in order to enable the network device to calibrate a camera. [6] Method according to claim 1, wherein the OOB message is structured as a plurality of TLVs (Type-Length-Value). [7] Method according to claim 1, wherein the OOB message contains a cyclic redundancy code. [8] Method according to claim 1, wherein the OOB message is encoded using a forward error correction (FEC) mechanism. [9] Method according to claim 1, wherein the network device queries GATT services in the joining device to determine whether the joining device is able to send the OOB message. [10] Method according to claim 1, wherein the Bluetooth network comprises a Bluetooth LE network and the joining process comprises an LE Secure Connections pairing process. [11] Method according to claim 10, wherein the network device sends a GATT request to the joining device to initiate the sending of the OOB message. [12] Method according to claim 1, wherein the Bluetooth network comprises a Bluetooth Mesh network and the joining process comprises a provisioning process. [13] Method according to claim 12, wherein the joining device transmits the OOB message to the network device after the network device has transmitted a deployment start PDU to the joining device. [14] Bluetooth system, comprising: a network device that includes a camera; and an adjoining device that has a multicolored light emitter; wherein the joining device is designed to send an OOB message using the multicolored light emitter; where the data are encoded by transitions with respect to a state of the multicolored light emitter; wherein the network device is designed to receive the OOB message using the camera; and where information in the OOB message is used by the network device to perform an joining process. [15] System according to claim 14, wherein the OOB message sent by the joining device is structured as a plurality of TLVs (Type-Length-Value). [16] System according to claim 14, wherein the multicoloured light emitter comprises an RGB LED, wherein there are at least 8 LED states. [17] System according to claim 16, wherein 8 LED states are used to generate 7 possible transitions, and all data in the OOB message transmitted by the joining device are encoded using base-7. [18] System according to claim 14, wherein the OOB message contains a cyclic redundancy code. [19] System according to claim 14, wherein the OOB message is encoded using a forward error correction (FEC) mechanism.

Images