Hi Johan, On Tue, 2012-01-17 at 03:27 -0500, Johan Hedberg wrote: > Hi Peter, > > On Mon, Jan 16, 2012, Peter Hurley wrote: > > The situation with this patch is that I asked Gustavo not to apply it > > (via IRC). Although the patch works, the overall logic of the > > auth/encryption system is flawed. > > > > With respect to this issue specifically (ie, ssp vs. non-ssp auth + > > encrypt), the flaw is that the semantic meaning of the > > HCI_CONN_ENCRYPT_PEND bit is overloaded. The meaning of one sense is > > that an actual HCI_OP_SET_CONN_ENCRYPT command is in-flight, and thus, > > for this hci connection, neither an auth nor encrypt request should be > > sent. The second meaning is that the event handler *should* submit an > > encrypt request upon receiving a successful auth complete event. > > > > At the time, I had a patch prepared which addressed this duality as part > > of a series which enabled true re-auth & sec_level promotion. > > Unfortunately, I discovered that a prior patch had been submitted and > > applied which specifically disables sec_level promotion for non-ssp > > devices. The ml conversation died here > > http://marc.info/?l=linux-bluetooth&m=131609282919575&w=2 so I dropped > > it. > > I think it'd be important to continue with this work. Even for > controllers that don't allow a "security upgrade" you can still detect > the situation when you get an auth_complete without any preceding > link_key or PIN request and just drop the connection in such a case. For > legacy pairing this would only happen when going from MEDIUM to HIGH > since LOW means that you don't have a link key yet. > > Btw, could you tell me the commit id of this "patch which specifically > disables sec_level promotion for non-ssp devices"? 19f8def Bluetooth: Fix auth_complete_evt for legacy units Peter -- 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
