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

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

kai19960504 — Mon, 23 May 2022 08:15:27 GMT

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

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

kai19960504 — Mon, 23 May 2022 06:02:25 GMT

Hi Einar,

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

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

Einar Thorsrud — Fri, 20 May 2022 07:37:47 GMT

[quote user="kai19960504"]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.[/quote]

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

[quote user="kai19960504"]Q1: regarding the encryption description in the code and my understanding from the experiment, are they mean the same things as the screenshot?[/quote]

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

[quote user="kai19960504"]Q2: according to my experiment, I'm confused why "Data Encryption" doesn't work with the configuration in red as the table?[/quote]

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.

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

kai19960504 — Fri, 20 May 2022 05:38:32 GMT

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?

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

Einar Thorsrud — Thu, 19 May 2022 13:36:39 GMT

Hi,

[quote user="kai19960504"]1. As long as the IO Capability of Initiator / Responder follows Table2.8, the configuration will happen automatically.[/quote]

Yes.

[quote user="kai19960504"]2. Table2.8 tells you the security level that IO Capability can achieve, which defines the security of Link.[/quote]

Yes.

[quote user="kai19960504"]3. sec_xxx represents security level which defines the security of access characteristics.[/quote]

Yes.

[quote user="kai19960504"]4. Each characteristics can have a different security level.[/quote]

Yes.

[quote user="kai19960504"]5. The security level of the link must be the same or higher than the security level to access the characteristics.[/quote]

Yes.

[quote user="kai19960504"]Why is data encrypted using the security level for just works?[/quote]

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

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

kai19960504 — Thu, 19 May 2022 01:31:21 GMT

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 :

[quote userid="7377" url="~/f/nordic-q-a/87430/question-about-mapping-of-io-capabilities-to-key-generation-method/365685#365685"]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. [/quote]

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)

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

kai19960504 — Thu, 05 May 2022 01:16:15 GMT

Hi Einar,

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

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

Einar Thorsrud — Wed, 04 May 2022 10:14:37 GMT

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.

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

kai19960504 — Wed, 04 May 2022 00:23:53 GMT

Hi Einar,

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

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

Einar Thorsrud — Tue, 03 May 2022 14:55:53 GMT

Hi Kai,

It goes back to what I have attempted to describe:

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

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

kai19960504 — Tue, 03 May 2022 07:32:28 GMT

Hi Einar,

[quote userid="7377" url="~/f/nordic-q-a/87430/question-about-mapping-of-io-capabilities-to-key-generation-method/365848#365848"]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.[/quote]

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

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

Einar Thorsrud — Tue, 03 May 2022 06:47:31 GMT

[quote user="kai19960504"]"the level you got from pairing/bonding" - Do you mean this part of the picture?[/quote]

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

[quote user="kai19960504"]or here?[/quote]

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.

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

kai19960504 — Tue, 03 May 2022 02:41:56 GMT

Hi Einar,

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

or here?

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

Einar Thorsrud — Mon, 02 May 2022 19:48:32 GMT

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.

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

kai19960504 — Mon, 02 May 2022 14:01:50 GMT

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?

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

Einar Thorsrud — Mon, 02 May 2022 06:43:35 GMT

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.

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

kai19960504 — Mon, 02 May 2022 04:36:18 GMT

Hi Einar,

[quote userid="7377" url="~/f/nordic-q-a/87430/question-about-mapping-of-io-capabilities-to-key-generation-method/365565#365565"]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.)[/quote]

sorry i don't quite understand.

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

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

Einar Thorsrud — Fri, 29 Apr 2022 11:28:19 GMT

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.

[quote user=""]

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

[/quote]

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