[Freedombox-discuss] Configuring Mobile Devices

[Matthew Johnson]

> From: Osama Khalid <osamak at gnu.org>
> To: freedombox-discuss at lists.alioth.debian.org
> Subject: [Freedombox-discuss] Configuring Mobile Devices
> 
> Eben was referring to the possibility of configuring 'mobile devices'
> to connect the FreedomBox directly without any third party.
> 
> I was wondering, what kind of devices is targeted? Is this kind of
> integration already implemented whether in free or proprietary
> technologies?

My take on this was having a mobile device (some sort of smart phone) which you
securely tether to your freedom box so that it can trust you to control it via
that device. Essentially, the association would establish a key-pair between
the devices to allow you to be trusted to update the FB from that device. You
also want to be able to change associations, resell the FB and have it lose
it's original associations and so on.

I'm going to go into research mode slightly and start referencing relevant
literature.

This concept of secure association is discussed in [0] which introduces the
"Resurrecting duckling" security policy. It's a good read and I recommend
everyone look at it. The basic premise is that the appiance (FB in this case)
would come in an 'imprintable' state. While in that state it's possible to
associate it with a controlling device, whereupon only the controlling device
can return it to being imprintable.

Doing this imprinting securely and usably is a separate problem. This is
essentially what the bluetooth protocol does, albeit very badly.  There's a
paper discussing problems with bluetooth's implementation [1], which suggests
fixes, but it still requires shared passwords.

Most key exchange protocols are vulnerable to middle-person attacks without
having some out-of-band method to identify the other party (the web of trust,
an SSL certificate provider, etc). The trick is coming up with an out-of-band
method which can be used.

This [2] 2007 paper talks about using a second (low bandwidth) channel on which
to verify the key exchange. The example in that paper is of associating two
mobile phones. Both phones display a hash and the users visually compare it.
This channel isn't confidential, but you do trust it not to have been tampered
with. Combining this with a key exchange protocol which is confidential, but
you can't trust the origin (like diffie-helman) allows you to securely
associate over an untrusted link like wifi.

How is this applicable to the FB? Well, the configuration website can be the
other half of the display if the FB device doesn't have any sort of display on
it. We can even automate the comparisons and use QR/TRIP codes which the
smartphone can automatically read (as suggested in the paper). This is possible
because the user is physically located with the FB and hence has a trusted
channel. Of course, if the user's computer is connected to the FB over wifi
then we might need another solution. Printing the initial association code on
the bottom of the FB might be sufficient for this.

Matt

0. http://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf
1. http://www.cl.cam.ac.uk/~fms27/papers/2005-WongStaClu-bluetooth.pdf
2. http://www.cl.cam.ac.uk/~fms27/papers/2007-WongSta-multichannel.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20100905/1664f9e3/attachment.pgp>