[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bluetooth socket timeout, device pairing

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 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_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"