BLE security question

[Terutaka Takeuji]

Nice to meet you, I am an engineer living in Japan.

【Development environment】
"PCA10040 (nRF52832)" x 2 (center/periphery)
"SDK: 17.1.0"
"IDE: Segger Embedded Studio for ARM7.10a"

I have a question about BLE security.
I built a test environment using "PCA10040" for the central and peripheral, and tried simple communication.

I installed an app called "BLE Scanner" on my smartphone.
When I started the app, the device name advertised by the peripheral device was displayed, so when I clicked the "Connect" button, I was able to connect to the peripheral device from "BLE Scanner".

I don't want to connect my smartphone to a peripheral without entering a "password" or "passkey", so I want to increase security.

It turns out that there are four methods for authentication processing of BLE Central and Peripheral: "Just Works", "Passkey Entry", "Numeric comparison", and "Out Of Band".
I think that "Just Works" is good for this product because it is communication between devices without a screen.

question)
Please tell me the sample program of the authentication method using "Just Works".

It would be helpful if you could tell me the program code.
If there is any other better way, please let me know.

[Vidar Berg]

Hello,

I suggest you try the Heart Rate sensor and BLE Heart Rate Collector Example. These examples support LE secure connections pairing with Just works which provides protection against passive eavesdropping (i.e. BT sniffers). Just remember to increase the security level of your Bluetooth characteristics to limit access to paired clients only. 

Increasing the security levels of the Bluetooth characteristics in the heart rate example:

diff --git a/main.c b/main.c
index cc98734..9434a82 100644
--- a/main.c
+++ b/main.c
@@ -493,8 +493,8 @@ static void services_init(void)
     hrs_init.p_body_sensor_location      = &body_sensor_location;
 
     // Here the sec level for the Heart Rate Service can be changed/increased.
-    hrs_init.hrm_cccd_wr_sec = SEC_OPEN;
-    hrs_init.bsl_rd_sec      = SEC_OPEN;
+    hrs_init.hrm_cccd_wr_sec = SEC_JUST_WORKS;
+    hrs_init.bsl_rd_sec      = SEC_JUST_WORKS;
 
     err_code = ble_hrs_init(&m_hrs, &hrs_init);
     APP_ERROR_CHECK(err_code);
@@ -508,9 +508,9 @@ static void services_init(void)
     bas_init.initial_batt_level   = 100;
 
     // Here the sec level for the Battery Service can be changed/increased.
-    bas_init.bl_rd_sec        = SEC_OPEN;
-    bas_init.bl_cccd_wr_sec   = SEC_OPEN;
-    bas_init.bl_report_rd_sec = SEC_OPEN;
+    bas_init.bl_rd_sec        = SEC_JUST_WORKS;
+    bas_init.bl_cccd_wr_sec   = SEC_JUST_WORKS;
+    bas_init.bl_report_rd_sec = SEC_JUST_WORKS;
 
     err_code = ble_bas_init(&m_bas, &bas_init);
     APP_ERROR_CHECK(err_code);

Best regards,

Vidar

[Terutaka Takeuji]

Thank you for your answer.

I will check the security operation with the sample program you gave me.

[Terutaka Takeuji]

Sorry for the late reply.
Based on the sample program and advice that you gave me last week
I have checked the operation.

Sample program used)
Central “ble_app_hrs_c”
Peripheral “ble_app_hrs”

I have confirmed that the build was successful and it is working.
As a result, I understood as follows.

I understand that "LE Secure Connections" is a technique for encrypting the communication after pairing is successful and making it safe, and does not determine whether the connection is possible or not by identifying the other party at the time of connection.

Is the above understanding correct?

question)
I would like to use a private key at the connection stage to allow connections only from a specific central. Is there a way to do that?
If it is technically possible, I would like to receive a sample program or program code.

Thank you.

[Vidar Berg]

You can advertise with a whitelist like we do in the BLE HID examples to only allow known peers to establish a connection with your device. 

[Terutaka Takeuji]

Thank you for your answer.

The problem this time is that an external smartphone is connected to the peripheral, which is a product.
Therefore, it is necessary to deny external smartphone connections from the product's peripherals.

I understand that connection refusal using a whitelist is a setting on the central side.

Please let me know if there is a way to deny connections from devices including smartphones from the peripheral side.

Thank you.

[Vidar Berg]

If you advertise with a whitelist, as in the HID examples, the peripheral will reject connection requests from devices that have not been added to the whitelist.

[Terutaka Takeuji]

Mr. Vidar
Sorry for the late reply.

I built "ble_app_hids_keyboard" as the HID sample program you taught me, and analyzed its operation and program.

As a result, as Mr. Emil said, we were always able to connect the first time, and it was not possible to achieve the security provided by a common password as I had thought.

I have never seen a device that requires a password to be entered in the Bluetooth products I use, such as mice and speakers, so I think this is due to the design philosophy of the Bluetooth connection.
Therefore, I felt that the idea was to make it easy to connect to devices, but to ensure security by encrypting communication.

Based on the verification so far, I believe that security using a common password is not possible with BLE, but when verifying the whitelist, I could not understand what purpose the whitelist was used for.

last question)
Please tell me the purpose and benefits of using a whitelist for peripherals. It will be easier to understand if you explain the usage case.

[Vidar Berg]

Hi,

The HID example initially starts advertising without a whitelist, as it doesn't have any bonded peers to populate the list with. As a result, any GAP Central can connect and pair with your device. However, this behavior is only for the first connection. Subsequent advertising sessions will use a whitelist, populated with device addresses from the bond table.

You can test this by using two different GAP central devices:

1. Connect and pair with your first device. Then terminate the connection. 

2. The peripheral will be advertising with a whitelist containing the address of the first device at this point.

3. Try to connect your second device and observe that the connection request will be rejected.