* LE Kernel (bluetooth-le-2.6) and LE Security Manager
@ 2010-12-03 19:11 Brian Gix
2010-12-03 22:05 ` Vinicius Costa Gomes
0 siblings, 1 reply; 18+ messages in thread
From: Brian Gix @ 2010-12-03 19:11 UTC (permalink / raw)
To: linux-bluetooth
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?
> git://git.kernel.org/pub/scm/linux/kernel/git/vtervo/bluetooth-le-2.6.git
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 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 2011-01-24 19:03 ` Brian Gix 0 siblings, 2 replies; 18+ messages in thread From: Vinicius Costa Gomes @ 2010-12-03 22:05 UTC (permalink / raw) To: Brian Gix; +Cc: linux-bluetooth 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. > > > git://git.kernel.org/pub/scm/linux/kernel/git/vtervo/bluetooth-le-2.6.git > > > Brian Gix > bgix@codeaurora.org > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, -- Vinicius [1] git://git.infradead.org/users/vcgomes/linux-2.6.git ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: LE Kernel (bluetooth-le-2.6) and LE Security Manager 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 1 sibling, 1 reply; 18+ messages in thread From: Brian Gix @ 2010-12-04 0:40 UTC (permalink / raw) To: 'Vinicius Costa Gomes', 'Gustavo F. Padovan', 'Ville Tervo' Cc: linux-bluetooth Hi Vinicius & Gustavo, -----Original Message----- From: Vinicius Costa Gomes [mailto:vinicius.gomes@openbossa.org] Sent: 03 December, 2010 2:06 PM To: Brian Gix Cc: linux-bluetooth@vger.kernel.org Subject: Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 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. [Gix] Unfortunately, I can't access git.infradead.org. Gustavo, would it be possible for you to pull Vinicius' devel branch from git://git.infradead.org/users/vcgomes/linux-2.6.git to an le-devel branch on your bluetooth-testing repository? [Gix] I am trying to integrate Qualcomm's latest LE capable (BR/EDR/LE) chipset with bluez. Additionally, I do have a working non-open-source [Gix] host which has had it's LE Security Manager UPF tested, which I hope to be able to use to help test/solidify the bluez version. > > > git://git.kernel.org/pub/scm/linux/kernel/git/vtervo/bluetooth-le-2.6.git > > > Brian Gix > bgix@codeaurora.org > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, -- Vinicius [1] git://git.infradead.org/users/vcgomes/linux-2.6.git ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2010-12-04 0:40 ` Brian Gix @ 2010-12-06 14:50 ` Vinicius Costa Gomes 0 siblings, 0 replies; 18+ messages in thread From: Vinicius Costa Gomes @ 2010-12-06 14:50 UTC (permalink / raw) To: Brian Gix Cc: 'Gustavo F. Padovan', 'Ville Tervo', linux-bluetooth Hi Brian, On 16:40 Fri 03 Dec, Brian Gix wrote: > > > Hi Vinicius & Gustavo, > > > -----Original Message----- > From: Vinicius Costa Gomes [mailto:vinicius.gomes@openbossa.org] > Sent: 03 December, 2010 2:06 PM > To: Brian Gix > Cc: linux-bluetooth@vger.kernel.org > Subject: Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager > > 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. > > [Gix] Unfortunately, I can't access git.infradead.org. Gustavo, would it be > possible for you to pull Vinicius' devel branch from > git://git.infradead.org/users/vcgomes/linux-2.6.git to an le-devel branch on > your bluetooth-testing repository? > Sorry for the delay. I pushed a copy to gitorious: http://gitorious.org/bluetooth-next branch devel. > [Gix] I am trying to integrate Qualcomm's latest LE capable (BR/EDR/LE) > chipset with bluez. Additionally, I do have a working non-open-source > [Gix] host which has had it's LE Security Manager UPF tested, which I hope > to be able to use to help test/solidify the bluez version. > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/vtervo/bluetooth-le-2.6.git > > > > > > Brian Gix > > bgix@codeaurora.org > > 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 majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Cheers, > -- > Vinicius > > [1] git://git.infradead.org/users/vcgomes/linux-2.6.git > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, -- Vinicius ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2010-12-03 22:05 ` Vinicius Costa Gomes 2010-12-04 0:40 ` Brian Gix @ 2011-01-24 19:03 ` Brian Gix 2011-01-24 20:09 ` Luiz Augusto von Dentz 2011-01-24 21:34 ` Vinicius Costa Gomes 1 sibling, 2 replies; 18+ messages in thread From: Brian Gix @ 2011-01-24 19:03 UTC (permalink / raw) To: Vinicius Costa Gomes; +Cc: linux-bluetooth 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-24 19:03 ` Brian Gix @ 2011-01-24 20:09 ` Luiz Augusto von Dentz 2011-01-24 20:33 ` Brian Gix 2011-01-24 21:34 ` Vinicius Costa Gomes 1 sibling, 1 reply; 18+ messages in thread From: Luiz Augusto von Dentz @ 2011-01-24 20:09 UTC (permalink / raw) To: Brian Gix; +Cc: Vinicius Costa Gomes, linux-bluetooth Hi, On Mon, Jan 24, 2011 at 9:03 PM, Brian Gix <bgix@codeaurora.org> 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 MITM. > 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 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Luiz Augusto von Dentz Computer Engineer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-24 20:09 ` Luiz Augusto von Dentz @ 2011-01-24 20:33 ` Brian Gix 0 siblings, 0 replies; 18+ messages in thread From: Brian Gix @ 2011-01-24 20:33 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Vinicius Costa Gomes, linux-bluetooth Hi Luiz, On Mon, 2011-01-24 at 22:09 +0200, Luiz Augusto von Dentz wrote: > Hi, > > On Mon, Jan 24, 2011 at 9:03 PM, Brian Gix <bgix@codeaurora.org> wrote: > > Hi Vinicius, > > [...] > > > > 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 > MITM. The basic use case envisioned is that the two sides do not necessarily know what the other side can support or has available until it attempts this "pairing" operation. So we want to avoid this catch 22: 1. We support MITM but don't know if the other side does, nor if it requires it. With the code I just tested, the remote side (bluez) indicated that it doesn't not support MITM and therefore rejects pairing. 2. However, if we support MITM but don't know if the other side does and we *do not* request MITM, then a remote side that *requires* MITM should reject us for *not* requesting it. The solution is therefore to *always* request MITM, if you are capable of supporting it. If it turns out that neither side actually needs it, then there is no harm in having provided it. If one side does not support it (as bluez currently does not) and the other side requires it, then it is up to the side that *requested* MITM to reject the pairing attempt, if it determines that MITM is required. A low security device like the current bluez should *never* reject a pairing request because the other side needs MITM. It is up to the side that has the MITM requirement to issue the Security Failure packet. So until bluez can support MITM, it should *accept* remote requests for MITM, knowing that the remote side may reject it. As long as bluez advertises no OOB and NO_IN_NO_OUT, there will be no MITM. It should just not request MITM, and then provide no way to achieve it. [...] -- Brian Gix bgix@codeaurora.org Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-24 19:03 ` Brian Gix 2011-01-24 20:09 ` Luiz Augusto von Dentz @ 2011-01-24 21:34 ` Vinicius Costa Gomes 2011-01-25 8:35 ` Luiz Augusto von Dentz 2011-01-28 23:19 ` GATT and D-Bus Inga Stotland 1 sibling, 2 replies; 18+ messages in thread From: Vinicius Costa Gomes @ 2011-01-24 21:34 UTC (permalink / raw) To: Brian Gix; +Cc: linux-bluetooth Hi Brian, On 11:03 Mon 24 Jan, 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. > I was assuming that the meaning of setting the MITM protection bit, was that it was *requiring* MITM protection, and when that couldn't be fulfilled the Pairing Request should be rejected. So my assumption was incorrect, going to fix it soon. > 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. > This is being worked on, but nothing ready for testing yet. > 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 > Cheers, -- Vinicius ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 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-28 23:19 ` GATT and D-Bus Inga Stotland 1 sibling, 1 reply; 18+ messages in thread From: Luiz Augusto von Dentz @ 2011-01-25 8:35 UTC (permalink / raw) To: Vinicius Costa Gomes; +Cc: Brian Gix, linux-bluetooth Hi Vinicius, On Mon, Jan 24, 2011 at 11:34 PM, Vinicius Costa Gomes <vinicius.gomes@openbossa.org> wrote: > Hi Brian, > > On 11:03 Mon 24 Jan, 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. >> > > I was assuming that the meaning of setting the MITM protection bit, was that > it was *requiring* MITM protection, and when that couldn't be fulfilled the > Pairing Request should be rejected. > > So my assumption was incorrect, going to fix it soon. Well the spec says it is a requirement: "If the STK generation method does not result in an STK that provides sufficient security properties then the device shall send the Pairing Failed command with the error code “Authentication Requirements”" - 2.3.5.1 Selecting STK Generation Method - Page 608 In my interpretation this is exactly what should happen when MITM is set but there is no way to generate an authenticated key as Table 2.4: Mapping of IO Capabilities to STK Generation Method suggest, in other words if one of sides has NoInputNoOutput and MITM is set we should return "Authentication Requirements" error. -- Luiz Augusto von Dentz Computer Engineer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 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 0 siblings, 2 replies; 18+ messages in thread From: Brian Gix @ 2011-01-25 16:58 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Vinicius Costa Gomes, linux-bluetooth On Tue, 2011-01-25 at 10:35 +0200, Luiz Augusto von Dentz wrote: > Hi Vinicius, > > On Mon, Jan 24, 2011 at 11:34 PM, Vinicius Costa Gomes > <vinicius.gomes@openbossa.org> wrote: > > Hi Brian, > > > > On 11:03 Mon 24 Jan, 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. > >> > > > > I was assuming that the meaning of setting the MITM protection bit, was that > > it was *requiring* MITM protection, and when that couldn't be fulfilled the > > Pairing Request should be rejected. > > > > So my assumption was incorrect, going to fix it soon. > > Well the spec says it is a requirement: > > "If the STK generation method does not result in an STK that provides > sufficient security properties then the device shall send the Pairing > Failed command with the error code “Authentication Requirements”" - > 2.3.5.1 Selecting STK Generation Method - Page 608 >>From Page 607: "If both devices have out of band authentication data, then the Authentication Requirements Flags shall be ignored when selecting the pairing method and the Out of Band pairing method shall be used. If both devices have not set the MITM option in the Authentication Requirements Flags, then the IO capabilities shall be ignored and the Just Works association model shall be used. Otherwise the IO capabilities of the devices shall be used to determine the pairing method as defined in Table 2.4." In the test case I ran, only One device (i.e. NOT BOTH) had the MITM option set. So my reading is that the IO Capabilities should be ignored, and JUST_WORKS used. Remember the phone use case: When it needs to pair with a remote device, it is usually a GATT client that can support any level of security. It does not know if this new remote device requires MITM security, or No security. However as the link Master and Initiator, it has to choose one. It Chooses MITM, and if the remote side supports MITM, then pairing proceeds with a resulting MITM protection level. If the remote device is a simple dumb device with no security, it also needs to proceed without failing, but this time it completes with NO-MITM as the protection level. If it fails because the remote doesn't require security, then there is a fundamental incompatibility between the devices, which in the SIG we have tried to avoid. > > In my interpretation this is exactly what should happen when MITM is > set but there is no way to generate an authenticated key as Table 2.4: > Mapping of IO Capabilities to STK Generation Method suggest, in other > words if one of sides has NoInputNoOutput and MITM is set we should > return "Authentication Requirements" error. > -- Brian Gix bgix@codeaurora.org Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-25 16:58 ` Brian Gix @ 2011-01-25 17:10 ` Brian Gix 2011-01-25 17:59 ` Johan Hedberg 1 sibling, 0 replies; 18+ messages in thread From: Brian Gix @ 2011-01-25 17:10 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Vinicius Costa Gomes, linux-bluetooth Hi Luiz & Vinicius, On Tue, 2011-01-25 at 08:58 -0800, Brian Gix wrote: > On Tue, 2011-01-25 at 10:35 +0200, Luiz Augusto von Dentz wrote: > > Hi Vinicius, > > > > On Mon, Jan 24, 2011 at 11:34 PM, Vinicius Costa Gomes > > <vinicius.gomes@openbossa.org> wrote: > > > Hi Brian, > > > > > > On 11:03 Mon 24 Jan, 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. > > >> > > > > > > I was assuming that the meaning of setting the MITM protection bit, was that > > > it was *requiring* MITM protection, and when that couldn't be fulfilled the > > > Pairing Request should be rejected. > > > > > > So my assumption was incorrect, going to fix it soon. > > > > Well the spec says it is a requirement: > > > > "If the STK generation method does not result in an STK that provides > > sufficient security properties then the device shall send the Pairing > > Failed command with the error code “Authentication Requirements”" - > > 2.3.5.1 Selecting STK Generation Method - Page 608 My interpretation of the paragraph at the end of page 608 is that if a device realizes that the security level that will results will not meet it's minimum security requirements, then it may reject and abort the pairing. I think it is a bad reading, though, for a device to reject a pairing if it thinks that the *other* device will not be satisfied. However that is the case here. In this case, it was the device that did *not* have the MITM option set (the low security device) that was rejecting the device *with* the MITM option set. > > >From Page 607: > "If both devices have out of band authentication data, then the > Authentication Requirements Flags shall be ignored when selecting the > pairing method and the Out of Band pairing method shall be used. If both > devices have not set the MITM option in the Authentication Requirements > Flags, then the IO capabilities shall be ignored and the Just Works > association model shall be used. Otherwise the IO capabilities of the > devices shall be used to determine the pairing method as defined in > Table 2.4." > > In the test case I ran, only One device (i.e. NOT BOTH) had the MITM > option set. So my reading is that the IO Capabilities should be ignored, > and JUST_WORKS used. > > Remember the phone use case: When it needs to pair with a remote device, > it is usually a GATT client that can support any level of security. It > does not know if this new remote device requires MITM security, or No > security. However as the link Master and Initiator, it has to choose > one. It Chooses MITM, and if the remote side supports MITM, then > pairing proceeds with a resulting MITM protection level. If the remote > device is a simple dumb device with no security, it also needs to > proceed without failing, but this time it completes with NO-MITM as the > protection level. If it fails because the remote doesn't require > security, then there is a fundamental incompatibility between the > devices, which in the SIG we have tried to avoid. > > > > > In my interpretation this is exactly what should happen when MITM is > > set but there is no way to generate an authenticated key as Table 2.4: > > Mapping of IO Capabilities to STK Generation Method suggest, in other > > words if one of sides has NoInputNoOutput and MITM is set we should > > return "Authentication Requirements" error. > > > -- Brian Gix bgix@codeaurora.org Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 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 1 sibling, 1 reply; 18+ messages in thread From: Johan Hedberg @ 2011-01-25 17:59 UTC (permalink / raw) To: Brian Gix; +Cc: Luiz Augusto von Dentz, Vinicius Costa Gomes, linux-bluetooth Hi Brian, On Tue, Jan 25, 2011, Brian Gix wrote: > >From Page 607: > "If both devices have out of band authentication data, then the > Authentication Requirements Flags shall be ignored when selecting the > pairing method and the Out of Band pairing method shall be used. If both > devices have not set the MITM option in the Authentication Requirements > Flags, then the IO capabilities shall be ignored and the Just Works > association model shall be used. Otherwise the IO capabilities of the > devices shall be used to determine the pairing method as defined in > Table 2.4." > > In the test case I ran, only One device (i.e. NOT BOTH) had the MITM > option set. So my reading is that the IO Capabilities should be ignored, > and JUST_WORKS used. It certainly is an unusual form of English. It's saying "If both devices have <x>", i.e. the condition <x> needs to be fulfilled by both devices for the statement to be true. In this case the condition is "not set the MITM option", i.e. both devices need to fulfill the condition "not set the MITM option". Doesn't that then mean that it's not enough for one device to not set the MITM flag, but both devices need to have it unset for just-works to take place? Johan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-25 17:59 ` Johan Hedberg @ 2011-01-25 18:35 ` Brian Gix 2011-01-25 21:44 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 18+ messages in thread From: Brian Gix @ 2011-01-25 18:35 UTC (permalink / raw) To: Johan Hedberg Cc: Luiz Augusto von Dentz, Vinicius Costa Gomes, linux-bluetooth Hi Johan, On Tue, 2011-01-25 at 19:59 +0200, Johan Hedberg wrote: > Hi Brian, > > On Tue, Jan 25, 2011, Brian Gix wrote: > > >From Page 607: > > "If both devices have out of band authentication data, then the > > Authentication Requirements Flags shall be ignored when selecting the > > pairing method and the Out of Band pairing method shall be used. If both > > devices have not set the MITM option in the Authentication Requirements > > Flags, then the IO capabilities shall be ignored and the Just Works > > association model shall be used. Otherwise the IO capabilities of the > > devices shall be used to determine the pairing method as defined in > > Table 2.4." > > > > In the test case I ran, only One device (i.e. NOT BOTH) had the MITM > > option set. So my reading is that the IO Capabilities should be ignored, > > and JUST_WORKS used. > > It certainly is an unusual form of English. It's saying "If both devices > have <x>", i.e. the condition <x> needs to be fulfilled by both devices > for the statement to be true. In this case the condition is "not set the > MITM option", i.e. both devices need to fulfill the condition "not set > the MITM option". Doesn't that then mean that it's not enough for one > device to not set the MITM flag, but both devices need to have it unset > for just-works to take place? Yes, it is very unfortunate and awkward English. I am going to look for any errata that might be more explicit, so that an absolute truth table based on: MITM, OOB, and IO-Caps can be constructed. But the Truth table as I understood it from conversations at UPFs and WGs and in my notes was: 1. If BOTH devices have OOB available, it is used and results in MITM 2. If NEITHER device wants MITM, JUST_WORKS used resulting in no MITM 3, If One or more want MITM, the IO Caps Table 2.4 on page 608 is used and MAY or MAY NOT result in MITM. In every case, MITM outcome is known, and propagated up the stack. I have nothing to prove this, but it appears to be what the mature stacks were using at UPF in Barcelona. But it is apparent that the spec is not 100% clear, and that an errata is required to explicitly spell it out. I am going to either find the errata if it exists, or propose one to the Core Working Group if it doesn't. Whatever the outcome, I will post it here. -- Brian Gix bgix@codeaurora.org Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-25 18:35 ` Brian Gix @ 2011-01-25 21:44 ` Luiz Augusto von Dentz 2011-01-25 22:04 ` Brian Gix 0 siblings, 1 reply; 18+ messages in thread From: Luiz Augusto von Dentz @ 2011-01-25 21:44 UTC (permalink / raw) To: Brian Gix; +Cc: Johan Hedberg, Vinicius Costa Gomes, linux-bluetooth Hi, On Tue, Jan 25, 2011 at 8:35 PM, Brian Gix <bgix@codeaurora.org> wrote: > Hi Johan, > > On Tue, 2011-01-25 at 19:59 +0200, Johan Hedberg wrote: >> Hi Brian, >> >> On Tue, Jan 25, 2011, Brian Gix wrote: >> > >From Page 607: >> > "If both devices have out of band authentication data, then the >> > Authentication Requirements Flags shall be ignored when selecting the >> > pairing method and the Out of Band pairing method shall be used. If both >> > devices have not set the MITM option in the Authentication Requirements >> > Flags, then the IO capabilities shall be ignored and the Just Works >> > association model shall be used. Otherwise the IO capabilities of the >> > devices shall be used to determine the pairing method as defined in >> > Table 2.4." >> > >> > In the test case I ran, only One device (i.e. NOT BOTH) had the MITM >> > option set. So my reading is that the IO Capabilities should be ignored, >> > and JUST_WORKS used. >> >> It certainly is an unusual form of English. It's saying "If both devices >> have <x>", i.e. the condition <x> needs to be fulfilled by both devices >> for the statement to be true. In this case the condition is "not set the >> MITM option", i.e. both devices need to fulfill the condition "not set >> the MITM option". Doesn't that then mean that it's not enough for one >> device to not set the MITM flag, but both devices need to have it unset >> for just-works to take place? > > Yes, it is very unfortunate and awkward English. > > I am going to look for any errata that might be more explicit, so that > an absolute truth table based on: MITM, OOB, and IO-Caps can be > constructed. > > But the Truth table as I understood it from conversations at UPFs and > WGs and in my notes was: > > 1. If BOTH devices have OOB available, it is used and results in MITM > 2. If NEITHER device wants MITM, JUST_WORKS used resulting in no MITM > 3, If One or more want MITM, the IO Caps Table 2.4 on page 608 is used > and MAY or MAY NOT result in MITM. At least for ssp yapparently you are right that may or may not result on MITM being used, this is the code we use on BlueZ: if (*auth == 0x00 || *auth == 0x04) { /* If remote requests dedicated bonding follow that lead */ if (device_get_auth(device) == 0x02 || device_get_auth(device) == 0x03) { /* If both remote and local IO capabilities allow MITM * then require it, otherwise don't */ if (device_get_cap(device) == 0x03 || agent_cap == 0x03) *auth = 0x02; else *auth = 0x03; } /* If remote indicates no bonding then follow that. This * is important since the kernel might give general bonding * as default. */ if (device_get_auth(device) == 0x00 || device_get_auth(device) == 0x01) *auth = 0x00; /* If remote requires MITM then also require it, unless * our IO capability is NoInputNoOutput (so some * just-works security cases can be tested) */ if (device_get_auth(device) != 0xff && (device_get_auth(device) & 0x01) && agent_cap != 0x03) *auth |= 0x01; } So we only set MITM if the other side also support it, hopefully it works the same way on LE. I still think it is a waste of time for no bonding case to use just-works when MITM was marked as required by one of parties, but I guess pretty everybody does that way. > In every case, MITM outcome is known, and propagated up the stack. > > I have nothing to prove this, but it appears to be what the mature > stacks were using at UPF in Barcelona. But it is apparent that the spec > is not 100% clear, and that an errata is required to explicitly spell it > out. > > I am going to either find the errata if it exists, or propose one to the > Core Working Group if it doesn't. Whatever the outcome, I will post it > here. -- Luiz Augusto von Dentz Computer Engineer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-25 21:44 ` Luiz Augusto von Dentz @ 2011-01-25 22:04 ` Brian Gix 2011-01-26 17:54 ` Brian Gix 0 siblings, 1 reply; 18+ messages in thread From: Brian Gix @ 2011-01-25 22:04 UTC (permalink / raw) To: Luiz Augusto von Dentz Cc: Johan Hedberg, Vinicius Costa Gomes, linux-bluetooth Hi Luiz & all, On Tue, 2011-01-25 at 23:44 +0200, Luiz Augusto von Dentz wrote: > Hi, > > On Tue, Jan 25, 2011 at 8:35 PM, Brian Gix <bgix@codeaurora.org> wrote: > > Hi Johan, > > > > On Tue, 2011-01-25 at 19:59 +0200, Johan Hedberg wrote: > >> Hi Brian, > >> > >> On Tue, Jan 25, 2011, Brian Gix wrote: > >> > >From Page 607: > >> > "If both devices have out of band authentication data, then the > >> > Authentication Requirements Flags shall be ignored when selecting the > >> > pairing method and the Out of Band pairing method shall be used. If both > >> > devices have not set the MITM option in the Authentication Requirements > >> > Flags, then the IO capabilities shall be ignored and the Just Works > >> > association model shall be used. Otherwise the IO capabilities of the > >> > devices shall be used to determine the pairing method as defined in > >> > Table 2.4." > >> > > >> > In the test case I ran, only One device (i.e. NOT BOTH) had the MITM > >> > option set. So my reading is that the IO Capabilities should be ignored, > >> > and JUST_WORKS used. > >> > >> It certainly is an unusual form of English. It's saying "If both devices > >> have <x>", i.e. the condition <x> needs to be fulfilled by both devices > >> for the statement to be true. In this case the condition is "not set the > >> MITM option", i.e. both devices need to fulfill the condition "not set > >> the MITM option". Doesn't that then mean that it's not enough for one > >> device to not set the MITM flag, but both devices need to have it unset > >> for just-works to take place? > > > > Yes, it is very unfortunate and awkward English. > > > > I am going to look for any errata that might be more explicit, so that > > an absolute truth table based on: MITM, OOB, and IO-Caps can be > > constructed. > > > > But the Truth table as I understood it from conversations at UPFs and > > WGs and in my notes was: > > > > 1. If BOTH devices have OOB available, it is used and results in MITM > > 2. If NEITHER device wants MITM, JUST_WORKS used resulting in no MITM > > 3, If One or more want MITM, the IO Caps Table 2.4 on page 608 is used > > and MAY or MAY NOT result in MITM. > > At least for ssp yapparently you are right that may or may not result > on MITM being used, this is the code we use on BlueZ: > > if (*auth == 0x00 || *auth == 0x04) { > /* If remote requests dedicated bonding follow that lead */ > if (device_get_auth(device) == 0x02 || > device_get_auth(device) == 0x03) { > > /* If both remote and local IO capabilities allow MITM > * then require it, otherwise don't */ > if (device_get_cap(device) == 0x03 || > agent_cap == 0x03) > *auth = 0x02; > else > *auth = 0x03; > } > > /* If remote indicates no bonding then follow that. This > * is important since the kernel might give general bonding > * as default. */ > if (device_get_auth(device) == 0x00 || > device_get_auth(device) == 0x01) > *auth = 0x00; > > /* If remote requires MITM then also require it, unless > * our IO capability is NoInputNoOutput (so some > * just-works security cases can be tested) */ > if (device_get_auth(device) != 0xff && > (device_get_auth(device) & 0x01) && > agent_cap != 0x03) > *auth |= 0x01; > } > > So we only set MITM if the other side also support it, hopefully it > works the same way on LE. I still think it is a waste of time for no > bonding case to use just-works when MITM was marked as required by one > of parties, but I guess pretty everybody does that way. > > > In every case, MITM outcome is known, and propagated up the stack. > > > > I have nothing to prove this, but it appears to be what the mature > > stacks were using at UPF in Barcelona. But it is apparent that the spec > > is not 100% clear, and that an errata is required to explicitly spell it > > out. > > > > I am going to either find the errata if it exists, or propose one to the > > Core Working Group if it doesn't. Whatever the outcome, I will post it > > here. I have filed errata #4249. This errata can be looked up on bluetooth.org in the specifications area under number: "4249" title: "Clarification of STK generation" Part: "Security Manager 4.0" Paragraph: "2.3.5.1 Selecting STK Generation Method" The Core Working Group (CWG) is meeting this week in Israel, and our guy on the group, Brian Redding, has told me that he will try to get some face time for it. So in the next day or two, we could either get a definitive statement, or at least a few comments. If you don't have access to the BT Sigs errata system, let me know & I will copy the errata here. > > -- Brian Gix bgix@codeaurora.org Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager 2011-01-25 22:04 ` Brian Gix @ 2011-01-26 17:54 ` Brian Gix 0 siblings, 0 replies; 18+ messages in thread From: Brian Gix @ 2011-01-26 17:54 UTC (permalink / raw) To: Luiz Augusto von Dentz Cc: Johan Hedberg, Vinicius Costa Gomes, linux-bluetooth Hi Luiz, Vinicius & all, On Tue, 2011-01-25 at 14:04 -0800, Brian Gix wrote: > Hi Luiz & all, > > On Tue, 2011-01-25 at 23:44 +0200, Luiz Augusto von Dentz wrote: > > Hi, > > > > On Tue, Jan 25, 2011 at 8:35 PM, Brian Gix <bgix@codeaurora.org> wrote: > > > Hi Johan, > > > > > > On Tue, 2011-01-25 at 19:59 +0200, Johan Hedberg wrote: > > >> Hi Brian, > > >> > > >> On Tue, Jan 25, 2011, Brian Gix wrote: > > >> > >From Page 607: > > >> > "If both devices have out of band authentication data, then the > > >> > Authentication Requirements Flags shall be ignored when selecting the > > >> > pairing method and the Out of Band pairing method shall be used. If both > > >> > devices have not set the MITM option in the Authentication Requirements > > >> > Flags, then the IO capabilities shall be ignored and the Just Works > > >> > association model shall be used. Otherwise the IO capabilities of the > > >> > devices shall be used to determine the pairing method as defined in > > >> > Table 2.4." > > >> > > > >> > In the test case I ran, only One device (i.e. NOT BOTH) had the MITM > > >> > option set. So my reading is that the IO Capabilities should be ignored, > > >> > and JUST_WORKS used. > > >> > > >> It certainly is an unusual form of English. It's saying "If both devices > > >> have <x>", i.e. the condition <x> needs to be fulfilled by both devices > > >> for the statement to be true. In this case the condition is "not set the > > >> MITM option", i.e. both devices need to fulfill the condition "not set > > >> the MITM option". Doesn't that then mean that it's not enough for one > > >> device to not set the MITM flag, but both devices need to have it unset > > >> for just-works to take place? > > > > > > Yes, it is very unfortunate and awkward English. > > > > > > I am going to look for any errata that might be more explicit, so that > > > an absolute truth table based on: MITM, OOB, and IO-Caps can be > > > constructed. > > > > > > But the Truth table as I understood it from conversations at UPFs and > > > WGs and in my notes was: > > > > > > 1. If BOTH devices have OOB available, it is used and results in MITM > > > 2. If NEITHER device wants MITM, JUST_WORKS used resulting in no MITM > > > 3, If One or more want MITM, the IO Caps Table 2.4 on page 608 is used > > > and MAY or MAY NOT result in MITM. > > > > At least for ssp yapparently you are right that may or may not result > > on MITM being used, this is the code we use on BlueZ: > > > > if (*auth == 0x00 || *auth == 0x04) { > > /* If remote requests dedicated bonding follow that lead */ > > if (device_get_auth(device) == 0x02 || > > device_get_auth(device) == 0x03) { > > > > /* If both remote and local IO capabilities allow MITM > > * then require it, otherwise don't */ > > if (device_get_cap(device) == 0x03 || > > agent_cap == 0x03) > > *auth = 0x02; > > else > > *auth = 0x03; > > } > > > > /* If remote indicates no bonding then follow that. This > > * is important since the kernel might give general bonding > > * as default. */ > > if (device_get_auth(device) == 0x00 || > > device_get_auth(device) == 0x01) > > *auth = 0x00; > > > > /* If remote requires MITM then also require it, unless > > * our IO capability is NoInputNoOutput (so some > > * just-works security cases can be tested) */ > > if (device_get_auth(device) != 0xff && > > (device_get_auth(device) & 0x01) && > > agent_cap != 0x03) > > *auth |= 0x01; > > } > > > > So we only set MITM if the other side also support it, hopefully it > > works the same way on LE. I still think it is a waste of time for no > > bonding case to use just-works when MITM was marked as required by one > > of parties, but I guess pretty everybody does that way. > > > > > In every case, MITM outcome is known, and propagated up the stack. > > > > > > I have nothing to prove this, but it appears to be what the mature > > > stacks were using at UPF in Barcelona. But it is apparent that the spec > > > is not 100% clear, and that an errata is required to explicitly spell it > > > out. > > > > > > I am going to either find the errata if it exists, or propose one to the > > > Core Working Group if it doesn't. Whatever the outcome, I will post it > > > here. > > I have filed errata #4249. This errata can be looked up on > bluetooth.org in the specifications area under number: > "4249" > title: > "Clarification of STK generation" > Part: > "Security Manager 4.0" > Paragraph: > "2.3.5.1 Selecting STK Generation Method" I got a response from Steven Wenhem of CSR and the CSWG and he offered the opinion on the errata (4249) that aligns with my understanding of the truth table: 1. If BOTH devices have OOB available, it is used and results in MITM 2. If NEITHER device wants MITM, JUST_WORKS used resulting in no MITM 3, If One or more want MITM, the IO Caps Table 2.4 on page 608 is used and MAY or MAY NOT result in MITM. Note that this is an opinion only at this point, and has not been approved or adopted. I believe that it is how more than one stack with a more mature SM currently work, though. Based on other conversations with members of the working group, I believe that it is also generally accepted that a device with weak security requirements (such as JUST WORKS) should *never* Reject the pairing attempt because the remote device requests stronger (MITM) security. It is the responsibility of the Strong Security device to reject the pairing if it will not meet the minimum security requirements of the Strong Security Device. This principle applies to not only MITM, but also the Key Length, which is specified in the same SM packets. The key length used will be the MIN of the two devices "max key length" field, but either side can reject the pairing if the resulting length is shorter than it's Minimum key length. But again, these are stated opinions only, and not published (specification) fact. -- Brian Gix bgix@codeaurora.org Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum ^ permalink raw reply [flat|nested] 18+ messages in thread
* GATT and D-Bus 2011-01-24 21:34 ` Vinicius Costa Gomes 2011-01-25 8:35 ` Luiz Augusto von Dentz @ 2011-01-28 23:19 ` Inga Stotland 2011-01-29 0:07 ` Vinicius Costa Gomes 1 sibling, 1 reply; 18+ messages in thread From: Inga Stotland @ 2011-01-28 23:19 UTC (permalink / raw) To: 'Vinicius Costa Gomes'; +Cc: linux-bluetooth Hi Vinicus, Not sure who to ask, but it seems that you are the active contributor to the part of the code that I am interested in :) I am looking at using D-Bus to talk to GATT just over BR/EDR. The support for that seems to be partially there ( I am working off the current bluez tip). However, in the current code it does not seem possible to get GATT over D-Bus working if the device is not LE. Am I missing something here? Also, I can see that you were sending GATT patches upstream: "[PATCH 00/18] Making GATT a first class citizen", not all of them have been pushed through. Are you planning on re-submitting the changes? Thank you, Inga Stotland ingas@codeaurora.org Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: GATT and D-Bus 2011-01-28 23:19 ` GATT and D-Bus Inga Stotland @ 2011-01-29 0:07 ` Vinicius Costa Gomes 0 siblings, 0 replies; 18+ messages in thread From: Vinicius Costa Gomes @ 2011-01-29 0:07 UTC (permalink / raw) To: Inga Stotland; +Cc: linux-bluetooth Hi Inga, On 15:19 Fri 28 Jan, Inga Stotland wrote: > Hi Vinicus, > > Not sure who to ask, but it seems that you are the active contributor to the > part of the code that I am interested in :) > I am looking at using D-Bus to talk to GATT just over BR/EDR. The support > for that seems to be partially there ( I am working off the current bluez > tip). However, in the current code it does not seem possible to get GATT > over D-Bus working if the device is not LE. Am I missing something here? > Also, I can see that you were sending GATT patches upstream: "[PATCH 00/18] > Making GATT a first class citizen", not all of them have been pushed > through. Are you planning on re-submitting the changes? Those patches are already upstream, it was just that the "applied" message came via IRC. What is missing for the BR/EDR case is that we need to trigger GATT Service Discovery after the SDP Browse, if the Device has the GATT Service Record. SMP is still taking a lot of my time, that I didn't have the time to go back and solve this issue, but it is still on the top of my todo list ;-) > > Thank you, > > Inga Stotland > > ingas@codeaurora.org > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum > > > > Cheers, -- Vinicius ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-01-29 0:07 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.