• State Verified Answer
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 1482 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 109760
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DoS immunity at general advertising mode

Valer_I

Hello,

My question based on case, I've experienced recently. nRF device that could advertise in general mode for limited time by pressing on button and continuously in whitelist mode after bonding. The windows was paired with this device before. I pressed button to run general advertising mode to bond with another central (i.e. Android tablet). But Windows connect the device once it detect advertisment from address of my device and I simply can't catch the connection by tablet. I know that this problem extincts if use IRK, but is there any solution for static address?
ADDED: I also found this thread link with the same problem. At present the only solution I found is to decrease TX power to minimum during general advertisement. However it looks like workaround.

Parents
  • 0

    Hi Valer,

    It's true that it could be a risk that we can be DoS attacked by attacker by do continuous scanning and sending connect request.

    Unfortunately, with the current Bluetooth stack, we don't have a way to do a blacklist advertising to avoid being connected by a central device (the attacker can spoof and change the address of the central device anyway).

    Your solution to reduce the TxPower sounds like a good idea. You can set that mode so that the first connection and bond should be performed with short distance.

    Another solution is that you do non-connectable advertising at the beginning then you do active scanning from the central device you want to connect to. The previously bonded device will also do active scanning but you should be able to detect him. By having active scan, you should be able to find the address of the new device you want to allow connection.

    Then you can start advertising with whitelist for only the specific device. This way you can block the connect request from the other device. However, it won't help if the previously device keep sending connect request on every single advertising packet (jamming the connection).

    So, what you proposed is a proper workaround.

Reply
  • 0

    Hi Valer,

    It's true that it could be a risk that we can be DoS attacked by attacker by do continuous scanning and sending connect request.

    Unfortunately, with the current Bluetooth stack, we don't have a way to do a blacklist advertising to avoid being connected by a central device (the attacker can spoof and change the address of the central device anyway).

    Your solution to reduce the TxPower sounds like a good idea. You can set that mode so that the first connection and bond should be performed with short distance.

    Another solution is that you do non-connectable advertising at the beginning then you do active scanning from the central device you want to connect to. The previously bonded device will also do active scanning but you should be able to detect him. By having active scan, you should be able to find the address of the new device you want to allow connection.

    Then you can start advertising with whitelist for only the specific device. This way you can block the connect request from the other device. However, it won't help if the previously device keep sending connect request on every single advertising packet (jamming the connection).

    So, what you proposed is a proper workaround.

Children
No Data
Related
Terms of service