[Freedombox-discuss] FBX Server/Client Communication Model and Threat Modeling

[Nick M. Daly]

As before, please continue this discussion here or on the FBX wiki:

    http://wiki.debian.org/FreedomBox/ClientServerCommunication

Melvin Carvalho <melvincarvalho at gmail.com> writes:

> Hi Nick, great topic.  Which client/server interactions would you envisage
> as being high on the priority list?  e.g. ssh to box, login to dashboard
> via a browser, using gpg based tools for email etc. ... a specific context
> may be slightly easier to visualize the possible attack surface ...

That's a really good point.  I'm seeing a few different potential
client/server interactions here.  How do we enforce, yet not compromise,
key and identity material for both end points in each case?  How do we
deliver services or client-applications from the server to the client?

0. Everything connects to a fully free FreedomBox: DreamPlug or
   equivalent that's fully verifiable (without binary blobs or non-free
   software).

I care about two different aspects of each client:

1. Is the client fully end-user-controlled and verifiable?

   - Binary blobs?
   - Firmware?
   - Bootloader?
   - Non-free software?

2. Is the network trustworthy? 

   - End-user-controlled?
   - Verifiable?
   - End-to-End?
   - Other Criteria?

Am I missing anything meaningful?

These attributes are non-exclusive and seem to line up like:

1. (Yes, Yes) A fully trusted client (a user-owned/rooted laptop)
   connecting over wifi.

2. (Yes, No) A rooted phone connecting over most data-networks, or a
   tethered laptop.

   This case seems to simplify to (Yes, Yes) as, unless the network
   censors encrypted connections, you could always set up a VPN.  In
   those cases, it seems to transform into (No, No), as the user has to
   be complicit in the network's insecure requirements.

3. (No, Yes) A compromised client connecting over a "trusted" connection.

   A rooted phone connecting over wifi: the client could be ratting out
   the user, and the network would never know.  Most Windows boxes fall
   into this category.

4. (No, No) A compromised client connecting over a compromised
   connection.

   These are called iPhones.

What do we need to support useful communication between each without
disclosing secret-identity material to third parties?

My suspicions are:

1. This one's easy as pie, were pie easy.  If we need client
   applications, we use them.  If we need browser plugins, we use them.
   If we need a network, we use it.  We can enforce any restrictions we
   need for secure communications.

2. Initial delivery is difficult but, thereafter, execution is easy.

3. We can't trust the client, so it can't handle its own data.  ...What?
   Yeah...  We have to start being creative here.  Perhaps the client
   could hold half its (secret-shared) key, which is delivered to the
   server on connection.  Anybody could extract the key and impersonate
   the client.  It's the same problem as
   third-party-advertising-networks: only your adversaries and their
   3,000 closest friends have the information you don't want them to
   have.  Without your phone and password nobody else could impersonate
   you, though, so your secrets are safe from your siblings.

4. I have no idea how to handle the iPhone case.  iPhones can't store
   their own key identity material, as it's preemptively compromised.
   This is where the client-key-splitting idea comes into play, but that
   makes each FreedomBox a more worthwhile target, as knocking one of
   those over then compromises all its clients.

   I would be stunned if FBX applications were inoffensive enough to be
   distributable through any app stores.  Users can say *anything* they
   want and *we can't censor them?!* It'd never fly.

How do we support all four modes at once?  Anybody want to add another
variable and make it 8 or 16 states?

If anyone's aware of any recent research into these problems, I'd
appreciate the pointers.

Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130216/a23f2dc5/attachment.pgp>