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