[Freedombox-discuss] Crypto questions

Sat Apr 23 12:26:28 UTC 2011

On 11-04-23 at 03:07pm, Sandy Harris wrote:
> Strong security is an essential attribute for the freedom box, and
> security is notoriously hard to get right. To a very large extent,
> the box can just use existing components, but "the devil is in
> the details", so here are some questions to start discussion
> on some of the issues that come up.
> 
> One question is "what have I missed?"
> 
> A big question is "What do we do about SSL/TLS?" It is
> an important, even essential, protocol, the standard way
> to protect various web activities, and the basis of most of
> the VPNs people use to bypass the Great Firewall and
> other censorship.
> 
> However, it depends on certificates for authentication.
> Without good authentication, you have no security.
> You can encrypt outgoing messages so that only the
> recipient can read them and check authentication
> on incoming ones to be sure they are from the
> expected sender and have not been altered en
> route. However, those do zero good if you do not
> know who you are talking to.
> 
> Arguably, the whole certificate infrastructure for SSL
> is broken beyond repair. My /etc/ssl/certs has 289
> Certificate Authorities listed. These are not just
> people I am expected by default to trust; they can
> sign certificates that make me trust others.
> 
> Among other problems, many CAs are run by
> government agencies, some by governments
> with policies antithetical to the box.

CA Certificates are just _vectors_ of trust.  They do not promise you 
e.g. that your friends will not betray you.  By collecting more trust 
vectors you can gain more trust - and FreedomBox can help calculate how 
much trust you have collected towards each of your peers.

Instead of throwing away all CA certificates, it makes better sense to 
me to put into UX design a visualization of the _types_ of trust vectors 
governing various types of communication.  That out of the box there are 
some _commercially_ and organizational trust vectors and some community 
driven ones (e.g. Debian PGP keyring).  Our user may then - initially or 
later - educate their FreedomBox what types of trust vectors they favor, 
and maybe even put a negative score to e.g. "commercial" or "western" 
vectors.

Then the FreedomBox can offer a "trust quality" meter for the included 
tools served on the box - e.g. when someone comments on your blog, or a 
VoIP call comes in, you can see how "trustworthy" the link is.
Facebook suggests friends based on your existing friends, their 
relationships with each other, and your activities amongst each other.  
FreedomBox can do similar for trust vectors, I believe.

I imagine a properly configured semantic database is essential here.  
Setup tools so that the FreedomBox can _learn_ to improve trust vectors 
based on human relationships gathered anyway.  Have e.g. addressbook 
entries and sorting of browser bookmarks be key ingredients for rating 
trust vectors.

Maybe Monkeysphere does such things already? I don't know.

> Passwords are a standard security mechanism and very often
> a weak link. You can avoid passwords altogether for many
> server activities by using the public key stuff in SSH. Great
> for some of us, but is it going to be usable by our target
> market? If not, what would that take?
> 
> One thing to look at is ways to eliminate the default
> password at setup:
> http://www.turnkeylinux.org/blog/end-to-default-passwords
> 
> Another is Bcrypt, a password system that aims
> to be more secure:
> 
> An overview/advocacy article:
> http://codahale.com/how-to-safely-store-a-password/
> The original technical paper:
> http://www.usenix.org/events/usenix99/provos.html
> 
> Bcrypt is the default for NetBSD. It is available in the
> Ubuntu repositories, so I presume also in Debian. I'd
> say it should be the default for the box, and we could
> ask the Debian folks to look at whether it might
> become the default for Debian.
> 
> Almost all crypto needs random numbers, and much
> otherwise sound crypto is easily broken if it is used
> with a weak random source.
> 
> No problem on a typical Linux desktop; it does not
> do much crypto and /dev/random gets input from
> keyboard & mouse movement, disk delays, etc.
> However, it might be a major problem for a plug
> server that does more crypto, runs headless, and
> use solid state storage.
> 
> Some plug computers may have a hardware RNG,
> which is the best solution, but we cannot count on
> that in the general case.

We can perhaps integrate into UX design an indicator of encryption 
quality - i.e. if (or how frequent) random pool got depleeted?

> Where the plug has a sound card equivalent, and
> it isn't used for sound, there is a good solution
> using circuit noise in the card as the basis for
> a hardware RNG.
> http://www.av8n.com/turbid/paper/turbid.htm
> 
> A good academic paper on the problem is:
> https://db.usenix.org/publications/library/proceedings/sec98/gutmann.html
> 
> However, his software does not turn up in
> the Ubuntu repository. Is it in Debian?
> Could it be?
> 
> Ubuntu, and I assume Debian, does have
> Havege, another researcher's solution
> to the same problem.
> http://www.irisa.fr/caps/projects/hipsor/
> 
> This is not as well-known as Gutmann's work.
> Has anyone anlyzed it?

That must be haveged: http://packages.debian.org/sid/haveged

There's also randomsound: http://packages.debian.org/sid/randomsound

Not my expertise - I just know they exist.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110423/ea32c28a/attachment.pgp>