From 78d8ac5ff04134bc43cc1edc9f12c030df6d6eec Mon Sep 17 00:00:00 2001 From: James Vasile Date: Thu, 29 Sep 2011 23:19:52 -0400 Subject: Remove roadmap and design as they have no place in this package. --- doc/Makefile | 2 +- doc/design.mdwn | 196 ------------------------------------------------------- doc/roadmap.mdwn | 65 ------------------ 3 files changed, 1 insertion(+), 262 deletions(-) delete mode 100644 doc/design.mdwn delete mode 100644 doc/roadmap.mdwn (limited to 'doc') diff --git a/doc/Makefile b/doc/Makefile index 9efe8f7..6d9637d 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -7,7 +7,7 @@ PDFLATEX=pdflatex # List text files in the order in which you want them to appear in the # complete manual: SOURCES=README.mdwn INSTALL.mdwn themes.mdwn hacking.mdwn TODO.mdwn modules.mdwn scripts.mdwn faq.mdwn COPYING.mdwn colophon.mdwn -OTHER=design.mdwn roadmap.mdwn +OTHER= TODO_SOURCES=$(patsubst TODO.mdwn,,$(SOURCES)) MAN_SOURCES=$(patsubst COPYING.mdwn,copyright_notice00,$(SOURCES)) diff --git a/doc/design.mdwn b/doc/design.mdwn deleted file mode 100644 index acaa17e..0000000 --- a/doc/design.mdwn +++ /dev/null @@ -1,196 +0,0 @@ -# Freedom Box Design and Architecture - -This article describes and documents architectural considerations for -my vision of Freedom Box. It is not specific to the user interface -and instead contains thoughts about the Freedom Box as a whole. - -The major immediate design problems that I see are authentication, ip -addressing, and backup. I'm sure there are others. - -If the Freedom Box front end pulls together basic pieces and -configures them properly, we'll have the start of the freedom stack. -Then we can build things like free social networking applications on -top. - -## Design Goals - -The target hardware for this project is the -[GuruPlug](http://www.globalscaletechnologies.com/t-guruplugdetails.aspx). -It has low power consumption, two wired network interfaces, one -wireless hostapd-capable interface (802.11b), and two usb slots for -connecting external drives and peripherals. The hardware target might -change if a better unit becomes available (for example, with 802.11n -or USB 3 capability). The GuruPlug is reputed to have availability -problems involving shipping delays, and targetting a unit that cannot -satsify high demand might be an issue. - -Freedom Boxes are not giant honking servers. They are small boxes -that do perform a lot of functions. They are not heavily resourced. -So keep things small and light. - -By the same token, there is no need to scale up to thousands of users. -A box should happily serve a person and her family, maybe an extended -group of friends. Call it 100 people at the most. - -The target user for this project is the home consumer of network -appliances. It ranges from the most basic user (the kind of person -who might have spent all of three minutes setting up her LinkSys -WRT54G) to the home enthusiast who wants a local file server for media -and backups, print server and dns service. - - -## Authentication - -Authentication in the context of the Freedom Box is a diffiult -problem. You need to be able to trust your box, and it needs to be -able to trust you. What's more, security must withstand forgotten -passwords, server destruction, changing email addresses and any other -possible disaster scenario. - -In addition, your friends (and their boxes) need to trust your box -when it acts on your behalf, even if it does so when you're not around -to enter passphrases or otherwise confirm agency. But even as it -needs to operate in your absence, it can't itself have authority to -access all your data, because you might lack exclusive physical -control of the box (e.g. if you have a roommate). If the box can act -as you without limits, anybody who takes control of the box takes -control of your online identity. - -What's more, security should be high. Freedom Boxes might contain -emails or other sensitive documents. The box mediates network -traffic, which means rooting it would allow an attacker to spy on or -even change traffic. Demonstrating control of an email address should -not be enough to gain access to the box and its admin functions. - -### Passphrases - -Most users habitually think of passwords. We need to force them to -think of passphrases. It starts by using 'passphrase' in the -literature. Second, we need to encourage users to pick phrases, and -prompts should urge them to do so. We also need minimum password -lengths and maybe even a requirement of at least a few spaces. - -Even better than passphrases are passfiles. We should keep a lookout -for ways to use files instead of phrases when securing the Freedom -Box. - -### A Scheme for Secure Web Login - -Passphrases should -[never be stored in plain text](http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html). -[MD5 is too fast for passphrases.](http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html) -Therefore, my current plan for secure website login involves bcrypt: - -The server sends the client a permanent salt, PS, a random session -salt, SS and a number of rounds, R. It brcypts the password using PS -and stores the result, B. - -The browser -[bcrypts the passphrase using javascript](https://code.google.com/p/javascript-bcrypt/) -and PS. Then, it bcrypts that result with SS. It does R rounds of -bcrypt with S. The browser then sends the result, C, back to the -server. - -The server retrieves bcrypts its stored, hashed passphrase and does R -rounds of bcrypt on it with SS. If that matches C, the passphrase is -a match. - -The server must be able to keep track of sessions, as it needs to -remember SS between giving it to the client and getting it back. The -Server cannot rely on the client to remind it of SS. This would allow -an attacker to dictate SS and leave the server vulnerable to replay -attacks. - -This scheme has the dual advantage of not storing any cleartext -passphrases and also never sending any cleartext passphrases between -client and server. - -TODO: consult a security expert as to the strength of this scheme - -### Other Schemes - -#### Monkeysphere - -[Monkeysphere](http://web.monkeysphere.info/) is a promising project. -Monkeysphere's major win is that it avoids the clunkiness of SSL -certificate authorities. That's huge, except it replaces the -certificate authority structure with the PGP web of trust. Relying on -the web of trust is a good idea -([much better than relying on SSL certificate authorities](http://www.crypto.com/blog/spycerts/)), -except that new users might not have joined the web. It also requires -a bunch of GPG infrastructure that might be difficult to setup -automatically and with little user intervention. - -As of this writing, it does not appear to support Windows or Macintosh -clients, making it unsuitable for this project. - -#### Secure Remote Password - -[SRP](http://srp.stanford.edu/) is an interesting technique. Patents -are a concern. What does it buy us that my scheme, above does not? - -There is a -[python implementation](http://members.tripod.com/professor_tom/archives/srpsocket.html), -although it is not clear that it has been through the crucible. Even -if SRP is solid, this implementation might be flawed. - - - -## Finding Each Other - -### Dynamic DNS - -Each box might need multiple dynamic DNS pointers. Every box is going -to require its own set of dynamic names. For example, my Freedom Box -might be known as both `fb.hackervisions.org` and -`james.softwarefreedom.org`. My work colleagues might know me as -`james@james.softwarefreedom.org` while my friends might reach me at -`james@fb.hackervisions.org`. By default, when contacts come in via -different names, my box might be smart enough to treat those contacts -differently. - -If I share this box with my partner, Emily, she might be -`emily@jv187.fboxes.columbia.edu`, in which case my box will need -another dynamic DNS pointer. - -### Mesh Networking - -Freedom Boxes should be meshed. Rather than run in infrastructure -mode, they should route for each other and create strong local meshes -that will carry data for anybody that passes through. - -There are some problems, though. - -* I'm not sure how well nodes in ad-hoc mesh mode interact with -others in infrastructure mode. - -* The Freedom Box only has one wireless radio, which will drastically -hurt speed. - -* Routing can be difficult when connecting mesh network nodes to the WAN. - -## Backup - -Everybody should automatically and redundantly store encrypted backups -on their friend's freedom boxes. Recovery should not assume you kept -your key or know a password. We can recover the decryption key by -having a bunch of friends encrypt the key in various combinations. If -enough of my friends get together, they can decrypt it for me. -Optionally, a passphrase can serve to slow my friends down if they -turn against me. Maybe it takes 5 friends acting in concert to -recover my key, but only 3 to recover a version protected by the -passphrase. - -## Push vs Pull - -For a social network, real time communication is key. Asynch -communication is good, but sometimes people just want to bash comments -back and forth. For that, you need push, which is just a web fetch -meaning "pull my rss feed". - -If, however, you have a lot of friends and they have a lot of friends, -your extended network can be large, resulting in many "pull my rss -feed" commands. We should only process push requests for friends to -reduce load. You really don't need real time updates of the social -networking activity of strangers. Friends of friends is as far out as -things should ever go. diff --git a/doc/roadmap.mdwn b/doc/roadmap.mdwn deleted file mode 100644 index 7099711..0000000 --- a/doc/roadmap.mdwn +++ /dev/null @@ -1,65 +0,0 @@ -# Plinth Roadmap - -## 0.1 Basic Wireless Access Point - -* Basic/Expert mode toggle -* SSH access -* Connect to WAN via DHCP and static IP -* Offer DHCP on wired and wireless interfaces -* WEP -* WPA2 -* Bridge WAN and LAN - -## 0.2 Basic Wireless Router - -* NAT -* DMZ -* Port forwarding and triggering -* dhcp server (on by default, expert can disable) -* dns server -* MAC address filtering -* NTP client - -## 0.3 Advanced Wireless Router - -* dynamic dns - This is special. See the notes in the section on - [dynamic DNS](#dynamic-dns) for details. -* UPnP -* Cron -* Tx power management - -## 0.4 File Server, More Routing Features - -* boxbackupd -* NFS -* Samba -* Auto mount usb volumes and create samba shares for them -* TOR -* Ad blocking web proxy -* HTTPS everywhere (on by default, experts can disable) - -## 0.5 Print Server and Backups - -* Social backup to friend's boxes via ddns and boxbackup -* printer discovery and sharing via samba and cups - -## 1.0 Plinth Lives! - -* Complete user documentation for every basic and expert menu item -* Package management complete - -## Unscheduled Features - -There are a variety of other features to be implemented, but they are -of lower priority than all the tasks scheduled above. - -* NTP Server -* Provide virtual networks and multiple SSIDs -* Radius Server -* QoS -* file explorer -* Mesh networking -* Chaining boxes so the furthest upstream knows to route messages down - the chain (e.g. if you and your roommate both have your own box, you - just plug one into the other). -* Bit Torrent / onion router integration -- cgit v1.2.3