[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] Crypto questions



On 04/23/2011 03:07 AM, 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.
>
> 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?
>
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
Time to demonstrate my ignorance on the subject: the FBX will have a 
mic, right?  Why not pick several different frequencies, at random, and 
then at random intervals, read levels of background or street noise for 
digits?
Even if your RNG to pick frequencies and times wasn't truly random, I'd 
think that real-world noise levels would effectively wreck any 
discernible pattern in the end result.  If this idea isn't so great, 
please, somebody speak up.  Bad ideas must die, here, preferably sooner 
than later.
-And I have no idea how this notion would be enacted.  Not a coder, at all.



Reply to: