Hi All Been quite busy and wasn't able to respin this again, but here is what seems to be a complete implementation (although probably I missed a few things).
As I indicated before, as part of the work for Wireless USB, I need to introduce in the USB stack the concept of unauthorized vs authorized device. WUSB introduces the idea of authenticated (vs unauthenticated) device, so that you have an standarized way to establish strong crypto between your host and your device. Before being able to do anything useful we have to authenticate a device. This even includes reading string descriptors; for what it matters, the unauthenticated device is able only of authenticating. Because authentication happens using (wireless) USB requests, the USB stack has to be up and running in what respects to its knowledge of the device (so we can run URBs). As well, we'll need to contact user space to obtain pairing data (shared secret keys, etc for out-of-band association using the Cable-Based-Association model), confirming identity (for numeric association, similar to bluetooth's) and user input from conditioning for allowing a device to connect to the system or not. So I came up with the idea that maybe it was easier to dissociate the 'wusb authentication' from the 'authorization to connect to the system', and so does this patchset. At the end the process will become: 1. a wusb device wants to connect to the system 2. system 'connects' it as unauthenticated/unauthorized; device is partially connected (no drivers are bound, no configuration is selected). 3. user space receives a new device notification. user can decide if to ignore the connection request (end) 4. user space decides to authenticate the system (authentication interaction happens through sysfs); if it fails, break. $ method yet TBD, working on it... 5. authentication succeeds, user space authorizes the device to connect; device is fully enumerated. $ echo 1 > /sys/class/usb_dev/X/authorize 6. Use the device... Thus, this patchset provides the means to do that; means to authorize/deauthorize a device from user space, that effectively means configuring or unconfiguring it (plus associated headaches). Because it is fully dissasociated from the WUSB devices, it can be used for all kinds of USB devices. Other benefits/thinkings are: - The authentication (WUSB or other) process is completely separate, and is orthogonal to this. WUSB authentication is quite complex (I'd like to say is a pain in the ass) that requires in the most simple case (when the secrets have been exchanged out of band) at least four USB transactions if all things are ok (citing by memory). Numeric association takes even more. All this must be done in close collusion with user space, who manages the secrets database. The further away it is from the mechanism and the USB core, the better. - System lockdown: Could be used to enforce a policy of USB device connection that some security-paranoid organizations might enjoy (for example: don't allow to plug USB dongles that could be used to copy sensitive data or allow only the ones that have an approved crypto system with keys signed by the CA...etc...<insert your paranoid method here>). [*1] - Could also be used to implement black/white lists for devices that aren't compliant, etc, fully controlled from user space. This has been compiled against 2.6.21-rc7 (2.6.21) should work. When trying it against 2.6.22-rcsomething I saw a conflict in one of the patches, but doesn't seem to be *that* serious. Most of the stuff should be ok. [*1] Cited from a previous email I sent: A case that comes to mind are medical devices, where only certain configurations are tested and FDA certified--(so it is a white list of devices). Udev checks against the whitelist. Device could trick the host yes, but that's why the enforcing mechanism is not in the kernel, so your user space sw called by udev figures out how to do it so that it is good enough. The kernel only cares about being said to authorize it to connect or not via the sysfs interface. -- Inaky ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
