* BlueZ health device interface, problems with link security level? [not found] <AANLkTi=Kohr02dZOFS4HJknp=keMTCN47jYFOdJBN7Ze@mail.gmail.com> @ 2011-03-22 16:37 ` Bill Turner 2011-03-22 16:47 ` Elvis Pfützenreuter 0 siblings, 1 reply; 7+ messages in thread From: Bill Turner @ 2011-03-22 16:37 UTC (permalink / raw) To: linux-bluetooth I've run into a problem trying to use the BlueZ health device plugin (BlueZ 4.89), related to the Bluetooth link security level requested and the device capabilities. I'm connecting to an Omron BP792IT blood pressure monitor and have it correctly paired with my system. The problem I have is when the MCAP instance is created (mcap_create_instance, in health/hdp.c), it uses BT_IO_SEC_HIGH, which sets the link authentication requirement to 5 (MITM protection required, general bonding). Since the BP monitor doesn't have any user input capabilities (IO capabilities returns 3, NoInputNoOutput), the request to change the link authentication level fails, and the connection is refused. I've gotten the device to correctly connect and exchange data if I modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM instead, so the MITM protection isn't required. I'm not sure if I'm doing something else wrong and BT_IO_SEC_HIGH should work, or if there is indeed a problem in the BlueZ code (and if so what the correct solution is). Does anyone else have the unmodified BlueZ code working correctly with health devices? -- Bill Turner Senior Software Engineer Visionary Mobile Corp. -- Bill Turner Senior Software Engineer Visionary Mobile Corp. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BlueZ health device interface, problems with link security level? 2011-03-22 16:37 ` BlueZ health device interface, problems with link security level? Bill Turner @ 2011-03-22 16:47 ` Elvis Pfützenreuter [not found] ` <AANLkTikTJsY3-WY12hD0yTbU3u7ovW3C1CHic2WReoZq@mail.gmail.com> 0 siblings, 1 reply; 7+ messages in thread From: Elvis Pfützenreuter @ 2011-03-22 16:47 UTC (permalink / raw) To: Bill Turner; +Cc: linux-bluetooth Hi, On 22 Mar 2011, at 13:37 , Bill Turner wrote: > I've run into a problem trying to use the BlueZ health device plugin > (BlueZ 4.89), related to the Bluetooth link security level requested > and the device capabilities. I'm connecting to an Omron BP792IT blood > pressure monitor and have it correctly paired with my system. > > The problem I have is when the MCAP instance is created > (mcap_create_instance, in health/hdp.c), it uses BT_IO_SEC_HIGH, which > sets the link authentication requirement to 5 (MITM protection > required, general bonding). Since the BP monitor doesn't have any > user input capabilities (IO capabilities returns 3, NoInputNoOutput), > the request to change the link authentication level fails, and the > connection is refused. > > I've gotten the device to correctly connect and exchange data if I > modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM > instead, so the MITM protection isn't required. I'm not sure if I'm > doing something else wrong and BT_IO_SEC_HIGH should work, or if there > is indeed a problem in the BlueZ code (and if so what the correct > solution is). > > Does anyone else have the unmodified BlueZ code working correctly with > health devices? Another known workaround is to disable SSP mode with hciconfig (hciconfig hciX sspmode 0). There has been discussion whether BlueZ HDP is correct or not in this respect. The HDP specification says that devices SHOULD require authenticated and encrypted connections (which maps to SEC_HIGH) while some devices are known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD', not 'SHALL'. ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <AANLkTikTJsY3-WY12hD0yTbU3u7ovW3C1CHic2WReoZq@mail.gmail.com>]
* Re: BlueZ health device interface, problems with link security level? [not found] ` <AANLkTikTJsY3-WY12hD0yTbU3u7ovW3C1CHic2WReoZq@mail.gmail.com> @ 2011-03-22 18:46 ` james.steele 2011-03-23 9:17 ` Santiago Carot 0 siblings, 1 reply; 7+ messages in thread From: james.steele @ 2011-03-22 18:46 UTC (permalink / raw) To: epx, wjturner; +Cc: linux-bluetooth Hi, >> I've gotten the device to correctly connect and exchange data if I >> modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM >> instead, so the MITM protection isn't required. I'm not sure if I'm >> doing something else wrong and BT_IO_SEC_HIGH should work, or if there >> is indeed a problem in the BlueZ code (and if so what the correct >> solution is). >> >> Does anyone else have the unmodified BlueZ code working correctly with >> health devices? > Another known workaround is to disable SSP mode with hciconfig > (hciconfig hciX sspmode 0). > There has been discussion whether BlueZ HDP is correct or not in this > respect. The HDP specification says that devices SHOULD require authenticated > and encrypted connections (which maps to SEC_HIGH) while some devices are > known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD', > not 'SHALL'. An "authenticated" connection has a slightly ambiguous meaning in Bluetooth since 2.1+EDR, since you can have an authenticated link that does not have any MITM protection. I think the correct behavior is that HDP should be using "Level 2" (from GAP in the Core specification), where HDP wants the strongest level of security it can achieve with a device, but it does not want to exclude devices that do not have the capability to support input/output. There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ and Security Level 2 in GAP. I believe that the intention of Level 2 is to propose that MITM protection is needed - however it will happily accept security where no MITM protection has been achieved (this being the difference between Level 2 and Level 3). BlueZ however does not seem to propose MITM protection for SEC_MEDIUM - which would be important for HDP (at least in the BlueZ <-> BlueZ case). James Steele Software Engineer Accenture This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BlueZ health device interface, problems with link security level? 2011-03-22 18:46 ` james.steele @ 2011-03-23 9:17 ` Santiago Carot 2011-03-23 9:26 ` Johan Hedberg 0 siblings, 1 reply; 7+ messages in thread From: Santiago Carot @ 2011-03-23 9:17 UTC (permalink / raw) To: james.steele; +Cc: epx, wjturner, linux-bluetooth Hello Elvis, James 2011/3/22 <james.steele@accenture.com> > > Hi, > > >> I've gotten the device to correctly connect and exchange data if I > >> modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM > >> instead, so the MITM protection isn't required. I'm not sure if I'm > >> doing something else wrong and BT_IO_SEC_HIGH should work, or if there > >> is indeed a problem in the BlueZ code (and if so what the correct > >> solution is). > >> > >> Does anyone else have the unmodified BlueZ code working correctly with > >> health devices? > > > Another known workaround is to disable SSP mode with hciconfig > > (hciconfig hciX sspmode 0). > > > There has been discussion whether BlueZ HDP is correct or not in this > > respect. The HDP specification says that devices SHOULD require authenticated > > and encrypted connections (which maps to SEC_HIGH) while some devices are > > known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD', > > not 'SHALL'. > > An "authenticated" connection has a slightly ambiguous meaning in > Bluetooth since 2.1+EDR, since you can have an authenticated link that > does not have any MITM protection. > > I think the correct behavior is that HDP should be using "Level 2" > (from GAP in the Core specification), where HDP wants the strongest > level of security it can achieve with a device, but it does not want to > exclude devices that do not have the capability to support input/output. > > There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ > and Security Level 2 in GAP. I believe that the intention of Level 2 > is to propose that MITM protection is needed - however it will happily > accept security where no MITM protection has been achieved (this being > the difference between Level 2 and Level 3). BlueZ however does not > seem to propose MITM protection for SEC_MEDIUM - which would be important > for HDP (at least in the BlueZ <-> BlueZ case). > I remember that issue with we were developing HDP and MCAP. We set SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS. The problem doing that is related with devices that don't support MITM protection (In fact if they don't have any user input capabilities). This may be a good opportunity to go back about this issue. What do you think? In any case, such as Elvis has said, you can disable sspmode to get HDP working without modify BlueZ code. Regards Santiago ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BlueZ health device interface, problems with link security level? 2011-03-23 9:17 ` Santiago Carot @ 2011-03-23 9:26 ` Johan Hedberg 2011-03-23 11:44 ` Elvis Pfützenreuter 0 siblings, 1 reply; 7+ messages in thread From: Johan Hedberg @ 2011-03-23 9:26 UTC (permalink / raw) To: Santiago Carot; +Cc: james.steele, epx, wjturner, linux-bluetooth Hi, On Wed, Mar 23, 2011, Santiago Carot wrote: > > > There has been discussion whether BlueZ HDP is correct or not in this > > > respect. The HDP specification says that devices SHOULD require authenticated > > > and encrypted connections (which maps to SEC_HIGH) while some devices are > > > known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD', > > > not 'SHALL'. > > > > An "authenticated" connection has a slightly ambiguous meaning in > > Bluetooth since 2.1+EDR, since you can have an authenticated link that > > does not have any MITM protection. > > > > I think the correct behavior is that HDP should be using "Level 2" > > (from GAP in the Core specification), where HDP wants the strongest > > level of security it can achieve with a device, but it does not want to > > exclude devices that do not have the capability to support input/output. > > > > There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ > > and Security Level 2 in GAP. I believe that the intention of Level 2 > > is to propose that MITM protection is needed - however it will happily > > accept security where no MITM protection has been achieved (this being > > the difference between Level 2 and Level 3). BlueZ however does not > > seem to propose MITM protection for SEC_MEDIUM - which would be important > > for HDP (at least in the BlueZ <-> BlueZ case). > > I remember that issue with we were developing HDP and MCAP. We set > SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS. > The problem doing that is related with devices that don't support MITM > protection (In fact if they don't have any > user input capabilities). This may be a good opportunity to go back > about this issue. What do you think? > > In any case, such as Elvis has said, you can disable sspmode to get > HDP working without modify BlueZ code. Either I just don't remember correctly how SEC_MEDIUM is supposed to work or then there's some confusion here. Medium security will require encryption. The main difference that high security brings is that unauthenticated link keys will not be accepted. Furthermore, you should also be able to get an authenticated link key with medium security as long as both sides have the IO capabilities for it and at least one side requires MITM protection (only if *neither* side requires MITM will Just Works be triggered). Johan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BlueZ health device interface, problems with link security level? 2011-03-23 9:26 ` Johan Hedberg @ 2011-03-23 11:44 ` Elvis Pfützenreuter 2011-03-23 11:47 ` Santiago Carot 0 siblings, 1 reply; 7+ messages in thread From: Elvis Pfützenreuter @ 2011-03-23 11:44 UTC (permalink / raw) To: Johan Hedberg; +Cc: Santiago Carot, james.steele, wjturner, linux-bluetooth On 23 Mar 2011, at 06:26 , Johan Hedberg wrote: > Hi, > > On Wed, Mar 23, 2011, Santiago Carot wrote: >>>> There has been discussion whether BlueZ HDP is correct or not in this >>>> respect. The HDP specification says that devices SHOULD require authenticated >>>> and encrypted connections (which maps to SEC_HIGH) while some devices are >>>> known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD', >>>> not 'SHALL'. >>> >>> An "authenticated" connection has a slightly ambiguous meaning in >>> Bluetooth since 2.1+EDR, since you can have an authenticated link that >>> does not have any MITM protection. >>> >>> I think the correct behavior is that HDP should be using "Level 2" >>> (from GAP in the Core specification), where HDP wants the strongest >>> level of security it can achieve with a device, but it does not want to >>> exclude devices that do not have the capability to support input/output. >>> >>> There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ >>> and Security Level 2 in GAP. I believe that the intention of Level 2 >>> is to propose that MITM protection is needed - however it will happily >>> accept security where no MITM protection has been achieved (this being >>> the difference between Level 2 and Level 3). BlueZ however does not >>> seem to propose MITM protection for SEC_MEDIUM - which would be important >>> for HDP (at least in the BlueZ <-> BlueZ case). >> >> I remember that issue with we were developing HDP and MCAP. We set >> SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS. >> The problem doing that is related with devices that don't support MITM >> protection (In fact if they don't have any >> user input capabilities). This may be a good opportunity to go back >> about this issue. What do you think? >> >> In any case, such as Elvis has said, you can disable sspmode to get >> HDP working without modify BlueZ code. > > Either I just don't remember correctly how SEC_MEDIUM is supposed to > work or then there's some confusion here. Medium security will require > encryption. The main difference that high security brings is that > unauthenticated link keys will not be accepted. Furthermore, you should > also be able to get an authenticated link key with medium security as > long as both sides have the IO capabilities for it and at least one side > requires MITM protection (only if *neither* side requires MITM will Just > Works be triggered). So it is a matter of testing HDP with Nonin oximeter (which works with HIGH security) having BlueZ set to MEDIUM. If it works ok, we should submit a patch to change HDP to MEDIUM. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BlueZ health device interface, problems with link security level? 2011-03-23 11:44 ` Elvis Pfützenreuter @ 2011-03-23 11:47 ` Santiago Carot 0 siblings, 0 replies; 7+ messages in thread From: Santiago Carot @ 2011-03-23 11:47 UTC (permalink / raw) To: Elvis Pfützenreuter Cc: Johan Hedberg, james.steele, wjturner, linux-bluetooth Hello, 2011/3/23 Elvis Pfützenreuter <epx@signove.com>: > > On 23 Mar 2011, at 06:26 , Johan Hedberg wrote: > >> Hi, >> >> On Wed, Mar 23, 2011, Santiago Carot wrote: >>>>> There has been discussion whether BlueZ HDP is correct or not in this >>>>> respect. The HDP specification says that devices SHOULD require authenticated >>>>> and encrypted connections (which maps to SEC_HIGH) while some devices are >>>>> known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD', >>>>> not 'SHALL'. >>>> >>>> An "authenticated" connection has a slightly ambiguous meaning in >>>> Bluetooth since 2.1+EDR, since you can have an authenticated link that >>>> does not have any MITM protection. >>>> >>>> I think the correct behavior is that HDP should be using "Level 2" >>>> (from GAP in the Core specification), where HDP wants the strongest >>>> level of security it can achieve with a device, but it does not want to >>>> exclude devices that do not have the capability to support input/output. >>>> >>>> There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ >>>> and Security Level 2 in GAP. I believe that the intention of Level 2 >>>> is to propose that MITM protection is needed - however it will happily >>>> accept security where no MITM protection has been achieved (this being >>>> the difference between Level 2 and Level 3). BlueZ however does not >>>> seem to propose MITM protection for SEC_MEDIUM - which would be important >>>> for HDP (at least in the BlueZ <-> BlueZ case). >>> >>> I remember that issue with we were developing HDP and MCAP. We set >>> SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS. >>> The problem doing that is related with devices that don't support MITM >>> protection (In fact if they don't have any >>> user input capabilities). This may be a good opportunity to go back >>> about this issue. What do you think? >>> >>> In any case, such as Elvis has said, you can disable sspmode to get >>> HDP working without modify BlueZ code. >> >> Either I just don't remember correctly how SEC_MEDIUM is supposed to >> work or then there's some confusion here. Medium security will require >> encryption. The main difference that high security brings is that >> unauthenticated link keys will not be accepted. Furthermore, you should >> also be able to get an authenticated link key with medium security as >> long as both sides have the IO capabilities for it and at least one side >> requires MITM protection (only if *neither* side requires MITM will Just >> Works be triggered). > > So it is a matter of testing HDP with Nonin oximeter (which works with > HIGH security) having BlueZ set to MEDIUM. If it works ok, we should > submit a patch to change HDP to MEDIUM. I'm agree. I'm going to send a patch fixing that ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-03-23 11:47 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTi=Kohr02dZOFS4HJknp=keMTCN47jYFOdJBN7Ze@mail.gmail.com>
2011-03-22 16:37 ` BlueZ health device interface, problems with link security level? Bill Turner
2011-03-22 16:47 ` Elvis Pfützenreuter
[not found] ` <AANLkTikTJsY3-WY12hD0yTbU3u7ovW3C1CHic2WReoZq@mail.gmail.com>
2011-03-22 18:46 ` james.steele
2011-03-23 9:17 ` Santiago Carot
2011-03-23 9:26 ` Johan Hedberg
2011-03-23 11:44 ` Elvis Pfützenreuter
2011-03-23 11:47 ` Santiago Carot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox