linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Gix <bgix@codeaurora.org>
To: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
Date: Mon, 24 Jan 2011 11:03:37 -0800	[thread overview]
Message-ID: <1295895817.2656.26.camel@ubuntuLab1> (raw)
In-Reply-To: <20101203220534.GA16709@eris>

Hi Vinicius,

I am sorry that it has taken so long to test the snapshot that you
placed on gitorious, but I have now done so.

On Fri, 2010-12-03 at 19:05 -0300, Vinicius Costa Gomes wrote:
> Hi Brian,
> 
> On 11:11 Fri 03 Dec, Brian Gix wrote:
> > 
> > Hi Claudio, Johan & All,
> > 
> > Is this LE capable kernel that Ville is working on, the development stream
> > for the LE Security Manager?  And if so, is it in a partial fleshed out
> > state?
> 
> There is a simple implementation of SMP here[1] on my "devel" branch. I am 
> cleaning it up for sending it for review.
> 
> If you want to help, have any comments or just want to tell us what you are
> working on, please drop by #bluez on freenode, or send an email.

I have been able to verify that the Just Works negotiation of the Short
Term Key does work against an independent implementation of the LE
Security Manager, as long as I have requested no MITM protection.  I
have the following comments:

1. You currently reject security if I *do* request MITM protection.
This should not be done.  The correct functionality should be to
continue the negotiation.  Even though I requested MITM, it will be
clear to both sides that JUST_WORKS methodology has been used, and so
when the Keys are generated and exchanged, both sides will indicate in
their Key Database that they are no-MITM keys. If I then actually
*needed* MITM protection, then whatever functionality requiring that
level of security will fail with an insufficient security error code.
However, security should *never* be rejected unless there is a
fundamental incompatibility such as no level of security actually
supported.  This is the only functionality that I found to be actually
incorrect.

2. Currently, you are not exchanging any permanent keys, which I am sure
you are aware.  This makes it impossible to test much else, such as
command signing, or security requests that use the generated keys.

If you have a later version of SM that could be uploaded to your devel
branch on gitorious, I would be more than happy (and in fact would love
to be able) to test that for you as well.

This is the git configuration I used for testing, which only has your SM
up to the end of last December, and is so about a month old:

remote.origin.url=git://gitorious.org/bluetooth-next/bluetooth-next.git
branch.devel.remote=origin
branch.devel.merge=refs/heads/devel


Thanks for doing the SM,

-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum


  parent reply	other threads:[~2011-01-24 19:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-03 19:11 LE Kernel (bluetooth-le-2.6) and LE Security Manager Brian Gix
2010-12-03 22:05 ` Vinicius Costa Gomes
2010-12-04  0:40   ` Brian Gix
2010-12-06 14:50     ` Vinicius Costa Gomes
2011-01-24 19:03   ` Brian Gix [this message]
2011-01-24 20:09     ` Luiz Augusto von Dentz
2011-01-24 20:33       ` Brian Gix
2011-01-24 21:34     ` Vinicius Costa Gomes
2011-01-25  8:35       ` Luiz Augusto von Dentz
2011-01-25 16:58         ` Brian Gix
2011-01-25 17:10           ` Brian Gix
2011-01-25 17:59           ` Johan Hedberg
2011-01-25 18:35             ` Brian Gix
2011-01-25 21:44               ` Luiz Augusto von Dentz
2011-01-25 22:04                 ` Brian Gix
2011-01-26 17:54                   ` Brian Gix
2011-01-28 23:19       ` GATT and D-Bus Inga Stotland
2011-01-29  0:07         ` Vinicius Costa Gomes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295895817.2656.26.camel@ubuntuLab1 \
    --to=bgix@codeaurora.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=vinicius.gomes@openbossa.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).