Which data should be in advertising data package?

[Ethan]

Could you please advise me regarding BLE security?

For security purposes, UUID data shouldn't be included in the advertising data package?

If we don' t put UUID in the AD package, how can we make our advertisement distinctive since our master device scans the advertisement and pair with a right device advertising the service and account information?  

If possible to share some sample case setting up the advertising data, that would be appreciated. 

Thank you

[run_ar]

Hi,

Not sure why not advertising the UUID would improve security. Normally you would advertise the UUID so the scanner can see what kind of device you are and make an assessment on whether or not to connect. An alternative could be to advertise manufacturer specific data, or some kind of ID.

All the peripheral examples in our SDK perform advertising. So I would recommend that you take a look at them and maybe also our tutorial here: https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/ble-advertising-a-beginners-tutorial

[Ethan]

Hi, 

Thank you for your response.
I am very sorry to ask such a basic question.
My concern is what if a malicious person read the UUID, paired with it, and take some information from the device.

Since our device is collecting location data able to use for tracking and does not scan the advertisement of its master, I would like to know how the peripheral device is able to connect with the right master securely. Otherwise, anyone can connect the peripheral device. 

I think that even though we set some unique identifier like UUID on the advertising package, unless the peripheral device scans its master's advertising, we cannot confirm that these two device can be securely connected each other.

So we set predefined passkey on the device and a master device only which knows the predefined passkey can be paired with the peripheral device because our peripheral device doesn't have a display.

This is the right way to connect between a peripheral device and its master device or any other way to achieve to connect two devices?

Thank you again, 

[run_ar]

Hi,

Would it be possible for you to have a special mode where new bonds are accepted? i.e. normally you could advertise using a whitelist so you only accept connection requests from known devices. in addition you have to make sure no new bonds are allowed in this mode as an attacker can easily copy you BT address and by pass the whitelist. Then you have the special mode that accepts new bonds? Unfortunately it will be hard to implement MITM protection without a display. But do you have buttons that can be used to for LESC numeric comparison, or maybe you could consider using LESC OOB with NFC?

As for protecting characteristics you have to configure which security level is required to read a characteristic.

[Ethan]

Hi,

Here is how we would like to achieve in BLE security:
1st phase. a master device filters data a slave device advertised and confirm whether the slave device belongs to our service
2nd phase. Identify the account the slave device belongs while connecting phase
3rd phase. After established connection, pairing with predefined passkey which only the client is notified
4th phase. communication between the slave and maseter devices is permitted

In 1st phase, we think that if the advertising packets includes the service name and the manufacturer name, the master device fileters the AD packets and can confirm the slave device belongging to our service.
In 2nd phase, when the master device requests the slave device to connect, at the time the slave device can allow the master device to read UUID charateristic which identify the device account. I think that any device can read the UUID and establish the connection at this point. Here is a question, reading UUID characteristics by someone can harm the security system at this point?
In 3rd phase, we set flag for level 4 and are thinking to set a predefined key or QR code in the slave device and the key or QR code is given to only user and the client can pair two devices by using the key or QR code. Unless the predefined key or QR code got leaked, no device can fully communicate with the slave device. We believe that at this point, we can block the maricious person.
In 4th phase, finally the master can communicate with the device.

One question about LE secure connection (level 4).
When we set a flag for LE secure connection, the above 2nd and 3rd phase can be encripted?

Could you please give us your advice or any opinions for the connection process?
Thank you,
Ethan

[run_ar]

1. ok, if you have an existing bond it is also possible to use a whitelist on the peripheral.

2. Allowing someone to read the UUID's is most likely not an issue. But make sure you configure the characteristics with the correct security settings, this has to be done individually.

3. If I understand this correctly, I think that yes, you can avoid MITM by doing this.

4.ok.

Ethan said:

One question about LE secure connection (level 4).
When we set a flag for LE secure connection, the above 2nd and 3rd phase can be encripted?

No, encryption can only be enabled after the connection is established. But you can add a whitelist to avoid unwanted connection request. however the whitelist only checks the address so it does not provide any real security.