bluetooth: host: Add workaround for USB HCI controllers

[fnde-ot]

This commit adds a new option CONFIG_BT_SMP_USB_HCI_CTLR_WORKAROUND
to support USB HCI controllers that sometimes send out-of-order HCI
events and ACL Data due to using different USB endpoints.

Enabling this option will make the master role not require the
encryption-change event to be received before accepting
key-distribution data.

It opens up for a potential vulnerability as the master cannot detect
if the keys are distributed over an encrypted link.

Fixes: #22086

Signed-off-by: François Delawarde fnde@oticon.com

[joerchan]

@jhedberg @fnde-ot From the discussion in the issue I assumed we weren't gonna do this?

In the case that we allow it I think we should only accept Identity Information and Identity Address Information. This would be the first thing the slave sends in LESC. (In legacy it is the LTK being sent first). If the peer decides to send it's identity information on an unencrypted link then the peer has messed up it's own privacy, but shouldn't affect us unless we need network privacy.

[jhedberg]

@jhedberg @fnde-ot From the discussion in the issue I assumed we weren't gonna do this?

That's what I assumed as well, particularly since (to my knowledge) this isn't preventing any critical (product) use case. So my first choice would be not to add anything like this.

If there really is a critical need I'd request at least the following:

• Make it depend on CONFIG_BT_TESTING
• Throw a big fat warning to the logs when initialising Bluetooth that there is an intentional security vulnerability enabled

[fnde-ot]

@jhedberg @fnde-ot From the discussion in the issue I assumed we weren't gonna do this?

I was thinking that maybe a workaround (disabled by default) could be acceptable for us to be able to use the official PTS dongles with Zephyr host in native_posix. We are using that heavily for testing purposes. Although it clearly states that it opens up for a potential vulnerability if the slave is broken, maybe we could make this Kconfig option depend on BT_TESTING to make sure no one enables this in production builds?

In the case that we allow it I think we should only accept Identity Information and Identity Address Information. This would be the first thing the slave sends in LESC. (In legacy it is the LTK being sent first). If the peer decides to send it's identity information on an unencrypted link then the peer has messed up it's own privacy, but shouldn't affect us unless we need network privacy.

Working with the PTS dongle in legacy mode, we sometimes get the LTK before receiving the encryption_change event, so this patch also fixes that case.

[fnde-ot]

If there really is a critical need I'd request at least the following:
* Make it depend on CONFIG_BT_TESTING
* Throw a big fat warning to the logs when initialising Bluetooth that there is an intentional security vulnerability enabled

Looks like our messages crossed paths, I can certainly update the patch to do that!

[joerchan]

@fnde-ot Ok. then BT_TESTING and the BT_WARN.

[fnde-ot]

@fnde-ot Ok. then BT_TESTING and the BT_WARN.

Pushed!!

[jhedberg]

@joerchan are you ok with this now?