Cheix USB

Cheix is named after the Swiss national abbreviation to denote its neutrality in a world of hostile environments.

Current release: beta-22
Updated: 2012-07-29

Current Effort: While Cheix is still fully functional and Slack 13.37 remains available in the depositories, I have long been unable to continue development on this project. I am sorry for this. But tens of thousands of people are using Cheix as it is now in hostile environments. So something has been achieved.
Next step: Booting the image within a running Linux OS.

Downloads | ChangeLog | INSTALL


Cheix USB is a console-based USB image that preserves the USB. It is a tool for those who need reliable email, browsing, and other network apps but who work where the climate, the infrastructure, or the local politics are unfriendly to laptops. Cheix will [eventually] run inside a running Windows or Linux box. In its current beta state, Cheix USB is suitable for a single-user machine install or USB install. It is extremely secure because it records no data to the USB unless you ask it to. By using mailx on a remote email server and /dev/null for the sent box, no email data remains on the installation. The cheix_home and cheix_storage scripts help you maintain a transient file system which is stored remotely. Cheix is secure because it preserves no data unless you tell it to. That said, I need to say what I mean by "secure." Cheix is a response to all the privacy and security Linux Live CD and USB solutions that I have seen. Those distributions contain a lot of encryption and security software. But technology, especially when used by ordinary people, offers more of a false sense of security than an actual secure environment.

First, consider that if you can go download something and install it on your USB, so can other people. There are no secrets in these open software solutions. If you cannot use your own secure encryption keys and cannot control who they are shared with, much of the communication security is negated. You have to be able to generate and protect your own keys. That might mean that they have to be transient and never reside on the system. So if people have enough resources, and most governments do, they can find ways to monitor or intrude into these open systems. Note that all oppressive governments have the backing of either the Russians, the Chinese, the Americans, the Saudis or the Iranians. And those always have the resources. Also, technically speaking, keep in mind that if you watch the releases of some of this "secure" software, you will see how often people find new holes in it which the developers have to patch.

Second, consider that you may be using these CDs or USBs on public machines. Depending on the local political situation, state security forces will be able to monitor the use of those boxes to different degrees. There is no guarantee that rebooting into your own portable system will escape this surveillance. It is not difficult to create a box that runs everything within a running system so that anything running in it is subject to control and surveillance. Some nations are sufficiently advanced to extend some of this surveillance onto private computers once they are on the Internet.

Third, encryption implies decryption. To decrypt your own data you have a key or a password. While it is true that a 128-bit key is very difficult to crack from the outside, it is very easy to crack from the inside. If someone wants your data badly enough, they can take you and your USB. There are many people in this world who will regard you as a bag of meat containing useful information. And they will pursue that information without regard to the well-being of the meat. This is an extreme case and there are lesser pressures that can be brought to bear on humans to extract information almost as effectively. The reality is that if you can get in, there are unpleasant ways for others to get in. Even in the US, encrypted data is not necessarily private. In the February 2012 case of Colorado v. Fricosu, a judge ordered the defendant to reveal the password to her encrypted hard-drive. He did not consider evidence on her laptop any more private than evidence left laying around her house. There is no reason to expect this ruling to be overturned.

The point of all this is that if anyone were to rely on Cheix for security, I want them to know the limits of that security. Nothing is written to the USB unless you write it there. That's it. You can use gnupgp email encryption or the encrypted volumes software. Any other Slackware packages can be added. But you should judge the limitations of these things intelligently in your particular environment. You must realize that THE ONLY REAL SECURITY IS HUMAN SECURITY. This actual security is only possible through intelligent planning and discipline. If you rely on technology for security, it will let you down. And if you do not handle the human security correctly, the technology will compromise you at the speed of light.

Let's suppose I were in a politically hostile environment. I would keep my email messages innocuous even if they were very much not innocuous. All email would be on the remote IMAP server in a neutral country and be regularly, if not immediately, deleted and no sent mail would stay on the USB. I would keep all my passwords in my head and never write one down or save one in a file. I would keep my ftp servers in a nation that valued human rights and privacy. (Mmm, that would take some thought...) And I say ftp "servers," because I would change them on a regular basis. I would try to have a reliable way to know if those remote servers had been compromised. I would have one more local ftp server for plain harmless files that I could keep on Cheix. I could keep that password in ncftp and leave the cheix_* scripts as-is. I would save only harmless normal human-readable files to Cheix -- never anything that would compromise my situation. In this way, Cheix would give me a plausible deniability if the USB were taken from me and exposed to hostile elements. I believe that this would amount to a decent amount of security in a seriously hostile environment. But don't take my word for it. Real security is YOUR RESPONSIBILITY.

UPDATE 2017. If you set up your own ftp servers somewhere trustworthy, ftp remains reliable. But if you use ftp on cloud servers, upload is now problematic. The cloud is simply a great number of servers working together. To the clients (you), they appear as one server. To the sysadmin, they appear as a giant hairball. The problem with ftp, without going into intolerably boring detail, is that files between 1.5kb and roughly 10kb get hung up in the processes of the cloud and do not upload. You will know this is happening if your file is completely uploaded and the remote server hangs, dropping down to nothing on the speed indicator in ncftp. The SOLUTION is to install lftp which can use SFTP. Go to the Slackware 13.37 depository, download and install lftp (and any of its dependencies). You can then change "ncftp" to "lftp" in the scripts in user/local/bin. I would do this for you but, as indicated at the top of the page, I am unable to do so. My apologies. END UPDATE

Current Status

  • Standard Slackware 13.37 installation
  • ISO image ready for installation and bzipped tarball for hand installation
  • Entire module tree (non-smp) with generic kernel and initrd
  • All mods, pkgs, and firmware for ethernet and wireless
  • Media: Normal hard-drive or bootable USB installation (approx. 225 Mb)
  • System: readonly root fs with all writes in tmpfs, rw /storage partition for user
  • Memory: no longer using swap, actively freeing memory with freememd
  • Apps: screen, vi (nvi), lynx, ncftp, nano, slackpkg, mailx, openssh, boypages, clex
  • Scripts: cheix_admin, cheix_home, cheix_storage, cheix_secure
  • Documentation: /usr/local/docs (hooked into lynx bookmarks)
  • User Space: /home/user in tmpfs, loaded from /storage/skel, rw access to /storage

Remaining Milestones

  1. boot USB inside running Linux
  2. add USB/Linux install to installer CD
  3. boot USB inside running Win32
  4. final installer CD with USB/Linux/Win32


My thanks to the following for their advice and assistance.
(All deficiencies in the project are mine, not theirs.)

  • Chris (k_at_guciek_dot_net) for excellent ro-fs advice.
  • Se'b (sbb_at_tuxfamily_dot_org) whose tool contribs continue to be useful.
  • prfaasse on for the "Re: Zen Walk on thumb drive" forum post.

Contact info is here