[Freedombox-discuss] Crypto questions

[Sandy Harris]

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.

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.

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?