-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple token generation on the BLE media #1
Comments
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 ? |
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. |
Thanks for the additional information. |
The design of DESIRE shares a lot of similarities with Pronto-C2 proposed in https://eprint.iacr.org/2020/493.pdf . |
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 ? |
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. |
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 |
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.
The text was updated successfully, but these errors were encountered: