irk as the only security perimeter

RE: irk as the only security perimeter

Stanislav Silnitskiy — Sat, 12 Dec 2015 14:19:44 GMT

Is it possible to distinguish which IRK the address from recent received adv. packet belongs to? For the scenario, there are a several IRKs in use be infrastructure of beacons?

RE: irk as the only security perimeter

Stanislav Silnitskiy — Fri, 11 Dec 2015 12:12:19 GMT

Hi Hung, do I understand right, that IRK infrastructure implemented at hardware level?

RE: irk as the only security perimeter

Hung Bui — Fri, 11 Dec 2015 12:03:29 GMT

Hi Stan, Yes, it's possible to use the IRK as the whitelist for the scanner (with the limit of 8 IRK at a time as mentioned).

RE: irk as the only security perimeter

Stanislav Silnitskiy — Thu, 10 Dec 2015 16:44:37 GMT

OK! thank you very much for opposing my ideas, I will consider it in implementation! Indeed, the answer for initial question (is using IRK fits proposed scenario?) has to be negative, I suppose.

RE: irk as the only security perimeter

Hung Bui — Thu, 10 Dec 2015 16:20:24 GMT

Hi Stan,

You can apply a white list when doing scanning. It's inside ble_gap_scan_params_t when calling sd_ble_gap_scan_start.

But we don't support too many IRKs in the whitelist at a time, max 8 I believe. The stack will handle the resolving and only advertising packet from advertiser with correct IRK will be notify to the application. If you want more you may need to handle the address solving in the application.

What you described may work. My only concern is that it only work if all packets are received correctly to the scanner. If the attacker jam the signal, and then use the old address(es) (that the scanner couldn't receive) and advertise with modified data, then you may have a trouble.

What about keeping the address fixed, but encrypting your advertising data instead of the address ?

RE: irk as the only security perimeter

Stanislav Silnitskiy — Thu, 10 Dec 2015 13:41:06 GMT

... So, from client's point of view, it will receive broadcasts with incremental "random" part and will keep track of expired addresses pretty straightforward. Every 1000th address periph. takes the next IRK from available (and pre-shared with clients) list and generates next 1000 addresses using a new IRK. The client sees, that "random" part of address has reached 1000 and expires previously used IRK.

RE: irk as the only security perimeter

Stanislav Silnitskiy — Thu, 10 Dec 2015 13:34:42 GMT

Yes, I understand that I need to extract the address from received advert. packet. I mean how to check this address?

As for spoofing I see the following infrastructure:

Each peripheral has an array of IRKs, those shared with all clients (centrals). All IRKs are uniq across all perihps. When periph. starts advertising, it generates next address (the hash, as per spec.) from its first IRK and 0x1 in place of random part, so the broadcasted address has a form (24bit hash) || (0x1). The next address will be generated with 0x2 as a random part and so on... The new address will be generated for every Nth second of operation or, if not a performance issue, for every advert. packet.

RE: irk as the only security perimeter

Hung Bui — Thu, 10 Dec 2015 13:14:02 GMT

@Stan: No, you can get the device address when you receive the advertising packet (BLE_GAP_EVT_ADV_REPORT event) . It's in peer_addr in ble_gap_evt_adv_report_t struct.

I still don't know how you can avoid address spoofing with the IRK. Note that 2 devices with same address can still advertise at the same time without causing interference.

RE: irk as the only security perimeter

Stanislav Silnitskiy — Thu, 10 Dec 2015 12:33:11 GMT

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?

RE: irk as the only security perimeter

Hung Bui — Thu, 10 Dec 2015 10:33:01 GMT

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.