Testing of Shorter than 16 octet keys.
In smp_cmd_pairing_random() when the STK is generated, it needs to be
truncated to the MIN of conn->preq[4] and conn->pres[4].
This Min value may need to be saved for later as well, because it needs
to also limit the LTK key exchange.
This failure showed up with the PTS tool, and at least one other device
during the days testing. I have mocked up a fix, but have not had a
chance to test it yet.
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Vinicius,
More on Key Distribution:
When we are an SM responder, we are suppose to AND the requested key
distribution values with our values (what we expect, and what we
generate). So for instance, if we have 07 07 as our prefered key
distribution values, and we receive 00 01, then we should mask
everything out except for the Responder LTK distribution PRIOR to
responding with the Pairing Response, and then of course only distribute
that one LTK key after link encryption.
Currently, we are always responding with 07 07 regardless of what the
Initiator requested, and then always distribute all possible keys.
Regards,
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Vinicius,
On 2/8/2011 5:58 AM, Vinicius Costa Gomes wrote:
> Hi Brian,
>
> On 17:22 Mon 07 Feb, Brian Gix wrote:
>> On 2/7/2011 4:26 PM, Brian Gix wrote:
>>>
>>> Testing of Shorter than 16 octet keys.
>>>
>>> In smp_cmd_pairing_random() when the STK is generated, it needs to be
>>> truncated to the MIN of conn->preq[4] and conn->pres[4].
>>>
>>> This Min value may need to be saved for later as well, because it needs
>>> to also limit the LTK key exchange.
>>>
>>> This failure showed up with the PTS tool, and at least one other device
>>> during the days testing. I have mocked up a fix, but have not had a
>>> chance to test it yet.
>>>
>>>
>
> First, thanks for the reports. This particular issue should be fixed soon.
>
When testing this morning, I successfully negotiated and paired with a
device, where we both said that we could accept and produce all keys
(key mask 0x07). We were the responder, and sent all keys (0x06 through
0x0A) then we received all keys from remote device (0x06 through 0x0A).
The apparent problem was that we sent the all of our keys a second
time. This caused no problems, but was noticable on the hcidump trace:
> ACL data: handle 10 flags 0x02 dlen 11
L2CAP(d): cid 0x0006 len 7 [psm 0]
0000: 01 03 00 00 10 07 07 .......
< ACL data: handle 10 flags 0x00 dlen 11
0000: 07 00 06 00 02 03 00 00 10 07 07 ...........
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 1
> ACL data: handle 10 flags 0x02 dlen 21
L2CAP(d): cid 0x0006 len 17 [psm 0]
0000: 03 de 36 99 3f ed 4a 13 78 2c 3e dd 6f 3c 0f 2f
..6.?.J.x,>.o<./
0010: 6e n
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 03 df 4b f0 b0 f1 8e 1c 5e b6 f9 9c
......K.....^...
0010: c4 65 c3 9e 3d .e..=
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 1
> ACL data: handle 10 flags 0x02 dlen 21
L2CAP(d): cid 0x0006 len 17 [psm 0]
0000: 04 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91
................
0010: 91 .
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 04 56 54 2b 45 81 16 6a d4 58 5c 73
.....VT+E..j.X\s
0010: 77 08 43 e5 6f w.C.o
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 1
> HCI Event: LE Meta Event (0x3e) plen 13
LE Long Term Key Request
0000: 0a 00 00 00 00 00 00 00 00 00 00 00 ............
< HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18
0000: 0a 00 16 51 6d 0c c3 59 fc 71 e2 e1 64 59 a7 81 ...Qm..Y.q..dY..
0010: c1 72 .r
> HCI Event: Command Complete (0x0e) plen 6
LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
0000: 00 0a 00 ...
> HCI Event: Encrypt Change (0x08) plen 4
status 0x00 handle 10 encrypt 0x01
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 06 01 01 01 01 01 01 01 01 01 01 01
................
0010: 01 01 01 01 01 .....
< ACL data: handle 10 flags 0x00 dlen 15
0000: 0b 00 06 00 07 02 02 02 02 02 02 02 02 02 02 ...............
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 08 04 04 04 04 04 04 04 04 04 04 04
................
0010: 04 04 04 04 04 .....
< ACL data: handle 10 flags 0x00 dlen 12
0000: 08 00 06 00 09 00 53 53 53 53 53 53 ......SSSSSS
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 0a 05 05 05 05 05 05 05 05 05 05 05
................
0010: 05 05 05 05 05 .....
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 4
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 1
> ACL data: handle 10 flags 0x02 dlen 21
L2CAP(d): cid 0x0006 len 17 [psm 0]
0000: 06 87 87 87 87 87 87 87 87 87 87 87 87 87 87 87
................
0010: 87 .
> ACL data: handle 10 flags 0x02 dlen 15
L2CAP(d): cid 0x0006 len 11 [psm 0]
0000: 07 33 22 91 91 91 91 91 91 91 91 .3"........
> ACL data: handle 10 flags 0x02 dlen 21
L2CAP(d): cid 0x0006 len 17 [psm 0]
0000: 08 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98
................
0010: 98 .
> ACL data: handle 10 flags 0x02 dlen 12
L2CAP(d): cid 0x0006 len 8 [psm 0]
0000: 09 00 45 98 76 98 34 67 ..E.v.4g
> ACL data: handle 10 flags 0x02 dlen 21
L2CAP(d): cid 0x0006 len 17 [psm 0]
0000: 0a 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99
................
0010: 99 .
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 06 01 01 01 01 01 01 01 01 01 01 01
................
0010: 01 01 01 01 01 .....
< ACL data: handle 10 flags 0x00 dlen 15
0000: 0b 00 06 00 07 02 02 02 02 02 02 02 02 02 02 ...............
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 08 04 04 04 04 04 04 04 04 04 04 04
................
0010: 04 04 04 04 04 .....
< ACL data: handle 10 flags 0x00 dlen 12
0000: 08 00 06 00 09 00 53 53 53 53 53 53 ......SSSSSS
< ACL data: handle 10 flags 0x00 dlen 21
0000: 11 00 06 00 0a 05 05 05 05 05 05 05 05 05 05 05
................
0010: 05 05 05 05 05 .....
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 3
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 10 packets 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 10 reason 0x13
Reason: Remote User Terminated Connection
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Brian,
On 17:22 Mon 07 Feb, Brian Gix wrote:
> On 2/7/2011 4:26 PM, Brian Gix wrote:
> >
> >Testing of Shorter than 16 octet keys.
> >
> >In smp_cmd_pairing_random() when the STK is generated, it needs to be
> >truncated to the MIN of conn->preq[4] and conn->pres[4].
> >
> >This Min value may need to be saved for later as well, because it needs
> >to also limit the LTK key exchange.
> >
> >This failure showed up with the PTS tool, and at least one other device
> >during the days testing. I have mocked up a fix, but have not had a
> >chance to test it yet.
> >
> >
First, thanks for the reports. This particular issue should be fixed soon.
>
> PTS also did not like that we request No Bonding, but request to
> exchange keys. I am not sure who is at fault there. At first
> glance, exchanging keys insinuates a bonded relationship, so I don't
> know what it means to request key exchange but not bond. I think
> both sides need to agree to bond (bit 0x01 in offset 3 (4th octet)
> of the req and res) to remember the exchanged keys, but exchanging
> keys should still be OK for the duration of that session at least.
> They would then be discarded when the connection ended.
>
> It also may not make sense to request Bonding, but not have keys to
> exchange, because I am not sure if you are really bonded if you have
> no keys exchanged with the remote device. You could always just
> remember the remote device's BD Addr, I suppose and choose to accept
> or reject no-security connections based on that.
>
> I am sorry, the above is mostly just me thinking out loud. I don't
> know for sure if any of that is actually correct.
>
So, I will add something to the thinking out loud session ;-) seems to me that
the tests were written assuming that most of the limitations are in the slave,
when some of them find a limited (for now) SM implementation in the master
side some things are not so clear.
>
> --
> Brian Gix
> [email protected]
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Cheers,
--
Vinicius
On 2/7/2011 4:26 PM, Brian Gix wrote:
>
> Testing of Shorter than 16 octet keys.
>
> In smp_cmd_pairing_random() when the STK is generated, it needs to be
> truncated to the MIN of conn->preq[4] and conn->pres[4].
>
> This Min value may need to be saved for later as well, because it needs
> to also limit the LTK key exchange.
>
> This failure showed up with the PTS tool, and at least one other device
> during the days testing. I have mocked up a fix, but have not had a
> chance to test it yet.
>
>
PTS also did not like that we request No Bonding, but request to
exchange keys. I am not sure who is at fault there. At first glance,
exchanging keys insinuates a bonded relationship, so I don't know what
it means to request key exchange but not bond. I think both sides need
to agree to bond (bit 0x01 in offset 3 (4th octet) of the req and res)
to remember the exchanged keys, but exchanging keys should still be OK
for the duration of that session at least. They would then be discarded
when the connection ended.
It also may not make sense to request Bonding, but not have keys to
exchange, because I am not sure if you are really bonded if you have no
keys exchanged with the remote device. You could always just remember
the remote device's BD Addr, I suppose and choose to accept or reject
no-security connections based on that.
I am sorry, the above is mostly just me thinking out loud. I don't know
for sure if any of that is actually correct.
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum