In this document we present a specification of a Privacy Enhancing LiveDistro as well as an actual implementation of it called Incognito.
The Privacy Enhancing LiveDistro (or PELD for short) aims at providing a software solution presenting the user with the technological means for using popular Internet technologies while maintaining the privacy of the user, in particular with respect to anonymity. While there are different techniques and services providing that functionality, this specification will assume the usage of The Tor™ Project's state-of-the-art anonymizing overlay network Tor.
The PELD is supposed to be self-contained and portable (literally, not necessarily with respect to code portability), and thus possible to run in as many computing environments as possible fot the same single distribution. In addition, while the PELD's main objective indeed is to act as a traditional LiveDistro (i.e. a LiveCD or LiveUSB) it should also be compatible with popular virtual machine technologies for users that simply want a sandboxed environment within their normal operating system.
The PELD's target user is the average user in terms of computer literacy, and who is using a computer of which he or she not necessarily have full control of. Examples would be a public computer in a library, coffee shop, university or a residence. The target user is assumed to not want to do any of the configurations (at least with respect to security and anonymity) of the various applications and tools used themselves, either because of insufficient knowledge, lack of interest or other reasons. The PELD should provide strong anonymity with no need of advanced configuration whatsoever. It should be made as difficult as possible for the user to unknowingly compromise anonymity.
In short, the PELD aims at providing privacy on the Internet for anyone anywhere.
The goal of staying anonymous and keeping sensitive information protected stands in direct conflict with the gols of several entities "present" on the Internet. The following threat model is meant to describe the intentions and capabilities of such hypothetical attackers:
Information such as user-agent, locale and (especially) IP address can all be used in various degrees to identify the user.
Sensitive data sent through the Tor network will only be untraceable (with respect to Tor's threat model) and thus will be at least as likely to be eavesdropped.
It is assumed that the attacker can observe any traffic that exits the Tor network.
It is conceivable for attackers to mount attacks which bypass the proxy and DNS setup in the applications which could then be used to identify the user, either by injecting data or social engineering.
The attacker might be able to run arbitrary code by exploiting unpatched vulnerabilities present in any of the software packages installed.
The PELD should be distributed in a common format that can easily be used to install the PELD on the selected medium. For instance, if distributed as an ISO 9660 compatible image file it can be burned to a CD with almost any CD recording software available.
This section handles mostly the criteria that the PELD should be portable and able to run in as many environments as possible. It also deals with issues such as virus infections and leaving traces.
The binaries should all be executable on the most common computer hardware architecture(s). As of 2008, the x86 computer architecture seems to be the obvious choice as the vast majority of personal computers in use is compatible with it.
The PELD should be able to boot and run from either CD or a USB drive. While running the PELD in that mode it should be completely independent from the host operating system and all other storage media on the host computer unless the user explicitly tries to access any of them.
In all circumstances, binaries, dynamic libraries and other executable code susceptible to virus infections and similar should always be completely write-protected, even when running from a writeable USB medium. Such files should not even be modifiable temporarily, which could be the case even when running from CD if the filesystem is loaded into memory (e.g. tmpfs).
Configuration files, temporary files, user home directories and similar files that most likely need to be modifiable during operation should only be saved temporarily in memory (e.g. by use of something like tmpfs or unionfs).
It is tempting to utilize the possibility to write back data when running from USB as that could be used to allow user settings to be persistent. If this is considered, this feature should be optional and offer the possibility to use string encryption for the persistent storage.
As an alternative to running the PELD natively from a CD or USB, it should also be possible to run from virtual machines. This is useful in situations where the user might not have the possibility to run the PELD natively, which often can be the case with public computers. Additionally, many users seem to prefer this mode of operation, and that alone is a reason for making sure it works.
The role of the kernel is mainly to provide support for the features required elsewhere in this specification. This includes:
"Good" is a sketchy word in a specification. The general idea is to include as much drivers for relevant hardware as possible, in particular for network cards (wire and wireless), video card and other things necessary for basic operation.
It must be able to separate between traffic some how for the functionality of the transparent proxying mentioned in the network section to work. Similarly, it must be able to identify and drop non TCP traffic destined to the Internet.
With the dangers of exploitable vulnerabilities in any code running, attempts to mitigate these on the kernel level is a good idea. Executable space protection with the NX bit, address space layout randomization and similar techniques are all interesting in this respect. Access control in the form of Mandatory Access Control, Role-Based Access control and so on should also be considered.
In order to prevent accidental leaks of information, proxy bypass attacks on Tor and similar, the access to the Internet should be heavily restricted by a firewall:
Note that the above is not necessary (or desirable) for local network addresses.
The user should be able to do all relevant things with easy to use graphical interfaces. As such it should be presented a solid, user-friendly desktop environment with all the expected features (file managing, change system settings, support applications etc.) after booting.
At minimum, clients for the following Internet activities must be supported:
Support for PGP or S/MIME is highly recommended. Also, beware that the EHLO/HELO sent to the SMTP-server will contain the host's IP address in many email clients
Other recommended client for Internet activities includes:
Note, however, that large scale file-sharing activity in general is frowned upon in the Tor community as it consumes extreme amounts of bandwidth compared to other kinds of services.
Given that these applications will be the user's interface to the Internet, these should be chosen with care and security in mind, and also configured in such a way. In general, as little information as possible should leak about the user, the applications used and the system settings.
Tor should be setup to use its DNS server (DNSPort) and transparent proxy (TransPort, TransListen) so the functionality specified in the network section is covered. Since Tor really is at the core of the PELD only stable releases should be considered. Also, while there are many other interesting configurations to consider in the Tor manual, none of them that impairs anonymity or security should be set.
A GUI Tor controller application such as Vidalia or TorK is highly recommended. However, this requires opening the control port in Tor, and thus some means of authentication will be required (CookieAuthentication preferably) to hinder attacks on the Tor software.
As an addition to the security against exploitable vulnerabilities provided by the kernel, compiling software with stack smashing protection, address space layout randomization and similar compiler security enhancements is recommended. Note that in some circumstances compiler level stuff is necessary for utilizing the kernel security features. Because of this it is recommended to compile essentially all software from sources to take benefit from these security features.
Tools for securely signing, verifying, encrypting and decrypting files and messages should be available. In particular some implementation of OpenPGP should be included as it in practice is the de-facto standard when it comes to these things. GUIs for managing keys and performing the relevant cryptographic tasks should be available. Tools for creating encrypted storage containers are also recommended.
Security is usually hard to get. Therefore steps need to be taken in order to make the user more comfortable with the PELD, and also to educate the user about the specific risks and quirks with respect to anonymity on the Internet.
The user should be able to easily select his of her language of preference. User applications should be localized to fit this preference, as should system settings such as keyboard layout.
The PELD should include an easily read document explaining how to use it and its software securely. The user should be assumed to only have the knowledge of you average computer user, so there will be required some explaining of general security concepts.
The procedure to update the PELD should not be prohibitive to provide timely software updates to address issues related to security or anonymity. A scripted, automatic build procedure is greatly preferred to manually setting up things.
For the sake of transparency the use of open-source software is encouraged. Binary blobs should only be used when no good alternatives exist, which could be the case with certain hardware drivers or driver firmwares.
Similarly, it is recommended that the PELD itself is open-source, and that it is well documented to help security analysis by third-parties.
The Incognito LiveDistro is an implementation the PELD specification above. It is licensed under the GNU GPL version 2.
NOTICE: This distribution is provided as-is with no warranty of fitness for a particular purpose, including total anonymity. Anonymity depends not only on the software but also on the user understanding the risks involved and how to overcome those risks.
See the download section on Incognito's main site for download information. Various development files (portage snapshot and stage3 tarball) as well as the current version of Incognito can be found at http://files1.cjb.net/incognito/.
The sources are stored in a Subversion repository. It can be viewed or checked out at https://tor-svn.freehaven.net/svn/incognito/.
The latest version of this document for the current release can be found here. The development version of this document can be found at Incognito's subversion repository here, although it should be noted that some information which is added dynamically at build will not be present.
The following software is used in Incognito. This list is not complete, but only contains packages deemed as important for whatever reason. The complete list of the packages is included in the distribution at /usr/share/packages.txt but note that this package list currently will contain a few false positives of packages that get uninstalled in order to conserve space.
The base operating system, provides hardware detection, infrastructure. Please note that the Gentoo Foundation does not provide or endorse this software distribution.
Anonymizing overlay network for TCP. Our intention is to always use the latest stable version.
A caching web proxy
Utility for viewing/manipulating the MAC address of network interfaces
Lightweight high-performance web server
really tiny cross-platform proxy servers set
A Type III Anonymous Remailer
Proxy DNS server with permanent caching. Configured to do lookups through Tor.
Free open-source disk encryption software. This is what is used for encrypting the persistent home partition while running on USB. It also has a GUI for general usage.
Firefox Web Browser. In addition, the following extensions are installed for security and usability reasons:
Firefox plugin to control Tor. It also provides protections against several attacks possible due to Firefox's non-HTTP features.
Firefox extension to control what gets sent as the HTTP Referer on a per-site basis.
Advertisement blocker for Firefox
Firefox plugin to quickly switch the locale
Thunderbird Mail Client. In addition, the following extensions are installed for security and usability reasons:
GnuPG encryption binary plugin for thunderbird
Mozilla Thunderbird extension to clean up files
Graphical IRC client
Port of OpenBSD's free SSH release
links is a fast lightweight text and graphic web-browser
OpenVPN is a robust and highly flexible tunneling application compatible with many OSes.. Can operate over TCP or UDP. Due to limitations of the Tor software only TCP is anonymized. UDP is currently blocked.
Qt 4 front-end for Tor
Standard GUI for GnuPG
Qt password manager compatible with its Win32 and Pocket PC versions.
K Desktop Environment, a reduced install with parts that could be useful on an anonymity CD.
KDE: Web browser, file manager, ...
A Tor controller for the KDE desktop
KDE personal information manager
KDE Screenshot Utility
KDE news feed aggregator.
VNC-compatible server to share KDE desktops
A BitTorrent program for KDE.
KDE gpg keyring manager
The GNU Privacy Guard, a GPL pgp replacement
Network discovery and fingerprinting tool
A utility for network exploration or security auditing
802.11b Wireless Packet Sniffer/WEP Cracker
Screen is a full-screen window manager that multiplexes a physical terminal between several processes
Standard Linux telnet client and server
Multipurpose relay (SOcket CAT)
The following locales are installed. If you'd like to see another locale, please let us know.
In this section we briefly present the setup of several key software packages and system settings of Incognito with respect to security and anonymity. There are of course other minor tweaks here and there, but those are mainly for usability issues and similar.
The Tor software is currently configured as a client only. The client listens on SOCKS port 9050 with a control port 9051 (using cookie authentication), as a transparent proxy on port 9040 and as a DNS server on port 8853. Only connections from localhost are accepted. It can be argued that running a server would increase your anonymity for a number for reasons but we still feel that most users probably would not want this due to the added consumption of bandwidth.
Mixminion cannot be configured as a server as these servers need to be very reliable. As a client the default configuration seems to be acceptable. Note that TorK has built-in support for Mixminion with an easy to use interface (lacking PGP support, unfortunately).
DNS leaks are controlled by using a local caching DNS server, pdnsd, that in turn performs its DNS lookups through the Tor network. pdnsd is the server configured in /etc/resolv.conf, listening on localhost. There is a security concern that some application could attempt to do its own DNS resolution without consulting /etc/resolv.conf, and therefore UDP packets are blocked in order to prevent leaks. Another solution may be to use the Linux network filter to forward UDP lookups to the local DNS server.
Polipo provides with caching HTTP proxy functionality. It contacts the Tor software via SOCKS5 to make the real connections.
tsocks (patched for Tor usage as per the ebuild's tordns USE flag) and dante are installed. Note that it is unnecessary with the Linux network filter (see below) and the local DNS server to socksify or torify applications. This is done at a lower level. These libraries are here due to dependencies and configured for completeness.
One serious security issue is that we don't know what software will attempt to contact the network and whether their proxy settings are setup to use the Tor SOCKS proxy or polipo HTTP(s) proxy correctly. This is solved by forwarding all direct TCP connections through Tor's transparent proxy. Linux has a kernel level network filter that accomplishes this.
The macchanger program can be used to change the network card MAC addresses to a random value. Gentoo has direct support for macchanger so all we need to do is configure it. The configuration is set to "random-ending" which is equivalent to "macchanger -e", meaning the vendor and media type are not changed. This is done to not draw attention to the changed MAC address in case someone is watching. Using a random MAC address may improve anonymity with respect to the LAN and prevent mapping the user to a specific physical location.
This functionality is not enabled by default as some DHCP servers may be configured with specific MAC addresses. In the boot menu there is an "Enable/Disable MAC changer" option that can be set before a language is chosen and the system starts booting.
Thunderbird's proxy settings are set up to use Tor. An old version of Torbutton (1.0.4.01, when it still supported Thunderbird) is installed solely for the purpose of scrubbing the real IP address and hostname from the EHLO/HELO messages which otherwise would be sent in the clear to the SMTP server. Furthermore, the first ten or so accounts that a user will create are pre-configured to not use HTML as that otherwise may break PGP usage. See the comments in the Thunderbird config for more settings.
Firefox have preset bookmarks related to anonymity.
XChat is configured to use the Tor software as a SOCKS5 proxy. It will pass the hostname through SOCKS5 so that the exit node does the DNS resolution. In addition all ctcp responses except PING are disabled as they otherwise could disclose useragent, system time and other information.
Pidgin is configured to not log anything and to use the Tor SOCKS proxy. Additionally the Off-the-record Messaging plug-in and two IRC enhancing plugins are loaded automatically. The IRC More plug-in is patched to not report useragent and to use empty part/quit messages to prevent fingerprinting.
When shutting down the system RAM is securely wiped. RAM can actually be read after the machine shuts off with the right equipment. The software doing this is smem, part of the secure-delete package. This process can take a while. If you are booting from a CD it should eject, and if you are booting from a USB drive you can remove the drive once prompted. In either case you can leave the computer and let it finish on its own, or simply turn it off if you are not worried about this attack.
There are two users that are intended to be used for logins, 'incognito' and 'root'. Since this is a CD/USB the passwords are empty. This should not be a security concern because the user will remove the CD/USB when done and there should be no services allowing logins from the network. Suggestions for better solutions are welcome, though.
Incognito may of course be run in virtual machines. Due to the popularity of VMWare we include open-vm-tools (an open-source alternative to VMware tools) as well as special video and input divers for an improved user experience in that environment. Due to the closed-source nature of VMWare we try to encourage users of open VMs, like VirtualBox and QEMU, by making sure that these also work. In the case of VirtualBox both video and input drivers are included.
Security concerns for all VMs are a keyloggers, viruses and other malware in the host OS which a guest OS like Incognito cannot defend against.
QEMU for Microsoft Window ships with Incognito and is used to run the CD/USB in a virtual machine whenever native boot is impossible or not desirable. Note that this will work for Windows 2000/XP or greater only.
The CD may be copied to a USB drive. Why do that? USB drives are easier to carry, harder to break, offer file storage and persistent user settings between sessions. There is a script provided that will copy the CD to a USB drive and make the drive bootable. Note the script depends on the Gentoo LiveCD structure, it probably won't work when run on another LiveCD setup.
The persistent home volume can be stored as a TrueCrypt volume or unencrypted. For the Un*x savvy, the unencrypted volume is stored as an ext3 file on the USB drive. The file home.tc (TrueCrypt) or home.ext3.img (unencrypted) on the USB drive and can be removed to reset to the CD defaults or copied elsewhere for a backup. You will need to do a clean shut-down to make sure your settings are saved. When booting from a writeable medium and there is no home volume you will be prompted to create one, you may choose not to do so and to disable the feature altogether with the possibility to enable it again from within the GUI.
Certain configurations are copied from the USB drive on boot if no persistent drive is mounted. Note that this feature is pretty secret at the moment. A more elaborate and general filesystem overlaying thing is in the works as a replacement.
The following table lists the configuration, where it should exist on the USB drive and where it is copied into.
|Software||USB drive location||Destination|
Hidden HTML content may be served if running from an USB drive. Content is limited to static HTML pages. The content is stored in the home directory and so takes advantage of TrueCrypt encryption. The directory structure follows.
Base directory for hidden content where [name] can be anything (sane) that you'd like.
Configuration directory mostly used for Tor hidden service information. It will include the hostname and private key, keep it safe, i.e. don't copy it over to your buddy's USB drive.
Optional port for the hidden service. This is what you'd give out to others. If you will have multiple services it is best to specify the port. The default is 80, increasing from there for each additional service.
Optional config to append to /etc/tor/torrc after the hidden service description. An example would be a HiddenServiceNodes directive, etc.
The HTML content. Use index.html for your default page.
The lighttpd server is used to serve the content. Configuration of the server is done at boot time in the /etc/init.d/hidden-service init script.
The host name to use for the hidden service can be found in the /home/hidden/[name]/conf/hostname file for that service. This file is created by the Tor software when configuring the hidden service. The host name will be the same across sessions and machines as it and the private key are stored in the /home/hidden/[name]/conf directory.
Changes to /home/hidden (service addition/removal, /home/hidden/[name]/conf change) can be applied using the following command from a terminal. To get a terminal on full, type "Alt-F2", "konsole". On tiny right-click on the desktop and choose "xterm".
su -c /etc/init.d/hidden-service restart
Note that content changes in /home/hidden/[name]/www should take effect immediately without running the above command.
The Gentoo Catalyst release build tool is used to build Incognito. This tool is designed automate the build process of the target distribution, which also make them easy to maintain. Since essentially everything is compiled from sources, building Incognito from scratch takes several hours or even a few days to complete. But this is seldom done or needed and catalyst makes it possible to cache already built packages so they need not be compiled again. Adding or removing software to/from the distribution is also generally trivial but might require altering the ebuild or writing new ones.
For detailed instructions on how to build and modify Incognito, see
hacking.html in the source root.
The following applications are kept up to date as soon as possible. Others may be updated sooner if a major security problem occurs (Firefox, Thunderbird etc.)
Remaining applications, including the base system, will be updated to whatever Portage deems is stable in each new release. It takes a long time to compile everything from scratch and sometimes there are problems that need to be addressed. Most of the packages are marked stable by Gentoo so there are not many problems.
UDP is a problem. The Tor network does not support UDP yet, only TCP. Outgoing UDP packets are dropped altogether by netfilter for this reason.
When using a USB drive your user settings are stored on the drive unsecured. If any personal information is stored by the applications you use then you must keep your drive secure from potential threats, for example by using the optional encryption and a strong passphrase.
(It would be great to have links to peer reviews here.)