Bluetooth: Host: Remove HCI ECC emulation

[jhedberg]

Remove the HCI command & event emulation layer for ECDH commands and events. This means that we always do the necessary operations in the host. The existing BT_ECC Kconfig option stays, but now gets automatically enabled when necessary (e.g. based on the BT_SMP option), which is why this PR removes so many explicit assignments in prj.conf files.

[alxelax]

Shouldn't Host ECC functionality instantiate multiple DH key pairs? Due to single pair, it is not possible to use Host implementation in Mesh when Mesh and SMP work in parallel (for example in DFU).
At the moment we have to keep two ECC implementations, one in Mesh and one in Host.

[jhedberg]

Shouldn't Host ECC functionality instantiate multiple DH key pairs? Due to single pair, it is not possible to use Host implementation in Mesh when Mesh and SMP work in parallel (for example in DFU). At the moment we have to keep two ECC implementations, one in Mesh and one in Host.

Yes. This is why I was trying to call out for some requirements gathering in #84216. I think even the Host itself would benefit from being able to handle multiple public/private key pairs, in order to support the multi-identity feature. I think this PR is a good step in fixing these issues, since it simplifies the general implementation in the Host. Once it's in we can look at doing more substantial changes to the API, and since it's internal (for now) we can quite freely mold it to our requirements, both from the Host and Mesh side.

[frkv]

Suggested change

	select PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_GENERATE
	select PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_GENERATE
	select PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_IMPORT
	select PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_EXPORT

Missing some required key-pair feature types. Please add these

[jhedberg]

Those are not present in the current tree, and this PR doesn't add any new requirements wrt PSA APIs or functionality, so I'm wondering are they really needed or if something else (by chance) happens to provide them:

zephyr/subsys/bluetooth/host/Kconfig

Lines 1002 to 1013 in d1d85fa

	config BT_SEND_ECC_EMULATION
	bool "Emulate ECDH in the Host using PSA Crypto API library"
	select MBEDTLS if !BUILD_WITH_TFM
	select MBEDTLS_PSA_CRYPTO_C if !BUILD_WITH_TFM
	select PSA_WANT_ALG_ECDH
	select PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_GENERATE
	select PSA_WANT_ECC_SECP_R1_256
	imply MBEDTLS_PSA_P256M_DRIVER_ENABLED if MBEDTLS_PSA_CRYPTO_C
	select BT_LONG_WQ
	depends on BT_ECC && (BT_HCI_RAW || BT_HCI_HOST)
	default y if HAS_BT_CTLR && !BT_CTLR_ECDH
	help

As such I could argue that this is really a separate enhancement, independent from this PR, so in that sense it could be done as a follow-up as well (once it's first understood why the current upstream tree seems to work just fine without them).

[frkv]

It "works just fine" because Mbed TLS has defined some types without enforcing usage. They have been converting to KEY_PAIR_BASIC and made that the thing that is currently being used in code.

This "just works" right now when using the original Mbed TLS distribution, but it is preventing optimizations that is possible to do for anyone implementing PSA crypto APIs making use of the intent of these configurations.

We make use of these configurations in Nordics own SDK and they are intently added into PSA crypto configurations scope in Zephyr, we are also cooperating with Trusted-Firmware organization (both in TF-M and Mbed TLS) to ensure that build optimizations are part of the final deliverables. These configurations were added for a reason.

Adding them here conforms to the intent, similar to how it is done done in BLE mesh

We will add a subsequent PR with these configurations added :)