DE102023124254B4 - Method for pairing a first device with a second device - Google Patents

Abstract

A method for pairing a first device with a second device via a wireless channel, wherein the first device receives information characteristic of the second device from the second device via the channel, wherein the first device generates a first key of the first device 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 of the second device, such that both first keys of both devices are exactly the same.

Description

Technical field

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

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.

To pair two devices, the current state of the art involves either generating the initialization key from 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 purpose: "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

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.

Numerical Comparison

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

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 provides 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

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 side needs a display, and the other side needs an input capability. The user is presented with a six-digit number (from "000000" to "999999") on the device with the 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

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.

The attacking third device can even eavesdrop on the communication between the two devices (active eavesdropping) and is able to insert and modify information in the connection. In this type of attack, all The information exchanged between the two devices is compromised, and the attacker can inject commands and information into each device, potentially compromising their functionality. Devices that fall victim to 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.

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.

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.

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

The “out-of-band” method requires an additional communication channel to transmit the initialization key.

US2023052917A1 relates to a pairing method applied to a short-range communication system. The method comprises: a first wireless device obtaining a first password, the first password being shared between the first wireless device and a second wireless device; and the first wireless device pairing with the second wireless device based on a password-based authenticated key exchange (PAKE) protocol and using the first password as an encryption password in a key exchange process. It is not disclosed that the algorithm for generating the initialization keys is the same in both devices.

US2015222517A1 relates to a communication protocol in which, when two partners pair, a shared secret is generated using information exchanged out-of-band between the two partners. It is not disclosed that the algorithm for generating the initialization keys is the same in both devices.

US 2022/0322101 A1 concerns the sharing of resources between wireless networks. Pairing two devices is not described.

US10299300B1 relates to a method for connecting wireless audio devices. It does not describe how any initialization keys are generated and/or distributed.

US 2023/0041669 A1 refers to a Bluetooth connection method in which confidential information is exchanged during pairing.

Brief description of the invention

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, it is necessary to provide appropriately designed devices.

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

• das erste Gerät von dem zweiten Gerät über den Kanal Information empfängt, die für das zweite Gerät kennzeichnend ist, wobei das erste Gerät mittels eines vorbestimmten Algorithmus auf der Basis der empfangenen Information einen ersten Schlüssel erzeugt, wobei
• die Information sowie der vorbestimmte Algorithmus dieselben sind, die dem zweiten Gerät zur Erzeugung eines ersten Schlüssels dienen, derart, dass beide erste Schlüssel genau gleich sind,
• wobei kein erster Schlüssel ausgetauscht wird.

Accordingly, a method is provided for pairing a first device with a second device via a wireless channel, wherein

• the first device receives information characteristic of the second device from the second device via the channel, the first device generating a first key by means of a predetermined algorithm on the basis of the received information,
• 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,
• where no first key is exchanged.

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 and the information which is characteristic of the second device.

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.

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 over the channel that is characteristic of the second device, where
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,
where no first key is exchanged.

Here, 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 and the information which is characteristic of the second device.

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

The predetermined algorithm must be secret for third-party devices - and also for any third person.

The first two keys must be identical.

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 the first device receives.

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

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.

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.

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.

The first key of both devices is a temporary key.

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.

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.

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

The first device can be a telecommunications device and the second device a peripheral device.

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

• das erste Gerät ausgestaltet ist, von dem zweiten Gerät über den Kanal eine Information zu empfangen, die für das zweite Gerät kennzeichnend ist, wobei
• das erste Gerät einen vorbestimmten Algorithmus enthält, der ihm erlaubt auf der Basis der empfangenen Information, einen ersten Schlüssel zu erzeugen, wobei
• die Information sowie der vorbestimmte Algorithmus dieselben sind, die dem zweiten Gerät zur Erzeugung eines ersten Schlüssels dienlich sind, derart, dass beide erste Schlüssel genau gleich sind, und
• wobei kein erster Schlüssel ausgetauscht ist.

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, and
• where no first key is exchanged.

• das zweite Gerät ausgestaltet ist, dem ersten Gerät über den Kanal Information zu senden, die für das zweite Gerät kennzeichnend ist, wobei
• das zweite Gerät einen vorbestimmten Algorithmus enthält, der ihm erlaubt, auf Basis der Information einen ersten Schlüssel zu erzeugen, wobei die Advertising-Information sowie der vorbestimmte Algorithmus dieselben sind, die dem ersten Gerät zur Erzeugung eines ersten Schlüssels dienlich sind, derart, dass beide erste Schlüssel genau gleich sind, und
• wobei kein erster Schlüssel ausgetauscht ist.

The invention also includes a second device configured to pair with a first device via a wireless channel, wherein

• the second device is configured 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, and
• where no first key is exchanged.

For the devices, the predetermined algorithm must be secret from third-party devices.

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.

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

• 1 zeigt den Ablauf der Kopplung zweier Bluetooth Low Energy Geräte gemäß einem Ausführungsbeispiel der Erfindung;
• 2 zeigt ein Sequenzdiagramm, das den asynchronen Ablauf der Bluetooth-Low Energy Kommunikation beschreibt;
• 3 illustriert die zugrunde liegenden Bluetooth-Address-Typen;
• 4 illustriert Datenformate der Advertising-Daten verschiedener Schritte.

The invention is described in more detail in conjunction with the figures.

• 1 shows the sequence of coupling two Bluetooth Low Energy devices according to an embodiment of the invention;
• 2 shows a sequence diagram describing the asynchronous flow of Bluetooth Low Energy communication;
• 3 illustrates the underlying Bluetooth address types;
• 4 illustrates data formats of advertising data from different steps.

Detailed description

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

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 advertise data. In principle, there are several options for establishing BT connections, depending on the "previous history" of the devices or their state, 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.

The following describes device states and the associated process steps that play a role in pairing.

Peripheral Advertiser Adv_Norm 1

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

If a connection with a Central Device CD already exists, a connection can be established between CD and PD.

Peripheral Advertiser Adv_Pair 4

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

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

• • Während dieser Phase ist es für alle Bluetooth-Geräte sichtbar.
• • Damit kein fremdes Central-Device, dem derselbe Algorithmus zur „Sicheren Generierung des Initialisierungs-Keys (Kixt)“ bekannt ist, unerlaubt koppelt.

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)”.

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 (for example, approximately 25 ms). Within this period, an advertise signal with extended advertise data is sent on the three advertise channels (see 4b or 4c ).

This extended advertising data then includes the MAC address and the header as well as the device name (see 4b) . Using this device name, the central device can determine whether it recognizes the peripheral device 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 4c ).

Central Scan 5

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

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)."

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

Connection Established 7

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”).

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.

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

• • IO-Fähigkeiten: Fähigkeiten, die aussagen, auf welcher Seite eine Eingabe- und/oder Ausgabemöglichkeit vorhanden ist (vgl. BT-Standard);
• • Verfügbarkeit von Out-of-Band-Authentifizierungsdaten;
• • Authentifizierungsanforderungen - Sicherheitsanforderungen des GAP an den Kommunikations-Kanal;
• • Schlüsselgrößenanforderungen - unterstützte Schlüssellängen (zwischen 56 und 128 Bit);
• • die zu verteilenden transportspezifischen Schlüssel, also welche Schlüssel in Phase 2/3 ausgetauscht werden müssen.

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.

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

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

• • Die Generierung des Kixt erfolgt auf beiden Seiten (also auf dem Peripheral-Device und auf dem Central-Device) mit dem gleichen Generierungs-Algorithmus (siehe unten). Der Generierungs-Algorithmus muss dabei beiden Geräten bekannt sein.
• • Der Algorithmus zur Generierung des Kixt wird dabei nicht offengelegt.
• • Ist der Generierungs-Algorithmus nur einer Partei (meist der Partei, die das PD herstellt oder den Code erstellt und einprogrammiert, sehr selten des CD) bekannt, so kann diese Partei der anderen Partei zur Kixt-Generierung eine Library zur Verfügung stellen, damit der Generierungs-Algorithmus nicht allgemein und für dritte Geräte oder Personen offengelegt werden muss. Die Library wird dann im Rahmen der Programmierung der Geräte fest (meist statisch, seltener dynamisch) mit in den Code eingebunden. Eine Library sollte aber die Ausnahme sein, da der Generierungs-Algorithmus einfacher reproduziert werden kann und deshalb unsicherer ist. Dies liegt in der Verantwortung des Entwicklers. Die Library darf Dritten nicht zugänglich sein.
• • Aufgrund der automatischen Generierung des Kixt auf beiden Geräten muss der Kixt nicht vom einen Gerät auf das andere übertragen werden. Daher besteht ein Schutz gegen passives Abhören sowie aktives Abhören (MITM).
• • Der Kixt leitet sich von der MAC-Adresse des Peripheral-Device ab.
• • Abhängig von der benötigten Kixt-Länge wird die MAC-Adresse verlängert.
• • Abhängig vom Sicherheits-Level kann zur Generierung zusätzlich oder alternativ zum Hash-Wert ein Hash-, ein Verschleierungs-, ein symmetrischer Verschlüsselungs- oder ein anderer Algorithmus oder eine Kombination der Algorithmen verwendet werden. Meist ist ein einfacher Verschleierungs-Algorithmus ausreichend, da es sich beim Kixt nur um den Initialisierungs-Schlüssel handelt, der in diesem Verfahren gar nicht übertragen werden muss.
• • Die Stärke des Kixt-Schlüssels ist so stark wie der Generierungs-Algorithmus, der in den verwendeten Geräten implementiert ist.

According to the state of the art (BLE standard), a common temporary key (Kixt) is first exchanged in Phase 2 Step 1. However, the exchange of the temporary key (Kixt) is no longer necessary with the invention, which replaces this method step. According to the invention, the secure generation The initialization key (Kixt) is generated in Phase 2 Step 1 as follows:

• • The Kixt is generated on both sides (i.e., on the peripheral device and on 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 can be reproduced more easily and is 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 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

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.

• • Der STK, der in Phase 2 bei Verwendung von LE Legacy Pairing erzeugt wird, oder
• • der in Phase 2 und 3 erzeugte LTK bei Verwendung von LE Secure Connections oder
• • der gemeinsame Verbindungsschlüssel, der mit Hilfe der BR/EDR-Kopplung erzeugt wurde (vgl. BT-Standard).

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

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

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

Phase 3

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

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. 3 . The individual parts of the address are explained below.

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.

Depending on the security level, the Kixt can be generated in addition to or alternatively to An obfuscation algorithm, a symmetric encryption algorithm, or another algorithm, or a combination of algorithms, can be used to generate 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.

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 microcontrollers (MCUs); therefore, MCU flash protection is required.

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

When generating the Kixt, it is important to ensure that when transmitting the confirm key data for key comparison, the other party cannot draw any conclusions about the Kixt generation algorithms used.

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

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

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.

Suitable encryption algorithms are described in some places in the Bluetooth Core Specification (see, for example, BT Standard CRYPTOGRAPHIC TOOLBOX).

Hash value and special cases

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.

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.

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.

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.

.The hash value can either be stored in a table or calculated using an appropriate polynomial. $$\text{Neuer Hash}=\text{RSHW}+\text{Byte}-\text{Offset}\left(\text{Sonderfall}\right).$$

.

Concealment

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

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

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.

• • 1. Exchange (x): Vertauschung der ursprünglichen Byte-Reihenfolge
• • 2. Exchange Nibble (n): Vertauschung Low- und High-Nibble (Halbbyte vertauschen)
• • 3. Rotate (rx/lx): Bit-Rotationen durch Shift-Operation um n-Stellen in einem Byte entweder nach links oder rechts
• • 4. Hash-Wert (h): Verwendung einer Hash-Wert-Berechnung
• • 5. Algorithmus (a): Verwendung von unterschiedlichen Verschleierungs-Algorithmen abhängig
• • 6. Andere Bit-Operationen sowie Kombination(en) der zuvor genannten Möglichkeiten

The following options are available for concealment (this is only a small selection):

• • 1. Exchange (x): Exchange of the original byte order
• • 2. Exchange Nibble (n): Swap 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 previously mentioned possibilities

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

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.

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

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.

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

Symmetric encryption

Source: https://www.elektronik-kompendium.de/sites/net/1907041.htm (last accessed on 16.08.2023 )

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

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

Symmetric encryption – some methods have already been standardized.

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

• • Public MAC Address (PMA) / öffentliche MAC-Adresse:
  • Dies ist eine globale, feste Adresse. Sie muss bei der IEEE Registration Authority registriert werden und ändert sich während der Lebensdauer des Geräts nicht. Die PMA ist in zwei Teile aufgeteilt:
    • Ein fester Teil (24 Bit), der öffentlich ist und von IEEE Standards
    • Association fest vergeben wird. Dieser Teil sollte nicht zur Polynom-Generierung verwendet werden.
    • Der „Company Assigned“ Teil (PMA-CA - 24 Bit) ist dynamisch und kann zur Berechnung des Kixt verwendet werden. Zur Generierung des Ziel-Polynoms stehen hier 24 Bits, das entspricht 3 Bytes, zur Verfügung; das sind 2²⁴ Möglichkeiten und entspricht 16.777.216 unterschiedlichen Adressen.
    • Die Bit-Reihenfolge ist im Little-Endian-Format - siehe BT Core Specification. Das Verfahren kann für die folgenden Fälle angewendet werden:
      • • Es kann für beide Authentifizierungsverfahren (Legacy-Authentifizierung und sichere Authentifizierung) angewendet werden.
      • • Es kann außerdem für alle vier oben genannten Assoziations-Modelle (Just Works, Numeric Comparison, Out of Band und Passkey Entry) angewendet werden. (Vol. 1, Part A 5.2.4 Association models, S. 270).
• • Random Static MAC Address (RSMA) / zufällige statische MAC-Adresse:
  • Eine zufällige statische Adresse ist einfach eine Zufallszahl, die entweder bei jedem Hochfahren des Geräts generiert werden kann oder während der gesamten Lebensdauer des Geräts gleich bleibt Sie kann jedoch nicht innerhalb eines einzigen Einschaltzyklus des Geräts geändert werden.
  • Diese Adresse ist die Default-MAC-Adresse beim Pairing. Zur Generierung eines Ziel-Polynoms stehen hier 48 Bits, das entspricht 6 Bytes, zur Verfügung. Das sind 2⁴⁸ Möglichkeiten und entspricht 281.474.976.710.656 unterschiedlichen Adressen.
• • Private Resolvable MAC Address / Private auflösbare MAC-Adresse:
  • Diese werden aus einem Identity Resolving Key (IRK) und einer Zufallszahl generiert und können oft geändert werden (sogar während der Lebensdauer einer Verbindung), um zu vermeiden, dass das Gerät von einem unbekannten Scangerät identifiziert und verfolgt wird. Nur Geräte, die über den vom Gerät verteilten IRK verfügen, der eine private, auflösbare Adresse verwendet, können diese Adresse tatsächlich auflösen, wodurch sie das Gerät identifizieren können.
• • Private Non-Resolvable MAC Address / Private, nicht auflösbare MAC-Adresse:
  • Solche MAC-Adressen werden nicht sehr häufig verwendet. Es handelt sich dabei um eine Zufallszahl, die jederzeit geändert werden kann.

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 part (24 bits) that is public and defined by IEEE Standards
    • Association is assigned a fixed value. This part 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; this is ²²⁴ 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-on cycle of the device.
  • This address is the default MAC address during pairing. 48 bits, or 6 bytes, are available to generate a target polynomial. This is ²⁴⁸ possible addresses 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:
  • Such MAC addresses are not used very frequently. They are a random number that can be changed at any time.

4 illustrates the advertising data of different steps. 4a when establishing a BT connection. 4a Shows the advertising data sent by the PD in the Adv-Norm 1 state. Only the MAC address and header are sent here. 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 = 0, then the address is public; if the TxAdd flag = 1, then the address is random.

4b Shows the advertising data sent in state Adv_Pair 4. The MAC address, header, and device name of the sending device are sent here. This data can also be part of the ADV_xxx signal.

In a variant that 4c As illustrated, the advertising data of the ADV_xxx signal includes, in addition to the 4b The data illustrated also includes a random start hash value RSHW.

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, e.g., via the ADV_xxx signal.

Application example: garage door control

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

• Fall 1: Ein bereits zuvor mit dem DoorCtrl-Device gekoppeltes Handy baut eine Verbindung zum DoorCtrl-Device auf, um dieses zu steuern (Öffnen/Schließen). Dieser Fall wird fast immer ausgeführt, eben dann, wenn das Handy und das DoorCtrl-Device bereits miteinander gepaart wurden und gebonded sind. Die folgenden Schritte werden dann nicht durchgeführt. Die Steuerung (Öffnen/Schließen des Garagentors) kann unmittelbar erfolgen.
• Fall 2: Nicht gekoppeltes Handy (Central Device) führt eine Kopplung/Paarung mit dem DoorCtrl-Device des Garagentors durch. Das erfindungsgemäße Verfahren wird im Folgenden angewandt.

This process step represents the normal state of a peripheral device that is not connected to a central device. After the peripheral device is started, it 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 that has already been 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 take place immediately.
• Case 2: An unpaired mobile phone (central device) performs a pairing with the garage door's DoorCtrl device. The method according to the invention is applied below.

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.

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.

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

Peripheral Advertiser Adv_Pair 4

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 advertise data (ADV_IND). Using this device name, the mobile phone can determine whether it knows the algorithm for "Secure Initialization Key Generation (Kixt)."

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

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

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

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

Once the DoorCtrl device is found, the initialization key (Kixt) is generated. Afterward, a connection setup 6 is initiated.

Connection Established 7

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.

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 calculations. Each chip has its own MAC address. 48 bits, or 6 bytes, are available to generate a target polynomial. This is ²⁴⁸ possibilities and corresponds to 281,474,976,710,656 different addresses.
• • Scanning: Receiving information sent during advertising.
• • STK: Short Term Key
• • TK: Temporary Key

Claims (22)

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 that is characteristic of the second device (PD), wherein the first device (CD) generates a first key (Kixt-1) of the first device (CD) using a predetermined algorithm based on 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 (Kixt-1, Kixt-2) are exactly the same, wherein no first key (Kixt-1, Kixt-2) is exchanged. Procedure according to Claim 1 , wherein the first device (CD) sends a request to establish a connection (CONNECT_IND) to the second device (PD) after receiving the information (ADV_xxx), 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). 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). 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) identifying the second device (PD) to the first device (CD) via the channel, wherein the second device (PD) generates a first key (Kixt-2) of the second device (PD) using a predetermined algorithm based on 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, wherein no first key (Kixt-1, Kixt-2) is exchanged. 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). 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) in the connection establishment state with the first device (CD) receives information for pairing from exchanges, preferably before it generates the first key (Kixt-2). Method according to one of the preceding claims, wherein the predetermined algorithm is secret for third devices. 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. Method according to one of the preceding claims, wherein the pairing takes place when establishing a peer-to-peer connection, in particular a Bluetooth connection or Bluetooth Low Energy connection. 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). 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). 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). 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. Method according to one of the preceding claims, wherein both first keys (Kixt-1, Kixt-2) are temporary keys. 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). 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. 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. 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. Method according to one of the preceding claims, wherein the first device (PD) and the second device (CD) are each a telecommunications device. A first device (CD) configured to pair with a second device (PD) via a wireless channel, wherein the first device (CD) is configured to receive information (ADV_xxx) from the second device (PD) via the channel that is characteristic of the second device (PD), wherein the first device (CD) has a predetermined algorithm for generating, based on 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, and wherein no first key (Kixt-1, Kixt-2) is exchanged. A second device (PD) configured to pair with a first device (CD) via a wireless channel, wherein the second device (PD) is configured to send information (ADV_xxx) identifying the second device (PD) to the first device (CD) via the channel, wherein the second device (PD) has a predetermined algorithm for generating, based on 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 both first keys (Kixt-1 and Kixt-2) are exactly the same, and wherein no first key (Kixt-1, Kixt-2) is exchanged. Device (CD, PD) to Claim 20 or 21 , where the predetermined algorithm is secret for third devices.

Images