<br><br><div class="gmail_quote">On 16 February 2013 04:25, Nick M. Daly <span dir="ltr"><<a href="mailto:nick.m.daly@gmail.com" target="_blank">nick.m.daly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks, here's an active question that I'd appreciate your input on.<br>
<br>
    What is an appropriate threat-model for the FreedomBox's<br>
    client-server communications?<br>
<br>
Please discuss on list or feel free to add to the FBX wiki:<br>
<br>
    <a href="http://wiki.debian.org/FreedomBox/ClientServerCommunication" target="_blank">http://wiki.debian.org/FreedomBox/ClientServerCommunication</a><br>
<br>
This question has a number of obvious answers, but keep in mind the<br>
project's end-goals: to bring communication freedom to as many folks in<br>
as many situations as possible.  To that end, what are appropriate<br>
compromises between server and client security, accessibility, and<br>
availability?<br>
<br>
It seems to me that client devices fall into one of two basic<br>
categories:<br>
<br>
1. Those on which the user has root privileges and fully trusts (like<br>
   their own laptop, running a fully free operating system and BIOS, in<br>
   which no mal/spy/inscrutable-ware exists).<br>
<br>
2. Those on which the user doesn't have root privileges and therefore<br>
   can't fully trust (an iPhone, a laptop with non-free software and/or<br>
   binary kernel blobs, a desktop with a non-free BIOS).<br>
<br>
I've illustrated the fact that there's a range of trustworthiness,<br>
though I don't know how to meaningfully measure this quantitatively (I'd<br>
like to survey and classify devices, but I don't know how to massively<br>
and remotely detect un-trustworthy or malicious software, suggestions<br>
are welcome).<br>
<br>
At this point, I'm worried about secret key (identity) material.  This,<br>
being the most important and secret of data, can teach lessons that can<br>
be applied to nearly all other data.<br>
<br>
I'll start by throwing out a few more directed questions to start off<br>
the discussion:<br>
<br>
1. Who can be trusted with which secret key material?<br>
<br>
   1.A. Can servers be trusted with the client's key?<br>
<br>
   1.B. Which clients can be trusted with parts of the server's key?<br>
<br>
2. In what ways is it acceptable for devices to give up which secrets?<br>
<br>
   For example, is it acceptable if the client's secret key be exposed<br>
   when the box is rooted by attackers?  (Probably not, but that does<br>
   let the host act as a trust proxy without relying on subkeys, or<br>
   other weird yet conceptually interesting trust models).<br>
<br>
3. What is the client application delivery model?  Is it:<br>
<br>
   3.A. Browser-based interaction between client and server?<br>
<br>
   3.B. Browser-plugin-based interaction?<br>
<br>
   3.C. Appstore-based interaction?<br></blockquote><div><br><br>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 ...<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks for your time,<br>
Nick<br>
<br>_______________________________________________<br>
Freedombox-discuss mailing list<br>
<a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br></blockquote></div><br>