Secure simple pairing bluetooth

Difference between Secure Simple Pairing and Secure Connections in Bluetooth?

I would like to know what are the differences between Secure Simple Pairing and Secure Connections in Bluetooth v4.2. Between BR/EDR legacy, BR/EDR, LE, LE legacy, I don’t get it.

Recently I stumbled on exact question, and didn’t find the answear. Did you manage to find the answear by yourself? As far as I understand this, it SEEMS to me, that Secure Simple Pairing and Secure Connections is the same, but I’m not sure.

1 Answer 1

Most answers to your questions are given in the spec Bluetooth Core, VOL1.PartA.5

Timeline

The following suites exist:

• Prior to version 2.1 => BR/EDR legacy
• Version 2.1 => BR/EDR (uses Secure Simple Pairing)
• Version 4.2 => BR/EDR (uses Secure Connections)

• Version 4.0 and 4.1 => LE legacy (uses Secure Simple Pairing)
• Version 4.2 => LE (uses Secure Connections)

Legacy

It all started with the initial security algorithms (BR/EDR legacy) for the following security features:

• pairing
• bonding
• device authentication
• message encryption
• message integrity

The algorithms used in BR/EDR legacy were not FIPS approved.

Secure Simple Pairing

This was introduced in version 2.1. Secure Simple Pairing uses FIPS-approved algorithms for pairing and message integrity and so in essence it upgraded the security of BR/EDR legacy, which is why we call this new one BR/EDR security.

Version 4.0 ported the exact same security model as BR/EDR to Low Energy (LE), with the following exceptions:

• no Numeric Comparison equivalent
• Just Works and Passkey Entry do not provide passive eavesdropping protection, because ECDH is not used in LE 4.0.

Secure Connections

In version 4.1, the Secure Connections feature was added to BR/EDR. This was an upgrade to the existing Secure Simple Pairing algorithms for pairing, device authentication, and message integrity. See table for a comparison with the Simple Pairing method for BR/EDR (not LE!):

Version 4.2 then upgraded LE as well. One of the main improvements was the adoption of ECDH for pairing. It also modified the Numeric Comparison association model to be used on Bluetooth LE. LE pairing used in 4.0 and 4.1 is since then referred to as LE Legacy. LE Secure Connections and BR/EDR Secure Connections are functionally equal.

One last word on the association methods

• Numeric Comparison protects against passive and active attacks;
• Just works protects against passive attacks IF ECDH is used, and never protects against active attacks;
• Passkey entry protects against passive attacks IF ECDH is used, and should protect against an active MITM attack (although there are some doubts about that, e.g. Padovan .
• Out Of Band security depends on the OOB method that is used.

Источник

Bluetooth Simple Pairing¶

Version 2.1 + EDR (BR/EDR) of the Bluetooth Core Specification introduced Secure Simple Pairing with four association models: Just Works, Numeric Comparision, Passkey Entry and Out Of Band. In version 4.0 the security model for Bluetooth Low Energy (LE) was added for similar association models except Numeric Comparision.

The general phases to achieve an association between two Bluetooth devices are (1) Device Discovery, (2) Bluetooth Connection, (3) Security Establishment, and (4) Device Authentication. Device Discovery can be achieved in-band or out-of-band using NFC and basically makes the Bluetooth address known to the other device. If the out-of-band communication transmitted security information, that information will then be used during Device Authentication to achieve secure pairing with protection against man-in-the-middle attacks without requiring the user to input a passkey or confirm that numeric values shown are equal.

An illustration of the Secure Simple Pairing Association Models can be found in the Bluetooth Core Specification Version 4.1, Volume 1, Part A, Section 5.2.4.5, Figure 5.2.

The data format for Bluetooth Out Of Band pairing for Bluetooth BR/EDR and Bluetooth LE is defined within the Bluetooth specification. For NFC transmission it becomes the payload of an NDEF record termed Bluetooth BR/EDR Carrier Configuration Record and Bluetooth LE Carrier Configuration Record. The NFC Forum and Bluetooth SIG Bluetooth Secure Simple Pairing using NFC Application Document contains implementation hints and recommendations on optional data elements that should be included in the out-of-band data when used with NFC.

Bluetooth BR/EDR Carrier Configuration Record

The record type is the Internet Media Type “application/vnd.bluetooth.ep.oob” and the payload is the Bluetooth BR/EDR out-of-band configuration data.

The configuration data must include the BR/EDR Bluetooth Device Address and may include any number of Extended Inquiry Response (EIR) data elements.

For negotiated connection handover both devices have the ability to transmit the Simple Pairing Hash C and Simple Pairing Randomizer R that allow the receiver to then authenticate the device during Bluetooth link setup.

Interoperability Test Requirement

The interoperability test scenarios require that Bluetooth BR/EDR Carrier Configuration data includes the Simple Pairing Hash and Randomizer if negotiated handover is performed.

The Bluetooth Device Name allows a graphical user interface to better represent the other device in informational messages that may be shown while connecting or especially if the connection could not be made (for example if the other device kept the Bluetooth radio deactivated and thus a device name could also not be learned through Bluetooth inquiry).

Interoperability Test Requirement

The interoperability test scenarios require that Bluetooth BR/EDR Carrier Configuration data includes the Bluetooth Local Name (Device Name).

Bluetooth LE Carrier Configuration Record

The record type is the Internet Media Type “application/vnd.bluetooth.le.oob” and the payload is the Bluetooth LE out-of-band configuration data.

The configuration data must include the LE Bluetooth Device Address and LE Role and may include any number of other Advertising and Scan Response Data (AD) elements.

For negotiated connection handover both devices have the ability to transmit the Temporary Key TK that allows the receiver to authenticate the device during Bluetooth link setup.

Interoperability Test Requirement

The interoperability test scenarios require that Bluetooth LE Carrier Configuration data includes the Temporary Key TK value if negotiated handover is performed.

The Bluetooth Device Name allows a graphical user interface to better represent the other device in informational messages that may be shown while connecting or especially if the connection could not be made (for example if the other device kept the Bluetooth radio deactivated and thus a device name could also not be learned through Bluetooth inquiry).

Interoperability Test Requirement

The interoperability test scenarios require that Bluetooth LE Carrier Configuration data includes the Bluetooth Local Name (Bluetooth Device Name).

List of Test Scenarios

Negotiated Handover with Bluetooth BR/EDR Device¶

1. Perform Link Activation and Establish Connection with Server
2. Send a Handover Request Message with a Bluetooth BR/EDR Carrier Configuration Record that includes the Bluetooth Device Address, Simple Pairing Hash C, Simple Pairing Randomizer R, Class of Device, Local Name and appropriate Service Class UUIDs.
3. Verify that the Device Under Test returns a Handover Select Message with a Bluetooth BR/EDR Carrier Configuration Record that includes the Bluetooth Device Address, Simple Pairing Hash C, Simple Pairing Randomizer R, Class of Device, Local Name and appropriate Service Class UUIDs.
4. Terminate Connection with Server
5. Verify that a Bluetooth connection can be made to the Device Under Test.

Negotiated Handover with Bluetooth LE Device¶

1. Perform Link Activation and Establish Connection with Server
2. Send a Handover Request Message with a Bluetooth LE Carrier Configuration Record that includes the Bluetooth Device Address, LE Role, Temporary Key TK, and Local Name.
3. Verify that the Device Under Test returns a Handover Select Message with a Bluetooth LE Carrier Configuration Record that includes the Bluetooth Device Address, LE Role, Temporary Key TK, and Local Name.
4. Terminate Connection with Server
5. Verify that a Bluetooth connection can be made to the Device Under Test.

Static Handover with Bluetooth BR/EDR Device¶

Handover Tag Format¶

1. Read the NDEF Message from the NFC Tag presented by the Device Under Test.
2. Verify that the NDEF Message is a Handover Select Message with a Bluetooth BR/EDR Carrier Configuration Record that includes the Bluetooth Device Address, Class of Device, Local Name and appropriate Service Class UUIDs.
3. Verify that a Bluetooth connection can be made to the Device Under Test.

Simplified Tag Format¶

1. Read the NDEF Message from the NFC Tag presented by the Device Under Test.
2. Verify that the NDEF Message is a single Bluetooth BR/EDR Carrier Configuration Record that includes the Bluetooth Device Address, Class of Device, Local Name and appropriate Service Class UUIDs.
3. Verify that a Bluetooth connection can be made to the Device Under Test.

Static Handover with Bluetooth LE Device¶

Handover Tag Format¶

1. Read the NDEF Message from the NFC Tag presented by the Device Under Test.
2. Verify that the NDEF Message is a Handover Select Message with a Bluetooth LE Carrier Configuration Record that includes the Bluetooth Device Address, Generic Access Profile Role, Appearance, Flags and Local Name.
3. Verify that a Bluetooth connection can be made to the Device Under Test.

Simplified Tag Format¶

1. Read the NDEF Message from the NFC Tag presented by the Device Under Test.
2. Verify that the NDEF Message is a single Bluetooth LE Carrier Configuration Record that includes the Bluetooth Device Address, Generic Access Profile Role, Appearance, Flags and Local Name.
3. Verify that a Bluetooth connection can be made to the Device Under Test.

Источник