Note: This KBA has been marked as deprecated. A more updated KBA can be found here:
OOB example
Introduction of OOB
Below is the description of Out of Band from BLUETOOTH SPECIFICATION Version 5.0 | Vol 1, Part A, 5.2.4.3
The Out of Band (OOB) association model is primarily designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process. In order to be effective from a security point of view, the Out of Band channel should provide different properties in terms of security compared to the Bluetooth radio channel. The Out of Band channel should be resistant to MITM attacks. If it is not, security may be compromised during authentication.
The user's experience differs a bit depending on the Out of Band mechanism. As an example, with a Near Field Communication (NFC) solution, the user(s) will initially touch the two devices together, and is given the option to pair the first device with the other device. If "yes" is entered, the pairing is successful. This is a single touch experience where the exchanged information is used in both devices. The information exchanged includes discovery information (such as the Bluetooth Device Address) as well as cryptographic information. One of the devices will use a Bluetooth Device Address to establish a connection with the other device. The rest of the exchanged information is used during authentication.
The OOB mechanism may be implemented as either read only or read/write. If one side is read only, a one-way authentication is performed. If both sides are read/write, a two-way authentication is performed.
The OOB protocol is selected only when the pairing process has been activated by previous OOB exchange of information and one (or both) of the device(s) gives OOB as the IO capabilities. The protocol uses the information which has been exchanged and simply asks the user to confirm connection.
The OOB association model supports any OOB mechanism where cryptographic information and the Bluetooth Device Address can be exchanged. The OOB association model does not support a solution where the user has activated a Bluetooth connection and would like to use OOB for authentication only.
Environments
- IDE – Simplicity Studio 4
- Software – Bluetooth SDK 2.7.0
- Hardware – BRD4104a Rev A00 * 2
- Tools – Serial terminal
- Baud rate: 115200
- Data bits: 8
- Stop bit: 1
- Flow control: False
Purpose of the example
There are 2 OOB pairing modes, one is OOB with legacy pairing and the other is OOB with secure connection pairing. This example implements both modes for user’s reference.
There are 2 projects in the example, implementing the central and peripheral rolls.
Central
- It’s the master roll of the connection
- Implements the GATT client
- It sends the write request to the server every 3 seconds and receives the notification from server side.
Peripheral
- It’s the slave roll of the connection
- Implements the GATT server, there are 1 service containing 2 characteristics
- Notification characteristic – the property of this characteristic is “notify”, which doesn’t require authentication.
- Write characteristic – the property of this characteristic is “Authenticated write”, which requires authenticated connection to write value to this characteristic.
- It sends notification to the client every 3 seconds and receives write request from the client.
Due to the different property of these two characteristics, if the pairing and bonding procedure succeeds, the client will receive notifications and the server will receive write requests. Otherwise if pairing and bonding procedure fails, the client should not be able to write the characteristic value due to unauthenticated connection, but it should be able to receive notifications because it doesn’t require authentication.
Key points of the example
In both projects, there is a symbol definition - PAIRING_MODE, it can either be LEGACY_PAIRING or SECURE_CONNECTION_PAIRING. This symbol determines which pairing mode will be used in the connection.
#define LEGACY_PAIRING 1
#define SECURE_CONNECTION_PAIRING 2
#define PAIRING_MODE SECURE_CONNECTION_PAIRING
- Behaviors of both roll
- Central – It scans for the advertisement containing the service UUID “4880c12c-fdcb-4077-8920-a150d7f9b907”, and establish connection if found. After connection, go through the pairing and bonding procedure, discover services and characteristics. Send write request to the peer device every 3 seconds after the specified characteristic is found. Enable CCC of the specified characteristic the peer device to enable notifications.
- Peripheral – It won’t start advertising after boot until it receives the OOB data from the serial terminal. For OOB with legacy pairing, the OOB data is 16-byte length, for OOB with secure connection pairing, the length is 32-byte, containing 16-byte OOB data and 16-byte confirm value. It will go through the pairing and bonding procedure after connection established with the central device, and send notifications to central every 3 seconds after CCC is enabled by the central device.
Test the example
As shown above, the example requires 2 devices (BRD4104a Rev A00) and serial terminal, VCOM has been enabled in the example, so the serial print information will go out from the USB cable.
Central device (#D1) – the device programmed with the project “KBA_oob_central”.
Peripheral device (#D2) - the device programmed with the project “KBA_oob_peripheral”.
Serial terminal (#S1) connected to central device.
Serial terminal (#S2) connected to peripheral device.
Test process
- Power on both devices (#D1 and #D2) by the USB cable.
- Open the serial terminals connected to both device, the port name should be “JLink CDC UART Port (COMxx)”.
- Recognize which serial terminal connects to #D1 and which connects to #D2 by the print information after boot. Enter the right OOB data shown on #S1 to #S2. #D2 should start advertising if it receives enough length of data.
- #D1 will connect and start pairing and bonding to #D2 automatically.
- Below are 4 different test results
- Figure 1 shows what happened if right OOB data was input while using the legacy pairing mode. Both sides can receive the GATT data from the remote peer device.
- Figure 2 shows what happened if wrong OOB data was input while using the legacy pairing mode. Only the notification can be received, the write characteristic can’t be written because of unauthenticated connection.
- Figure 3 shows what happened if right OOB data was input while using the secure connection pairing mode. Both sides can receive the GATT data from the remote peer device.
- Figure 2 shows what happened if wrong OOB data was input while using the secure connection pairing mode. Only the notification can be received, the write characteristic can’t be written because of unauthenticated connection.
Figure 1. OOB with legacy pairing succeed
Figure 2. OOB with legacy pairing failed
Figure 3. OOB with Secure Connection pairing succeed
Figure 4. OOB with Secure Connection pairing failed
[Deprecated] KBA_BT_1106: OOB introduction and example
Note: This KBA has been marked as deprecated. A more updated KBA can be found here:
OOB example
Introduction of OOB
Below is the description of Out of Band from BLUETOOTH SPECIFICATION Version 5.0 | Vol 1, Part A, 5.2.4.3
Environments
Purpose of the example
There are 2 OOB pairing modes, one is OOB with legacy pairing and the other is OOB with secure connection pairing. This example implements both modes for user’s reference.
There are 2 projects in the example, implementing the central and peripheral rolls.
Central
Peripheral
Due to the different property of these two characteristics, if the pairing and bonding procedure succeeds, the client will receive notifications and the server will receive write requests. Otherwise if pairing and bonding procedure fails, the client should not be able to write the characteristic value due to unauthenticated connection, but it should be able to receive notifications because it doesn’t require authentication.
Key points of the example
In both projects, there is a symbol definition - PAIRING_MODE, it can either be LEGACY_PAIRING or SECURE_CONNECTION_PAIRING. This symbol determines which pairing mode will be used in the connection.
Test the example
As shown above, the example requires 2 devices (BRD4104a Rev A00) and serial terminal, VCOM has been enabled in the example, so the serial print information will go out from the USB cable.
Central device (#D1) – the device programmed with the project “KBA_oob_central”.
Peripheral device (#D2) - the device programmed with the project “KBA_oob_peripheral”.
Serial terminal (#S1) connected to central device.
Serial terminal (#S2) connected to peripheral device.
Test process
Figure 1. OOB with legacy pairing succeed
Figure 2. OOB with legacy pairing failed
Figure 3. OOB with Secure Connection pairing succeed
Figure 4. OOB with Secure Connection pairing failed
Hello Mr Kevin Fu,
This article is really helpful for me.
I have question about using function gecko_cmd_sm_use_sc_oob.
I want to renew oob data for each new connection, so I put gecko_cmd_sm_use_sc_oob in the gecko_evt_le_connection_closed_id event block.
gecko_cmd_sm_use_sc_oob returns success for the only first time, after that every call of gecko_cmd_sm_use_sc_oob return fail.
Is it impossbile to renew oob data/confirmdata unless I reset the device?