Start advertising when NFC field is sensed

[yes]

Hi,

We implement oob pairing using NFC.

According to my knowledge NFC is used as "private" advertising channel (this is what OOB  means) i.e. peripheral address, encryption initial keys etc. are transmitted via NFC instead of broadcasting them via 2.4GHz (BLE).

The central device extracts peripheral address from NFC message ("tag") according to NDEF format and sends connection request.

I reviewed ble_nfc_pairing_reference example code from SDK 15.2.

In nfc_callback function (file: nfc_ble_pir_lib.c) if NFC_T2T_EVENT_FIELD_ON event is detected it calls ble_advertising_start (line 184)

What do I miss?

Thanks in advance

[Marjeris Romero]

Hi,

From the nRF SDK documentation library about the BLE Pairing using NFC peripheral reference example, here:

The application does not start advertising immediately, but only when the NFC tag is read by an NFC polling device, for example a smartphone or a tablet with NFC support. The message that the tag sends to the NFC device contains data required to initiate pairing. To start the NFC data transfer, the NFC device must touch the NFC antenna that is connected to the nRF52 Development Kit.

After reading the tag, the device can pair with the nRF52 device which is advertising. Connection state of the device is signalled by LEDs. When the connection is lost due to timeout, the library automatically triggers direct advertising.

Best Regards,

Marjeris

[yes]

Following above discussion thread, it seems that Nordic's implementation doesn't follows BT specification "The Out of Band channel should be resistant to MITM attacks.".

First of all according to below quote from BT specification there should be a way to pair via NFC only (2 way authentication).

Moreover, seems that public key and confirmation value which are transferred by the server (one way authentication) doesn't used for pairing or transmitted again during consecutive advertising/pairing.    

We did a few experiments and succeed to establish connection during advertising (which was initiated by NFC "field on" event)   by different client device (MITM) despite NFC pairing mode was set to     NFC_PAIRING_MODE_LESC_OOB,          /**< LESC pairing with OOB authentication data. */

[Marjeris Romero]

Hi yerry,

I am not sure I understand your problem here yet, maybe you should explain a bit more about which security threats you are facing or worried about?

You said you are able to connect with a different client to the BLE NFC peripheral when it starts advertising when the NFC field is sensed, but this is not what MITM protection is about.

MITM protection is only enforced during pairing. If you are worried about other 3rd party central device being able to connect to your BLE peripheral you should use whitelisting to restrict connections from non-paired devices.

And unfortunately there is no way to connect two BLE devices without advertising. This document from the NFC forum "Bluetooth Secure Simple Pairing Using NFC" describes how NFC is use to simplify the discovery process by providing the Bluetooth address, which removes the need for the user to select the appropiate device from a long list of advertising devices, but advertising is still used in the connection and pairing process. But I don't see why this should be a problem.

Best Regards,

Marjeris

 

 

[yes]

Marjeris Romero said:

MITM protection is only enforced during pairing. If you are worried about other 3rd party central device being able to connect to your BLE peripheral you should use whitelisting to restrict connections from non-paired devices

According to BT specification as I quoted above '2 ways' NFC data exchange should replace the BLE pairing process. Nevertheless we use NFC 'one way' i.e. only peripheral device (tag) passes its address and encryption data via NFC to central and not vice versa.

Therefore, we can't use whitelist because the NFC central device address is not recognized by the peripheral. The address and encryption data is used by the central for sending connection request.

This is also the reason we can't use direct advertising.

During our experiments we prevent the central from sending connection request and succeed to establish connection by another central which observed the peripheral from the advertising which was initiated by NFC field on event.

The NFC was configured to NFC_PAIRING_MODE_LESC_OOB mode.

I expected that using NFC as OOB channel shall prevent this scenario. 

1) The advertising as part of NFC field on event is redundant because the advertising data is transmitted to central via NFC i.e the server should move to advertising state without broadcasting.

2) If advertising is mandatory at least it shall omit encryption data so any other observers could not connect.

If I shall force omitting encryption data from broadcasted advertising data as part of start advertising call , can it prevent other connections?

Thanks in advance  

[Marjeris Romero]

Hi,

Sorry for the confusion. The NFC peripheral can only act as a tag, not a NFC reader (cannot generate a field) so a 2-way data exchange is not supported as you stated above. But still I am not sure if a 2-two ways OOB would mean that the devices will paired without advertising, to my knowledge there is no way to connect two BLE devices without advertising.

yes said:

During our experiments we prevent the central from sending connection request and succeed to establish connection by another central which observed the peripheral from the advertising which was initiated by NFC field on event.

Is this a concern? Regardless of the connection request by another central, the peripheral won't be able to pair and raise the security level to 4 with this new client (when using LESC OOB pairing).

yes said:

1) The advertising as part of NFC field on event is redundant because the advertising data is transmitted to central via NFC i.e the server should move to advertising state without broadcasting.

NFC only simplifies the discovery process by providing the Bluetooth address and other optional parameters related to the specific device. In order to establish a BLE connection between two devices a peripheral device needs to start a connectable advertising, see the connection establishment message sequence chart here.

 

yes said:

2) If advertising is mandatory at least it shall omit encryption data so any other observers could not connect.

Not sure what you mean here. There is no need of any "encryption data" for two devices to connect to each other. But connections do not offer any form for security. When you wish to do something that requires security, lets say access a data value (a characteristic) that requires authenticated access, then you will need to first pair the devices in order to do so.

There are 2 data types relevant for LESC OOB pairing that are encoded in the NFC tag using the advertising data format: BLE_GAP_AD_TYPE_LESC_CONFIRMATION_VALUE and BLE_GAP_AD_TYPE_LESC_RANDOM_VALUE. These values are not keys but are relevant for pairing process and are used to authenticate the connected peer during pairing procedure.

Again it may help if you can explain a bit more about how your devices are going to interact with each other and I may be able to point you better in the right direction. I can see two use cases here but I am not sure about what you are aiming for.

1) You can use LESC OOB pairing with the central the user wants to use, then use whitelist so other centrals are unable to send connection request to the peripheral. Only the authenticated central will have access to read and write the secure characteristics of the peripheral.

2) If your goal is to develop a device that is pre-bonded, you could also use a pre-programmed static passkey. Try searching for "static key bonding" in this forum and you will find some cases that examplifies this method.

Best Regards,

Marjeris