Hi Andrejs, >>>> So LE Legacy Pairing needs the Security Manager TK value and LE Secure Connections needs the Confirmation and Random values. However right now, we can not get these ones from the kernel. >>>> >>>> As a side note, I added tools/oobtest utility where you can test this between two controllers attached to the same host. >>> Based on oobtest/kernel code/mgmt-api comments, the OOB LE legacy pairing is still not supported: "Currently there is no support for providing the Security Manager TK Value for LE legacy pairing". >>> >>> Is there any plan to support it? Maybe some patches exist? Are there any serious technical difficulties behind the absence of this functionality? >> >> making OOB LE legacy pairing work is pretty tricky since it is the wrong kind of OOB. Essentially it is just a shared secret between two device and only if that shared secret is truly random and communicated out-of-band you get proper strong keys. But nothing in the process guarantees that or can verify it. >> >> It also does not fit into the SSP, BR/EDR SC or LE SC model with the public key exchange. So we actually gave up on supporting OOB LE legacy pairing. >> >>> I know that BT 4.2 SC provides better alternatives for secure pairing, but the 4.2 is not so widely adopted as 4.0 and our BT chip also don't support 4.2… >> >> You can run LE SC on Bluetooth 4.0 chips. We do that and also Apple’s iOS does that. No need for new hardware. > Our device (peripheral) chip runs proprietary SW which doesn't support 4.2 yet, it is not related to BlueZ/Linux at all, unfortunately. I would try to get your chip software updated to support LE SC as quickly as possible. It is the one update that is really worth the effort since it makes a huge difference from a security point of view. The advantage with OOB from LE SC is that the OOB material only needs to be transported in one direction. It is truly random since it is based on your public/private key pair. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
