Function wiced_bt_smp_create_local_sc_oob_data creates wrong commitment value

[hanhes]

I'm implementing out of band pairing with the CYBT-413055 as peripheral and an Android smartphone as central. During the out of band pairing procedure the pairing is aborted because of unmatching commitment values. After that I checked how this commitment value is calculated inside the bluetooth specs. The calculation is described as follows:

commitment(key, message) = AES-CMAC(secure_connections_random_value, (public_key_x_of_a || public_key_x_of_a || 0x00)).

So for the key the random value exchanged via the oob interface is used and for the message a concatenation of two times the public key x of the device and 0x00 is used. I calculated the AES-CMAC manually using data generated by the function wiced_bt_smp_create_local_sc_oob_data. With the manual calculation I couldn't reproduce the commitment value. So could it be that the algorithm used inside the function  wiced_bt_smp_create_local_sc_oob_data is not the same as described in the bluetooth specs? And how can I solve this issue?

[advait_kulkarni]

Hi @hanhes 

Thank you for contacting infineon tech support team. We will check the concerned api and get back to you soon.

In the mean time, can you let us know what event are you getting when the connection is aborted?

Thanks and regards.

Advait

[hanhes]

Hi @advait_kulkarni,

thank you for your reply. I get the BTM_PAIRING_COMPLETE_EVT when the pairing is aborted. Inside the event data the reason is specified as 0x04 (SMP_CONFIRM_VALUE_ERR). 

[hanhes]

Hi @advait_kulkarni,

is there any update on this?

[advait_kulkarni]

Hi @hanhes ,

We checked with our development team and no such issue has been observed.

Can you please share the inputs and the values that you got from the api and used to calculate the AES-CMAC manually so that we can cross check at our end?

Thanks and regards.

Advait Kulkarni.

[hanhes]

Hi @advait_kulkarni,

thank you very much for the effort.

Here are some further details:

For the input of wiced_bt_smp_create_local_sc_oob_data(bd_addr, bd_addr_type) I use the local address of the peripheral and BLE_ADDR_PUBLIC (0x00). The function generates the following out of band data:

Bluetooth device address: 8e:92:fe:5c:b4:9f:9f
Bluetooth device address type: 0
Commitment: 0xc6, 0x52, 0x11, 0xcd, 0xd5, 0x35, 0x11, 0xec, 0x1, 0x8e, 0x26, 0x35, 0x2, 0xac, 0xa0, 0x16
OOB data present: 1
private key used: bb:60:2:ff:d5:4f:67:3d:f9:62:5:fe:25:83:71:b7:4:67:54:44:4b:5a:be:f6:dc:4:1c:b5:a0:ec:f0:48
public key used (x): 0xa9,0x94,0xbc,0xfc,0xf7,0x97,0xdb,0x83,0x2,0x18,0x40,0x25,0x18,0x65,0x1b,0x53,0x3,0x6c,0x38,0x27,0x2e,0x52,0x84,0x3,0x35,0x41,0xa9,0x55,0xf5,0xcb,0xf7,0xff
public key used (y): 0xbe,0x69,0xf7,0x18,0xad,0x65,0x1,0x22,0xbf,0xf5,0x8e,0x75,0x7d,0xab,0x26,0x3f,0xd3,0x95,0x32,0xa2,0xa0,0xf8,0x4b,0x91,0x76,0x33,0xb8,0x4d,0x11,0xcf,0x4e,0xe2
Randomizer: 0x85,0xf3,0x94,0x8b,0x52,0xf1,0x44,0x4a,0x7a,0x90,0xde,0xc3,0x32,0xbf,0x89,0x30

To verify the commitment value I used c# with the nuGet package "Dorssel.Security.Cryptography.AesExtra" and the class AesCmac. With this algorithm I was able to reproduce an example of the aes-cmac calculation from the bluetooth specification (Version 5.1, Vol. 3 Part H Appendix D.2):

U                           20b003d2 f297be2c 5e2c83a7 e9f9a5b9eff49111 acf4fddb cc030148 0e359de6
V                            55188b3d 32f6bb9a 900afcfb eed4e72a59cb9ac2 f19d7cfb 6b4fdd49 f47fc5fd
X                            d5cb8454 d177733e ffffb2ec 712baeab
Z                            0x00
M0                        20b003d2f297be2c5e2c83a7e9f9a5b9
M1                        eff49111acf4fddbcc0301480e359de6
M2                        55188b3d32f6bb9a900afcfbeed4e72a
M3                        59cb9ac2f19d7cfb6b4fdd49f47fc5fd
                              00
AES_CMAC        f2c916f1 07a9bd1c f1eda1be a974872d

I used this algorithm to calculate the commitment value manually using the following inputs according to the bluetooth specifications (Version 5.1, Vol. 3 Part H 2.2.6):

U                           public key used (x) 

V                            public key used (x)

X                            Randomizer

Z                            0x00

M                          0xa9,0x94,0xbc,0xfc,0xf7,0x97,0xdb,0x83,0x2,0x18,0x40,0x25,0x18,0x65,0x1b,0x53,0x3,0x6c,0x38,0x27,0x2e,0x52,0x84,0x3,0x35,0x41,0xa9,0x55,0xf5,0xcb,0xf7,0xff,
0xa9,0x94,0xbc,0xfc,0xf7,0x97,0xdb,0x83,0x2,0x18,0x40,0x25,0x18,0x65,0x1b,0x53,0x3,0x6c,0x38,0x27,0x2e,0x52,0x84,0x3,0x35,0x41,0xa9,0x55,0xf5,0xcb,0xf7,0xff,
0x00

The result of the AES-CMAC with these inputs is: 74,DA,AD,4B,4C,09,2F,E4,37,DF,1A,CB,65,57,98,9A, which is different from the commitment value calculated by the api.

Regards.

[advait_kulkarni]

Hi @hanhes ,

Can you please provide us your project and the air logs so that we can debug the issue further?

Thanks and regards.

Advait Kulkarni.