From owner-freebsd-bluetooth@FreeBSD.ORG Fri Dec 19 17:43:27 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11574106564A for ; Fri, 19 Dec 2008 17:43:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id D91A18FC22 for ; Fri, 19 Dec 2008 17:43:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2445110rvf.43 for ; Fri, 19 Dec 2008 09:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dMz+/WSx/SMmOEbUyggolSnSCqjF8NAlqy39sLo1Q4U=; b=lEHoKKvbDRtqNGKOgO0emMMJFSU1PhcAqjpeVRnpQL0kBf+NTHQfs3VXHcEkKqgVTv oTS3qqxotNgZGxWsFEU+O0v6g5b86SOj+GcoCORMR0XUyh1IgYoXfbr9jW+ZCmIzL5xy HVMWzV+wJmfPMqW+e1DVMHR+/Wk+SeH6ZetEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gfLQhf9xC8SJH17FaEC2g0AumFxqLi9j2jhQLLCCuudmzBXbbaH43KxjSAxK/+eiTL sYRwcxTmdxWfAopvvhVjceBP4KuqTdhrLpP4mB9SxKl7G3ddUxKv1xHv6LRUiUTxDyQE r6vuo2fPBrBB1aIcaENAvX9+0d/Wz1iScbCDw= Received: by 10.141.98.13 with SMTP id a13mr1691670rvm.85.1229708606497; Fri, 19 Dec 2008 09:43:26 -0800 (PST) Received: by 10.140.177.21 with HTTP; Fri, 19 Dec 2008 09:43:26 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 09:43:26 -0800 From: "Maksim Yevmenkin" To: "Oliver Fromme" In-Reply-To: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812190944.mBJ9iWKp086368@lurza.secnetix.de> Cc: freebsd-bluetooth@freebsd.org Subject: Re: Bluetooth socket timeout, device pairing X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 17:43:27 -0000 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. 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. thanks, max