Bluetooth

for forming Wireless Personal Area Network

cable replacement for personal devices

Not intended for long-running/persistent networks

advanced and promoted by the Bluetooth Special Interest Group

IEEE standardised Bluetooth as IEEE 802.15.1

not based on other standards/technologies

Basic Rate/Enhanced Data Rate (BR/EDR) vs Bluetooth Low Energy (LE)

Maintaining backwards compatibility is a major requirement for the development of new version

ad-hoc wireless network

short-lived

limited range

moderate data rate

called a Piconet

one device is master (usually the most powerfull device)

up to 7 active slaves

slaves are polled by master to transmit data

unlimited connectionless slaves

only receive certain broadcast messages, can not send data

piconet only exists as long as the master is present

devices can chage roles

A BT device can participate in more than one Piconet at once

device has to use Time Multiplexing to switch between the Piconets

A device that is a master in one Piconet can not be a master in another Piconet

A device in more than one Piconet can theoretically be used to route traffic between the Piconets and form a so-called Scatternet

unicast connection between the master and each slave for data transmission

direct connections between slaves are NOT possible

Two broadcast “connections from master to slave

Active Slave Broadcast (ASB)

Connectionless Slave Broadcast (CSB)

Class 1: 1-100mW, approx. 100m

Class 2: 0.25-2.5mW, approx. 10m

Class 3: max. 1mW, few metres

Nominal maximum data rate is 1Mb/s for Basic Rate and 2-3Mb/s for Enhanced Data Rate

Can be much smaller when many slaves are present or interference is high (shared medium)

Time Division Duplex (TDD)

Devices maintain a clock with a frequency of 3.2kHz

Every 2 clock ticks the device hops to another frequency

master device clock is used to synchronise the traffic of all devices in the Piconet

Data is transferred as packets

A packet can be 1, 3 or 5 slots long

Master sends packets only in even slots, slaves only in odd slots

frequency hopping is disabled until the complete packet is transmitted

Master periodically polls a particular slave by sending a data or special poll packet

both devices negotiate a maximum polling interval (T poll) - the master commits to polling the slave at least once in each polling interval, possibly more often, to give the slave the opportunity for data transfer.

XOR-ing the packet bits with a pseudo-random whitening sequence, generated from the master device clock (note that this is no encryption)

intended to improve the resulting RF signal by forcing more frequent changes

Service Discovery Protocol (SDP) … Used by BT devices to query other devices for offered services

RFCOMM … Emulation of RS-232 communication via BT

BT Network Encapsulation Protocol (BNEP) … Encapsulation layer for transfer of common network protocols (IP, IPX) via BT, emulates Ethernet framing

Audio/Video Distribution Transport Protocol (AVDTP) … for streaming Audio/Video content between BT devices

OBject EXchange (OBEX) … for transfer of simple data objects between BT devices (e. g. synchronisation of calendars and phonebooks), uses RFCOMM as transport layer

Prior to v2.1: Legacy Security, considered insecure

v2.1: Replacement of Pairing procedure with more secure one but Security otherwise unchanged

v4.1: Major upgrade of Security services (Secure Connections)

Security Services

Key management: establishment of shared secrets between devices via Pairing procedure

Authentication: allows a device to prove its identity to another device, no auth. for services or users

Confidentiality: Encryption of BT packet payload

Integrity: Protection of packet header and payload, since v4.1

All security services in BT rely on a shared secret, the Link Key

128-bit random number

when known by other the security is completly comprimised

devices must agree on a common Link key

Link key is derived dynamically during pairing

pre v2.1

Link Key is based on a PIN number

length of the PIN depends on the devices and their configuration, and can range from 1 to 16 byte (8-128 bit)

The user must enter the same PIN on both devices prior/during the pairing

two steps

1. Initialisation Key Kinit is created Once pairing is performed, Kinit is no longer needed and is discarded

2. actual Link Key is agreed between the paired devicestwo possible procedures:

   1. Unit Key

   2. Combination Key

Create Initialisation Key

initator generates a 128 bit random number

sends number to responder

if a static PIN is configured at the responder an alternative random number is generated otherwise the initators is accepted

both devices calculate the initialisation key using the E22 algorithm

input: PIN

addresses of the devices with user-entered PIN

accepted random number

Create Link Key

two ways

1. Unit Key of one device

   1. generated at manufacturing and hardcoded into the device

   2. specifications is against using as once know every future pairing is compromised

2. Combination Key

   1. derived from random values generated by the devices

   2. recommended

Unit Key is XOR-ed with Kinit

Result is sent to other deice

receiver recovers clear text by XOR-ing cipher with Kinit

Link Key: Unit Key of master or device that dit not send the Combination Key Half

Only used when both devices use a combination key

each device gnerates a random number

calulates a Combination Key Half with the E21 alorithm using the random number and the bluetooth address

calculates the secret by XOR-ing Combination Key Half and Kinit

sends secret to other half

receiver deciphers random number and recalulates the combination Key Half of the other device

Combination Key is calculated by XOR-ing the Combination Key Halfs

Depends solely on the PIN

eavesdropper during pairing only needs to brut force the PIN

To have adequat security:

1. PIN has the maximum length of 128 bit

2. each pairing has to use a different PIN

response to problems of Legacy Pairing

no user endtered PIN

PIN is created for each pairing attemt

Key generation is based on asymetric cryptography

two parts

1. Basic procedure that offers protection from passive eavesdropping

2. one of four different protocols after key exchange to protect from M-i-M attack

IO Capabilities Exchange

both devices exchange their input and output capabilities

input: only yes/no or digits

output: can device display at least 6 digits

Has deivce ability to Out of Band Data?

Public Key Exchange

Elliptic Curve Diffie-Hellman (ECDH) key agreement to create the common Link Key

ECDH is a variant of classical Diffie-Hellman which uses Elliptic Curves and was chosen because it is more efficient (shorter keys)

Devices prior to v4.1 use P-192 elliptic curves, devices which support Secure Connections can use P-256 for higher security

Both devices calculate a Public/Private Key Pair from the elliptic curve

Send public Key to other device in clear

both calculate the common link key by combining private key and received public key

Authentication Stage 1

ECDH only offers protection from a passive eavesdropper

However, an active attacker (Man-in-the-Middle, MITM) can simply exchange own Public Keys with both devices to insert in the message transfer

SSP uses one of four different protocols to authenticate the Public Key values exchanged in the prior step, the choice depends on the IO Capabilities

In general, the following decision procedure is used:

1. If at least one device indicated that OOB data is available, OOB (Out Of Band) is used

2. When both devices have a display and a yes/no input, Numeric Comparison is used

3. When one device has only a display and the other device has only a keyboard for entering digits or when both devices have keyboards, Passkey Entry is used

4. When neither device has IO Capabilities, Just Works is used

Both devices show a randomly generated 6-digit number on their displays the user has to confirm that both devices show the same number

1. Both devices generate a 128-bit random number

2. B calculates the Commitment Value using a nonlinear alorithm (HMAC-SHA256) with own random number and both public key values

3. B sends Commitment Value to A

4. Devices exchange random values in clear text

5. A calulates the commitment value

6. Both devices calculate the confirmation value using SHA-256 with random numbers and public keys as input

7. both devices display the least significant bits as 6 decimal digits

One device displays a random number which the user has to enter on the other device OR user has to enter the same number at both devices (when no device has a display)

1. One device displays random k-bit Passkey, Passkey is entered into other device or user enters Passkey at both devices

2. For each bit of the Passkey

   1. A generates a 128 bit random number

   2. calculates a Commitment Value with bit, random number and public keys

   3. B does the same

3. devices exchange their commitment values

4. both devices calculate the other commitment value and calculate the commitment value

5. both devices compare the commitment values

For devices without IO Capabilities

The procedure is identical to Numeric Comparison, without the confirmation step

Either the user is asked for confirmation without showing any values or the equality of VA and VB is simply assumed and the pairing continues

Public Key values are authenticated over a separate Out Of Band (OOB) channel

1. Both generate a random number and calculate a commitment value with random number and own publich key as input

2. exchange of commitment value OOB

3. Both calculate a commitment value from the random number and the public key of the other device and compares it to the OOB received one

   
   

Authentication Stage 2

information exchanged in all prior steps is confirmed in a separate step

1. both calculate a confirmation value using HMAC-SHA-256 with DHKey from step 2 and random numbers from step 3

2. both send their values to the other

3. both compute the other value

4. both compare their computed with received ione

Link Key Calculation

generation of the actual Link Key that will be used between the devices

using HMAC-SHA-256 with DHKey from step 2, random number from step 3 and the bluetooth addresses of both devices

only secret value is DHKey

resilient against passive eavesdropping

Most values exchanged are strong hashes of the actual important values

Protection from a MITM:

1. When Just Works is used, no protection is given

2. All other protocols authenticate the Public Key values and differ only in their usability

The most important difference to Legacy Pairing is, that the Security does not depend on user-generated values