Hi Brian, On 11:55 Thu 03 Mar, Brian Gix wrote: > > Hi Vinicius & All, > > I am starting to move forward on the LE Security Manager for bluez. > I am currently using the patches submitted by Vinicius for > bluetooth-next, and hope that they are accepted by Gustavo soon, but > at some point, I will be forced to move forward with or without that > acceptance. I hope so too. There are still some still some details to be sorted out, but I think that the meat of those patches will stay as they are right now. > > My more immediate attention is therefore placed on key storage (LTK, > IRK, CSRK), and high level APIs, in particular Passkey agents for > MITM support. > > If anyone is working these problem already, I would like to discuss > details, so that we are not coming up with competing solutions. The > main reason I would like Vinicius' patches accepted sooner rather > than later is so that I (and others) can start contributing these > next pieces without creating a divergence headache. > I have a very simple implementation of the key distribution part, for now it is focused on only the LTK. As I did a lot of experiments while writing it, the code still a mess. I hope to have a cleaner version soon and will send a RFC, so more people can take a look and test it, which was extremely useful the last time :-) I think that the most important fact about this implementation is that it is dependend on the Management Interface[1]. It needs this interface for communicating userspace about new keys and so userspace loads the stored keys when the userspace daemon is run. > To begin with, I am planning on making the key storage part of the > existing system used by BR/EDR. I am primarily concerned with Dual > Mode devices, and we believe that from a "big system" point of view, > that most of the differences between remote dual-mode and remote > LE-only can be largely abstracted and out of sight by high level > apps. The main differences between LE keys and BR/EDR keys of > course is that there are multiple keys per "pairs of devices", and > except for LTKs, they are used very differently. For now I have a separate storage for LTKs. For the other kinds of keys I am still not sure how to store/use them. Right now, your idea holds, it is completely hidden from the apps how the pairing happened. > > Also, I understand that some people think that Write-Cmd signing > (CSRK) and verification should be a function of GATT/ATT in User > space, and others think it should be handled down in the SM kernel > on the way out (and in). I know that the crypto library is being > brought into the kernel for STK resolution, and this would seem to > point towards kernel based signing and verification. How/where to do signing is a very good question. I just have a small preference about doing it in userspace (most of the ATT stuff is there). But it is just a gut feeling. This is something that any form of input will be awesome. > > Privacy is the biggest problem however. Identity *resolution* can > of course be done at the kernel level but if addresses change, we > will need to come up with a plan as to how to deal with everything > up to and including dbus object-paths that currently include an > ascii representation of the BD Addr as part of the path. At the > highest (DBus) level I am thinking that a signal on the original > object path might work when we connect/detect a new address for an > existing device, and an object path which is then an extension of > the originally paired device: > > If Original was: > /org/bluez/3456/hci0/dev_XX_XX_XX_XX_XX_XX > > The Private could be: > /org/bluez/3456/hci0/dev_XX_XX_XX_XX_XX_XX/priv_YY_YY_YY_YY_YY_YY > Yeah, this is the most serious problem. One thought that happened some time ago, was that the DBus path doesn't have to have the address, it is just a path, we could change the way we name the objects, as long as the naming is consistent i.e. the same device will have always the same path. But even without this restriction I guess there are few problems that need be solved before we can support Privacy the Right Way. In short, any help with this will be great :-) > > Anyway, we are starting work on this soon, so if there is > competing/complimentary work being done, I would really like to hear > from you. There is a lot to be done here, and I'd like to have the > architectural conversations sooner rather than later. > > I would also like to hear from you if you simply have a good idea of > how you think these LE pieces should be architected, and haven't > started writing code. > > > > -- > Brian Gix > bgix@xxxxxxxxxxxxxx > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum Cheers, -- Vinicius [1] http://www.bluez.org/the-management-interface/ -- 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
