Multiple token generation on the BLE media

[Matioupi]

Hello,

have you done any assessments / tests about the way to handle the diffie-hellman meeting token generation on the BLE advertising channels (is this still the RF channels we are talking about ?).

Only a few bits can be exchanged at each step. There is not flow control / error control with the raw BL advertising frames so a whole new protocol must be built on top of the advertising protocol. And this is for a single pair of smartphones. If one smartphone is to handle several other devices at the same time, this make things even harder.

[Matioupi]

I've seen the proposal in the details spec (part C) but i'm still wondering how this will apply within a N smartphone env. Is there some kind of ACK to make sure that the protocol was successful ? Also if I understand correctly, the proposal somehow assume uniqueness of MAC address. This is not alway true with some low cost smartphones, and MAC address are also spoofable on rooted devices.

[vincent-grenoble]

Thank you for your feedback @Matioupi. You’re right, each EBID is now 32-byte long and needs to be split over two BLE frames (16-byte payload each). The current specification provides two potential solutions for doing that. We already did it in a different context using dedicated hardware (rather than smartphones), so we know it’s feasible from a BLE point of view. But yes, we need to work with specialists on the technical details.

Regarding MAC addresses, we don’t necessarily need such uniqueness guarantees (BTW, MAC addresses are probably random during these transmissions). Using a random ID to link the two BLE frames is a way to do that, which also leads to other questions. No decision taken at the moment but this is a known topic.

[Matioupi]

Thanks for the additional information. I think the ref page 15 : [10, Vol 3, Part B, sec. 4.4.2.3] is referring the wrong vol. It should be Vol 6, not Vol 3.

[vincenzoiovino]

The design of DESIRE shares a lot of similarities with Pronto-C2 proposed in https://eprint.iacr.org/2020/493.pdf . In Pronto-C2 the problem of the length of the beacons is circumvented by transmitting instead the addresses on which the beacons are publicly stored (like in IPFS); see the paper for precise details. This could be a valid suggestion for DESIRE as well. The issue of syncing the MAC, as also discussed in the paper, is also very important and OS limitations have to be carefully analyzed.

[Matioupi]

After reading BT 5.1 core spec and trying to think a bit more about it, I believe that DESIRE C.2 fragmentation approach is better than the C.1 scan/resp approach.

As I understand it, C.1 scan/resp approach will increase the overall RF congestion as the advertiser needs to reply to each SCAN_REQ PDU from all the scanners that would have received the initial ADV_IND PDU (as I understand BT spec)

I can't think of any advantage of using C.1 approach vs. C.2, but I suppose that there are some as both proposal were made what are they ?

[Matioupi]

Oh, I may see one point against C.2. It looks like (on Android) the device address for different advertiser services will have different MAC addresses (from the quick tests I've done) so the pairing of the different parts must be handled from the payload itself.

[cunchem]

I can't think of any advantage of using C.1 approach vs. C.2, but I suppose that there are some as both proposal were made what are they ?

C.2 requires to frequently change the payload of adv packets. It is unclear how mobile OSs will handle that. Note that the secret sharing scheme proposed in DP3T is also relying on a similar mechanism (although the number of payload is >> 2 in DP3T).

We've tested this carousel-like mechanism on a BLE-enabled microcontroler (ESP32), and it was working fine. https://github.com/cunchem/BLE_Privacy_Beacon