Date: Fri, 19 Dec 2008 09:43:26 -0800 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: "Oliver Fromme" <olli@lurza.secnetix.de> Cc: freebsd-bluetooth@freebsd.org Subject: Re: Bluetooth socket timeout, device pairing Message-ID: <bb4a86c70812190943v7e277306p4a614ed7cba376ce@mail.gmail.com> In-Reply-To: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> References: <bb4a86c70812182151q44cd1225o1c05aa5cd86bd4be@mail.gmail.com> <200812190944.mBJ9iWKp086368@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70812190943v7e277306p4a614ed7cba376ce>