[Freedombox-discuss] Package Lists and Configuration

[Johan Henselmans]

On 8 feb. 2013, at 04:38, "Nick M. Daly" <nick.m.daly at gmail.com> wrote:

> Johan Henselmans <johan at netsense.nl> writes:
> 
>> Thanks Nick, I have just read up on the FreedomBuddy
>> project. (http://wiki.debian.org/Freedombox/FreedomBuddy).
> 
> Huh.  I didn't know that page existed.  Thanks, planetlarg.  It's
> outdated, but there is no updated documentation (until after this
> weekend, when the dust settles).
> 
>> That seems a solution, until your tor/GNUnet endpoint service is
>> compromised, which seems not too hard, considering we are talking
>> about bad guys not encumbered by legal restrictions.
> 
> Please define compromised.  I'm not being a pedantic jackass here, I'm
> wondering what you mean exactly.  If the message you receive fails to
> decrypt to your key, FBuddy ignores it, so it's unlikely that you'll
> compromise FBuddy itself with malformed input.  If you mean someone
> duplicating your Tor Hidden Service identity and posing as you, then
> they can't read your messages without your key.  It's also difficult to
> duplicate an identity without physically taking over the hosting box.
> 

Sorry, I meant purely on an IP-level. Organization suspects unwanted stuff regarding organization going on, tracks Tor/Gnunet servers inside area on which it exerts power, then takes over routers before Tor/Gnunet server, pinpoints Tor/Gnunet boxes.

With the amount of routers that routinely are compromised, the area in which an organization can exert power has to be presumed bigger than its geographic boundaries. 

I was thinking of a mesh network (wifi, 3G, Zigbee) of dirt-cheap boxes that might be randomly distributed to locations, turned on and off in a random way to prevent triangular pinpointing to make it harder to get to the users box. Perhaps tor/gnunet servers configured in such a way would already do the trick. I am not familiar with the build-up time of a tor network, if that would be feasible. I have just bought some extra Raspberries with Wi-Pi wifi plugs  (next to my dreamplug, ionics stratus/guruplug) and some other el-cheapo hardware, and could do some testing, if it is worth the effort. 

Or has somebody already been doing some testing on such a setup?


>> Compromised GPG keys is the other problem.
> 
> Yeah.  Rule #1 of network security: if the attacker has physical access
> to the box, you're screwed.  Nothing anyone can do can prevent that,
> unless you avoid creating or using the service at all.
> 
>> I still have a GPG key created in 2001, which I am sure is on some
>> keyservers. My sloppy security behavior ( the private key had been
>> transported from server account to server account, some of which I am
>> pretty sure they were compromised), combined with some rainbow-tables
>> and other brute force attack scripts make it sure that my private key
>> would be compromised by now-if anyone would be interested.
> 
> Then revoke or expire it, if you still have the password.  A compromised
> 12 year old key is just bad manners.
> 

I just used it as an example. I don't use that key anymore, I know irony is hard to transmit in an email conversation: I am just using myself as the clueless user, instead of pretending to be a know-it-all security expert.

> If users are determined to shoot themselves in the foot, we can't stop
> them.  In order to preserve their software freedoms (and Asimov's laws),
> we have to assume users mean to do what they're doing.  The best we can
> do is to make key management as easy (or as secure, depending on the
> user's request) as possible.
> 

Absolutely,  

>> A solution would be to make sure anyone would have a smart-card
>> derived PGP key with opensc, so that if you can not find your smart
>> card you should assume your key is compromised. That also poses the
>> problem of losing ones precious would make your freedombox data lost.
> 
> You're free to go with whatever you're more comfortable with, it all
> involves tradeoffs.  Me, I'm happy keeping a subkey (or single-purpose
> key) on the box.  If the SSSS system [0] pans out and keys are never
> written to disk, then whole keys are never hosted anywhere and the box
> has to be captured alive, without ever losing power, significantly
> raising the bar for attacks.
> 
> 0: http://lists.alioth.debian.org/pipermail/freedombox-discuss/2013-February/005106.html
> 
>> But perhaps you have already discussed that kind of setups.
> 
> I have, but I doubt I've convinced you.  Please, rebut!
> 

Sorry for taking so much time. I am just trying to come up with scenarios that might compromise the whole effort. The subkey approach seems to be fine.

Something unique one might have and something one might know, I was always taught would be the combination. I'll see if I can get a smart card reader of some sort running against the dreamplug setup, and try to get some pgp/opensc running against that. 

If there is anyone around that has already been doing that, please let me know, so not to duplicate efforts. 


> Thanks for your time,
> Nick

Johan Henselmans
johan at netsense.nl