Hello, 2011/3/23 Elvis Pfützenreuter <epx@xxxxxxxxxxx>: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
