TinHat is a Linux distribution derived from hardened Gentoo which aims to provide a very secure, stable and fast Desktop environment that lives purely in RAM. TinHat boots from CD, or optionally a pen drive, but it is not a LiveCD. It does not mount any file system from CD via unionfs or otherwise. Rather, TinHat is a massive image (approx. 2.3GB) which loads into tmpfs upon booting. One pays the prices of long boot times (5 minutes off CD, 2 minutes off pen drives), but the advantage afterwords is that there are no delays going back to the CD when starting applications. Needless to say, this has some rather extreme advantages and disadvantages, making TinHat a rather particular distribution.
TinHat was conceived as a challenge to the old mantra that physical access to a system means full access to the data. This is certainly true in the case of unencrypted file systems, and at least potentially true in the case of encrypted. Rather, TinHat aims towards the ideal of guaranteeing zero information loss should the attacker physically acquire the box --- either the adversary is faced with no file system to even begin cracking, or if any non-ephemeral memory is found, the adversary should not be able to tell if he is looking at encrypted data or random noise. Of course, achieving this ideal is impossible, or at least highly improbable, but it is nonetheless something one can strive towards. TinHat is a baby step in that direction.
Even before sitting down and thinking of the technologies one could use for such a project, other considerations pop up. Obviously if the user is able to get to the data, then in principle so can others. These issues impinge on the user's social situations: What happens if the user walks away from a running system where he is logged in? A classic problem. What happens if he is coerced into letting the adversary in while the system is up? If the user is uneasy keeping his personal files in RAM, he may want to back them up to encrypted drives. Then the window of a "coercive attack" extends beyond the uptime of the system. What if the user is watched via a secret surveillance camera? What about a hardware keylogger? Or a microphone listening to the unique sounds of keystrokes on a keyboard? How deep does the rabbit hole of paranoia go?
Let's set aside the social engineering attacks for now and focus on the major technological obstacles. Recent advances in cold boot attacks, where data in RAM (such as encryption keys) can be retrieved even after a system reboot, have put our goal even further beyond reach Utilities like msramdmp can be used to dump the entire tmpfs root file system of TinHat for forensic analysis. The situation seems bleak, but this just gives us opportunity for more clever ways of encrypting/hiding data in RAM itself --- at least until hardware solutions come along. This is clearly the direction in which we would like to develop TinHat, but must admit that we are stumped. No matter how many layers of encrypts we add, we cannot avoid keeping clear key somewhere in RAM.
Of course, the ideal that "physical access == zero information loss" would be useless if TinHat didn't also protect against the more familiar network/code born exploits. For this we employ GRSEC/PaX technology which is a reliable security solution already integraged into major Linux distribution by the Hardened Gentoo Project. Since TinHat provides an option between Gnome, XFCE4, or FluxBox desktop environments running on top of X, some compromises in security had to be made; however, these are noted so that the user is aware of their existence. Little can be done on generic hardware; however, we have found that on specific motherboard/video chipset combinations, hardening features which would otherwise break X can be enabled. For this reason, we not only provide polished ISO images for immediate use, but also our "cookers," VMware virtual machines which we use to make the ISOs.
Finally, TinHat has a secondary goal. Since we are running purely in RAM, TinHat is fast! If "Zero Information" is one subtitle that we can append, another would be "a Glorious Waste Of RAM". TinHat requires about 5 GB to run comfortably, 4 GB for the tmpfs root file system, and 1 GB for paging. If one wants to further reintroduce Gentoo's portage system and/or the kernel source tree, 5GB becomes a very tight squeeze. Forget adding any more software after that, which leads to the paridoxical sitatution: why else would you reintroduce portage/kernel trees if you don't plan to add any new software? Although we provide an i686 release, in our lab we run the amd64 version on 8 GB boxes in which we reintroduce portage/kernel and add the entire Open Office suite. One gets spoiled when your word processor pops up in mere seconds!
We distribute TinHat as pre-built ISO images which can be used as is or can be used to "cook" new customized ISOs --- the older technique of using VMware has been deprecated. The ISOs can be burned to CD, or with our scripts, can be put onto a pen drive. However, nowadays we recommend using UNetbootin to install the ISO image to the pen drive.