Re: RFC/patch: authorizing (or not) devices to connect to the system

On Tuesday 24 April 2007, Eric Blossom wrote:
> On Tue, Apr 24, 2007 at 05:46:16PM -0700, Inaky Perez-Gonzalez wrote:
> > 
> > Hi All
> > 
> > As part of the work for Wireless USB, I need to introduce in the USB stack
> > the concept of unauthorized vs authorized device. The first one is one that
> > cannot be really used until we move it to authorized, but at least we have
> > some knowledge of it.
> 
> Instead of "breaking the USB stack", why don't you just force your
> authorization into the peripheral, and have it refuse to work/transmit
> until your magic authorizer has talked to it.

Have a look at the wireless USB spec.  There's a secure key
handshake, relying on pre-established keys.  (Most easily
established using a wired connection, of course, since it's
so easy to ensure physical security there!)

Both sides need to be authenticated, so that for example your
disk can't send your sensitive data to the wrong host, and your
host can't write that data to someone else's disk.

Some of the authentication (not "authorization"!!) *is* in the
peripheral.  But not all of it.

Agreed that the USB stack should need minimal surgery; but
what's really missing in this patch series is the real work
of doing that authentication and key management.


Inaky ... it would be very useful to implement the authentication
and key management steps as used in the wired cases.  We know that
needs to work, and we also know those cases won't actually need to
disrupt the USB stack very much.  That would make the radio-related
updates a lot clearer when they're ready.  (Including the extra
pre-enumeration states.)



> That way you don't need to 
> contaminate the rest of the system with what I assume is your attempt
> to placate the FCC.  I'm sympathetic to your problem, but the solution
> seems a bit overbearing.  Last time I checked, this wasn't Windows Vista.

FCC has nothing to do with this.  Think of it as more like storing
your data on a web server through HTTPS -- and requiring both host
and client side certificates.  (But not needing to pay Verisign or
run your own local CA.)  There's some messy stuff you're often not
aware of that kicks in before you can actulaly read or write that
data ... and in a few cases that stuff *must* be visible.

- Dave


-------------------------------------------------------------------------
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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel