As before, please continue this discussion here or on the FBX wiki:
http://wiki.debian.org/FreedomBox/ClientServerCommunicationMelvin Carvalho <[email protected]> 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
pgpAtXR9x_isB.pgp
Description: PGP signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
