Method for pairing a first device with a second device

Abstract

Method for pairing a first device with a second device via a wireless channel, wherein the first device receives information from the second device via the channel that is characteristic of the second device, wherein the first device generates a first key of the first device by means of a predetermined algorithm based on the received information, wherein the information and the predetermined algorithm are the same as those used by the second device to generate a first key of the second device, such that both first keys of both devices are exactly the same.

Description

Technical area

[0001] The present invention relates to methods for pairing a first device with a second device. The invention focuses on the secure coupling of Bluetooth Low Energy devices. Bluetooth Low Energy (BLE) is a wireless transmission technology for two directly coupled devices that uses a frequency band between 2.404 GHz and 2.480 GHz and is optimized for minimal energy consumption. State of the art

[0002] To pair the devices, the Bluetooth (BT) connection must first be initialized using an initialization key. This requires the same initialization key to be sent to both devices. The process of generating one or more shared keys is called pairing; the process of storing the shared keys generated during pairing for use in subsequent connections to form a trusted pair of devices is called bonding.

[0003] To pair two devices, the current state of the art involves either generating the initialization key on one device and then transferring it to the other, displaying the initialization key on one device and entering it on the second, or entering it on both devices. Several association models exist for this: "Just Works," "Numeric Comparison," "Out of Band," and "Passkey Entry," each of which is used in combination with an authentication method—legacy authentication or secure authentication. Just Works

[0004] Just Works is primarily intended for scenarios where at least one of the devices has neither a display capable of displaying a six-digit number nor a keypad. With Just Works, the initialization key must be transmitted via BLE, which poses a risk of eavesdropping. Numeric Comparison

[0005] Numeric Comparison is intended for scenarios where both devices can display a six-digit number, and in both cases, users can enter "yes" or "no" into their device. Users are shown a six-digit number (from "000000" to "999999") on both displays and are then asked if the numbers match on both devices. If "yes" is entered on both devices, pairing is successful. Numeric Comparison also requires the initialization key to be transmitted over BLE. This, in turn, poses a risk of eavesdropping. Out-of-band

[0006] Out-of-band is designed for scenarios where a non-BT channel is used to both discover the devices and exchange or transmit cryptographic information used in the pairing process. Out-of-band is a flexible option for developers, allowing them to define some of their own pairing mechanisms, so the level of security depends on the out-of-band protection feature. Out-of-band therefore requires an additional communication channel to transmit the initialization key. Passkey Entry

[0007] Passkey Entry is primarily designed for the scenario where one device has input capabilities but lacks the ability to display six digits, and the other device has output capabilities. With Passkey Entry, one device needs a display and the other needs an input capability. The user is shown a six-digit number (from "000000" to "999999") on the device with a display and is then prompted to enter the number on the other device. If the number entered on the second device is correct, pairing is successful. Technical problem

[0008] When establishing a wireless connection between two devices, BLE connections are particularly vulnerable to "man-in-the-middle" (MITM) attacks. A MITM attack occurs when the user of one device wants to establish a connection with the other device, but instead of establishing a direct connection with the other device, unknowingly connects to a third (attacking) device that plays the role of the device with which the connection is actually intended. The third device then relays information between the two devices, creating the impression that they are directly connected.

[0009] The attacking third device can even eavesdrop on the communication between the two devices (active eavesdropping) and is capable of inserting and modifying information into the connection. In this type of attack, all information exchanged between the two devices is compromised, allowing the attacker to inject commands and information into each device, potentially compromising their functionality. Devices targeted by the attack can only communicate when the attacker is present. If the attacker is inactive or out of range, the two victim devices cannot communicate directly with each other, and the user will notice.

[0010] Passive eavesdropping is the process by which a third device listens to the data exchanged between two paired devices. This poses a problem if the initialization key is intercepted during the key exchange.

[0011] The coupling methods (association models) described above are vulnerable to MITM attacks because the shared initialization key must be transferred from one device to the other or - in the case of the "passkey entry" method - must be openly displayed on one device.

[0012] With the passkey entry method, one side needs a display and the other side needs an input option.

[0013] The “out-of-band” method requires an additional communication channel to transmit the initialization key. Brief description of the invention

[0014] The task is therefore to provide methods for pairing, i.e., for the initial connection of two devices, that eliminate vulnerability to MITM attacks and passive eavesdropping. Furthermore, the task is to provide appropriately designed devices.

[0015] This object is achieved by methods or devices according to the claims.

[0016] Accordingly, a method is provided for pairing a first device with a second device via a wireless channel, wherein the first device receives information from the second device via the channel which is characteristic of the second device, wherein the first device generates a first key by means of a predetermined algorithm on the basis of the received information, wherein the information and the predetermined algorithm are the same as those used by the second device to generate a first key, such that both first keys are exactly the same.

[0017] In this case, after receiving the information, the first device can send a request to the second device to establish a connection, wherein the request contains information which is characteristic of the first device as well as the information which is characteristic of the second device.

[0018] Furthermore, after sending the request, the first device may enter a connection establishment state, and in the connection establishment state, the first device may exchange pairing information with the second device before generating the first key.

[0019] The invention also includes a method for pairing a first device with a second device via a wireless channel, wherein the second device sends information to the first device via the channel that is characteristic of the second device, wherein the second device generates a first key based on the information by means of a predetermined algorithm, wherein the information and the predetermined algorithm are the same as those used by the first device to generate a first key, such that both first keys are exactly the same.

[0020] In this case, after sending the information from the first device, the second device can receive a request to establish a connection, wherein the request contains information which is characteristic of the first device, as well as the information which is characteristic of the second device.

[0021] Furthermore, after receiving the request, the second device can switch to a connection establishment state (Connection Established), wherein the second device in the connection establishment state exchanges pairing information with the first device, preferably before it generates the first key.

[0022] The predetermined algorithm must be secret to third-party devices – and also to any third person.

[0023] The first two keys must be identical.

[0024] Pairing can occur when establishing a peer-to-peer connection, particularly a Bluetooth or Bluetooth Low Energy connection. In this case, the information specific to the second device is part of the advertising data that the second device sends during advertising and that the first device receives.

[0025] The algorithm must be implemented in the first device and the second device.

[0026] The information may contain at least part of a device address of the first device, in particular the random part of the static address, and / or the company assigned public MAC address part.

[0027] The first key of the first device and / or the first key of the second device can be extended in length by extending an address part.

[0028] To generate the first key on the first device and the second device, a hash algorithm, an obfuscation algorithm, a symmetric encryption algorithm or another algorithm or a combination of the algorithms may be used in addition to or alternatively to the hash value.

[0029] The first key of both devices is a temporary key.

[0030] Based on the generated first key, at least one further key is generated on the first device and the second device and used for the encrypted distribution of transport-specific keys between the first device and the second device.

[0031] The first device may be a peripheral device or a telecommunications device, in particular a portable telecommunications terminal, and the second device may also be a peripheral device or a telecommunications device, in particular a portable telecommunications terminal.

[0032] The first device can specifically be a peripheral device and the second device a telecommunications device.

[0033] The first device can be a PBX and the second device can be a peripheral device.

[0034] The first device and the second device can each be a peripheral device.

[0035] Furthermore, the invention comprises a first device configured to pair with a second device via a wireless channel, wherein the first device is designed to receive from the second device via the channel information which is characteristic of the second device, wherein the first device contains a predetermined algorithm that allows it to generate a first key based on the received information, wherein the information and the predetermined algorithm are the same as those used by the second device to generate a first key, such that both first keys are exactly the same.

[0036] The invention also includes a second device configured to pair with a first device via a wireless channel, wherein the second device is designed to send information characteristic of the second device to the first device via the channel, wherein the second device contains a predetermined algorithm that allows it to generate a first key on the basis of the information, wherein the advertising information and the predetermined algorithm are the same as those used by the first device to generate a first key, such that both first keys are exactly the same.

[0037] The predetermined algorithm must be kept secret from third-party devices.

[0038] In a further development of the invention, the devices can be further designed in the same way so that they can carry out the methods according to the special embodiments described above or have the properties mentioned above.

[0039] According to the invention, no initialization key is exchanged. Therefore, no initialization key can be intercepted through a "man-in-the-middle" attack. Short description of the characters

[0040] The invention is described in more detail in conjunction with the figures. Fig. 1 shows the sequence of pairing two Bluetooth Low Energy devices according to an embodiment of the invention; Fig. Figure 2 shows a sequence diagram describing the asynchronous flow of Bluetooth Low Energy communication; Fig. 3 illustrates the underlying Bluetooth address types; Fig. Figure 4 illustrates data formats of advertising data from different steps. Detailed description

[0041] Fig. 1 and Fig. 2 shows the pairing process, i.e., the initial connection of two BT devices for a Bluetooth Low Energy connection according to one embodiment of the invention. The steps, or rather the states in which the steps are executed by the BT devices, are explained in detail below. Fig. 1 shows the chronological sequence of the steps of both devices, Fig. 2 shows the sequence of steps separately for the two BT devices.

[0042] Following the terminology of the BT standard, the Central Device CD is the BT device that can discover Peripheral Devices PD and has the ability to establish BLE connections with a Peripheral Device. The Peripheral Device PD can announce its willingness to pair with a Central Device CD via a BLE connection by sending advertisement data. In principle, there are several options for establishing BT connections, depending on the "history" of the devices or the state of the devices, e.g., if the devices are already bonded or if previously unknown devices are to be paired. In the present invention, the pairing method via scanning (Central Scanner) is relevant.

[0043] The following describes device states and the associated process steps that play a role in pairing. Peripheral Advertiser Adv_Norm 1

[0044] The PD's "Peripheral Advertiser Adv_Norm" 1 state is an example of how the pairing process can be initiated, but is not mandatory. After the peripheral device is started, the PD normally switches from the standby state to the advertiser state Adv_Norm 1. In this state, the peripheral device sends only the advertise data according to the protocol data unit (PDU) in a data packet approximately every 1.5 - 2 seconds. Fig. 4a. In this state, peripheral device 1 waits for an external user input (User Event 2) to pair with another device CD or for a connection to be established by an already paired device CD.

[0045] If a connection with a Central Device CD already exists, a connection can be established between CD and PD. Peripheral Advertiser Adv_Pair 4

[0046] Alternatively, the peripheral device is started in Advertise Pair Mode 4, in which case no user input (User Event 2) is required.

[0047] In “Advertise Pair” mode 4, the peripheral device is made visible to the outside world at short intervals.

[0048] However, the PD should only be switched to Advertise Pair Mode 4 briefly. There are several reasons for this: • During this phase it is visible to all Bluetooth devices. • To prevent unauthorized coupling of a foreign central device that knows the same algorithm for “Secure generation of the initialization key (Kixt)”.

[0049] To ensure that no external central device can establish a connection to the peripheral device, the peripheral device is switched to advertise pair mode (Adv_Pair 4) only at the time when pairing / bonding is to be performed. During bonding, an advertising signal ADV_xxx is transmitted for a very limited period of time at short intervals (e.g., approximately 25 ms). During this period, an advertise signal with extended advertise data is sent on the three advertise channels (see Fig. 4b or Fig. 4c).

[0050] This extended advertising data then includes the MAC address and the header as well as the device name (see Fig. 4b). Using this device name, the central device can determine whether the peripheral device is known to it and whether it uses the same algorithm for "Secure Generation of the Initialization Key (Kixt)." In addition to the device name, a random start hash value (RSHW) can also be sent in the advertise data (see [see text]. Fig. 4c). Central Scan 5

[0051] In this state, the Central Device CD uses a scanner to search for the Peripheral Device PD that is to be paired.

[0052] When the central device is to perform a pairing, it starts scanning the current Bluetooth MAC addresses. The CD uses a filter for the device name (DevName; see above) with which it is to be paired. Using the device name (DevName), the central device can determine whether it recognizes the peripheral device and whether the peripheral device uses the same algorithm for "Secure Initialization Key Generation (Kixt)."

[0053] If a known peripheral device is found during scanning 5 6 or an advertise packet with the expected advertise data is received (cf. Fig. 4b or Fig. 4c), the CD switches to the initiating state. In this state, the CD starts establishing a connection. 7. To do so, the CD sends a connection request with the CONNECT_IND data packet to the PD. Connection Established 7

[0054] After the PD receives the CONNECT_IND data packet, the connection between the two devices CD and PD is considered established (state “Connection Established 7”).

[0055] From this point on, the temporary key (Kixt) can be generated on the central device, as it now knows the MAC address of the peripheral device. For better understanding, this is described in Phase 2, Step 1 below, as this phase sequence corresponds to the standard.

[0056] On the peripheral device, however, the temporary key (Kixt) can be generated at any time during the process, e.g. immediately after booting, since the PD naturally knows its own MAC address and does not require any information from the CD for this purpose. Phase 1: Pairing Feature Exchange 8

[0057] In Phase 1, a pairing feature exchange 8 takes place. This step serves to exchange the following information: • IO capabilities: Capabilities that indicate on which side an input and / or output option is available (cf. BT standard); • Availability of out-of-band authentication data; • Authentication requirements - GAP security requirements for the communication channel; • Key size requirements - supported key lengths (between 56 and 128 bits); • the transport-specific keys to be distributed, i.e. which keys must be exchanged in phase 2 / 3.

[0058] The exchanged information, such as IO capabilities, availability of OOB authentication data, and authentication requirements, is used to determine the key generation method used in Phase 2. Phase 2: Key Generation 9

[0059] Both devices derive from the “Pairing Feature Exchange Information” exchanged in Phase 1 which authentication method and association model is used (see above). Phase 2 Step 1

[0060] According to the state of the art (BLE standard), a shared temporary key (Kixt) is first exchanged in Phase 2 Step 1. However, the exchange of the temporary key (Kixt) is eliminated with the invention, which replaces this process step. According to the invention, the secure generation of the initialization key (Kixt) in Phase 2 Step 1 is carried out as follows: • The Kixt is generated on both sides (i.e., on the peripheral device and the central device) using the same generation algorithm (see below). The generation algorithm must be known to both devices. • The algorithm for generating the Kixt is not disclosed. • If the generation algorithm is known to only one party (usually the party that manufactures the PD or creates and programs the code, very rarely the CD), this party can provide the other party with a library for Kixt generation, so that the generation algorithm does not have to be disclosed generally to third parties or devices. The library is then permanently integrated into the code as part of the device programming (usually statically, rarely dynamically). However, a library should be the exception, as the generation algorithm is easier to reproduce and therefore less secure. This is the responsibility of the developer. The library must not be accessible to third parties. • Because the Kixt is automatically generated on both devices, it doesn't need to be transferred from one device to the other. This provides protection against both passive eavesdropping and active eavesdropping (MITM). • The Kixt is derived from the MAC address of the peripheral device. • Depending on the required Kixt length, the MAC address is extended. • Depending on the security level, a hash, obfuscation, symmetric encryption, or other algorithm, or a combination of these algorithms, can be used in addition to or as an alternative to the hash value. A simple obfuscation algorithm is usually sufficient, since the Kixt is only the initialization key, which does not need to be transmitted in this process. • The strength of the Kixt key is as strong as the generation algorithm implemented in the devices used. Phase 2 Step 2

[0061] In this process step 10, the additional keys required for the pairing process are generated. The generation of the additional keys depends on the authentication method used.

[0062] Depending on the authentication method used, LE Legacy Pairing or LE Secure Connections Pairing, the further key generation in Phase 2 and Phase 3 differs. This is known to the expert (see BT standard): • The STK generated in Phase 2 when using LE Legacy Pairing, or • the LTK generated in phases 2 and 3 when using LE Secure Connections or • the common connection key generated using the BR / EDR coupling (see BT standard).

[0063] At the end of phase 2 or 3, the generated keys are compared on both sides for consistency by transmitting confirm key data.

[0064] If the Confirm Key data does not match on both sides, the pairing process is aborted and the corresponding device sends the “Pairing Failed” command with the error code “Confirm Value Failed”. Phase 3

[0065] Phase 3 Key Distribution 11 can then optionally be performed to distribute transport-specific keys, such as the Identity Resolving Key (IRK) value and the identity address information. Phase 1 and Phase 3 are identical, regardless of the method used in Phase 2. Generation of the initialization key Kixt

[0066] The inventive generation of the Kixt is explained in more detail below. As described above, the Kixt for both devices is derived from the MAC address of the peripheral device. Usually, the random-static MAC address or the public MAC address of the peripheral device is used, although in rare cases, another device address is used. An overview of the device addresses used by BLE is shown below. Fig. 3. The individual parts of the address are explained below.

[0067] In addition to the Device_Name of the PD, the 1 to n byte long random start hash value optionally contained in the advertise data (step 1) can be included in the generation of the Kixt.

[0068] Depending on the security level, an obfuscation algorithm, a symmetric encryption algorithm, another algorithm, or a combination of these algorithms can be used to generate the KIXT in addition to or as an alternative to the hash value. In this case, an obfuscation algorithm should be used first to generate the KIXT, followed by a symmetric encryption algorithm. However, in exceptional cases where appropriate security is not required, only one of the two algorithms can be used.

[0069] It is important that the app on the CD and / or PD telecommunications device is protected from being read. This also applies to the CD and / or PD's microcontrollers (MCUs), so MCU flash protection is required.

[0070] Such algorithms are known to those skilled in the art and need not be described in detail here.

[0071] When generating the Kixt, it is important to ensure that when transmitting the confirm key data for key comparison, no conclusions can be drawn from the other party about the Kixt generation algorithms used.

[0072] In the next step, the Kixt is used as an initialization key for calculating the short / long-term key.

[0073] For a more detailed description of the calculation of the short / long-term key, see Bluetooth Core Specification “LE legacy pairing phase 2” and “LE Secure Connections pairing phase 2”.

[0074] When generating the Kixt, only one direction—encoding—needs to be implemented. Decoding is unnecessary because the same Kixt is reused on both sides, i.e., it is encrypted symmetrically.

[0075] Suitable encryption algorithms are described in some places in the Bluetooth Core Specification (see e.g. BT standard CRYPTOGRAPHIC TOOLBOX). Hash value and special cases

[0076] There are two special cases, namely 0x00 and 0xFF, where the subsequent operations have no effect and therefore must be initialized with special hash values. The hash value for each byte in the special cases must be different depending on the byte position and the starting value. This is intended to prevent the algorithm from being reproduced by iterating the MAC address.

[0077] This can be achieved by transmitting a random start hash value, usually one or two bytes (or, in exceptional cases, n bytes), from the peripheral device 4 to the central device in advertise pair mode 5. The random start hash value must be stored persistently on the peripheral device. A new random value must be generated for each new pairing. This value must be different from the previous values.

[0078] The random start hash value serves as the starting value for calculating the special cases. Each special case is replaced with the corresponding calculated value. The following calculation and replacement must then be performed for all bytes of the special cases.

[0079] The random start hash value can also be calculated using the checksum of the MAC address modulo the key size. However, this is not as secure as the transmitted value.

[0080] The hash value can either be stored in a table or calculated using an appropriate polynomial. New hash = RSHW + byte offset (special case). Concealment

[0081] When obfuscating, it is important that after obfuscation, no conclusions can be drawn about the initial MAC address of the peripheral device.

[0082] The MAC address should be extended to the supported key lengths when generating Kixt.

[0083] There are two special cases, namely 0x00 and 0xFF, where the subsequent operations have no effect and therefore must be initialized with special hash values. The hash value for each byte in the special cases must be different depending on the byte position and the starting value. This is intended to prevent the algorithm from being reproduced by iterating the MAC address.

[0084] The following options are available for obfuscation (this is only a small selection): • 1. Exchange (x): Exchange of the original byte order • 2. Exchange Nibble (n): Exchange of low and high nibble (swap halfbytes) • 3. Rotate (rx / lx): Bit rotations by shift operation by n positions in a byte either to the left or right • 4. Hash value (h): Using a hash value calculation • 5. Algorithm (a): Use of different obfuscation algorithms depending • 6. Other bit operations and combination(s) of the above-mentioned possibilities

[0085] Simple overview example for point 6 for a key length of 128 bits (16 bytes) for Kixt.

[0086] The first 6 bytes are created by swapping the byte order and swapping the low and high nibbles of each byte. The next 6 bytes are generated by bit rotating the individual bytes, and the remaining 4 bytes are generated by swapping the low and high nibbles starting at byte offset 2.

[0087] More complex overview example for point 6 for a key length of 128 bits (16 bytes) for Kixt.

[0088] Mixed application of steps 1-4, i.e. swapping the byte order (Operation (Op.) 1), swapping the low and high nibbles and bit rotation by shift operation by n places in different directions in a byte (Op. 2+3) and use of 2 bytes hash value.

[0089] Such obfuscation algorithms are known to those skilled in the art and need not be described in detail here. Symmetric encryption

[0090] Source: https: / / www.elektronik-kompendium.de / sites / net / 1907041.htm (last accessed on August 16, 2023)

[0091] Source: http: / / ddi.cs.uni-potsdam.de / Lehre / e-commerce / elBez2-5 / page05.html (last accessed on August 16, 2023)

[0092] Symmetric encryption is also known as secret-key encryption. It is based on a mathematical function that converts plaintext into ciphertext based on a key (digital code).

[0093] Symmetric encryption – some methods are already standardized here.

[0094] Example: DES (Data Encryption Standard), Triple-DES (also known as TDES, 3DES or DESede), AES (Advanced Encryption Standard), IDEA (International Data Encryption Algorithm), Blowfish, Twofish, CAST-128, CAST-256, Fox and so on. Types of Bluetooth MAC addresses

[0095] Fig. Figure 3 shows the types of MAC addresses used in Bluetooth connections. The Media Access Control (MAC) address is the Bluetooth device address. This 48-bit (6-byte) number uniquely identifies a device among peers. There are several types of device addresses, of which usually only the Static Random Address and the Public Address, and in rare cases another one, are relevant for this invention: • Public MAC Address (PMA): This is a global, fixed address. It must be registered with the IEEE Registration Authority and does not change during the lifetime of the device. The PMA is divided into two parts: A fixed portion (24 bits) that is public and allocated by the IEEE Standards Association. This portion should not be used for polynomial generation. The "Company Assigned" part (PMA-CA - 24 bits) is dynamic and can be used to calculate the Kixt. 24 bits, corresponding to 3 bytes, are available to generate the target polynomial; that is, 2 24 possibilities and corresponds to 16,777,216 different addresses. The bit order is in little-endian format – see BT Core Specification. This method can be used for the following cases: • It can be applied to both authentication methods (legacy authentication and secure authentication). • It can also be applied to all four association models mentioned above (Just Works, Numeric Comparison, Out of Band, and Passkey Entry). (Vol. 1, Part A 5.2.4 Association models, p. 270). • Random Static MAC Address (RSMA) / random static MAC address: A random static address is simply a random number that can either be generated every time the device boots up or remain the same throughout the device's lifetime. However, it cannot be changed within a single power cycle of the device.

[0096] This address is the default MAC address during pairing. 48 bits, or 6 bytes, are available to generate a target polynomial. That's 2 48 Possibilities and corresponds to 281,474,976,710,656 different addresses. • Private Resolvable MAC Address: These are generated from an Identity Resolving Key (IRK) and a random number and can be changed frequently (even during the lifetime of a connection) to prevent the device from being identified and tracked by an unknown scanning device. Only devices that have the IRK distributed by the device, which uses a private, resolvable address, can actually resolve this address, allowing them to identify the device. • Private Non-Resolvable MAC Address / Private, non-resolvable MAC address: Such MAC addresses are not used very frequently. They are a random number that can be changed at any time.

[0097] Fig. Figure 4 illustrates the advertising data of different steps. Fig. 4a when establishing a BT connection. Fig. Figure 4a shows the advertising data sent by the PD in the Adv-Norm 1 state. Only the MAC address and the header are sent. This data is part of the "ADV_xxx" signal. The AdvA field in the physical advertising channel contains either a public address (MAC address) or a random address. If the TxAdd flag is 0, then the address is public; if the TxAdd flag is 1, then the address is random.

[0098] Fig. Figure 4b shows the advertising data sent in state Adv_Pair 4. Here, the MAC address, header, and device name of the sending device are sent. This data can also be part of the ADV_xxx signal.

[0099] In a variant that Fig. 4c, the advertising data of the ADV_xxx signal includes, in addition to the Fig. 4b data illustrates a random start hash value RSHW.

[0100] The CONNECT_IND signal sent by the CD in initiating state 7 includes, in addition to the MAC address of the CD, the MAC address of the PD, which the CD has received, for example, via the ADV_xxx signal. Application example: garage door control

[0101] One application example of the invention is controlling the opening and closing of a garage door (DoorCtrl) using a portable device (e.g., a mobile phone) via a BLE connection. Typically, several mobile phones (central devices) are paired with a DoorCtrl device (peripheral device), allowing multiple people to open or close the same garage door. The following section describes the above process using a real-life example. Peripheral Advertiser Adv_Norm 1

[0102] This process step represents the normal state of a peripheral device that is not connected to a central device. After starting the peripheral device, the peripheral device switches from the standby state to the advertising state 1 (Adv_Norm). In this state, an advertise signal (ADV_IND) without additional advertise data is briefly sent on the three advertise channels at intervals of approximately 2000 ms. In this state, care is taken to ensure that the DoorCtrl device is no longer visible from the outside, thus preventing unwanted pairing attempts. This state is maintained until one of the following external user events occurs: Case 1: A mobile phone previously paired with the DoorCtrl device establishes a connection to the DoorCtrl device to control it (opening / closing). This case almost always occurs, especially if the mobile phone and the DoorCtrl device have already been paired and bonded. The following steps are then not performed. Control (opening / closing the garage door) can be performed immediately. Case 2: An unpaired mobile phone (central device) pairs with the garage door's DoorCtrl device. The method according to the invention is applied below.

[0103] After receiving the advertise signal ADV_IND (Adv_Pair 4), the mobile phone (central device) can be put into scan mode. After pairing is initiated, the mobile phone switches to scan state 5.

[0104] To ensure that no other mobile phone can establish a connection to the DoorCtrl device (PD), the DoorCtrl device is only switched to Advertise Pair Mode (Adv_Pair 4) at the time when a user specifically wants to perform pairing / bonding.

[0105] This occurs after the user presses the pairing button (User Event 2). The pairing button is located on the DoorCtrl device (PD). After this external user event, the DoorCtrl device switches to the Advertiser Adv_Pair 4 state. Peripheral Advertiser Adv_Pair 4

[0106] In Advertise Pair mode, the DoorCtrl device is made visible to the outside world at short intervals. From this point on, the device name (DevName, e.g., DoorCtrl) is also sent in the advertised data (ADV_IND). Using this device name, the mobile phone can determine whether it knows the algorithm for "Secure Initialization Key Generation (Kixt)."

[0107] For bonding, an advertise signal with additional advertise data, such as the DevName, is sent on the three advertise channels within a limited period of approximately 5 seconds at short advertise intervals (e.g., approximately 25ms). Central Scanner 5

[0108] In this step, the mobile phone uses a scanner to search for the DoorCtrl device that is to be paired.

[0109] It starts scanning the current Bluetooth MAC addresses. It uses a filter for the device name (DevName) DoorCtrl with which it wants to pair.

[0110] Using the device name DoorCtrl, the mobile phone can detect whether it recognizes the DoorCtrl device and whether it uses the same algorithm for “Secure Generation of the Initialization Key (Kixt)”.

[0111] Once the DoorCtrl device is found, the initialization key (Kixt) is generated. Afterward, a connection setup 6 is initiated. Connection Established 7

[0112] As soon as the DoorCtrl device receives a valid connection request packet (Connect_Ind; CONNECT_REQ) from the scanning mobile phone, both devices enter the "Connection Established 7" state. In this state, the mobile phone (central device) establishes a connection to the DoorCtrl device. After a connection request packet (CONNECT_REQ) has been sent from the mobile phone and received by the DoorCtrl device, the two BLE devices are considered connected.

[0113] From this point on, the process complies with the BLE standard. Glossary / Abbreviations • Advertising: Sending information about the readiness to connect or pair with another device. Sending advertising messages, which are simple periodic announcements / presence notifications to other devices. • ADV_xxx: Represents the following advertise PDU types: ADV_IND, ADV_SCAN_IND, ADV_EXT_IND, and other advertise PDU types. In most cases, the advertise PDU type ADV_IND is used. • Adv_Norm: State of the peripheral device that is not connected. With Adv_Norm, only the MAC address and header are sent. • Adv_Pair: Advertise-Pair mode. With Adv_Pair, the MAC address, the header, and the device name are sent, and optionally (variant 2) a random start hash value (RSHW) is also sent. • Bonding: Storing the keys created during pairing for use in subsequent connections to form a trusted pair of devices. • BT: Bluetooth • BLE: Bluetooth Low Energy • B_KEY: Base key • CD: Central Device • Device name: The device name or a unique device ID (hereinafter referred to as the device name) identifies the functionality of the peripheral device. This is defined by the developer of the corresponding peripheral device. • FIPS: Federal Information Processing Standard • Hash function: A hash function is a mapping that maps an input set, the keys, to a target set, the hash values. The target set (e.g., 2 bytes) can be larger than the input set (e.g., 1 byte). • IEEE: Institute of Electrical and Electronics Engineers • IRK: Identity Resolving Key • Kixt: Key Init X (Short / Long) Term. Initialization key for STK / LTK. This is equivalent to the transmitted or entered key (see association models). • LTK: Long-Term Key • MAC: Short for Media Access Control (address) • MCU: Microcontroller Unit • MITM: Man-in-the-Middle attacks • Nibble: Four bits or a half-byte are called a nibble • Octet: An octet always consists of exactly 8 bits. 8 bits “b” = 1 byte “B” = 1 octet “O • Pairing: The process of creating one or more shared secret keys. • PD: Peripheral Device • PDU: Protocol data unit • Peer to peer: This means that communication takes place directly from one device to another device, without going through an intermediate server • PMA: Public MAC Address • Random start hash value (RSHW): This can further increase the security of the Kixt generation. • RSMA: Random Static MAC Address (default MAC address during pairing). With RSMA, the "Random Part of Static Address" is used for calculation. Each chip has its own MAC address. 48 bits, corresponding to 6 bytes, are available to generate a target polynomial. That is, 2 48 Possibilities and corresponds to 281,474,976,710,656 different addresses. • Scanning: Receiving information sent during advertising. • STK: Short Term Key • TK: Temporary Key QUOTES CONTAINED IN THE DESCRIPTION

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

[0000] https: / / www.elektronik-kompendium.de / sites / net / 1907041.htm (last accessed on 16.08.2023

[0090] http: / / ddi.cs.uni-potsdam.de / Lehre / e-commerce / elBez2-5 / page05.html (last accessed on 16.08.2023

[0091] Association models (Just Works, Numeric Comparison, Out of Band, and Passkey Entry) are applied. (Vol. 1, Part A 5.2.4 Association models, p. 270

[0095]

Claims

[1] A method for pairing a first device (CD) with a second device (PD) via a wireless channel, wherein the first device (CD) receives information (ADV_xxx) from the second device (PD) via the channel, which is characteristic of the second device (PD), wherein the first device (CD) generates a first key (Kixt-1) of the first device (CD) by means of a predetermined algorithm on the basis of the received information (ADV_xxx), wherein the information (ADV_xxx) and the predetermined algorithm are the same as those used by the second device (PD) to generate a first key (Kixt-2) of the second device (PD), such that both first keys of both devices (Kixt-1, Kixt-2) are exactly the same. [2] Method according to claim 1, wherein the first device (CD) after receiving the information (ADV_xxx) sends to the second device (PD) a request to establish a connection (CONNECT_IND), wherein the request (CONNECT_IND) contains information which is characteristic of the first device (CD) and the information which is characteristic of the second device (RSMA, PMA-CA). [3] Method according to the preceding claim, wherein the first device (CD) changes to a connection establishment state (Connection Established) after sending the request (CONNECT_IND) and wherein the first device exchanges pairing information with the second device (CD) in the connection establishment state before generating the first key (Kixt-1). [4] A method for pairing a first device (CD) with a second device (PD) via a wireless channel, wherein the second device (PD) sends information (ADV_xxx) to the first device (CD) via the channel, which is characteristic of the second device (PD), where the second device (PD) generates a first key (Kixt-2) of the second device (PD) by means of a predetermined algorithm on the basis of the information, wherein the information and the predetermined algorithm are the same as those used by the first device (CD) to generate a first key (Kixt-1) of the first device (CD), such that both first keys (Kixt-1, Kixt-2) are exactly the same. [5] Method according to the preceding claim, wherein the second device (PD) receives a request to establish a connection (CONNECT_IND) after sending the information from the first device (CD), the request (CONNECT_IND) containing information which is characteristic of the first device (CD) and the information which is characteristic of the second device (RSMA, PMA-CA). [6] Method according to the preceding claim, wherein the second device (PD) changes to a connection establishment state (Connection Established) after receiving the request (CONNECT_IND) and wherein the second device (PD) exchanges pairing information with the first device (CD) in the connection establishment state, preferably before it generates the first key (Kixt-2). [7] Method according to one of the preceding claims, wherein the predetermined algorithm is secret for third devices. [8] Method according to one of the preceding claims, wherein the first key (Kixt-1) of the first device (CD) and the first key (Kixt-2) of the second device (PD) are identical. [9] Method according to one of the preceding claims, wherein the pairing takes place during the establishment of a peer-to-peer connection, in particular a Bluetooth connection or Bluetooth Low Energy connection. [10] Method according to one of the preceding claims, wherein the algorithm is implemented in the first device (PD) and / or in the second device (CD). [11] Method according to one of the preceding claims, wherein the information (ADV_xxx) contains at least a part (RSMA, PMA-CA) of a device address of the first device (PD), in particular the random part of the static address (RSMA), and / or the company assigned public MAC-address part (PMA-CA). [12] Method according to one of the preceding claims, wherein both first keys (Kixt-1, Kixt-2) are extended in their length dependently by extending an address part (RSMA, PMA-CA). [13] Method according to one of the preceding claims, wherein a hash value, hash algorithm, obfuscation algorithm, a symmetric encryption algorithm or another algorithm or a combination of the algorithms is additionally used to generate the first key (Kixt-1) of the first device and the first key (Kixt-2) of the second device. [14] Method according to one of the preceding claims, wherein both first keys (Kixt-1, Kixt-2) are temporary keys. [15] Method according to one of the preceding claims, wherein based on the generated first key (Kixt-1) of the first device (CD) and the first key (Kixt-2) of the second device (PD), at least one further key (STK, LTK) is generated and is used for the encrypted distribution of transport-specific keys (IRK; LTK) between the first device (CD) and the second device (PD). [16] Method according to one of the preceding claims, wherein the first device (PD) is a peripheral device or a telecommunications device, in particular a portable telecommunications terminal, and the second device (CD) is also a peripheral device or a telecommunications device, in particular a portable telecommunications terminal. [17] Method according to one of the preceding claims, wherein the first device (PD) is a peripheral device and the second device (CD) is a telecommunications device. [18] Method according to one of the preceding claims, wherein the first device (PD) is a telecommunications device and the second device (CD) is a peripheral device. [19] Method according to one of the preceding claims, wherein the first device (PD) and the second device (CD) are each a telecommunications device. [20] A first device (CD) configured to pair with a second device (PD) via a wireless channel, wherein the first device (CD) is designed to receive from the second device (PD) via the channel information (ADV_xxx) which is characteristic of the second device (PD), wherein the first device (CD) has a predetermined algorithm for generating, on the basis of the received information (RSMA; PMA-CA), a first key (Kixt-1), wherein the information (ADV_xxx) and the predetermined algorithm are the same as those used by the second device (PD) to generate a first key (Kixt-2), such that both first keys (Kixt-1 and Kixt-2) are exactly the same. [21] Second device (PD) configured to pair with a first device (CD) via a wireless channel, wherein the second device (PD) is designed to send information (ADV_xxx) to the first device (CD) via the channel, which is characteristic of the second device (PD), wherein the second device (PD) has a predetermined algorithm for generating, on the basis of the information, a first key (Kixt-2), wherein the advertising information and the predetermined algorithm are the same as those used by the first device (CD) to generate a first key (Kixt-1), such that the first key (Kixt-1) of the first device (PD) is exactly the same as the first key (Kixt-2) of the second device (PD). [22] Device (CD, PD) according to claim 20 or 21, wherein the predetermined algorithm is secret for third devices.

Images