Bluetooth socket timeout, device pairing

[Oliver Fromme]

Hello,

My Bluetooth Python module basically works now.
However, I've got one small problem with pairing ...

I have entered an 8-character PIN code in hcsecd.conf.
When I try to open a connection for the first time,
the device (i.e. my Mindstorms NXT brick) asks me to
enter the PIN code.  However, entering the code on
the brick takes some time ...  I have to scroll
through the alphabet and digits which is rather slow.
I can enter at most 4 characters of the PIN code
before the socket() call returns with ECONN
("Connection refused").

For now I'm using a short 4-character PIN code, but
I would really like to use a longer one.  Where is
the timeout defined for that?

Python's socket module has no timeout by default.
I've also searched the net.bluetooth sysctls and
increased all of the timeout values (half a dozen),
but none of them seemed to have an effect on this
particular problem.  So I think this value must be
hardcoded somewhere.  Where do I have to look?

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If Java had true garbage collection, most programs
would delete themselves upon execution."
        -- Robert Sewell
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

Oliver,

> My Bluetooth Python module basically works now.
> However, I've got one small problem with pairing ...
>
> I have entered an 8-character PIN code in hcsecd.conf.
> When I try to open a connection for the first time,
> the device (i.e. my Mindstorms NXT brick) asks me to
> enter the PIN code.  However, entering the code on
> the brick takes some time ...  I have to scroll
> through the alphabet and digits which is rather slow.
> I can enter at most 4 characters of the PIN code
> before the socket() call returns with ECONN
> ("Connection refused").
>
> For now I'm using a short 4-character PIN code, but
> I would really like to use a longer one.  Where is
> the timeout defined for that?

its so called "LMP (link manager protocol) response timeout". its
defined in link manager, i.e. part of the device's firmware. v1.1 spec
seems to be implying that LMP response timeout should be set to 30
sec.

> Python's socket module has no timeout by default.
> I've also searched the net.bluetooth sysctls and
> increased all of the timeout values (half a dozen),
> but none of them seemed to have an effect on this
> particular problem.  So I think this value must be
> hardcoded somewhere.  Where do I have to look?

i'm afraid that you can not change LMP response timeout. there isn't
any defined command that would do that. i'm not sure why do you care
much about pin length. pin is only used once to generate link key and
as soon as link key is generated both devices should use it instead of
pin.

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Oliver Fromme]

Hello Max,

Maksim Yevmenkin wrote:
 > Oliver,
 >
 > > My Bluetooth Python module basically works now.
 > > However, I've got one small problem with pairing ...
 > >
 > > I have entered an 8-character PIN code in hcsecd.conf.
 > > When I try to open a connection for the first time,
 > > the device (i.e. my Mindstorms NXT brick) asks me to
 > > enter the PIN code.  However, entering the code on
 > > the brick takes some time ...  I have to scroll
 > > through the alphabet and digits which is rather slow.
 > > I can enter at most 4 characters of the PIN code
 > > before the socket() call returns with ECONN
 > > ("Connection refused").
 > >
 > > For now I'm using a short 4-character PIN code, but
 > > I would really like to use a longer one.  Where is
 > > the timeout defined for that?
 >
 > its so called "LMP (link manager protocol) response timeout". its
 > defined in link manager, i.e. part of the device's firmware. v1.1 spec
 > seems to be implying that LMP response timeout should be set to 30
 > sec.
 >
 > > Python's socket module has no timeout by default.
 > > I've also searched the net.bluetooth sysctls and
 > > increased all of the timeout values (half a dozen),
 > > but none of them seemed to have an effect on this
 > > particular problem.  So I think this value must be
 > > hardcoded somewhere.  Where do I have to look?
 >
 > i'm afraid that you can not change LMP response timeout. there isn't
 > any defined command that would do that. i'm not sure why do you care
 > much about pin length. pin is only used once to generate link key and
 > as soon as link key is generated both devices should use it instead of
 > pin.

Thankyou very much for the explanation.

It was my impression that the length of the PIN code has
to do with the security (i.e. the longer, the better).
It seems I was wrong.

Is it correct that it would even be secure enough to use
the public default factory PIN code of the device ("1234")?
In that case I could skip the whole business of entering
a PIN code ...

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"I have stopped reading Stephen King novels.
Now I just read C code instead."
        -- Richard A. O'Keefe
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

Oliver,

[...]

>  > > I have entered an 8-character PIN code in hcsecd.conf.
>  > > When I try to open a connection for the first time,
>  > > the device (i.e. my Mindstorms NXT brick) asks me to
>  > > enter the PIN code.  However, entering the code on
>  > > the brick takes some time ...  I have to scroll
>  > > through the alphabet and digits which is rather slow.
>  > > I can enter at most 4 characters of the PIN code
>  > > before the socket() call returns with ECONN
>  > > ("Connection refused").
>  > >
>  > > For now I'm using a short 4-character PIN code, but
>  > > I would really like to use a longer one.  Where is
>  > > the timeout defined for that?
>  >
>  > its so called "LMP (link manager protocol) response timeout". its
>  > defined in link manager, i.e. part of the device's firmware. v1.1 spec
>  > seems to be implying that LMP response timeout should be set to 30
>  > sec.
>  >
>  > > Python's socket module has no timeout by default.
>  > > I've also searched the net.bluetooth sysctls and
>  > > increased all of the timeout values (half a dozen),
>  > > but none of them seemed to have an effect on this
>  > > particular problem.  So I think this value must be
>  > > hardcoded somewhere.  Where do I have to look?
>  >
>  > i'm afraid that you can not change LMP response timeout. there isn't
>  > any defined command that would do that. i'm not sure why do you care
>  > much about pin length. pin is only used once to generate link key and
>  > as soon as link key is generated both devices should use it instead of
>  > pin.
>
> Thankyou very much for the explanation.
>
> It was my impression that the length of the PIN code has
> to do with the security (i.e. the longer, the better).
> It seems I was wrong.

depending on your definition of "security" you may be right :) simply
put, pin code is not the only thing that is used to generate
initialization link key. there is something (in bluetooth spec) that
is called e2 key generation function. it can operate in 2 modes, and
mode 2, often referred as e22, is used to generate initialization link
key from pin. e22 accepts 128-bit random value and pin code augmented
with device's bd_addr. the output of the e22 function is 128-bit key.
in mode 1, e2, often referred as e21, takes 128-bit random value and
48-bit bd_addr and outputs 128-bit key.

for more details please take a look at section 14 "bluetooth security"
of part B "baseband specification" of bluetooth v1.1 specification
book.

> Is it correct that it would even be secure enough to use
> the public default factory PIN code of the device ("1234")?
> In that case I could skip the whole business of entering
> a PIN code ...

again, it depends on your definition of "secure enough" :) "fixed"
pins are most certainly have been around for a while. pretty much any
bluetooth gadget with limited input capabilities/user interface
usually has "fixed" pin. two examples on top of my head are bluetooth
headsets and bluetooth gps'es (most of them come with hardwired pin of
"0000" or something like that).

keep in mind that short rf range, point-to-point nature and absence of
"promiscuous mode" on of-the-shelf bluetooth devices make bluetooth
somewhat more "secure" than, say, 802.11. even if it is "security
through obscurity". also "pairing" is something that must be initiated
manually on both sides.

<off topic>
in my personal opinion, link level encryption is almost always a bad
idea. especially when link layer is exposed like rf. at link layer one
does not usually have enough information/resources/etc. to do a good
crypto. good auth/crypto is something that upper layer protocols
should do.
</off topic>

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Iain Hibbert]

On Thu, 18 Dec 2008, Maksim Yevmenkin wrote:
> Oliver Fromme writes:
> > When I try to open a connection for the first time,
> > the device (i.e. my Mindstorms NXT brick) asks me to
> > enter the PIN code.
>
> its so called "LMP (link manager protocol) response timeout". its
> defined in link manager, i.e. part of the device's firmware. v1.1 spec
> seems to be implying that LMP response timeout should be set to 30
> sec.

It could be that its not the LMP timeout that is causing the connection to
be terminated though -- I never read that part of the spec but there are a
bunch of other timeouts that could cause the problem depending on how the
pairing is initiated?

HCI Page Timeout
  time given for remote device to respond to HCI connection attempt

L2CAP response timeout
  L2CAP control packet times out after this time.

RFCOMM mcc/ack timeout

and I find that on NetBSD I don't really think I've got it right, because
the timeouts can trigger too fast. Eg, the default L2CAP response timeout
is 20 seconds but the L2CAP connect request will often trigger a link code
request then pin code request and entering the pin will take it over the
limit..

(pairing is not needed often so I pushed this to the back of my mind :)

I notice that some phone software has a 'pairing' function, where they can
just pair with the remote hardware and not try to make higher level
connections. Perhaps this kind of thing would work (ie just use hccontrol
to create a baseband connection) to avoid any higher level protocol
timeouts?

> i'm not sure why do you care much about pin length. pin is only used
> once to generate link key and as soon as link key is generated both
> devices should use it instead of pin.

more complex PIN does apparently mean more secure link key.

I wonder though, if "Change Connection Link Key" (not in hccontrol IIRC?)
can be used to make the link key more secure without needing to pair with
a complex PIN.. presumably it generates a new link key based on some kind
of random value exchanged over the already secure connection?

iain

ps I am also wondering, what kind of evil lego machine it is that Oliver
is making that he requires ultimate security on the command channel :)


_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Oliver Fromme]

Hello Max,

Maksim Yevmenkin wrote:
 > [...]
 > >
 > > It was my impression that the length of the PIN code has
 > > to do with the security (i.e. the longer, the better).
 > > It seems I was wrong.
 >
 > depending on your definition of "security" you may be right :) simply
 > put, pin code is not the only thing that is used to generate
 > initialization link key. there is something (in bluetooth spec) that
 > is called e2 key generation function. it can operate in 2 modes, and
 > mode 2, often referred as e22, is used to generate initialization link
 > key from pin. e22 accepts 128-bit random value and pin code augmented
 > with device's bd_addr. the output of the e22 function is 128-bit key.
 > in mode 1, e2, often referred as e21, takes 128-bit random value and
 > 48-bit bd_addr and outputs 128-bit key.
 >
 > for more details please take a look at section 14 "bluetooth security"
 > of part B "baseband specification" of bluetooth v1.1 specification
 > book.
 >
 > > Is it correct that it would even be secure enough to use
 > > the public default factory PIN code of the device ("1234")?
 > > In that case I could skip the whole business of entering
 > > a PIN code ...
 >
 > again, it depends on your definition of "secure enough" :) "fixed"
 > pins are most certainly have been around for a while. pretty much any
 > bluetooth gadget with limited input capabilities/user interface
 > usually has "fixed" pin. two examples on top of my head are bluetooth
 > headsets and bluetooth gps'es (most of them come with hardwired pin of
 > "0000" or something like that).
 >
 > keep in mind that short rf range, point-to-point nature and absence of
 > "promiscuous mode" on of-the-shelf bluetooth devices make bluetooth
 > somewhat more "secure" than, say, 802.11. even if it is "security
 > through obscurity". also "pairing" is something that must be initiated
 > manually on both sides.
 >
 > <off topic>
 > in my personal opinion, link level encryption is almost always a bad
 > idea. especially when link layer is exposed like rf. at link layer one
 > does not usually have enough information/resources/etc. to do a good
 > crypto. good auth/crypto is something that upper layer protocols
 > should do.
 > </off topic>

Thanks again for the insight.  Now I understand much better
how the PIN codes are used.

Well, the device I'm using is just a little toy, basically
(a programmable Lego robot element), so security is not on
top of my priorities.  So I will continue to use my custom
4-character PIN code.  :-)

But still, I'm surprised that PIN codes up to 16 characters
are supported (and this device explicitely supports custom
PIN codes that long), but there's no way you can enter more
than 4 characters on the device before the connect timeout
expires.  Well, maybe 5 or 6 if the characters are close to
each other in the alphabet, so you don't have to scroll
that much.

I guess it's something that the designes of the device
just did not take into account.  Maybe they assumed that
everyone will use the factory default PIN code.  Maybe
I'm just too paranoid.  :-)

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If you aim the gun at your foot and pull the trigger, it's
UNIX's job to ensure reliable delivery of the bullet to
where you aimed the gun (in this case, Mr. Foot)."
        -- Terry Lambert, FreeBSD-hackers mailing list.
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Maksim Yevmenkin-2]

Iain,

>> > When I try to open a connection for the first time,
>> > the device (i.e. my Mindstorms NXT brick) asks me to
>> > enter the PIN code.
>>
>> its so called "LMP (link manager protocol) response timeout". its
>> defined in link manager, i.e. part of the device's firmware. v1.1 spec
>> seems to be implying that LMP response timeout should be set to 30
>> sec.
>
> It could be that its not the LMP timeout that is causing the connection to
> be terminated though -- I never read that part of the spec but there are a
> bunch of other timeouts that could cause the problem depending on how the
> pairing is initiated?
>
> HCI Page Timeout
>  time given for remote device to respond to HCI connection attempt
>
> L2CAP response timeout
>  L2CAP control packet times out after this time.
>
> RFCOMM mcc/ack timeout

hmm... i think, i'd like to see hci dump now to see what is going on.
i kind of doubt it is "HCI Page Timeout" because, obviously, remote
device has responded and asked for authentication. but then again, it
is how i understand "page timeout" based on what spec says.

<quote>
The Page_Timeout configuration parameter defines the maximum time the
local Link Manager will wait for a baseband page response from the
remote device at a locally initiated connection attempt.
</quote>

i.e. wait for page response, not complete connection setup including
authentication. but then again, you never know :) and i have been
wrong before :)

l2cap and rfcomm timeouts are also not likely, imo, because Oliver
said he tried to increase them and it did not help.

> and I find that on NetBSD I don't really think I've got it right, because
> the timeouts can trigger too fast. Eg, the default L2CAP response timeout
> is 20 seconds but the L2CAP connect request will often trigger a link code
> request then pin code request and entering the pin will take it over the
> limit..
>
> (pairing is not needed often so I pushed this to the back of my mind :)
>
> I notice that some phone software has a 'pairing' function, where they can
> just pair with the remote hardware and not try to make higher level
> connections. Perhaps this kind of thing would work (ie just use hccontrol
> to create a baseband connection) to avoid any higher level protocol
> timeouts?

yes, that will work.

>> i'm not sure why do you care much about pin length. pin is only used
>> once to generate link key and as soon as link key is generated both
>> devices should use it instead of pin.
>
> more complex PIN does apparently mean more secure link key.

mmmm.... i'm not that good in cryto, so i will let someone more
qualified to render an opinion on the subject :) like i said,
according to spec, e22 takes 128-bit random number in addition to pin
code. plus pin code is apparently augmented by device's bd_addr, so...

> I wonder though, if "Change Connection Link Key" (not in hccontrol IIRC?)
> can be used to make the link key more secure without needing to pair with
> a complex PIN.. presumably it generates a new link key based on some kind
> of random value exchanged over the already secure connection?

i guess i could always add it :)

> ps I am also wondering, what kind of evil lego machine it is that Oliver
> is making that he requires ultimate security on the command channel :)

good call! now i want to know that too :) lego world domination team :) go lego!

thanks,
max
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."

[Iain Hibbert]

On Fri, 19 Dec 2008, Maksim Yevmenkin wrote:

> hmm... i think, i'd like to see hci dump now to see what is going on.

IIRC Oliver said ECONNREFUSED was returned, it might also be worth
grepping for that in the source to see how it can occur..

> i.e. wait for page response, not complete connection setup including
> authentication. but then again, you never know :) and i have been
> wrong before :)

No I think thats right. page timeout is the time that it takes to catch
attention of the remote device, not the time it takes to complete
connection negotiations.

> > more complex PIN does apparently mean more secure link key.
>
> mmmm.... i'm not that good in cryto, so i will let someone more
> qualified to render an opinion on the subject :)

I'm no crypto expert either but the only 'successful' generic attack I've
heard about on bluetooth encryption required listening in on the initial
pairing AND using weak PIN.

I don't think it likely that any such attacks will be successful in the
wild at any time soon though, as you say the hardware is not easily
available for 'script kiddie' or even hardcore geek level, it would have
to be some kind of targeted surveillance with a big budget.

> > I wonder though, if "Change Connection Link Key" (not in hccontrol IIRC?)
> > can be used to make the link key more secure without needing to pair with
> > a complex PIN.. presumably it generates a new link key based on some kind
> > of random value exchanged over the already secure connection?
>
> i guess i could always add it :)

I guess that "Change Connection Link Key" is e21 mode that you described

> > ps I am also wondering, what kind of evil lego machine it is that Oliver
> > is making that he requires ultimate security on the command channel :)
>
> good call! now i want to know that too :) lego world domination team :) go lego!

T-800: powered by FreeBSD?

iain
(eek!)
_______________________________________________
freebsd-bluetooth@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@..."