All of
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <>
To: Brian Gix <>
Cc: Vinicius Costa Gomes <>,
Subject: Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
Date: Mon, 24 Jan 2011 22:09:53 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1295895817.2656.26.camel@ubuntuLab1>


On Mon, Jan 24, 2011 at 9:03 PM, Brian Gix <> wrote:
> 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.

But the point of MITM is man in the middle protection, so if we end up
with a key which is not MITM there is no protection why store the link
key? Actually if we do that we can end up in a situation where
insufficient security is always triggered and the other stack may
attempt to repair but with current code it will never succeed to
generate a valid MITM link key. Anyway I suppose supporting MITM is
mandatory so obviously the only possible fix for this is to support

> 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://
> branch.devel.remote=origin
> branch.devel.merge=refs/heads/devel
> Thanks for doing the SM,
> --
> Brian Gix
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to
> More majordomo info at

Luiz Augusto von Dentz
Computer Engineer

  reply	other threads:[~2011-01-24 20:09 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
2011-01-24 20:09     ` Luiz Augusto von Dentz [this message]
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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.