Re-evaluating LE Legacy Pairing, we realized that customers could miss to set two security keys (ER + IR) to persistent random values, which would lead to a security issue. In addition, a Central would have issues identifying different devices if private random addresses are used.

With this advisory, we would like to make sure that your design is not affected.

Action

You should check if you are providing unique/random persistent ER and IR values to the Security Manager via sm_set_er() and sm_set_ir during startup.

If not, we would recommend to implement the following scheme:

1. On start, check persistent storage for ER and IR keys. If available call sm_set_* functions. Done.
2. Otherwise, use btstack_crypto_random_generate() to generate two 16-byte values, store them in perstisten storage, and use them as ER and IR in the call to the sm_set_* functions.

For more background and security details, see Background below.

Background

For LE Legacy Pairing, BTstack implements LTK key derivation as suggested in the Bluetooth Core Spec Vol 3, Part H, Appendix B2. This allows for pairing without a need for a persistent storage. Instead, the LTK is derived using random data from the ER key and the random data is provided by the Central in-the-clear on re-connect by the Central device. However, for this to be secure, each device needs unique ER and IR values. As BTstack did not have a generic persistent storage when the Security Manager was implemented, the task for providing ER and IR was left to the application.

For LE Secure Connections, not setting the IR key will result in identical IRK keys, which are used to resolve private addresses, and therefore can cause problems for a Central to lookup bonding information.

btstack_crypto_random_generate() uses the Random Generator of the Bluetooth Controller, which should be reasonably good. If you have a better source for randomness, that can be used as well.