kernel smp.c functions not called by Bluetootl LE controller

kernel smp.c functions not called by Bluetootl LE controller

[Martin Grothe]

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

Hi,
I try to call printk (with priority KERN_ALERT) functions placed in the
net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
output from specifc functions like:

static int smp_cmd_public_key()

But during a pairing with another bluetooth LE device the output of
these function is never shown in /var/log/kern.log

Is there any way to verify, that the LE Controller accesses the Security
Manager Protocol source code the Linux Kernel?

As far as I understood the Core Specification, in BT 4.0 an above the
Security Manager is always integrated in the Link Manager, when it comes
to BR/EDR. But for LE the SM is integrated in the Host part and not the
Controller. Thus LE Controller should access the smp.c in the Linux kernel.

Kind Regards,
Martin Grothe


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5481 bytes --]

Re: kernel smp.c functions not called by Bluetootl LE controller

[Marcel Holtmann]

Hi Martin,

> I try to call printk (with priority KERN_ALERT) functions placed in the
> net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
> output from specifc functions like:
> 
> static int smp_cmd_public_key()
> 
> But during a pairing with another bluetooth LE device the output of
> these function is never shown in /var/log/kern.log
> 
> Is there any way to verify, that the LE Controller accesses the Security
> Manager Protocol source code the Linux Kernel?
> 
> As far as I understood the Core Specification, in BT 4.0 an above the
> Security Manager is always integrated in the Link Manager, when it comes
> to BR/EDR. But for LE the SM is integrated in the Host part and not the
> Controller. Thus LE Controller should access the smp.c in the Linux kernel.

just run btmon and you see all the security manager exchanges.

Regards

Marcel

Re: kernel smp.c functions not called by Bluetootl LE controller

[Martin Grothe]

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

Am 20.07.2017 um 20:24 schrieb Marcel Holtmann:
> Hi Martin,
> 
>> I try to call printk (with priority KERN_ALERT) functions placed in the
>> net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
>> output from specifc functions like:
>>
>> static int smp_cmd_public_key()
>>
>> But during a pairing with another bluetooth LE device the output of
>> these function is never shown in /var/log/kern.log
>>
>> Is there any way to verify, that the LE Controller accesses the Security
>> Manager Protocol source code the Linux Kernel?
>>
>> As far as I understood the Core Specification, in BT 4.0 an above the
>> Security Manager is always integrated in the Link Manager, when it comes
>> to BR/EDR. But for LE the SM is integrated in the Host part and not the
>> Controller. Thus LE Controller should access the smp.c in the Linux kernel.
> 
> just run btmon and you see all the security manager exchanges.
> 
> Regards
> 
> Marcel
> 
Hi Marcel,
I tested it, and I saw some basic SMP messages, like:

Sent Pairing Request: Bonding, MITM, Initiator Key(s): LTK CSRK ,
Responder Key(s): LTK IRK CSRK

I get a response and a confirmation of the pairing afterwards, but I
don't see the key exchange, or the messages from Authentication Stage 1
or 2.

Is there any way to log parts of the smp.c functions into kern.log?

Kind Regards
Martin


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5481 bytes --]

Re: kernel smp.c functions not called by Bluetootl LE controller

[Marcel Holtmann]

Hi Martin,

>>> I try to call printk (with priority KERN_ALERT) functions placed in the
>>> net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
>>> output from specifc functions like:
>>> 
>>> static int smp_cmd_public_key()
>>> 
>>> But during a pairing with another bluetooth LE device the output of
>>> these function is never shown in /var/log/kern.log
>>> 
>>> Is there any way to verify, that the LE Controller accesses the Security
>>> Manager Protocol source code the Linux Kernel?
>>> 
>>> As far as I understood the Core Specification, in BT 4.0 an above the
>>> Security Manager is always integrated in the Link Manager, when it comes
>>> to BR/EDR. But for LE the SM is integrated in the Host part and not the
>>> Controller. Thus LE Controller should access the smp.c in the Linux kernel.
>> 
>> just run btmon and you see all the security manager exchanges.
>> 
>> Regards
>> 
>> Marcel
>> 
> Hi Marcel,
> I tested it, and I saw some basic SMP messages, like:
> 
> Sent Pairing Request: Bonding, MITM, Initiator Key(s): LTK CSRK ,
> Responder Key(s): LTK IRK CSRK
> 
> I get a response and a confirmation of the pairing afterwards, but I
> don't see the key exchange, or the messages from Authentication Stage 1
> or 2.
> 
> Is there any way to log parts of the smp.c functions into kern.log?

just send the file created via "btmon -w trace.log" and I can tell you what is going on here. My guess is that you do not have LE SC enabled. That means legacy pairing is happening which does not using public key exchange.

Regards

Marcel

Re: kernel smp.c functions not called by Bluetootl LE controller

[Marcel Holtmann]

Hi Martin,

>>>> I try to call printk (with priority KERN_ALERT) functions placed in the
>>>> net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
>>>> output from specifc functions like:
>>>> 
>>>> static int smp_cmd_public_key()
>>>> 
>>>> But during a pairing with another bluetooth LE device the output of
>>>> these function is never shown in /var/log/kern.log
>>>> 
>>>> Is there any way to verify, that the LE Controller accesses the Security
>>>> Manager Protocol source code the Linux Kernel?
>>>> 
>>>> As far as I understood the Core Specification, in BT 4.0 an above the
>>>> Security Manager is always integrated in the Link Manager, when it comes
>>>> to BR/EDR. But for LE the SM is integrated in the Host part and not the
>>>> Controller. Thus LE Controller should access the smp.c in the Linux kernel.
>>> 
>>> just run btmon and you see all the security manager exchanges.
>>> 
>>> Regards
>>> 
>>> Marcel
>>> 
>> Hi Marcel,
>> I tested it, and I saw some basic SMP messages, like:
>> 
>> Sent Pairing Request: Bonding, MITM, Initiator Key(s): LTK CSRK ,
>> Responder Key(s): LTK IRK CSRK
>> 
>> I get a response and a confirmation of the pairing afterwards, but I
>> don't see the key exchange, or the messages from Authentication Stage 1
>> or 2.
>> 
>> Is there any way to log parts of the smp.c functions into kern.log?
> 
> just send the file created via "btmon -w trace.log" and I can tell you what is going on here. My guess is that you do not have LE SC enabled. That means legacy pairing is happening which does not using public key exchange.

< ACL Data TX: Handle 3585 flags 0x00 dlen 11
      SMP: Pairing Request (0x01) len 6
        IO capability: DisplayYesNo (0x01)
        OOB data: Authentication data not present (0x00)
        Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
        Max encryption key size: 16
        Initiator key distribution: EncKey Sign (0x05)
        Responder key distribution: EncKey IdKey Sign (0x07)
> ACL Data RX: Handle 3585 flags 0x02 dlen 11
      SMP: Pairing Response (0x02) len 6
        IO capability: NoInputNoOutput (0x03)
        OOB data: Authentication data not present (0x00)
        Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)
        Max encryption key size: 16
        Initiator key distribution: Sign (0x04)
        Responder key distribution: EncKey IdKey (0x03)

So while your Linux side supports LE SC, your remote side only supports legacy pairing. Which means no public key exchange will happen,

The LTK information is distributed instead of locally derived as with LE SC that uses ECDH.

> ACL Data RX: Handle 3585 flags 0x02 dlen 21
      SMP: Encryption Information (0x06) len 16
        Long term key: 8eb620e0cf2f490b9a174777d45c57b3
> ACL Data RX: Handle 3585 flags 0x02 dlen 15
      SMP: Master Identification (0x07) len 10
        EDIV: 0x4be8
        Rand: 0xf9cd7eb564bf38b9

Btw. I have yet to see a LE HID device that uses LE SC.

Regards

Marcel

Re: kernel smp.c functions not called by Bluetootl LE controller

[Martin Grothe]

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

Am 21.07.2017 um 13:41 schrieb Marcel Holtmann:
> Hi Martin,
> 
>>>>> I try to call printk (with priority KERN_ALERT) functions placed in the
>>>>> net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
>>>>> output from specifc functions like:
>>>>>
>>>>> static int smp_cmd_public_key()
>>>>>
>>>>> But during a pairing with another bluetooth LE device the output of
>>>>> these function is never shown in /var/log/kern.log
>>>>>
>>>>> Is there any way to verify, that the LE Controller accesses the Security
>>>>> Manager Protocol source code the Linux Kernel?
>>>>>
>>>>> As far as I understood the Core Specification, in BT 4.0 an above the
>>>>> Security Manager is always integrated in the Link Manager, when it comes
>>>>> to BR/EDR. But for LE the SM is integrated in the Host part and not the
>>>>> Controller. Thus LE Controller should access the smp.c in the Linux kernel.
>>>>
>>>> just run btmon and you see all the security manager exchanges.
>>>>
>>>> Regards
>>>>
>>>> Marcel
>>>>
>>> Hi Marcel,
>>> I tested it, and I saw some basic SMP messages, like:
>>>
>>> Sent Pairing Request: Bonding, MITM, Initiator Key(s): LTK CSRK ,
>>> Responder Key(s): LTK IRK CSRK
>>>
>>> I get a response and a confirmation of the pairing afterwards, but I
>>> don't see the key exchange, or the messages from Authentication Stage 1
>>> or 2.
>>>
>>> Is there any way to log parts of the smp.c functions into kern.log?
>>
>> just send the file created via "btmon -w trace.log" and I can tell you what is going on here. My guess is that you do not have LE SC enabled. That means legacy pairing is happening which does not using public key exchange.
> 
> < ACL Data TX: Handle 3585 flags 0x00 dlen 11
>       SMP: Pairing Request (0x01) len 6
>         IO capability: DisplayYesNo (0x01)
>         OOB data: Authentication data not present (0x00)
>         Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
>         Max encryption key size: 16
>         Initiator key distribution: EncKey Sign (0x05)
>         Responder key distribution: EncKey IdKey Sign (0x07)
>> ACL Data RX: Handle 3585 flags 0x02 dlen 11
>       SMP: Pairing Response (0x02) len 6
>         IO capability: NoInputNoOutput (0x03)
>         OOB data: Authentication data not present (0x00)
>         Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)
>         Max encryption key size: 16
>         Initiator key distribution: Sign (0x04)
>         Responder key distribution: EncKey IdKey (0x03)
> 
> So while your Linux side supports LE SC, your remote side only supports legacy pairing. Which means no public key exchange will happen,
> 
> The LTK information is distributed instead of locally derived as with LE SC that uses ECDH.
> 
>> ACL Data RX: Handle 3585 flags 0x02 dlen 21
>       SMP: Encryption Information (0x06) len 16
>         Long term key: 8eb620e0cf2f490b9a174777d45c57b3
>> ACL Data RX: Handle 3585 flags 0x02 dlen 15
>       SMP: Master Identification (0x07) len 10
>         EDIV: 0x4be8
>         Rand: 0xf9cd7eb564bf38b9
> 
> Btw. I have yet to see a LE HID device that uses LE SC.
> 
> Regards
> 
> Marcel
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Thanks again for the help.

Is there any BE/EDR controller out there, which is open source/hardware
and which source code can be modified?

Kind Regards,
Martin


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5481 bytes --]

Re: kernel smp.c functions not called by Bluetootl LE controller

[Marcel Holtmann]

Hi Martin,

>>>>>> I try to call printk (with priority KERN_ALERT) functions placed in the
>>>>>> net/bluetooth/smp.c file of my linux kernel 4.9.35 in order to get
>>>>>> output from specifc functions like:
>>>>>> 
>>>>>> static int smp_cmd_public_key()
>>>>>> 
>>>>>> But during a pairing with another bluetooth LE device the output of
>>>>>> these function is never shown in /var/log/kern.log
>>>>>> 
>>>>>> Is there any way to verify, that the LE Controller accesses the Security
>>>>>> Manager Protocol source code the Linux Kernel?
>>>>>> 
>>>>>> As far as I understood the Core Specification, in BT 4.0 an above the
>>>>>> Security Manager is always integrated in the Link Manager, when it comes
>>>>>> to BR/EDR. But for LE the SM is integrated in the Host part and not the
>>>>>> Controller. Thus LE Controller should access the smp.c in the Linux kernel.
>>>>> 
>>>>> just run btmon and you see all the security manager exchanges.
>>>>> 
>>>>> Regards
>>>>> 
>>>>> Marcel
>>>>> 
>>>> Hi Marcel,
>>>> I tested it, and I saw some basic SMP messages, like:
>>>> 
>>>> Sent Pairing Request: Bonding, MITM, Initiator Key(s): LTK CSRK ,
>>>> Responder Key(s): LTK IRK CSRK
>>>> 
>>>> I get a response and a confirmation of the pairing afterwards, but I
>>>> don't see the key exchange, or the messages from Authentication Stage 1
>>>> or 2.
>>>> 
>>>> Is there any way to log parts of the smp.c functions into kern.log?
>>> 
>>> just send the file created via "btmon -w trace.log" and I can tell you what is going on here. My guess is that you do not have LE SC enabled. That means legacy pairing is happening which does not using public key exchange.
>> 
>> < ACL Data TX: Handle 3585 flags 0x00 dlen 11
>>      SMP: Pairing Request (0x01) len 6
>>        IO capability: DisplayYesNo (0x01)
>>        OOB data: Authentication data not present (0x00)
>>        Authentication requirement: Bonding, MITM, SC, No Keypresses (0x0d)
>>        Max encryption key size: 16
>>        Initiator key distribution: EncKey Sign (0x05)
>>        Responder key distribution: EncKey IdKey Sign (0x07)
>>> ACL Data RX: Handle 3585 flags 0x02 dlen 11
>>      SMP: Pairing Response (0x02) len 6
>>        IO capability: NoInputNoOutput (0x03)
>>        OOB data: Authentication data not present (0x00)
>>        Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)
>>        Max encryption key size: 16
>>        Initiator key distribution: Sign (0x04)
>>        Responder key distribution: EncKey IdKey (0x03)
>> 
>> So while your Linux side supports LE SC, your remote side only supports legacy pairing. Which means no public key exchange will happen,
>> 
>> The LTK information is distributed instead of locally derived as with LE SC that uses ECDH.
>> 
>>> ACL Data RX: Handle 3585 flags 0x02 dlen 21
>>      SMP: Encryption Information (0x06) len 16
>>        Long term key: 8eb620e0cf2f490b9a174777d45c57b3
>>> ACL Data RX: Handle 3585 flags 0x02 dlen 15
>>      SMP: Master Identification (0x07) len 10
>>        EDIV: 0x4be8
>>        Rand: 0xf9cd7eb564bf38b9
>> 
>> Btw. I have yet to see a LE HID device that uses LE SC.
> 
> Thanks again for the help.
> 
> Is there any BE/EDR controller out there, which is open source/hardware
> and which source code can be modified?

for LE, the support is inside the host. For BR/EDR it is in the controller. I do not know of any open source controller for BR/EDR. We only have open source code for LE controller in Zephyr.

Regards

Marcel