Question about "Mapping of IO capabilities to key generation method"

[kai19960504]

Hi All,

I would like to know how Nordic's pairing mode corresponds to the bluetooth specification.

If my smartphone(initiator) is keyboard display,and my slave(responder) is display only.

The comparison to the table is to use the passkey entry.

So which one should I choose for the settings in the program?

Best regards,

Kai

[Einar Thorsrud]

Hi Kai,

Both peers are configured with what they support of I/O capabilities, and with that input the table you refer to defines which (if any) pairing method that will be used. This follows the Bluetooth specification and happens automatically based on the configuration.

So which one should I choose for the settings in the program?

For each characteristic you define which security level you need in order to allow access to that characteristic. As long as the link has same or higher level, the peer is allowed to operate on the characteristic. (There are separate configurations for different operations, so it is for instance possible to require no security on say writing, but required MITM for reading. Or require just works for some characteristics, and MITM for others, etc.)

Br,

Einar

[kai19960504]

Hi Einar,

Einar Thorsrud said:

For each characteristic you define which security level you need in order to allow access to that characteristic. As long as the link has same or higher level, the peer is allowed to operate on the characteristic. (There are separate configurations for different operations, so it is for instance possible to require no security on say writing, but required MITM for reading. Or require just works for some characteristics, and MITM for others, etc.)

sorry i don't quite understand.

If both peers final match is " Passkey Entry",which enum should i choose in security_req_t?

[Einar Thorsrud]

That depends. This is set per characteristic, and can be different for the different characteristics you have in your product. With passkey entry you will hav MITM, so up to SEC_MITM can be used, and the characteristic can be accessed. You can also use SEC_JUST_WORKS for instance, if you do not want to require MITM protection in order to access that specific characteristic. So there is no direct one-to-one mapping here.

However, if you make both peers or one of them is a phone or a device you know will have full I/O capabilities, then you know that you will always have passkey entry, and you could just as well set SEC_MITM for all characteristics.

[kai19960504]

Hi Einar,

So table2-8 just tells you what security mode would normally be used for the IO capability of the two peers.

In fact, the security mode to be used can be customized through security_req_t.

It is right?

[Einar Thorsrud]

Almost. These are closely related, but not the exact same thing. Note that these are general Bluetooth concepts, so this is not related specifically to Nordic. 

The table tells you which security level you can achieve with the given combined I/O capabilities of the peers. This defines the security you get on the link after pairing/bonding. This is one thing.

The security_req_t type however, is associated with characteristics and define the security level required for reading and/or writing to that specific characteristic. That does not have to be the same. If the level you got from pairing/bonding is the same or higher as you have specified for a given characteristic, then you can read/write it. If it is lower, then you cannot.

[kai19960504]

Hi Einar,

Einar Thorsrud said:

If the level you got from pairing/bonding is the same or higher as you have specified for a given characteristic, then you can read/write it. If it is lower, then you cannot.

"the level you got from pairing/bonding" - Do you mean this part of the picture?

or here?

[Einar Thorsrud]

kai19960504 said:

"the level you got from pairing/bonding" - Do you mean this part of the picture?

No, that is where you set the security requirement for a specific characteristic. Here you set it to open so that it can be accessed even with an unencrypted link (no pairing needed for that specific characteristic to be used).

kai19960504 said:

or here?

These defines are used further down in the examples main.c and  is input to the peer manager, and configures if it should support bonding etc. Here you also set IO capabilities to none, so just works (or no pairing at all) is the only posibility.

[kai19960504]

Hi Einar,

Einar Thorsrud said:

If the level you got from pairing/bonding is the same or higher as you have specified for a given characteristic, then you can read/write it. If it is lower, then you cannot.

Could you please elaborate a little more on what this means?

[Einar Thorsrud]

Hi Kai,

It goes back to what I have attempted to describe:

1. The security level of the link depends on the IO-capabilities of the peers (and if LESC is supported). The highest possible given the combined support is used.
2. Each characteristic can requier separate specific security levels (from 1.) for each characteristic (and even separate for reading and writing).

Tese two concepts are closely related. You need to understand the concepts in order to work with this, and it is basically as I have deescribed. If you need more understanding of this you can read up on Bluetooth security in general as this is a generic concept ant not specific to Nordic.