• State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 62 subscribers
  • Views 25087 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 110771
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

irk as the only security perimeter

Stanislav Silnitskiy

Hello, Nordic!

In our entertainment project, nrf51 based devices exclusively utilizes either central or periph. role. All of them are headless (body mounted markers, etc). The environment is hostile (in the sense, that some cheater could spoof device address, advertising it as valid periph.) Besides, we don't need a connection at all, and wish to relay upon pre-shared set of IRKs, belonging to peripherals. What we need is just RSSI and some extra info in advert.

Is it right case to use private addresses for? If so, which API does sdk provide to hash/rehash the address in central and how IRK is being set in peripheral?

I tend to use S130 and if it is redudant for scenario explained, I'd appreciated an advice.

Stan

Parents
  • 0

    Hi Stan,

    It's possible to distribute the IRKs in advance and use the IRK to generate Random resolvable private address on each of the advertiser. It's supported by our softdevices (S110, S120, S130), please have a look in the description of the sd_ble_gap_address_set() function to know how you can tell the softdevice to use Random resolvable address, when to generate new one. And to the sd_ble_opt_set() ( and ble_gap_opt_t ->ble_gap_opt_privacy_t) to know how to set the IRK.

    I just want to know how you would deal with the attacker that can spoof the device address ? Even if you use resolvable random address and can change it periodically, the attacker can still simply copy the new address and spoof it when you update your address.

    Some little more on the security requirement and the implementation of your application would give better understanding.

  • 0 in reply to Hung Bui

    right question! I think to replace a random salt by incremental space, keeping track of lastly used address on central device. As soon as the solution is intended to be used limited time (2-3 hours session), it may work... I realize, that this decreases the security, though.

    Again, to balance drawback of above, an array of per-peripherial IRK could be used, those changed every 1000 address or so...

    Do I understand it right, that to check received address in central, I will use consequent calls of sd_ble_gap_address_set and sd_ble_gap_address_get for every pre-shared IPK?

Reply
  • 0 in reply to Hung Bui

    right question! I think to replace a random salt by incremental space, keeping track of lastly used address on central device. As soon as the solution is intended to be used limited time (2-3 hours session), it may work... I realize, that this decreases the security, though.

    Again, to balance drawback of above, an array of per-peripherial IRK could be used, those changed every 1000 address or so...

    Do I understand it right, that to check received address in central, I will use consequent calls of sd_ble_gap_address_set and sd_ble_gap_address_get for every pre-shared IPK?

Children
No Data
Related