2011/10/12 Joel jaeggli <joe...@bogus.com>

> On 10/11/11 18:38 , Ted Lemon wrote:
> > On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
> >> However, I am thinking that we can perhaps bootstrap equipment that has
> >> never been configured (or has been factory reset) in some fashion such
> >> that if the equipment is "virginal" that it can essentially always try
> >> some default keys, and bring up enough networking to let all equipment
> >> be discovered and identified.  There would be strong nag screens to get
> >> the user to up a network password.
> >
> > A pre-shared key that is pre-shared to every device is the same as no
> > key.
>
> Not really, it could serve an important hygenic function, notionaly, it
> could be filtered by default on all non-home-network gear. that is
> serves the purpose of identifying a well-known-service. there are of
> course other perhaps better ways to implment that.
>
> >  So you might as well not bother with that complexity.
> > Conceivably CGA could be used to publish public/private key pairs
> > allowing devices to automatically recognize each other and present their
> > relationships in a UI for the end user to approve, but that's not
> > precisely plug and play.
> >
> > I think the simplest thing would be to require that each device be able
> > to talk to a USB drive.   Each device collects all the public keys on
> > the USB drive, and stores their own there.   Devices then share their
> > public key with other devices identified on the USB drive, so that as
> > each device joins the network, the other devices learn about it.   This
> > isn't bulletproof—an infected PC that's configured with these keys could
> > be used to gain access to the keys, for example.   But it's a lot better
> > than a well-known key.
>

What about ID-based signature?

Just improvising (so forgive me for any naivety): the ID of the device could
be a triplet (producer-ID, product-ID, serial-number); the "key generator"
could be the producer itself (avoiding in this way the key escrow problem
related to ID-based cryptography) and a certificate with the public key of
the producer could be downloadable from some well-known host (alternatively,
the key of most known producers could be "built in" the device).

The authentication procedure would follow  the usual challenge scheme: the
device receives a challenge string, it appends to it a nonce and signs the
result with its private key (hardwired at production time).  If the
authentication is positive, then you know that you are talking to that type
of device, produced by that producer (if you trust the producer is another
matter).  Of course, this simple scheme would fall to a device-in-the-middle
attack, but maybe in this  context it is not a likely attack.

>
> > Of course, this isn't quite as plug and play as you seem to want, and it
> > requires that each device have a USB port, which might not be
> > acceptable.   Plus, it would mean that the IETF would have to talk about
> > hardware, which seems like a bit of a non-starter.   But I think it's
> > the right way to solve the problem.
> >
> >
> >
> > _______________________________________________
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to