I read through the Bluetooth core specification in order to get a better understanding of the information that has to be stored at a minimum if using bonding. But I'm still not sure if I found all keys and values in the core specification that have to be stored if only bonding and Just Works Pairing with diffie hellman key exchange is used. No other features or optional functions are used.
In the core specification I found the following sections:
Is this everything that has to be taken into account? What does this mean for the example above if these are the only keys and values that have to be stored?
In my opinion only the LTK has to stored regarding the example above. Because the Client Characteristic Configuration descriptor value does only have to be stored if GATT notfication or indication can be enabled. The IRK is used for privacy mechanism only, CSRK is necessary if data signing is used and EDIV and Rand are only necessary if LE legacy pairing is supported.
Is my assumption right or did I miss something?
You seem to have understood most things. A few things however:
When a central device connects to you and after the link has been established, it can make the link encrypted. With legacy pairing the master device sends the EDIV/Rand so the slave can find the right LTK. If the bond was made using SC, the EDIV/Rand fields are empty so the slave must first identify the master using either the address or the IRK in order to find the correct key. If you only store one bond and therefore a single LTK you can technically store this LTK and nothing else, but then you can't correctly send a negative reply if an "unknown" master sends an encryption request since it can't be distinguished.
If you have characteristics that must be sent over an encrypted link and the link is currently not encrypted, it's also mandatory to be able to identify whether the remote device is bonded or not since two different error codes are sent depending on this.
Thank you for the detailed answer. I think, I almost got it.
Maybe one more question to be sure.
Let's say I would extend the example explained above to a scenario where I need to store at least 5 bondings from different smartphones (Android and iOs) on the nRF. The nRF is of course the peripheral.
All smartphones nowadays use random resolvable addresses, and this is not something you can control unless you have root access to the phone.
I guess the most common setup is that peripherals do not use random resolvable addresses. If you use a public address or a static random, you don't need to generate an IRK and do not need to send it during bonding to the other device. You should however receive the IRK from the smartphone and store it together with the LTK. If the central happens to don't use IRK, you need to save the Bluetooth address instead (sent as Identity Address). Even if the central sends an IRK, you should still store the Identity Address in case the central some day doesn't use a random resolvable address. You should also make space for the EDIV and Rand in case some central doesn't support LESC. But I think the Peer Manager takes care of all this if you use that module.
I will use the Peer Manager, of course. As I mentioned at the beginning it's only in order to understand the relationships.
Thanks for your explanations.