Re: BTLE pairing sequence problem

Re: BTLE pairing sequence problem

[Andrew -]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

> why don't you look at the source code. We have a smp_c1() in net/bluetooth/smp.c in \
> the kernel (including actual test vectors). And there is also bt_crypto_c1() in \
> src/shared/crypto.c in BlueZ userspace.

Shame on me, but static analysis of the kernel code has never been a
strong point of mine.
So, the only built-in test case for smp_c1() that I found is called
test_c1(), and it contains the very case described in the standard.

As for userspace tools, I found out that they yield same results as my
code (and the former kernel code, apparently): see the attached source
file. When the second, real-life test case is commented out,
everything is ok.
Unfortunately, none of the uses of bt_crypto_c1() explain why calling
it with inputs set to legitimate values and exact packet captures does
not produce the captured result. Everything seems to comply, and I`m
sure that the problem is some insanely subtle detail I fail to
understand.

> And on a side note, the PDUs from pairing request / response need to fed into c1 as \
> they are received over the air. Meaning you can not mask out bits and then feed it \
> in. That has been clarified in an erratum and especially important for LE Secure \
> Connections (which Linux does support).

Exactly as I do, actually.
Or do I? Are these request/response packet dumps I got on my capture
the ones that have to be put into _pres and _preq variables from the
code attached?

[-- Attachment #2: btle.c --]
[-- Type: text/x-csrc, Size: 1860 bytes --]

#include <stdio.h>
#include "src/shared/util.h"
#include "src/shared/crypto.h"

int main() {
    uint8_t retn[16] = {}, conf[16] = {}, _mrand[16] = {};
    uint8_t _preq[7] = {}, _pres[7] = {};
    uint8_t _ia[6] = {}, _ra[6] = {};
    uint8_t _iat = 0, _rat = 0;
    uint32_t _code = 0;

    /// example from standard:
    _code = 000000;
    _iat = 0x01;
    _rat = 0x00;
    memcpy(&_ia, "\xA6\xA5\xA4\xA3\xA2\xA1", sizeof(_ia)); /// str2ba("A1:A2:A3:A4:A5:A6", &);
    memcpy(&_ra, "\xB6\xB5\xB4\xB3\xB2\xB1", sizeof(_ra)); /// str2ba("B1:B2:B3:B4:B5:B6", &);
    memcpy(&_preq, "\x01\x01\x00\x00\x10\x07\x07", sizeof(_preq));
    memcpy(&_pres, "\x02\x03\x00\x00\x08\x00\x05", sizeof(_pres));
    memcpy(_mrand, "\xE0\x2E\x70\xC6\x4E\x27\x88\x63\x0E\x6F\xAD\x56\x21\xD5\x83\x57", sizeof(_mrand));
    memcpy(conf, "\x86\x3B\xF1\xBE\xC5\x4D\xA7\xD2\xEA\x88\x89\x87\xEF\x3F\x1E\x1E", sizeof(conf));

//*  /// real example:
    _code = 415188;
    _iat = 0x01;
    _rat = 0x01;
    memcpy(&_ia, "\xC4\x30\x19\x3A\x5A\x30", sizeof(_ia)); /// str2ba("30:5A:3A:19:30:C4", &);
    memcpy(&_ra, "\xB9\x97\x2D\x5B\xC3\xC1", sizeof(_ra)); /// str2ba("C1:C3:5B:2D:97:B9", &);
    memcpy(&_preq, "\x01\x01\x00\x05\x10\x07\x07", sizeof(_preq));
    memcpy(&_pres, "\x02\x02\x00\x05\x10\x06\x03", sizeof(_pres));
    memcpy(_mrand, "\xDB\x7A\x48\xD9\xC5\x1F\x76\x43\x9C\xE4\x00\x56\x84\xF4\xE7\x1B", sizeof(_mrand));
    memcpy(conf, "\xEF\xDC\x1C\x63\xAF\x8B\x97\x1D\xFC\x35\x1F\x1D\x26\x21\x60\xFC", sizeof(conf));
//*/

    uint8_t k[16] = {};

    put_le32(_code, k);
    bt_crypto_c1(bt_crypto_new(), k, _mrand, &_pres, &_preq, _iat, &_ia, _rat, &_ra, retn);
    util_hexdump('\n', retn, sizeof(retn), printf, 0);
    util_hexdump('\n', conf, sizeof(conf), printf, 0);
    printf("\n\n %s!\n", (memcmp(retn, conf, sizeof(retn)))? "FAIL" : "PASS");
    return 0;
}

Re: BTLE pairing sequence problem

[Luiz Augusto von Dentz]

Hi Andrew,

On Sun, Mar 6, 2016 at 1:16 AM, Andrew - <hidefromkgb@gmail.com> wrote:
>> why don't you look at the source code. We have a smp_c1() in net/bluetooth/smp.c in \
>> the kernel (including actual test vectors). And there is also bt_crypto_c1() in \
>> src/shared/crypto.c in BlueZ userspace.
>
> Shame on me, but static analysis of the kernel code has never been a
> strong point of mine.
> So, the only built-in test case for smp_c1() that I found is called
> test_c1(), and it contains the very case described in the standard.
>
> As for userspace tools, I found out that they yield same results as my
> code (and the former kernel code, apparently): see the attached source
> file. When the second, real-life test case is commented out,
> everything is ok.
> Unfortunately, none of the uses of bt_crypto_c1() explain why calling
> it with inputs set to legitimate values and exact packet captures does
> not produce the captured result. Everything seems to comply, and I`m
> sure that the problem is some insanely subtle detail I fail to
> understand.
>
>> And on a side note, the PDUs from pairing request / response need to fed into c1 as \
>> they are received over the air. Meaning you can not mask out bits and then feed it \
>> in. That has been clarified in an erratum and especially important for LE Secure \
>> Connections (which Linux does support).
>
> Exactly as I do, actually.
> Or do I? Are these request/response packet dumps I got on my capture
> the ones that have to be put into _pres and _preq variables from the
> code attached?

I don't remember having any problems pairing the Designer Keyboard,
how did you actually connected to it? Note, recently there was a
problem with GATT services where errors such as authentication
required did not elevate the security which in turn would cause an
attempt to pair if not paired yet, perhaps that is the source of your
problem here, however if you did call Device.Pair that should start
the pairing procedure immediately.

-- 
Luiz Augusto von Dentz

Re: BTLE pairing sequence problem

[Andrew -]

> I don't remember having any problems pairing the Designer Keyboard, how did you actually connected to it?
$ bluetoothctl
[NEW] Controller 00:08:CA:E7:CD:35 UX31E [default]
[NEW] Device E8:12:16:14:E0:20 Designer Mouse
[NEW] Device C1:C3:5B:2E:97:B9 Designer Keyboard
[bluetooth]# agent DisplayYesNo
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# pair C1:C3:5B:2E:97:B9
Attempting to pair with C1:C3:5B:2E:97:B9
[CHG] Device C1:C3:5B:2E:97:B9 Connected: yes
[Designer Keyboard]# connect C1:C3:5B:2E:97:B9
Attempting to connect to C1:C3:5B:2E:97:B9
Connection successful
[bluetooth]#

And that`s pretty much the end. The «Ready to connect» LED still
flashes and no input can be retrieved from the keyboard.

dmesg shows its usual line:
[180261.398350] Bluetooth: SMP security requested but not available

Re: BTLE pairing sequence problem

[Luiz Augusto von Dentz]

Hi Andrew,

On Mon, Mar 7, 2016 at 4:27 PM, Andrew - <hidefromkgb@gmail.com> wrote:
>> I don't remember having any problems pairing the Designer Keyboard, how did you actually connected to it?
> $ bluetoothctl
> [NEW] Controller 00:08:CA:E7:CD:35 UX31E [default]
> [NEW] Device E8:12:16:14:E0:20 Designer Mouse
> [NEW] Device C1:C3:5B:2E:97:B9 Designer Keyboard
> [bluetooth]# agent DisplayYesNo
> Agent registered
> [bluetooth]# default-agent
> Default agent request successful
> [bluetooth]# pair C1:C3:5B:2E:97:B9
> Attempting to pair with C1:C3:5B:2E:97:B9
> [CHG] Device C1:C3:5B:2E:97:B9 Connected: yes
> [Designer Keyboard]# connect C1:C3:5B:2E:97:B9
> Attempting to connect to C1:C3:5B:2E:97:B9
> Connection successful
> [bluetooth]#
>
> And that`s pretty much the end. The «Ready to connect» LED still
> flashes and no input can be retrieved from the keyboard.
>
> dmesg shows its usual line:
> [180261.398350] Bluetooth: SMP security requested but not available

I think your problem start way before then, checking the logs this is
where that check got introduced:

Bluetooth: Fix NULL pointer dereference in smp_conn_security
The l2cap_conn->smp pointer may be NULL for various valid reasons where SMP has
failed to initialize properly. One such scenario is when crypto support is
missing, another when the adapter has been powered on through a legacy method.
The smp_conn_security() function should have the appropriate check for this
situation to avoid NULL pointer dereferences.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 4.0+

Perhaps you are missing the crypto support?

-- 
Luiz Augusto von Dentz

Re: BTLE pairing sequence problem

[Andrew -]

> I think your problem start way before then

Fair enough. There was an udev rule that enabled my bluetooth module
manually, circumventing the standard procedure (suggested on Arch Wiki
several years ago, obsolete by now).
So now the rule`s gone so pairing and encryption complete
successfully. First victory!

However, there`s still no input from the keyboard. Even after the
connection was estabilished properly, Wireshark is silent when I press
keys on the keyboard.

Re: BTLE pairing sequence problem

[Andrew -]

OK guys, this last step (registering as a HID device) I managed to make myself.

The problem seems to be that the keyboard was being registered as a
pointer in XInput, again due to outdated config in /etc/xorg.conf.d
that defined everything in /dev/input/* as pointers unless explicitly
told not to.

Problem solved. Thank you so much!

2016-03-07 22:06 GMT+03:00, Andrew - <hidefromkgb@gmail.com>:
>> I think your problem start way before then
>
> Fair enough. There was an udev rule that enabled my bluetooth module
> manually, circumventing the standard procedure (suggested on Arch Wiki
> several years ago, obsolete by now).
> So now the rule`s gone so pairing and encryption complete
> successfully. First victory!
>
> However, there`s still no input from the keyboard. Even after the
> connection was estabilished properly, Wireshark is silent when I press
> keys on the keyboard.
>

BTLE pairing sequence problem

[Andrew -]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Hello. I`m using BlueZ 5.37 on Arch Linux 4.4.3 and I`ve got problems
pairing a Bluetooth 4.0 LE device, Microsoft Designer Keyboard.

As it turns out, the kernel side of BlueZ can not initiate BTLE
pairing sequence on my machine (probably due to
https://bugzilla.kernel.org/show_bug.cgi?id=104011 bug: at least, the
message 'Bluetooth: SMP security requested but not available' does
appear in dmesg), so I decided to try and implement it myself in user
mode.
I did not yet apply the «untested» patch proposed, since first I want
to understand what exactly I`m doing wrong.

I`ve written an utility that sends BTLE pairing messages and analyzes replies.
It does pass the test from Vol.3, p.602 (p.1962 of the official
all-in-one PDF) of the standard which states that
c1(0x00, 0x5783D52156AD6F0E6388274EC6702EE0, 0x07071000000101,
0x05000800000302, 0x01, 0x00, 0xA1A2A3A4A5A6, 0xB1B2B3B4B5B6) =
0x1E1E3FEF878988EAD2A74DC5BEF13B86

However, my implementation of c1() does not return the value that the
real MS Designer Keyboard wants, despite having been written by the
standard and returning exact same results as CrackLE`s c1(), for
example.
This indicates that the problem is due to me passing wrong input.

Fortunately, I`ve got an Android smartphone that computes the
confirmation value correctly, and the capture log shows that
c1(0x0655D4, 0x1BE7F4845600E49C43761FC5D9487ADB, 0x07071005000101,
0x03061005000202, 0x01, 0x01, 0x305A3A1930C4, 0xC1C35B2D97B9) =
0xFC6021261D1F35FC1D978BAF631CDCEF

My question is: how`s that possible?
I`ve tried all 2^7 different combinations of byte orderings for every
PIN value (yielding 128 000 000 combinations in total), but I`m
positively unable to make c1() produce the result needed.
Can you please show how to feed the data to c1() properly?

The HCI packet log that confirms my words is attached; the PIN shall be 415188.

[-- Attachment #2: btle.cap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 1156 bytes --]

Re: BTLE pairing sequence problem

[Marcel Holtmann]

Hi Andrew,

> Hello. I`m using BlueZ 5.37 on Arch Linux 4.4.3 and I`ve got problems
> pairing a Bluetooth 4.0 LE device, Microsoft Designer Keyboard.
> 
> As it turns out, the kernel side of BlueZ can not initiate BTLE
> pairing sequence on my machine (probably due to
> https://bugzilla.kernel.org/show_bug.cgi?id=104011 bug: at least, the
> message 'Bluetooth: SMP security requested but not available' does
> appear in dmesg), so I decided to try and implement it myself in user
> mode.
> I did not yet apply the «untested» patch proposed, since first I want
> to understand what exactly I`m doing wrong.
> 
> I`ve written an utility that sends BTLE pairing messages and analyzes replies.
> It does pass the test from Vol.3, p.602 (p.1962 of the official
> all-in-one PDF) of the standard which states that
> c1(0x00, 0x5783D52156AD6F0E6388274EC6702EE0, 0x07071000000101,
> 0x05000800000302, 0x01, 0x00, 0xA1A2A3A4A5A6, 0xB1B2B3B4B5B6) =
> 0x1E1E3FEF878988EAD2A74DC5BEF13B86
> 
> However, my implementation of c1() does not return the value that the
> real MS Designer Keyboard wants, despite having been written by the
> standard and returning exact same results as CrackLE`s c1(), for
> example.
> This indicates that the problem is due to me passing wrong input.
> 
> Fortunately, I`ve got an Android smartphone that computes the
> confirmation value correctly, and the capture log shows that
> c1(0x0655D4, 0x1BE7F4845600E49C43761FC5D9487ADB, 0x07071005000101,
> 0x03061005000202, 0x01, 0x01, 0x305A3A1930C4, 0xC1C35B2D97B9) =
> 0xFC6021261D1F35FC1D978BAF631CDCEF
> 
> My question is: how`s that possible?
> I`ve tried all 2^7 different combinations of byte orderings for every
> PIN value (yielding 128 000 000 combinations in total), but I`m
> positively unable to make c1() produce the result needed.
> Can you please show how to feed the data to c1() properly?

why don't you look at the source code. We have a smp_c1() in net/bluetooth/smp.c in the kernel (including actual test vectors). And there is also bt_crypto_c1() in src/shared/crypto.c in BlueZ userspace.

And on a side note, the PDUs from pairing request / response need to fed into c1 as they are received over the air. Meaning you can not mask out bits and then feed it in. That has been clarified in an erratum and especially important for LE Secure Connections (which Linux does support).

Regards

Marcel