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]

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?

[Einar Thorsrud]

kai19960504 said:

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.

I believe we are talking about the same thing. (Encryption of the BLE link always happens the same way as long as encryption is used, regardless of how the pairing is performed.). The sniffer trace shows that the sniffer cannot interpret the packets after the link becomes encrypted, which means it does not have the LTK (either because you used LESC pairing of the sniffer did not listen in on the pairing procedure). Note that if you are using legacy pairing and you sniff the pairing the sniffer will get the LTK and can decode the packets even if the link is encrypted, so simply seeing that the sniffer can decode the packets does not show that the link is not encrypted. Instead, you need to see if if encryption is started (you se the LL packets right before the sniffer no longer can decode the packet in your sniffer trace), or look at the 

kai19960504 said:

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

I don't understand the question, to be honest. As mentioned before, the configuration on the characteristics configure the security level required on the link in order to be able to access the characteristics. This does not control if the link is encrypted or not. (You can for instance pair and have an encrypted link even if all characteristics are open, there is nothing in the spec that prevents that, even if it would be unusual.)

kai19960504 said:

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

I am not sure I understand the table. In what way does encryption not work? You can pair and encrypt the link without any I/O capabilities or any other requirements, as long as both peers support pairing and one of them initiates it.

[kai19960504]

Hi Einar,

I have already know what you say,thank you!!

[kai19960504]

Hi All,

According to Einar's analysis, the final answer is organized here :

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.

6. Encryption of the BLE link always happens the same way as long as encryption is used, regardless of how the pairing is performed.

7. The sniffer trace shows that the sniffer cannot interpret the packets after the link becomes encrypted, which means it does not have the LTK