I'll be going to defcon for the first time this year and as soon as I had booked my tickets I started to think about what kinds of things I'll bring with me and how I'll stay in touch with the world in a hostile network environment. It didn't take long before I realized that I probably won't want to carry my laptop around and turning off my cell for a weekend might be a nice break from things.

That being said, this scenario where the goal is to communicate securely in a completely untrusted and malicious network has become a bit of a thought experiment for me. The objectives are as follows.

Separate my communications from my identity. I tend to be fairly open about who I am on the internet, and it's not very difficult to figure out who I am given you can find my account name on nearly any website and are capable of using google. In a hostile environment, this is unacceptable behavior. The perceived importance of any communications will likely be much higher if the sender and recipient can be identified.

Encrypt everything. With open source encryption tools and methodologies so readily accessible these days, there's little reason not to encrypt as much data as possible in a hostile environment. A variety of different protocols and suites should be used in order to guard against the possibility of any of them being compromised.

Assume all of your security measures are worthless. Nothing is perfect, especially when humans are involved. Assuming all technical means of security have been compromised. Is your data still intact? Recoverable? On the other hand, you may want the ability to make it all disappear at a moment's notice...

With those goals in mind, let the games begin! Now, if I were a real criminal, it would presumably be much easier for me to separate myself from my identity by fabricating a new one. Even just a few key falsified documents can go a long way toward establishing a dead end for anybody that comes looking for you. Alas, I am not a criminal and would prefer not to face prison time. For this reason, I'm going to establish enough of a roadblock for the casual stalker, but it's probably not enough to stop a government agency with enough probable cause to get subpoenas and warrants issued in a timely fashion.

I keep a couple of these gift cards purchased from credit card companies around just for such occasions. The one I chose to use for this experiment was actually given to me as a gift by a family member, who used cash to purchase it. The remaining value on the card was just over $14. As these gift cards are meant to be transferable, they're generally not imprinted with a specific person's name but instead carry a name like Gift Recipient. Depending on the issuer of the card and when it was purchased, there may be certain limitations to making online purchases. I've heard that more recent cards actually require a social security number to be activated. Figuring out how well those numbers are validated is an exercise left to the reader. In my case, no personally identifying information was needed to activate the card. After a few failed attempts to charge small transactions, I found that I needed to login to the credit card company's website using nothing more than the numbers on the card (skimmers anyone?) and provide some basic contact information (Name, Address, Phone Number) so that the credit processor could verify the owner of the card. The credit card company's website did absolutely no validation of this information so false (yet believable looking) values were used.

The next portion of my plan involves email access. Specifically, how can I continue to read email without compromising my existing account or changing my address? There are options like HushMail that provide "anonymous" email services, but over the last few years, such services have proven less resistant to legal action. I ended up creating a few hushmail accounts anyway, just so that I could deal with activation emails and the like.

If I cannot trust a third-party, and I don't trust the security measures of my existing mail service, then the only remaining option is to run my own mail server. Rather than just pointing the MX record for my domain at a new, anonymous server, I decided to register a new domain name and forward my mail to it from my existing account. This setup allows me to continue reading email without transmitting my real account's credentials across the network. Sending mail gets a bit trickier when the recipient's domain checks reverse DNS entries and SPF records.

Right, so I'm going to need a domain name and a server. As I only had $14 on my anonymous credit card, cheaper is better. Currently several registrars are offering the first year of a .info domain between $1 and $2. I only plan to use this domain for a weekend, so just letting the registration lapse after a year is not an issue. Using the gift card along with the same information provided to the credit card company and a hushmail address, I was able to register a new domain using the registrar's DNS servers, leaving one less thing to worry about anonymizing.

Getting an anonymous server is somewhat tricky. Most sysadmins aren't going to be very receptive to the idea of letting you plug a box in without knowing who you are first. If you're lucky enough to have access to cheap, clandestine, rack space then you're already far better off than most of us and can probably stop reading here. Otherwise, you'll have to make due. I ended up using Amazon EC2 to boot up a virtual machine. Yes, there are inherent assumptions made about security here, not the least of which being that I am putting absolute trust in Amazon to not go poking around on my VM or in my data while I'm not looking. My thoughts are that there are probably thousands of nearly identical VMs in the same cluster that Amazon's engineers need to worry about and as long as you don't do anyting to draw attention to yourself, there's little reason for anybody to go messing around with your data.

For the record, the domain registration cost $1.20 and the cheapest EC2 instance is $0.10 an hour. As I'll only be running the instance over the three days I'm at defcon, the total cost of keeping it online is $7.20, plus whatever storage and bandwidth charges I incur (minimal). So, with an EC2 instance running, the registrar's DNS records updated to point to the instance's IP, I'm ready to get to work hardening the VM. Most of Amazon's AMI images have SSH password authentication disabled by default, it's worth double-checking now. While you're there, it might be useful to enable ChallengeResponseAuthentication (I'll get to this in a minute) and set UseDNS to no as we don't really care about reverse lookups. We already know the client is on an untrusted network, best not to provoke it with requests for PTR records that could possibly contain malicious responses. Basic security practices should also be used here... Create a separate user to login as, without root privileges of any type. Setup iptables rules to only allow SSH traffic (or whatever else you might need) even though Amazon's security zones provide similar firewalling, it can't hurt to do the same thing on the host, just in case there's a configuration mistake somewhere else.

I also like to wipe out the motd as there have been demonstrated known plaintext attacks against SSH sessions and the default motd is a big chunk of predictable known plaintext at the beginning of every session. Now let's go back to the ChallengeResponseAuthentication bit. Ever since World War II (possibly earlier, I'm not an expert of crypto history) the idea of perfect secrecy via One Time Pads has circulated. The concept is simple: encode the plaintext using a key that is at least as long the plaintext and never use the same key twice. The pad is just a list of completely random numbers to be applied to the plaintext. Both parties are issues a copy of the pad and cross off a key once it has been used to send or receive a message.

There are some difficult problems to solve with OTPs... The most obvious being that you have to distribute the pads to both parties securely. In an ideal world, this is a physical transaction between two humans who have picked numbers completely at random. Unfortunately, we don't have physical access to the EC2 instance, so we'll just have to make the assumption that we're using a trusted network when initializing the pad. Furthermore, because one of the parties is a computer and cannot generate truly random numbers and the other is a human that is generally too lazy to sit around spitting out random numbers all day, we end up settling for a pseudo-random sequence generated by the computer, possibly seeded by a "real" random number provided by a human.

There are a few implementations of OTPs for login authentication. S/Key seems to be one of the more long-lived implementations, but it unfortunately requires patching sshd on Linux systems. If your server is a BSD machine, then this functionality is builtin and you just need to turn it on. On Linux, there is a PAM module that links the OPIE library to accomplish the same effect. Using a PAM module also has the advantage of adding OTPs not just to SSH logins, but all PAM enabled logins on the system (eg. sudo, apache, some vpn implementations). In addition to the PAM module configuration, you will also need a "client" program that can use the OPIE request along with your passphrase to generate a valid response to send to the server. If you're using the S/Key implementation, then the use of a client program is entirely optional as you can just ask the server to print out an ordered list of keys that are valid for authentication. You can then write these down, print them on the back of a business card, laminate it, laser etch them, or whatever you like as long as you remember to cross off each key after you use it.

As you may have noticed, the OTP keys are nowhere near as long as the number of bits transferred in your average SSH session. We still allow the SSH protocol to handle a lot of the heavy lifting to verify the server's fingerprint (you didn't just type yes, right?) and generate session keys. The advantages to using OTP over SSH are questionable, especially because if an attacker has found a way to sniff your password, they're probably going to see your entire session anyway. All this does is stop the attacker from replaying the same password to login as you. But, there is a certain geeky cool factor about keeping a list of secret one-time-use codes in your pocket that you have to key in... Makes it feel like you're not just checking your email, but instead you're arming a nuclear weapon.

With all of this hardening out of the way, now might be a good time to save your work. Amazon provides some tools for re-packaging the live system as an AMI image and saving it back to their storage service, S3. You'll end up spending a few pennies a month to store a reasonable sized image, especially if you delete it when you get home from defcon.

Finally, we get to the email part. This is actually pretty straightforward. Install the MTA and smtpd of your choosing, setup firewall rules to allow inbound emails from your real email account's servers, force TLS on incoming SMTP connections if your real account's servers support it, and add some forwarding rules to your real account.

In addition to email, you can also run things like IRC clients and VPN daemons on your semi-anonymous VM. In some situations, it's also useful to run a service like nstx that allows you to tunnel IP packets over DNS to get around some captive portals on wifi hotspots at airports. Read the openssh client manpage... There are a whole bunch of tricks for forwarding ports over the SSH connection, it can even run a local SOCKS proxy that you can point your browser at. If you're using firefox, make sure to also tunnel DNS requests through the SOCKS tunnel.

This post is getting to be a bit on the long side, but I feel that it's also worth mentioning that I'm planning to purchase a prepaid cell phone with hopes of getting some sort of tethering going. Based on some of the defcon videos from last year, it might be possible to get a reasonable price on data with a Verizon prepaid phone, although I've yet to try it. Don't assume GSM, GPRS, EDGE, or whatever else is secure either... Anybody with a USRP board could be recording everything for bruteforcing on some crazy FPGA grid. Such things are not unheard of at these conferences.

I realize that most of these measures are probably unnecessary or overkill, but I also think that it's worth taking some time to examine all possible attack vectors, even the unlikely ones because those are the first places you'll start to get hit after you've fixed all the likely ones.