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?

[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.

[kai19960504]

Hi Einar,

So you mean that the security level set by the characteristic is preferably higher than the IO capability,right?

[Einar Thorsrud]

No. If you require higher security level on the characteristics than what you end up with on the link after pairing (based on IO capabilities), then you will not be able to access the characteristics.

[kai19960504]

Hi Einar,

I'm going to do some experiments first maybe to understand what you mean, it will take a while.

[kai19960504]

Hi Einar,

Based on my experiment, I am more clear about your explanation before.

But still want to ask questions.

Here's what I've done with your answer, please help me confirm :

1. As long as the IO Capability of Initiator / Responder follows Table2.8, the configuration will happen      automatically.

2. Table2.8 tells you the security level that IO Capability can achieve, which defines the security of Link.

3. sec_xxx represents security level which defines the security of access characteristics.

4. Each characteristics can have a different security level.

5. The security level of the link must be the same or higher than the security level to access the characteristics.

Here is my implementation of the problem :

Einar Thorsrud said:

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.

Why is data encrypted using the security level for just works?

(The encryption I am talking about is as follows : Sniffer cannot sniff during data transmission)