• State Verified Answer
  • Replies 11 replies
  • Subscribers 76 subscribers
  • Views 1685 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 313269
Options

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.

Parents
  • 0

    Sorry, but Bluetooth does not offer a standardised way to fully protect a device using a pre-defined "password". You need to implement PAKE (en.m.wikipedia.org/.../Password-authenticated_key_agreement), e.g. SPAKE2+ or similar in that case, just like Matter does, at the application layer yourself.

    This PAKE must run after the connection has been established. Note that there is a difference between disallowing connections to be established and granting permissions to a access a service during an ongoing connection. Except for certain denial-of-service scenarios, it's usually not any problem, security wise, to accept any connection. What you want to protect is access to data while connected, which is where you should put your effort securing.

    The filter accept list (previously known as white list) on a peripheral can be used to accept incoming connections only from previously known peers, but security wise is quite weak since a Bluetooth address can easily be spoofed. It's more like a firewall that drops packets from unknown sender addresses. It also obviously does not work at the first connection, since the peripheral at this point doesn't know the address of the central. Note that the filter accept list is often combined with requiring encryption to access services once the connection has been set up, but as explained earlier, Bluetooth does not implement a way to pair/bond using a pre-defined "password".

    If your application consists of two nRF devices (central and peripheral) that you can both pre-configure e.g. at the factory, then you could pre-bond them, i.e. pre-program the same random LTK at both devices, as well as set up the filter accept list to only accept the other device's address (which you know beforehand). Then require encryption for every service you have and disallow any incoming pairing requests. That would be a secure solution that would block any unwanted connections, as well as preventing spoofed devices to access your services in case an attacker manages to connect using a spoofed address.

Reply
  • 0

    Sorry, but Bluetooth does not offer a standardised way to fully protect a device using a pre-defined "password". You need to implement PAKE (en.m.wikipedia.org/.../Password-authenticated_key_agreement), e.g. SPAKE2+ or similar in that case, just like Matter does, at the application layer yourself.

    This PAKE must run after the connection has been established. Note that there is a difference between disallowing connections to be established and granting permissions to a access a service during an ongoing connection. Except for certain denial-of-service scenarios, it's usually not any problem, security wise, to accept any connection. What you want to protect is access to data while connected, which is where you should put your effort securing.

    The filter accept list (previously known as white list) on a peripheral can be used to accept incoming connections only from previously known peers, but security wise is quite weak since a Bluetooth address can easily be spoofed. It's more like a firewall that drops packets from unknown sender addresses. It also obviously does not work at the first connection, since the peripheral at this point doesn't know the address of the central. Note that the filter accept list is often combined with requiring encryption to access services once the connection has been set up, but as explained earlier, Bluetooth does not implement a way to pair/bond using a pre-defined "password".

    If your application consists of two nRF devices (central and peripheral) that you can both pre-configure e.g. at the factory, then you could pre-bond them, i.e. pre-program the same random LTK at both devices, as well as set up the filter accept list to only accept the other device's address (which you know beforehand). Then require encryption for every service you have and disallow any incoming pairing requests. That would be a secure solution that would block any unwanted connections, as well as preventing spoofed devices to access your services in case an attacker manages to connect using a spoofed address.

Children
  • +1 in reply to Emil Lenngren

    Emil, thank you for your reply.

    I understood that the standard functionality of BLE does not implement a way to reject connections using a predefined "password".

    I couldn't find any articles on the Internet, so I thought that passwords could not be used to strengthen security.
    Even if a whitelist can be set for peripherals, it is difficult to use with this product because the central can only be identified by "physical address," "UUID," and "device name."

    When shipped from the factory, they are shipped as a specific pair, but because the connection destination may be manually changed later due to malfunction, etc., identification by "physical address" is not possible.

    I've never used peripheral whitelisting, so I'll look into it a bit more.

    Thank you for your reply.

  • 0 in reply to Emil Lenngren

    Hi Emil. Is there any example for this solution which you mentioned at the last paragraph? I couldn't find any reference on SDK about this solution.

Related
Terms of service