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]

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)

[Einar Thorsrud]

Hi,

kai19960504 said:

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

Yes.

kai19960504 said:

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

Yes.

kai19960504 said:

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

Yes.

kai19960504 said:

4. Each characteristics can have a different security level.

Yes.

kai19960504 said:

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

Yes.

kai19960504 said:

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

Just works is the term for pairing without any MITM protection (no passkey or numeric comparison). But as long as you pair, there will be a procedure that results in an encryption key (LTK) that is used to encrypt the link. If you don't want encryption, then do not pair or bond and set the characteristic security to open (SEC_OPEN).

[kai19960504]

Hi Einar,

I'm not sure we're talking about the encryption is same or not.

My encryption means that Sniffer will send this message : Encrypted packet decrypted incorrectly (bad MIC),you can see the red frame,so I define it as data encryption.

Q1: regarding the encryption description in the code and my understanding from the experiment, are they mean the same things as the screenshot?

Q2: according to my experiment, I'm confused why "Data Encryption" doesn't work with the configuration in red as the table?