search

espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.79k stars 7.31k forks source link

BLE BR/EDR Cross Transport Key Derivation (CTKD) Example (IDFGH-3609) #5549

Open caleedubya opened 4 years ago

caleedubya commented 4 years ago

Hi Everyone,

With ESP32 being Bluetooth 4.2 SIG compliant I would think it should be able to do CTKD but it's certainly not easy to figure it out.

What is CTKD? For anyone using Dual Mode Bluetooth it's the ability to bond to either one of BLE or BT and have the both modes connected through calculating and deriving the key for the other mode not explicitly bonded by the user.

I've been rooting around at this for quite some time and I've been able to find the following function within the BT Stack that looks promising... smp_calculate_long_term_key_from_link_key but the question is how do we call this from app_main?

Having an example that shows how to perform this task while running Coex BLE would be very handy for the community.

Thanks!

ghost commented 4 years ago

Hi, ESP32 does not support this feature yet. Thanks

drewandre commented 4 years ago

@Wth-Esp any chance this is on the product roadmap at all? @caleedubya and I have been active on other forums like reddit and the esp32 forum trying to figure this out. We both use BLE and A2DP and having duplicate devices appear in the phone BT settings menu is frustrating for us and for our users. I had previously tried going down the MFi path to achieve a seamless dual mode integration but it proved too difficult to source MFi processors reliably and receive tech support for MFi/esp32 development. Having CTDK would solve this issue by consolidating dual mode esp32 profiles into one device while also preventing users from needing to manually pair the BT classic profile.

I think at the very least, the esp32 BT coex example's readme could be updated since the default demo profile names "ESP_COEX_BLE_DEMO" and "ESP_COEX_A2DP_DEMO" do not actually show up separately as suggested - at least on iOS, these are both consolidated into one name, but are shown to the user as two devices, despite being two different BT profiles.

ghost commented 4 years ago

@drewandre I have to talk with my teammates and share you with our decision ASAP.

chegewara commented 4 years ago

Yes, it would be nice to have it. I already have ble + classic, but it was single device app, not production, so i didnt bother and my app is showing 2 devices with the same name, both with pin code. Not very elegant solution, because i have to use classic bt with public address and ble with RPA.

caleedubya commented 4 years ago

Hey guys,

What about this quote from the BTStack Manual (https://bluekitchen-gmbh.com/btstack.pdf):

"5.7.7. Cross-transport Key Derivation for LE Secure Connections. In a dual- mode configuration, BTstack automatically generates an BR/EDR Link Key from the LE LTK via the Link Key Conversion function h6. It is then stored in the link key db.

To derive an LE LTK from a BR/EDR link key, the Bluetooth controller needs to support Secure Connections via NIST P-256 elliptic curves and the LE Secure Connections needs to get established via the LE Transport. BTstack does not support LE Secure Connections via LE Transport currently."

When I read that it suggests to me that getting a BR/EDR key from a LE LTK should be possible via the Link Key Conversion function. Going the other way though and deriving a LE LTK from a BR/EDR link key looks to be unsupported at this time.

So if I reading this correctly, to make this work we just need to call the Link Key Conversion function. Any idea how we might do that?

Thoughts?

On Wed, Jul 8, 2020 at 6:27 AM chegewara notifications@github.com wrote:

Yes, it would be nice to have it. I already have ble + classic, but it was single device app, not production, so i didnt bother and my app is showing 2 devices with the same name, both with pin code. Not very elegant solution, because i have to use classic bt with public address and ble with RPA.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/5549#issuecomment-655487788, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHRM4ESV63DKPZ5KJSF5A5LR2RQZ5ANCNFSM4OSNPUSA .

ghost commented 4 years ago

Hi all,

Thanks for your support, we agree to do this feature. But this year we have much work to do on the new chips, so we decide to develop this feature in Q4 this year.

Thanks Weitianhua

drewandre commented 4 years ago

@Wth-Esp thank you, this is pretty exciting. This is the last step I was looking to overcome before bringing an esp32-based BT product to market this winter.

caleedubya commented 4 years ago

I"ll echo's Drew's comments. Thank you and this is also my last step in bringing a new ESP32-based product to market. Sincerely

On Fri, Jul 10, 2020 at 7:09 AM Drew André notifications@github.com wrote:

@Wth-Esp https://github.com/Wth-Esp thank you, this is pretty exciting. This is the last step I was looking to overcome before bringing an esp32-based BT product to market this winter.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/5549#issuecomment-656668330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHRM4EROBQHYNJGC34TNSSDR24HKLANCNFSM4OSNPUSA .

drewandre commented 4 years ago

@Wth-Esp the esp-idf v4.2-beta1 release notes mention bluetooth 5.0 compatibility. With v4.2 stable looking likely to be released Q4 this year, should be expect cross transport key derivation support? This release looks really exciting. Thank you for all of your work!

erpalma commented 4 years ago

I would really suggest you to have a look to this paper before moving on with CTKD.

drewandre commented 4 years ago

Aren't these proposed vulnerabilities the responsibility of Bluetooth SIG and not Espressif though? I would imagine it's Espressif's goal to be in compliance with the bluetooth 4.2 standard whether or not it includes vulnerabilities. Either way, CTKD seems to be the only viable option we have to avoid user's having to manage two bluetooth connections for a product that requires bluetooth audio streaming alongside BLE commands (we've tried the MFi route, and LE audio isn't widely adopted yet). Thanks for sharing this though @erpalma, pretty interesting.

caleedubya commented 3 years ago

Hi all,

Thanks for your support, we agree to do this feature. But this year we have much work to do on the new chips, so we decide to develop this feature in Q4 this year.

Thanks Weitianhua

Hi @Wth-Esp, just wanted to check in to see if you guys are still on track for a Q4 release of CTKD functionality? There are a few of us where this feature is the last thing we need to release a ESP32 based product so we're anxiously awaiting it's release. :D

ghost commented 3 years ago

Hi @caleedubya

First of all, thanks for your patience. We have evaluated the development and the test work of this part. I'm so sorry that we can not push the feature as per the timeline, because of the security phase issue which may affect the Authentication and Encryption procedure of both BREDR and BLE. Now I cannot give you the timeline of the work, we have to test it more. But I will update the stage of development and test work here as soon as possible. Once again, sorry for the delay.

Thanks

caleedubya commented 2 years ago

Hi @Wth-Esp, it's been a couple years since we last touched on this. Wanted to see if there is any chance to take another shot at this?

xupenghu commented 1 year ago

Hi @ghost, I also have the same need, please push as soon as possible.

blueMoodBHD commented 1 year ago

We are very sorry that we have no development plan for this feature at the moment.

We have put this feature in featuer introduced list, and we will let you know if we starts working on it.