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 [email protected] http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
