We are able to pass all qualification tests with BlueZ as the Master except one:
TP/KDU/BV-06-C - Master Key Distribution - Encryption Key bit
This test requires that BlueZ initiates pairing with the
SMP_DIST_ENC_KEY bit set in the init_key_dist member of struct
smp_cmd_pairing - however this member is always initialized to zero
and never changed.
This seems to have changed at some point in the past, 2b64d153 added
MITM mechanism and changed the init_key_dist member initialization
from dist_keys to 0
So two questions:
1) should BlueZ be able to behave as Master? It passes the majority
of the tests except this one.
2) given the above, is this a bug that init_key_dist is 0 or is it a
test plan error that it requires this?
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
Hi Scott,
On 13:17 Mon 25 Nov, Scott James Remnant wrote:
> We are able to pass all qualification tests with BlueZ as the Master except one:
>
> TP/KDU/BV-06-C - Master Key Distribution - Encryption Key bit
>
> This test requires that BlueZ initiates pairing with the
> SMP_DIST_ENC_KEY bit set in the init_key_dist member of struct
> smp_cmd_pairing - however this member is always initialized to zero
> and never changed.
This test is in theory correct, but it doesn't test anything that does make
sense at this point. Let me try to explain, setting the Encryption Key bit in
the initiator key distribution field in the Pairing Request means that the
Initiator wants to send its Encryption Key to the Responder.
This is only useful in cases that both devices expect the roles to be reversed
in future connections (The Master of this connection would become the Slave in
future connections). And IIRC we weren't able to test this role reversal and
it even offends the current GAP spec for Dual mode devices.
>
> This seems to have changed at some point in the past, 2b64d153 added
> MITM mechanism and changed the init_key_dist member initialization
> from dist_keys to 0
>
>
> So two questions:
>
> 1) should BlueZ be able to behave as Master? It passes the majority
> of the tests except this one.
BlueZ should be able to bahave as Master, if not, it is a bug.
>
> 2) given the above, is this a bug that init_key_dist is 0 or is it a
> test plan error that it requires this?
I think it is a bit of both, for the current situation the Master distributing
its keys doesn't make much sense and we should be able to change this value to
be able to test the key distribution parts.
What I suggest is adding a debugfs entry to change the value of init_key_dist
for Pairing Requests, and keep the default being 0.
(disclaimer: I am follwing development from the sidelines for some time, so
feel free to correct me.)
>
> Scott
> --
> Scott James Remnant | Chrome OS Systems | [email protected] | Google
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Vinicius
Great, sounds like I came to the right conclusion myself - after
reading the spec and examining the test case, we couldn't find a
reason to set this bit unless BlueZ can also behave as the Slave,
which is not only something we didn't expect it to do, but also not
something we had claimed in the PICS.
I filed a TSE with the SIG on 11/25 and it looks like they agree too,
and that this test should only be used when a IUT specifies that it
supports both the Master and Slave role, so looks like the TSE will be
approved along with the matching TCW.
Scott
On Thu, Nov 28, 2013 at 8:59 AM, Vinicius Costa Gomes <[email protected]> wrote:
> Hi Scott,
>
> On 13:17 Mon 25 Nov, Scott James Remnant wrote:
>> We are able to pass all qualification tests with BlueZ as the Master except one:
>>
>> TP/KDU/BV-06-C - Master Key Distribution - Encryption Key bit
>>
>> This test requires that BlueZ initiates pairing with the
>> SMP_DIST_ENC_KEY bit set in the init_key_dist member of struct
>> smp_cmd_pairing - however this member is always initialized to zero
>> and never changed.
>
> This test is in theory correct, but it doesn't test anything that does make
> sense at this point. Let me try to explain, setting the Encryption Key bit in
> the initiator key distribution field in the Pairing Request means that the
> Initiator wants to send its Encryption Key to the Responder.
>
> This is only useful in cases that both devices expect the roles to be reversed
> in future connections (The Master of this connection would become the Slave in
> future connections). And IIRC we weren't able to test this role reversal and
> it even offends the current GAP spec for Dual mode devices.
>
>>
>> This seems to have changed at some point in the past, 2b64d153 added
>> MITM mechanism and changed the init_key_dist member initialization
>> from dist_keys to 0
>>
>>
>> So two questions:
>>
>> 1) should BlueZ be able to behave as Master? It passes the majority
>> of the tests except this one.
>
> BlueZ should be able to bahave as Master, if not, it is a bug.
>
>>
>> 2) given the above, is this a bug that init_key_dist is 0 or is it a
>> test plan error that it requires this?
>
> I think it is a bit of both, for the current situation the Master distributing
> its keys doesn't make much sense and we should be able to change this value to
> be able to test the key distribution parts.
>
> What I suggest is adding a debugfs entry to change the value of init_key_dist
> for Pairing Requests, and keep the default being 0.
>
> (disclaimer: I am follwing development from the sidelines for some time, so
> feel free to correct me.)
>
>>
>> Scott
>> --
>> Scott James Remnant | Chrome OS Systems | [email protected] | Google
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Cheers,
> --
> Vinicius
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google