Generating an OpenSSL Certificate
OFTC runs a forked version of hyperion-ircd that they call oftc-hybrid. It’s a patched version of hyperion that Freenode was running on their servers before the switch to ircd-seven. It supports IPV6, SSL, and CertFP with NickServ, that I’ll cover later in this post.

Before connecting to OFTC, we want to generate an OpenSSL certificate. This certificate will be used for authenticating to NickServ, and really isn’t related to setting up an SSL connection to OFTC. However, when you connect, you will be presenting OFTC with the generated certificate, and at that point, you will be able to add it to NickServ, because it’s been presented. If you already have your own personal certificate you want to use, then you can skip this step, and move on to connecting with SSL.

I’m going to assume you have OpenSSL installed. If you’re running any modern Unix-like operating system, such as GNU/Linux or one of the BSDs, chances are very high that it’s been installed by default. If not, install it, and continue with the rest of the post.

In this step, we’re going to generate our own self-signed personal OpenSSL certificate. So, fire up a terminal, type in the command below, and follow the on-screen instructions. The values you put here do not matter to OFTC in the least, so fill them in any way you wish. In my case, I’ll fill in the data for my personal certificate, but you fill in the values as you see fit. Replace “nick.key” and “nick.crt” with your IRC nick that you use for this connection.

cd ~/.irssi
mkdir certs
cd certs
openssl req -nodes -newkey rsa:2048 -keyout nick.key -x509 -days 365 -out nick.crt
Generating a 2048 bit RSA private key
writing new private key to 'nick.key'
-----
Country Name (2 letter code) [US]:US
State or Province Name (full name) [Texas]:Utah
Locality Name (eg, city) [San Antonio]:Ogden
Organization Name (eg, company) [Stealth3]:eightyeight
Organizational Unit Name (eg, section) [ISP]:OFTC
Common Name (eg, YOUR name) []:Aaron Toponce
Email Address []:aaron.toponce@gmail.com

Now, if you look, you’ll have two newly generated files: “nick.key”, which is your private key and “nick.crt” which is your public self-signed certificate. Because “nick.key” is your private key, you want to guard it appropriately. Its permissions should be modified to only be readable (and maybe even writable) by you, and you alone. Also, because we have both the private and public key set, let’s go ahead and combine the files into one PEM file that we’ll present to NickServ when connecting:

cat nick.crt nick.key > nick.pem
chmod 0400 nick.key nick.pem

Connecting with SSL
At this point, we are ready to connect to OFTC, and present our certificate to the server. So, fire up Irssi if you haven’t already:

irssi -!

Now that we’re in Irssi, we want to setup our SSL connections to OFTC. You should have ~/.irssi/certs/nick.pem available to send.

We will need to retrieve the CA certificate for verifying the server certificate. I personally like to put all my CA certificates in my certificates store, and this is where I deviate a little from the tutorial on the OFTC site. OFTC has their certificate signed by Software in the Public Interest, so we’ll need their CA certificate. Fortunately, Debian, Ubuntu, and many other GNU/Linux operating systems provide this certificate for us, so we just need to identify the location of the certificate, and plug that into Irssi. If you don’t have that certificate, refer to the tutorial on the OFTC site for obtaining it and installing it on your system.

So, with Irssi waiting for our command, let’s tell it out to connect to OFTC:

/network add oftc
/server add -auto -ssl -ssl_cert ~/.irssi/certs/nick.pem -ssl_verify -ssl_cafile /etc/ssl/certs/spi-cacert-2008.pem -network oftc irc.oftc.net 6697
/save
/connect oftc

When we successfully connect, we should see that OFTC has accepted our self-signed certificate in the MOTD, and it should also show that we are connected securely to the network with SSL:

16:20 [oftc] Irssi: Looking up irc.oftc.net
16:20 [oftc] Irssi: Connecting to irc.oftc.net [64.62.190.36] port 6697
16:20 [oftc] Irssi: Connection to irc.oftc.net established
16:20 [oftc] [charm.oftc.net]: *** Looking up your hostname...
16:20 [oftc] [charm.oftc.net]: *** Checking Ident
16:20 [oftc] [charm.oftc.net]: *** Found your hostname
16:20 [oftc] [charm.oftc.net]: *** No Ident response
16:20 [oftc] [charm.oftc.net]: *** Connected securely via TLSv1 AES256-SHA-256
16:20 [oftc] [charm.oftc.net]: *** Your client certificate fingerprint is 4A5463CE416649F72818B22945681D28250C1ACA
16:20 [oftc] >>> Welcome to the OFTC Internet Relay Chat Network eightyeight

Sweet! We’re connected securely, and OFTC accepted my client certificate by printing the fingerprint for me. If the fingerprint is not displayed, then OFTC has not accepted my certificate, and I need to review the steps outlined above, or on their site.

Authenticating to NickServ with SSL
From here on out, our connection is secured, and we can enjoy the safety that is encrypted packets. So, at this point, we need to register our nick with NickServ, if we haven’t already. It should be pointed out that Services has a complete help document provided. Messaging “help” to any of the Services bots will give you a break down of the available commands and their syntax. I would highly recommend becoming familiar with how to use the provided documentation.

/msg NickServ help
04:22 [notice(NickServ!services@services.oftc.net)] *** NickServ Help ***
04:22 [notice(NickServ!services@services.oftc.net)] ACCESS: Maintains the nickname ACCESS list.
04:22 [notice(NickServ!services@services.oftc.net)] CERT: Maintains the nickname client certificate list.
04:22 [notice(NickServ!services@services.oftc.net)] DROP: Releases your nickname for use.
04:22 [notice(NickServ!services@services.oftc.net)] ENSLAVE: Enslave a nickname to this master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] HELP: Shows this help.
04:22 [notice(NickServ!services@services.oftc.net)] IDENTIFY: Identify your nickname.
04:22 [notice(NickServ!services@services.oftc.net)] INFO: Get information on a nickname.
04:22 [notice(NickServ!services@services.oftc.net)] LINK: Link this nickname to a master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] LIST: Shows a list of nicknames matching a specified pattern.
04:22 [notice(NickServ!services@services.oftc.net)] RECLAIM: Release your nickname for you to use.
04:22 [notice(NickServ!services@services.oftc.net)] REGAIN: Release your nickname for you to use.
04:22 [notice(NickServ!services@services.oftc.net)] REGISTER: Registers a nickname for your usage.
04:22 [notice(NickServ!services@services.oftc.net)] SENDPASS: Send a password reset request.
04:22 [notice(NickServ!services@services.oftc.net)] SET: Set nickname properties.
04:22 [notice(NickServ!services@services.oftc.net)] STATUS: Shows the identified status of a nickname
04:22 [notice(NickServ!services@services.oftc.net)] UNLINK: Unlink this nickname from a master nickname.
04:22 [notice(NickServ!services@services.oftc.net)] *** End of NickServ Help ***

In this case, we’re interested in registering and then identifying. The syntax for registering is providing your password and email as arguments. Providing the correct email is key, so should you lose your password and you can no longer authenticate with SSL, you can have NickServ email you your password. So, I would recommend putting in a valid email here, and not some throw away string:

/msg nickserv register password username@example.com
/msg nickserv identify password

At this point, our nick is registered and we are identified to NickServ. If the nick you’re wishing to register is already registered, then you’ll either need to pick a different nick, or join #oftc on the network, and see if staff can assign that nick to you. At any event, you must be identified with a valid nick before you can proceed with the next steps.

Now that we are identified to NickServ, we need to add our hostmask to the access list. This is beneficial, so we won’t be asked to identify when we connect, which is what we want. So, we need to find our hostmask. This is simple enough by running a /WHOIS on yourself, and identifying your host string. So, it might be something like this:

/WHOIS eightyeight
04:29 [oftc]      nick  | eightyeight
04:29 [oftc]      host  | ~88@c-12-130-240-233.hsd1.mn.comcast.net
04:29 [oftc]     gecos  | eightyeight
04:29 [oftc]    server  | charm.oftc.net [Freemont, CA, USA]
04:29 [oftc]      info  | user has identified to services
04:29 [oftc]  hostname  | 12.130.240.233
04:29 [oftc]      info  | is connected via SSL (secure link)
04:29 [oftc]      idle  | 0d 0h 1m 48s [signon: Sat Jan 30 16:20:12 2010]

In this case, my host is “~88@c-12-130-240-233.hsd1.mn.comcast.net”. This is what I want to provide to NickServ:

/msg nickserv access add *@c-12-130-240-233.hsd1.mn.comcast.net

Good. Now we’re ready to add our self-signed certificate. Remember, when you connected, in the beginning of the MOTD, your certificate fingerprint was displayed. You will want to copy this output and paste it here. You can also use the “openssl” command to get the fingerprint of your cert, you will just need to remove the colons out of the string when providing it to NickServ. In my case, my fingerprint was 4A5463CE416649F72818B22945681D28250C1ACA, so I’m going to add that. Change the string for your fingerprint:

/msg nickserv cert add 4A5463CE416649F72818B22945681D28250C1ACA

That’s it! At this point, if you were to connect again (you must /disconnect and then /connect. /reconnect doesn’t apply the SSL settings, apparently (BUG?)), you will find that you will automatically identify to NickServ with your cert, and without a password. As you can imagine, this is highly secure. If you are not taking advantage of SSL, then your password can be sniffed on the wire, and your account could be compromised. In this case, we’re neglecting the password, and using public key cryptography instead to authenticate. I don’t know at this point if a MITM attack would be successful. So, bonus.

To see that it has succeeded, when you connect you should see the following at the end of the MOTD:

05:14 [oftc2] >>> You have set user mode +i
05:14 [oftc2] >>> You have set user mode +R
05:14 [oftc2] [notice(NickServ!services@services.oftc.net)] You are connected using SSL and have provided a matching client certificate
05:14 [oftc2] [notice(NickServ!services@services.oftc.net)] for nickname eightyeight. You have been automatically identified.

Wrap-up
Congratulations! You are now connected securely to OFTC via SSL and you have identified to NickServ successfully with your self-signed certificate. The major benefits of this method, is you can ditch any client-side identification scripts, which is always a bonus. Further, your packets are now encrypted between you and the OFTC servers. OFTC also utilizes server-to-server encryption, so if you’re physically connected to a server in the United States, and someone you’re in private message with is physically connected to a server in Europe, not a single plaintext packet is sent on the wire between your client and his (assuming he’s connected via SSL as well).

A final not on SSL connections, is your computer clock that you are running Irssi on needs to be accurate. It would be recommended to use NTP to keep your clock in sync with Internet time servers. If your clock is too far off, you won’t be able to negotiate the OpenSSL handshake, and as a result, not be able to take advantage of the encrypted traffic. Also, OpenSSL certificates need to be valid. If your certificate expires, then you will not be able to present it to the server, and as a result, not be able to authenticate to NickServ. The dates on expiration are up to you, but validity is important. You can see the dates of your certificate with the following command:

openssl x509 -noout -in nick.pem -dates

Enjoy the security.

Connecting with SSL
Freenode is listening for SSL connections on ports 7000 and 7070, rather than the standard 6697. I don’t know what the logic here is for that, but does it matter? A port is a port is a port. So, for Irssi, setting this up is rather simple.

/server add -auto -ssl -network freenode irc.freenode.net 7000

Boom! Done.

Now, if you want to verify the Freenode server SSL certificate against a certificate authority (CA), then you’ll need to download the CA certificate from the authority that signed the server certificate. In this case, its Gandi.net, and their CA certificate file can be found here: http://crt.gandi.net/GandiStandardSSLCA.crt. However, using the file in its native DER format for Irssi wasn’t working for me. So, using openssl, I converted the binary DER data file to PEM format, at which the Freenode certificate would properly verify:

/server add -auto -ssl -ssl_cacert /etc/ssl/certs/GandiStandardSSLCA.pem -network freenode irc.freenode.net 7000

[freenode] Irssi: Connecting to irc.freenode.net [140.211.166.4] port 7070
Irssi: warning Could not verify SSL servers certificate:
Irssi: warning   Subject : /OU=Domain Control Validated/OU=Gandi Standard Wildcard SSL/CN=*.freenode.net
Irssi: warning   Issuer  : /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
Irssi: warning   MD5 Fingerprint : F8:40:2C:D9:D6:46:1F:D0:38:5D:ED:21:69:8B:17:C4

2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: unable to get issuer certificate
the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.

/server add -auto -ssl -ssl_verify -ssl_capath /etc/ssl/certs -network freenode irc.freenode.net 7000

cd ~/.irssi/scripts/
wget http://freenode.net/sasl/cap_sasl.pl
cd autorun
ln -s ../cap_sasl.pl cap_sasl.pl

/RUN cap_sasl.pl
/sasl set freenode primary-nick password DH-BLOWFISH
/sasl save
/save

aptitude install libcrypt-blowfish-perl libcrypt-dh-perl libcrypt-openssl-bignum-perl

16:05 [freenode] Irssi: Looking up irc.freenode.net
16:05 [freenode] Irssi: Connecting to irc.freenode.net [140.211.166.4] port 7000
16:05 [freenode] Irssi: Connection to irc.freenode.net established
16:05 [freenode] [niven.freenode.net]: *** Looking up your hostname...
16:05 [freenode] [niven.freenode.net]: *** Checking Ident
16:05 [freenode] [niven.freenode.net]: *** Found your hostname
16:05 [freenode] [niven.freenode.net]: *** No Ident response
16:05 [freenode] Irssi: CLICAP: supported by server: identify-msg multi-prefix sasl
16:05 [freenode] Irssi: CLICAP: requesting: multi-prefix sasl
16:05 [freenode] Irssi: CLICAP: now enabled: multi-prefix sasl
16:05 [freenode] >>> eightyeight!88@oalug/member/pdpc.supporter.monthlybronze.eightyeight atoponce You are now logged in as atoponce.
16:05 [freenode] Irssi: SASL authentication successful
16:05 [freenode] >>> Welcome to the freenode Internet Relay Chat Network eightyeight

16:05 [freenode] >>> CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLMPQScgimnprstz CHANLIMIT=#:120 PREFIX=(ov)@+ MAXLIST=bqeI:100 MODES=4 NETWORK=freenode KNOCK STATUSMSG=@+ CALLERID=g are supported by this server
16:05 [freenode] >>> SAFELIST ELIST=U CASEMAPPING=rfc1459 CHARSET=ascii NICKLEN=16 CHANNELLEN=50 TOPICLEN=390 ETRACE CPRIVMSG CNOTICE DEAF=D MONITOR=100 are supported by this server
16:05 [freenode] >>> FNC TARGMAX=NAMES:1,LIST:1,KICK:1,WHOIS:1,PRIVMSG:4,NOTICE:4,ACCEPT:,MONITOR: EXTBAN=$,arx WHOX CLIENTVER=3.0 are supported by this server

First, a disclaimer. This post is not meant to be a sure method for defeating attackers. Rule number one in computer security is that if an attacker has physical access to your machine, all bets as to data integrity and physical safety are off. However, than doesn’t mean that you can make the process so tedious and time consuming for the attacker, that he will likely not bother and move to another victim. This post is about those methods. If they’re going to attack you, why not at least make it challenging for them?

If you have the ability, this post requires wiping your disk by starting from scratch. So, if you have data on that disk, you should probably back that up first. If it’s a new laptop, and you’re not invested into the operating system, then maybe you don’t need to worry about it. Just realize, that from this point on, if you decide to “follow along” with your own equipment, this will wipe your data, and if you didn’t back up your data first, you’re the moron, not me.

Okay, with that out of the way, shall we continue?

Step One: Prepare your hard drive.
The goal of this step is to install an encrypted filesystem. So, before we do that, we need to do some preparation. In order to get to that point, you will need to write random or pseudorandom data to the entire disk. This will take some time. My experience has show that laptop drives usually operate around 30MBps, so if you have a 300GB drive, this will take you just under 3 hours. The reason for doing this is to confuse the attacker just exactly where the encrypted filesystems reside. If the entire disk is underlined with random or pseudorandom data (it doesn’t necessarily need to be cryptographically secure here), then when looking at the drive level, it will be practically improbable to determine where the encrypted filesystem starts and where it ends. If you skip this step, then it’s quite obvious, and rather than wast his time on the entire disk, the attacker can focus his efforts on just the obvious encrypted portions of the disk.

Now, some tools for installing encrypted filesystems will already have this step built in, such as the Debian installer, but some won’t. You’ll need to discover your vendor’s documentation to see if this is the case. I would say it doesn’t hurt to be safe, and take this step anyway, but it’s up to you.

There are many utilities for writing random or pseudorandom data to the drive. Probably the best tool will be DBAN, or Derik’s Boot and Nuke. This utility is generally used for destroying data, but in this case, we’ll use it for preparing data. Download the live CD, burn it, and reboot your machine. I would recommend selecting the “PRNG Stream” from the menu. This will normally write pseudorandom data to the disk 4 times. However, it shows a progress report on the number of passes, so after it completes its first pass, you can reboot. It’s important to note that selecting “Quick Erase” will do a single pass of zeros. This isn’t what we want. We’re trying to deter attackers by not giving them the boundaries of our encrypted filesystems. If you choose “Quick Erase”, then you’ll be clearly showing them where those boundaries exist. As tempting as it may be, don’t select it.

If you’re familiar with Linux live CDs, you can boot into a live environment, such as KNOPPIX, pull up a terminal and run the following, assuming the drive you’re preparing is “/dev/sda”:

dd if=/dev/urandom of=/dev/sda

The point is getting random or pseudorandom data down on the entire disk. However you accomplish that, is up to you.

After a few hours pass (depending on the size of your drive, and if you cancel the operation after a single pass of PRNG Stream), you are now ready to reboot into your operating system installer if it provides the ability to encrypt the filesystems, or into a separate utility for doing so.

Step Two: Set up volumes or partitions and encrypt
With the Debian installer, and most GNU/Linux installers, you can set up your partitions or logical volumes, then tell the installer to encrypt them, even with some options on the cryptography. When you’ve defined your filesystem boundaries (I’m not going to cover that here), and you’re ready to encrypt, you’ll inevitably be required to type in a username and passphrase. Some encryption utilities will use this passphrase as a seed for the encryption algorithm, so the stronger the passphrase, the stronger the seed, and this the more unlikely an attack will be successful on the filesystem. So, choose wisely and choose securely.

Step Three: Install the operating system
Whether it be Windows, Mac, Linux or whatever operating system that supports encrypted filesystems, you’re now ready to install it. Follow the operating system’s installer to the end, reebot, and make any additional final preparations to your computer before putting down the data. You should at this point be able to boot the computer, provide the necessary username and passphrase, and use your operating system as normal. If not, you’ll need to spend some time with your operating system’s documentation or encrypted filesystem documentation to get to that point. This post isn’t about that, so Google might be your friend here.

Okay, so now we have a usable operating system running on top of a fully encrypted drive. If we were to stop here, we wouldn’t make things very challenging for the attacker. We want to do that. So, we’re going to start adding some hurdles along the way. If the attacker has the stamina, then so be it. I’m guess that most attackers, when faced with each of these hurdles, likely won’t bother, and move to their next victim, rather than waste time trying to figure out how to get from Point A to Point B.

Step Four: Password protect your BIOS
This will vary widely on hardware, so consult your vendor’s documentation on how to boot into your laptop BIOS and set an administrator password. However, this functionality should be provided on most modern BIOSes. When found, go ahead and set the password. It can be whatever you want. I would recommend making it hard to guess, but it doesn’t really need to be on the same level as the encryption passphrase you provided earlier. Just don’t make it successful to a dictionary attack, and you should be good. Don’t reboot. Stay in your BIOS for the next step.

Step Five: Change your boot order to boot off the hard drive first
The reason for setting the administrator password in the BIOS was so we can tell the BIOS that we always want it booting from the hard drive first, rather than from the floppy, CDROM, network or USB. This step is necessary to hopefully avoid the Evil Maid attack, something I’ve already blogged about here. In summary, the Evil Maid attack is booting your computer from a USB or CDROM, replacing your bootloader by installing a custom bootloader with a keylogger, and powering down. Then, when you boot your machine, and enter the encryption passphrase, it gets stored on disk, or sent over the network to a remote server. After you leave your laptop a second time, the attacker comes back to your computer, boots off the hard drive, provides the newly discovered encryption credentials, and steals your data.

So, if your laptop is BIOS password protected to only boot from the hard drive, this is a good deterrent. Why? Well, in order to remove the password off the BIOS, so the attacker can boot from some other medium, they will need to disassemble the laptop to get to the motherboard, and flash the BIOS. This is easier said than done on laptops. Have you ever taken your laptop apart? I have. I’ve take apart both my old HP Pavilion and my current ThinkPad T61. They’re a royal pain, and extremely time consuming.

A good attacker will be paranoid for time. They don’t want to get caught. If it means spending 3 hours disassembling a laptop just to flash the BIOS, so they can install their custom bootloader and keylogger, chances are high he’ll move on to another victim. Now, that’s not to say that every attacker can’t do this, or they know they have the time, and your data is that valuable to them. Maybe the attacker is skilled at disassembling Dell, Lenovo and HP laptops, so it’s only a 30 minute inconvenience that he knows he can make. But, maybe not. At least this is a moderately challenging task, and I’d be willing to bet most attackers won’t bother.

Step Six: Physically lock down your laptop or take it with you
Again, just another deterrent, but locking your laptop down to a secure location could provide enough of a challenge to deter physical theft, should all efforts being made at getting to your data fail. After all, there is value in the hardware itself. EBAY is probably making a killing of such scenarios without knowing specifics. This doesn’t mean the attacker isn’t skilled at lock picking or doesn’t have a strong set of bolt cutters with them. However, if the time it takes to remove the laptop from the premises is a challenging effort, the attacker likely won’t bother, and move on.

With that said, I had my car broken into once. They were after my stereo. Thankfully, they were caught in the act, and found guilty in court of seven counts of theft and property damage, among other things. However, in the car before mine, they couldn’t successfully remove the deck from the dash. It was bolted down. So, out of frustration, they physically destroyed the deck and the dash. Not out of failing to remove it, but out of anger for not succeeding. Your laptop may fall victim to such physical damage.

So, if you can carry it with you, you probably should. When I was on the road, I took my laptop with me everywhere I went for fear of physical damage or theft. I would take it with me to dinner. I would take it with me to events. I would take it with me sight seeing. I was paranoid. Sure, I run the risk of damage while traveling with it, but I know how to treat my bag carrying the laptop. At least then I’m somewhat in control. Further, an attacker can’t attack what isn’t there. But, when I couldn’t take it with me, I would lock it down securely, and hope it remained in tact when I returned.

Step Seven: Remove the data and/or encrypt it a second time
Many operating systems support encrypting directories and files on top of the filesystem itself. This means you can have an encrypted directory in your home folder, where the valuable data resides. Should the attacker successfully get access to your encrypted filesystem, if you chose a different passphrase for your encrypted directory, hopefully, they won’t get access to that.

But, keeping that sort of sensitive data on the drive might not be wise, even if it is encrypted. So, it would be best to have that data on an encrypted USB disk. Your only concern should be making sure you don’t lose that drive. Even if it’s not stolen data, lost data still sucks. Backups here help.

At my place of employment, we’re developing a virtualization solution where all the developers will have virtual desktops in our datacenter. The idea is to keep the data off of the developer’s laptop. So, when they login to their laptop, they then must login to the VPN, then use RDP or SPICE (yeah, we’re deploying RHEV) to login to their remote desktop, and work from there. At this point, the laptop becomes a mere dummy terminal, not storing a single piece of data- even email. There are concerns, like if the developer doesn’t have Internet access, or if the datacenter is compromised, but from a traveling perspective, keeping the data off of the traveling laptop is a net win. Some hotels might have crappy WIFI, but at least security has come first, and the data is safe.

Appendix A: Learn how to remove and restore your bootloader
This is a crucial skill, I think. It doesn’t really fit into the above steps per se, so I’ve added it as an appendix. The idea is simple. When traveling from another country to the United States, the Department of Homeland Security thinks it’s fun to ignore the Constitution, and seize and search your laptop without a warrant. Bruce Scheier has covered this extensively, so I’ll let you read up on his posts about the topic. If you’re running an encrypted filesystem, they can detain you until you provide them with the passphrase, at which point they can then image your drive, keeping your data. This is wrong on so many levels, but you have a good deterrent- wipe your bootloader before landing.

When I traveled to Canada for training, I was already aware of the DHS doing this at customs. So, before being required to turn off my laptop during landing, I wiped the bootloader, and prepared a script in my mind should the DHS want my to power on my laptop. I was resolved that I wouldn’t lie, as that would be perjury, but I would dance around the issue as best I could. The script would go something like this:

Agent: Can you power on your laptop please?
Me: Sure, but while on the road, something happened, and it will no longer boot. It says it’s missing an operating system. I’m hoping to get it fixed when I get back to the office.
Agent: Will you power it on anyway please?
Me: Sure.
(I power on the computer, at which point, it behaves exactly as described.)
Agent: Okay, thank you. Carry on.

When I was returning from my Canada trip, and passing through customs, the agent asked me to remove the laptop from my bag and open it. I was already prepared with a removed bootloader, and my heart was racing to go through the script. When I opened the laptop, we proceeded to swipe it looking for traces of explosives. When he was satisfied, he said thank you, I put the laptop back in my bag, and was on my way. I was a bit bummed that I didn’t get to defeat the DHS at their own game, but was relieved at the same time that I didn’t miss my flight home.

After I was on US soil, I boot off a rescue CD, and restored my bootloader, and was able to boot back into my Debian install without trouble. This takes some practice and know-how, but I think it’s really quite worth it should that scenario ever present itself. Of course, who knows what would happen? Maybe I would be detained until they could fix the problem with my laptop, at which point, I would still be required to turn over the passphrase, and they image the disk. Who knows? Still worth a shot, and it’s easy to do, if you know what you’re doing. Just don’t lie.

Appendix B: Stay with your belongings through metal detectors
Again, this is something that doesn’t really fit in the steps above, so it’s in the appendix as well. When you are entering an airport, and your belongings have to go through XRAY, there is an attack to steal laptops that is rather trivial and easy to setup. All it requires is three people- two attackers and the victim.

The attackers find a victim with a laptop (or bag obviously carrying a laptop) they want. They both position themselves immediately in front of the victim when standing in line to go through security. By the time the first attacker reaches the metal detector, the victim has likely placed their personal belongings on the belt to go through the XRAY machine. The first attacker goes through the metal detector without a problem. He waits at the end of the conveyor belt to get his belongings as well as snatch the laptop. The second attacker, however, causes problems going through. Every time he attempts to go through, something in his pockets, or otherwise, causes the detector to go off. Now, generally, it only takes 2 or 3 attempts before the agent will just get his magic want, and swipe him down from head to foot. But, two to three attempts is all the time that is needed for the victim’s bag or laptop to go through XRAY, at which point the first attacker takes the computer, and disappears into the crowd before the victim even had an opportunity to get through. It’s sneaky, it’s effective, it’s fast and it’s clean. Further, TSA isn’t keeping track of who’s belongings belong to who. For all they know, that was their laptop, not yours.

How do you avoid this attack? When I traveled, I stood at the XRAY machine with my hand on my laptop bin, and I sent it through the same time I went through. I never gave it a chance to get ahead of me. This would slow down the line a bit sometimes. In fact, I would let people go ahead of me while I waited. I took no chances. I’ll go through metal detection faster than my laptop will go through XRAY, so I can wait for it to come down the belt right into my own hands. It requires a bit of patience and stubbornness, but I think it’s worth it. You’ll likely not bump into the cranky people behind you again, so no biggie.

Conclusion
So, there you have it. Those are the procedures and steps I would take when traveling with my laptop. I would recommend the same to you. Really, it boils down to determination, knowledge and a bit of luck. You can avoid the worst if you are sufficiently paranoid. There’s nothing wrong with taking the extra precautions to protect your data and your laptop from theft or damage. Of course, these steps aren’t bullet proof, and everything comes at a cost. There might be a slight inconvenience to the traveler to jump through some of these hoops. But, what is it worth? If the cost of the inconvenience outweighs the cost of the data, then some or all of these steps might not be necessary. If the cost of the data outweighs the cost of the inconvenience, then I would say stick to each step religiously. That’s just me.

I then finished up showing how to break encrypted filesystems using the cold boot attack. The University of Princeton has an excellent white paper, video and software on how to make this possible. The idea is simple- read the contents of RAM immediately after a shutdown, then use software to search through that memory dump finding a passphrase used on the encrypted filesystem. The only problem with this attack, is the limited scope of software in which it is effective against.

Enter Evil Maid.

The idea is simple. Because you still have access to the target machine, rather than doing a cold boot attack, memory dumps and additional processing on the RAM dump, install a different boot loader that contains a key logger. When the target enters the encryption passphrase on his machine, the key logger will have grabbed every key stroke, either saving it somewhere on disk for later retrieval, sending it over the Internet to the attacker, or whatever is necessary to get the passphrase.

THIS WILL WORK ON ANY OPERATING SYSTEM AND IS EFFECTIVE AGAINST ANY FILESYSTEM ENCRYPTION SOFTWARE!

This is more effective than the cold boot attack, or even the “stoned boot” attack that Bruce Schneier covered earlier this year, but it’s still not without its weaknesses. This attack assumes that the target will power on the computer at a later time, and enter the passphrase for the encrypted filesystem. The attacker would not want to actually steal the powered down computer.

This is why it is called “Evil Maid”- you leave your computer in the hotel room, the housekeeping maid comes in to clean your room, but while there, installs the boot loader and key logger, then repowers down your computer. When you return to the hotel room, you power on, enter the passphrase, do you work, or whatever. The next day, when the maid returns, she returns, most likely to either retrieve the key and restore the previous boot loader, erasing her tracks. Now she has access to your data, can image the drive for offline analysis and have all sorts of nasty fun.

This should say something about encrypted filesystems. They really only protect you if the drive is stolen, and the computer has been powered down. Other than that, there is an important security lesson to learn here. If someone has physical access to your computer, with the intent to do harm, there is no stopping them from getting administrative rights on the machine, installing software, archiving data, imaging drives, etc. As a result, this should tell you something valuable: if possible, as in the case with laptops, keep your computer with you in untrusted environments.

There are possible protective measures to protect yourself against such an attack. Storing your computer in a strong box under lock and key might work. Although the attacker only needs to be proficient with lock picks, this is a good first safe measure. Many hotels offer such strong boxes. Second would be hardening your BIOS to help prevent such an attack. Again, just a “speed bump” do a dedicated attacker, but it could be enough to deter. Lastly, because this attack assumes installing software on non-encrypted boot partitions or sectors, getting a hash of the non-encrypted boot partition and storing on a separate USB key could be valuable. Thus, when you travel, before you boot the machine from the hard disk, you could boot from a live CD, and check the hash of the boot sector against the hash stored on your key. Of course, if the attacker ever gets access to your USB key, the hash could be corrupted or modified.

Long story short- don’t leave sensitive data on your machine in untrusted environments, such as hotel rooms. Take your computer with you whenever you can and shut it down when not in use.

The most popular of these, is DBAN, or Darik’s Boot and Nuke. It comes as a CD or USB image that you boot from, rather than the disk, then choose in a menu which wiping method you wish to choose. Of the choices, there are:

• Quick Erase- One pass, writing nothing but zeroes.
• RCMP TSSIT OPS-II- Eight passes using random writes and compliments on each pass.
• DoD Short- Three pass version of the stronger seven pass below. Each pass is random data written.
• DoD 5220.22-M- Sever passes using random data at each pass.
• Gutmann Wipe- 35 passes across the hard drive as described by security expert Peter Gutmann and Colin Plumb.
• PRNG- Arbitrary number of passes specified by the user using a pseudo random number generator for writing random data on each pass.

For most secure scrubbing purposes, a quick erase is more than good enough. There have been no published papers to date on recovering overwritten date after a single pass. Is that to say it’s not possible? No, of course not. For what it’s worth, all the drives that leave my possession only get a single pass. However, if you or or organization is more paranoid about getting the data off the platters, there are other options available that will do more passes on the drive.

The next option in the DBAN menu is the RCMP TSSIT OPS-II wipe. This pass uses a source for a pseudo-random number generator as the first pass, then produces the compliment of that first pass as the data for the second. The idea behind this method is switch the bit on the disk platter from one to zero as often as possible. By using a random source for the initial pass, then writing the compliment, we’ve successfully written two passes on disk. At this point, it should be “good enough” for even the most seasoned data recovery company. However, this pass does that dance three more times, for a total of eight passes.

The Department of Defense, in the United States of America, has established a standard for sanitizing disks that contain TOP SECRET data. They have two standards. The first is the “DoD Short” wipe. This is a short three pass wipe. Nothing fancy about it. Each pass uses a pseudo-random number generator as the source for the overwriting data, and makes three passes with this source. The “DoD 5220.22-M” is the more secure DoD sanitization method, which uses seven passes across the disk instead of three. Each pass uses a pseudo-random number generator for the source of the data.

The next method is for the ultra-paranoid company or individual. This wipe is known as the “Gutmann Wipe”, and it’s built to take advantage of different hard disk encoding mechanisms. Essentially, there are two main encoding schemes for storing the data on your disk: MFM and RLL. All modern drives today use the RLL encoding scheme. Essentially, RLL is a lossless compression encoding scheme, making it possible to fit more data on the disk platters. Because MFM and RLL store data differently on the drive, using a certain method might be optimized for MFM encoded drives, but won’t work well with RLL and vice-versa.

The method behind calculating the data to the disk is rather simple: generate a unique list of one-bit numbers (zeros and ones), then two-bit numbers, then a three-bit numbers, then finally four-bit numbers uniquely. After this list of numbers has been generated, begin writing. This list is as defined in hexadecimal:

1. 1-bit: 0×000, 0xFFF
2. 2-bit: 0×555, 0xAAA
3. 3-bit: 0×249, 0×492, 0×942, 0×6DB, 0xB6D, 0xDB6
4. 4-bit: 0×111, 0×222, 0×333, 0×444, 0×666, 0×777, 0×888, 0×999, 0xBBB, 0xCCC, 0xDDD, 0xEEE

If you want to convert this list to binary, then think about it in terms of the “number of bits”. For example, with one bit, you only have two options: a zero or a one. With two bits, you have a possible combination of 4 numbers: all zeroes, all ones, zero then one or one then zero. Because we’ve already defined “all zeroes” and “all ones” in the one-bit number, we don’t need to repeat them in the 2-bit, 3-bit or 4-bit representation. Now, why repeating that bit 3 times? Well, the least common denominator of three and four is twelve. The idea is that I’m writing patterns, not necessarily static data. So, the pattern needs to repeat through the 12-bit number. For example, take the 4-bit number

0x999

What is this in a 12-bit binary representation? Isn’t it:

100110011001

or if you were to separate it out:

1001 1001 1001

Do you see the pattern of two ones followed by two zeroes, followed by two ones followed by two zeroes, etc? That’s the idea. Writing patterns to the disk.

So, how do we put all these numbers together, so we can sanitize the data securely for both RLL and MFM drives? Wikipedia has a good article on it, and explains that the first and last four writes are random data from a secure random number generator. Then, at pass five through pass 31, we use the 1-bit through 4-bit numbers we came up with, and begin writing, some of them used two or three times, based on the drive encoding scheme it’s targeting.

Lastly, if this isn’t enough, you have one last option, where you can specify the number of passes for wiping the data. The pseudo-random number generator that is used for the other passes is chosen here, and each pass writes random data to the disk.

This is a great utility for sanitizing disks, however, I’ve found DBAN to be spotty on certain hardware configurations. For one, it’s x86-based only, which means you won’t be able to boot this on Sparc or HPPA-RISC hardware. Also, even on some x86-based hardware, I’ve found DBAN to hardlock, not ever getting to the menu for me to begin wiping. So, what can I do? Am I up a creek without a paddle? Most definitely not!

KNOPPIX is a solid LiveCD that loads the Linux kernel and the Debian user-space utilities, giving you a live desktop, complete with all the tools you would need for rescuing and wiping machines. KNOPPIX has been soundly tested against a vast array of hardware, and it sees very active development with a vibrant community behind it. How can KNOPPIX securely delete the data off your drives? Well, GNU Shred from the GNU Coreutils package is a flexible package for choosing the number of passes against a drive. Because you’ve booted into a live Linux environment, you also have /dev/zero, /dev/random and /dev/urandom as a source of endless data for sending to your drives. In my specific situation of wiping the 13 SCSI drives, I booted into a KNOPPIX CD, executed ’shred’ and told it to do three passes, then one last pass of zeroes, hiding any evidence of data sanitization. Many other GNU/Linux distributions provide live environments (CD or USB) that you could take advantage of. Ubuntu, openSUSE, Debian and Fedora are just a few worth mentioning.

Of course, if you’re running an encrypted filesystem worth its salt, then there really is no practical reason for scrubbing the data off your drives, and the encrypted representation of your data doesn’t mean squat without the private key to that data.

$ gpg -v --version
gpg (GnuPG) 1.4.9
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8),
        AES256 (S9), TWOFISH (S10)
Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9),
      SHA512 (H10), SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)

So, for ciphers, I support 3DES, CAST5, BLOWFISH, AES, AES192, AES256 and BLOWFISH. For digest hashes, I support MD5, SHA1, RIPEMD160, SHA224, SHA256, SHA384 and SHA512. Lastly, for compression algorithms, I support uncompressed, ZIP, ZLIB and BZIP2. Your output my vary slightly one way or the other. For example, you may not see the full suite of SHA algorithms. This can be obtained by generating an RSA subkey for signing only. Other ciphers might include IDEA, CAMELLIA128, CAMELLIA192 and CAMELLIA256, and you could have TIGER and WHIRLPOOL as possible supported hashes.

With all these algorithms, how do you know which to use and when? Fortunately, GnuPG takes care of that for you automatically. However, you can tell it what you would to prefer to use for each, if you like. You can set these in your ~/.gnupg/gpg.conf file. The options you are looking to set are “default-preference-list”, “personal-cipher-preferences”, “personal-digest-preferences” and “personal-compress-preferences”. For myself, here is what I have set in my gpg.conf:

default-preference-list 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH MD5 SHA1 RIPEMD160 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2
personal-cipher-preferences TWOFISH AES256 AES192 AES BLOWFISH CAST5 3DES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 SHA1 RIPEMD160 MD5
personal-compress-preferences BZIP2 ZLIB ZIP Uncompressed

Now, when we printed out the verbose version, we saw in parenthesis S2, S3, H8, H9, Z1, Z2 and so on. We can use these instead of the name in our gpg.conf if we so wish. I prefer the name, as I can’t recall the key to the algorithm, and it’s easier to read. So, in my case, I list out everything that I want for a default list of preferences, then I choose the order of which to pick from when encrypting, signing and compressing. So, for encryption, I have set TWOFISH as my first choice, with AES256 as my second choice, then AES192 as my third, and so forth. I’ve done the same with my preferred digest hashing algorithm choosing SHA512 first, then SHA384 second, and so on, and the same with compression.

Why set the preference? For starters, if you’re like me, you sign all your email by default. You probably want your signature to withstand the test of time as long as possible. Given the strength of today’s hardware, why not choose the strongest encryption and hash algorithms? But on a more practical note, if you’re encrypting data to yourself, this would tell GnuPG to use TWOFISH as the encryption algorithm. This means that if you want to decrypt it at a later date, maybe on another computer, you’ll need to make sure TWOFISH is compiled into GnuPG. How would you know what was used? We’ll cover that in a bit.

However, what about encrypting to someone else other than yourself? How do these preferences come into play? Well, you can also set preferences in your public key. The purpose of this, is when people grab a copy of your key, and they want to encrypt something to you, GnuPG will negotiate the first preferred algorithm that is common between the two end points (the one doing the encrypting and the one receiving the encrypted data).

For example, let’s suppose Alice has a GnuPG keypair as does Bob. In Alice’s public key, which Bob has a legitimate copy of, she has set a cipher preference order of: TWOFISH BLOWFISH AES CAST5 and 3DES. Bob wants to encrypt data to Alice. Because he has a copy of her public key, he can do this. The question here is, which algorithm will be chosen for the encryption? Well, Alice prefers TWOFISH as a first pick. If Bob has compiled TWOFISH support in his copy of GnuPG, then it will be used. Suppose he doesn’t have TWOFISH support. Then the next preferred algorithm is BLOWFISH, because it’s Alice’s second pick. Let’s say Bob does support it, then BLOWFISH is the algorithm used for encrypting the data to Alice. When Alice receives the encrypted data, she’ll use the BLOWFISH algorithm along with her private key to decrypt the data. Should she wish to reply, her copy of GnuPG will pull out the preferences from Bob’s public key, and go through the same process looking for the first preferred algorithm by Bob that is supported by both parties. The “SSL handshake” works much in this same manner.

Digest hashing works much the same way, but slightly different. Because the recipient doesn’t matter with signed data, then rather than looking to public keys for the digest algorithm preference, you turn to your gpg.conf file, if listed, and use that there. If the recipient, or recipients have a copy of your public key, and the same digest algorithm compiled into their copy of GnuPG, they can verify your signature. If either is missing, the public key, or the algorithm, the signature will fail, and GnuPG will explain the problem. This process is the same for compression algorithms.

So, we’ve made the preferences in our gpg.conf, but how do we set them in the public key, so we can distribute this to others? Well, in this case, we need to edit our key. From the terminal (I’ve snipped out the noise, focusing only on what’s important):

$ gpg --edit-key KEYID
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.
[ ... SNIP ... ]

Command>

We are now sitting at a command prompt that we can use to pass commands in an interactive fashion. I should mention that all this can be done non-interactively. Checking out the gpg manual will provide the list of options for making this possible. Typing “help” will give us the list of commands that we can pass:

Command> help
[... SNIP ...]
pref        list preferences (expert)
showpref    list preferences (verbose)
setpref     set preference list for the selected user IDs
[... SNIP ...]

The commands that we are interested in “pref” and “setpref”. Passing “pref” might give us something like the following:

Command> pref
[ultimate] (1). Aaron <aaron@example.com>
     S10 S9 S8 S7 S4 S3 S2 H10 H9 H8 H11 H2 H3 H1 Z3 Z2 Z1 Z0 [mdc] [no-ks-modify]

See those algorithm codes we saw at the beginning of this tutorial? They are listed in the preferred order that we wish to have each algorithm. In my case, I have all my encryption algorithms lists, from strong to weak, then hashing from strong to weak, then compression from most tight to no compression. What if I wanted to set a different order, or maybe not include some preferences: Using “setpref” makes this possible:

Command> setpref S10 S9 S8 S7 H10 H9 H8 H2 H3 Z2 Z1 Z3 Z0
Set preference list to:
     Cipher: TWOFISH, AES256, AES192, AES, 3DES
     Digest: SHA512, SHA384, SHA256, SHA1, RIPEMD160
     Compression: ZLIB, ZIP, BZIP2, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)

Typing “y” will of course make the setting in your key. At this point, you’ll be asked to enter your private key passphrase successfully before continuing. At that point, it will be statically set in your public key, and you can send your key off to the keyservers and emailed to your family and friends, so they can immediately start taking advantage of the new preferences. Type “quit” to leave the prompt.

Now, let’s say you have some signed and encrypted data, and you’re curious of the algorithms used when creating the cipher text. This can be done by passing the “–list-packets” option to gpg to see the data packets. We’ll need to turn on verbosity as well. For example, the output of a file I sent to a friend using the Mutt email client (emphasis mine):

gpg -v --list-packets file.txt
gpg: armor header: Version: GnuPG v2.0.11 (GNU/Linux)
[... SNIP ...]
gpg: AES256 encrypted data
:compressed packet: algo=3
:onepass_sig packet: keyid CE7911B7FC04088F
	version 3, sigclass 0x01, digest 8, pubkey 1, last=1
:literal data packet:
	mode t (74), created 1244484492, name="mutt-helios-1000-24974-13",
	raw data: unknown length

Here, I can easily see that AES256 was used for the encryption algorithm, but what’s this compressed “algo=3″ and “onepass_sig packet digest 8″ stuff? Well, in order to understand those, we need to turn to RFC 4880. This RFC describes the OpenPGP message format and the standards used. Browse your way down to section 9, and you’ll see what “algo=3″ means for compression and “digest 8″ is for signatures. It appears, according to that RFC, that BZIP2 was used for compression and SHA256 was used for the hashing algorithm. So, in this case, Christer and myself preferred those settings higher than the others, and my GnuPG acknowledged those preferences and did the encrypting, signing and compressing as told. We can see these by “editing” his key:

$ gpg --edit-key christer
[... SNIP ...]
Command> pref
[  full  ] (1). Christer <christer@example.com>
     S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1 [mdc] [no-ks-modify]
[... SNIP ...]

Command> quit

Christer places AES256 has his first preferred encryption algorithm. Because I also support this algorithm, this is used for the encryption. SHA1 is his preferred digest hashing algorithm with SHA256 as his second preferred, but remember that for the signature and compression, these preferences are found in my gpg.conf instead. I prefer SHA512 as my first preference, but he doesn’t list it as suported (according to his public key), so I move down to SHA384. Again, he doesn’t list it, so I try SHA256. He lists it, so it’s used. Lastly, BZIP2 as the compression algorithm, and he lists it, thus it’s chosen. Thus, the results we got. Make sense?

I hope this has been informative. It’s been great discovering the details of how these algorithms were chosen, and it’s been fun playing with all sorts of encrypted emails and files to get to the guts of the GunPG process. If I’ve misrepresented any data here, or you have questions, please let me know.

I used to travel the country teaching Linux System Administrators. I have spent many a day in airports, hotels and training centers. Whenever there was a network connection available, I was on it, mainly with SSH. SSH is so flexible, that here is how I configured it, and how I managed it.

First, my ~aaron/.ssh/config:

Host *
    Cipher=blowfish
    CompressionLevel=9
    ServerAliveInterval=30
Host *.server1.com
    GSSAPIAuthentication=yes
Host *.server2.com
    ForwardAgent=yes
Host foo
    Hostname foo.server2.com
    Port=22222
Host bar
    Hostname bar.server2.com
    Port=22000
Host baz
    Hostname baz.server2.com

Then, my ~aaron/.zshrc:

alias foo='ssh foo'
alias bar='ssh bar'
alias baz='ssh baz'

Now, from the terminal (assuming I’m using SSH keys to authenticate):

<<< 15:18.27 Thu Dec 11 2008!~
<<< aaron@kratos!3045 B:94% (0:45:31)
>>> for HOST in foo bar baz; do ssh $HOST 'touch ~/.hushlogin'; done

So, what’s going on here? In my SSH config, I’ve first chosen to use the Blowfish algorithm, as it’s light and fast, and I’ve turned compression on to the max to minimize the data passed on the wire as some connections just suck when it comes to bandwidth. I’m forwarding my SSH agent to *.server2.com, so I don’t have to always enter the SSH key passphrase after I’ve already entered it on my client. Of course, this should be on trusted systems only, and *.server2.com represents my personal servers here. I’ve set the connection to send a TCP SYN packet every 30 seconds, so I don’t lose the connection on some shoddy networks. Then, one specific host, I’ve setup support for Kerberos authentication, and all the rest, I’ve setup host shortcuts, telling SSH what hostname and port to use. Basically, I like typing as little as possible on the terminal

Then, on all SSH machines that I have access to, I don’t like the message of the day, if one exists, so I create the ~aaron/.hushlogin to stop that from displaying on my terminal. Finally, in my ~aaron/.zshrc, I created a few aliases for making it easy to get to the host- again, minimizing my typing as much as possible. So, I can just type “foo” on the terminal, and I will “ssh foo” which means to “ssh foo.server2.com”.

Beautiful.

However, not all is done. I also am a big fan of hiding any and all network traffic. It’s no ones business to see my packets. So, I have another alias setup in my ~aaron/.zshrc:

alias tunnelfoo="'pkill ssh; ssh -4fgN -D 8081 -L 8080:localhost:3128 foo"

This connects to foo setting up both a dynamic and static SOCKS proxy. First, however, you’ll notice that it runs “pkill ssh” before setting up the tunnel. I do this, because when I suspend my laptop, then resume on a different connection, that process is still running, and trying to re-establish the proxy fails, saying the ports are already bound. So, I just always kill any SSH connection when tunneling. This could be a little of a pain, if I already setup an SSH connection before running this alias. Also, the static SOCKS assumes that there is Squid proxy on the other end to tunnel the connection through. All I need to do now, is setup Firefox to connect to localhost on either port 8080 if I want to use Squid on the other end, or port 8081 if I want SSH to handle the proxied TCP/IP packets. Both are useful. I would recommend the FoxyProxy extension, if you aren’t already using it. It makes it easy to connect to these ports and tunnel your SSH traffic.

Finally, when I’m at remote locations, and I want access back into the network before I leave (this could be useful in the training center, where I may need to administer or play with student machines from the hotel), I’ll setup a reverse SSH tunnel, to get back into the network:

ssh -4fgNR 8080:remote.server.com:22 foo.server2.com

Now, when I get somewhere else, other than the location I was just at, I can run the following two commands to get back into that network:

<<< 15:33.43 Thu Dec 11 2008!~
<<< aaron@kratos!3048 B:98% (0:20:38)
>>> ssh foo
<<< 15:33.46 Thu Dec 11 2008!~
<<< aaron@foo!471
>>> ssh -p 8080 localhost
Password:
[aaron@remote.server.com:~]$

Now, I’m back into the network where I setup this remote SSH tunnel to begin with. From here, I can do work from home, the hotel, the airport, or wherever I happen to be. Those are my SSH tips. They make SSH much more enjoyable to be working with. Of course, I’m using SSH keys or Kerberos to authenticate, so I never need to deal with passwords when moving about networks.

Cheers!

However, the point of this post isn’t to complain about being laid off, or the bad shape of the economy. Rather, while employed, I was given a 120 GB LaCie Rugged hard drive that was called the “gurudisk” (being a “Linux Guru” from “Guru Labs”. Get it?). The gurudisk had everything on it necessary for easing the installation of Linux on computers. Kickstart and AutoYast files were used for automating the install of the instructor machine, while scripts and RPMs were used to automate the configuration and additional software installation of the instructor machine, and DHCP, DNS, TFTP and PXE, along with Kickstart and AutoYast files, were used for automating student machines. Using the gurudisk, I could do a full classroom install, complete with instructor machine and 20 student machines, in under an hour. The gurudisk held RHEL 5, RHEL 5.1, Fedora 6, SLES 10, SUSE Linux 10.1 and Oracle 4.5 disk ISOs and software, as well as RPMs, scripts and config files. It was truly a welcomed companion.

However, all of that can easily fit in 40 GB of space, so what to do with the rest of the 80 GB? Well, most of us began using that space for personal data. Music, videos, scripts, documents and so forth. I’m not one to carry music or movies with me, so that didn’t interest me much. Rather, I wanted the ability to take the gurudisk further with using Ubuntu and Debian. So, I had an “isos” directory on my gurudisk, where I kept more updated ISOs, including RHEL 5.2, Fedora 9 and 10, Ubuntu 8.04 LTS, Debian 4.0, openSUSE 11, OpenSolaris, FreeBSD, OpenBSD, and others. At one point, I had an entire Ubuntu repository mirroring 8.04 and 8.10 on the gurudisk. Lastly, if that’s not enough, I had VMWare, KVM, Xen and VirtualBox virtual machines with clean, vanilla installations of a few of the major distributions. I took advantage of my space, and it also came to the welcome approval of many students.

When news came yesterday that I had lost my job, and that I would need to turn in my gurudisk, I wanted to first get my Ubuntu mirror, virtual machines and ISOs off the disk. Then, I wanted to experience, first hand, “shredding” the data on the disk. Thus, we have now reached the topic of this post- GNU shred.

I had heard from students over and over again that zeroing out the drive using /dev/zero is not sufficient for secure data deletion. I full heartedly disagree, and I’m sure I’ll bring out the emotion of many of you in the comments. Here’s why I think /dev/zero is more than sufficient for secure data destruction:

• On older dive encoding schemes, mainly RLL and MFM, data was not written in exactly the same spot every time. As such, there was left over charge from the previous write, and expensive data recovery hardware could use math and averages to discover what the data once was. As such, a method known as the “Gutmann Method” became the standard of destroying data. Patters of ones and zeros would be written to the disk, in such a way that maximizing flipping the bits, minimizing the average left over charge. After seven passes, the residual charge would be so minute, that it would be virtually impossible to recover the data. Do 35 passes, and the data is gone for sure.
• Drives today do not use RLL or MFM encoding, and also, the bits are much more close together then they were in days gone by. The data has to be written in exactly the same spot, or data destruction is likely on other data existing on the disk. As such, there is no left over residual charge from rewriting the data. A single pass over existing data removes any existence of that data.
• Supposedly, top secret, mega government, super computers administered my corporations with endless amounts of cash flow can recover data on ATA drives, even after seven passes. However, there has been no academic study, no scientific evidence, no hard cold proof. All we have is hearsay and rumors of people we know claimed to recover the data using these killer machines or algorithms on ATA drives.

So, with that in mind, after backing up my data, a single zeroing of the entire drive would be more than sufficient for a couple reasons. First, my bosses and company don’t have the resources, the time and money, or the care to recover any data off of my gurudisk. Second, the data I was deleting wasn’t necessarily personal, as no passwords or private keys or information was stored on the disk. So, even if the data could be recovered, of what use would it be to anyone? Little, if any. Chances are good that the drive will sit on a shelf, unattended and unused, and when it does make it back into commission, it will just be formatted with ext3, files put on, and used as any other drive. So, /dev/zero it is.

Or not.

I’m a mathematician at heart. I love math and logic puzzles as well as cryptography and many an algorithm. If I had the time and money, I would finish college, and get a Doctorate in Mathematics. However, that’s a dream that just isn’t realistic at this point in my life, but I still enjoy pulling out my HP49G+, and crunching the numbers. So, the algorithm used in Gutmann’s Method is interesting. More interesting are the pseudo-random number generators used in cryptographic applications. So, I decided to give GNU shred a try, seeing as though it’s part of coreutils, and see what the result is. I ran the following command:

shred -v -z /dev/sdc

This means that GNU shred will make 26 total passes, with the 26th pass being straight zeros to hide the fact that the disk has been shredded. Once finished, I’ll add one final pass as an easter egg to the next person who gets the gurudisk. So, 27 total passes to the disk. What I’m mostly interested in, is the time it will take to finish. From my understanding, it will write pseudo-random numbers to the disk on the first, middle and second-to-last passes, due to passing ‘-z’ to zero the shred. Writing random data to 120 GB of disk is going to take some time. In fact, I timed it, and it took 5 hours and 20 minutes. Which means it will last at least 16 hours to run to completion. But then there is the one and zero pattern writing that will take place in between. I would expect this to go substantially faster than writing random data, and it does- about three times as fast. Three passes can be completed in 5 hours and 20 minutes, give or take, based on the pattern. There are 23 final passes at this rate, which is approximately 41 hours. Add the 16 on top of that, and it’s going to take 58 total hours to complete all 26 passes. That’s almost 2 and a half days! In fact, as I’m writing this, it’s 18:00 the next day, and I’m only on pass 11, writing the pattern “333333″ in hexadecimal to the disk. The next pass will be my second random data pass. When I get out of bet tomorrow, I expect to be on pass 18, give or take.

I figure, even though I’m long past any possible data retrieval, it’s fun to watch. Even more entertaining is the heat emanating off of the disk- it’s fairly warm, which I guess makes sense, as the disks have been going non-stop for almost 24 hours. Would I recommend GNU shred for wiping your data? No. Again, /dev/zero will be more than sufficient, and fast too, at roughly 30 MB per second on a SATA or USB 2.0 disk. Which, by the way, this disk is connected via FireWire 400 (I’m not a fan of the USB speed burst). I’d love to see this run to completion, but I’ll probably cancel it sometime tomorrow morning, install my easter egg, then be on my way to return the disk.

Long live hacking!

Identity: the state or fact of remaining the same one or ones, as under varying aspects or conditions.
Identification: an act or instance of identifying; the state of being identified.

You see, your identity is who you are, while your identification verifies your identity. This is an important realization that many of us in the tech-world don’t seem to grasp when wishing to sign GnuPG keys of others.

Public key cryptography is a wonderful technology. It gives us the ability to create a system in which encrypting and decrypting files can be done with the compromising integrity of the encryption. GnuPG is a decentralized system that enables end users, such as you and I, to create a web of trust, bypassing certificate authorities. This is done by using your own private GPG key to sign the public key of another. The more signatures on that key, the more that key can be trusted. If those who have signed your key have a great deal of signatures also, then a web of trust is created, and trust strengthens. The deeper those signature levels can do, as well as the wider they can spread, on a single key, the more you can trust the person owning that key.

It has been a long-standing acceptance that when you wish to sign another’s public key, that you check a government issued form of identification, such as a drivers license or passport, so you can verify with their picture that they are who they claim to be. I have no objections with this. However, I would have also asked my own mother for her identification before signing her public key. Thanks to my coworkers, I’ve changed my view on asking for identification, and the change stems from a simple sentence:

All you kneed to verify is their identity, not their identification.

In other words, you are there to verify that they are who they claim to be, or their identity. What if it’s your mother? Cerntainly, you already believe her claim to be your mother. What about your wife? Will you put 10 years of marriage and trust second to checking her government issued form of identification? What about coworkers? Hopefully, your company has done the necessary identity checks, including possibly a background check, on the employee. Is checking his identification really needed? Especially if you have worked with him for a great deal of time?

Let’s look at the process of key signing, then the reason behind it. GPG key signing is a 3 fold process:

1. Verify that you have the proper key installed in your public keyring by asking them for the fingerprint of their key
2. Verify they are who they claim to be by verifying their identity
3. Sign their public key

Notice, that no where did I mention a government form of ID. Instead, I said to verify their identity. If it’s my wife, she’s already been identified. If it’s my coworker or boss, they too have already been identified. If it’s a close friend or relative, again, they have clearly identified themselves to me without a government ID. However, if I am not familiar enough with the person to establish a trusting relationship, then checking for their identification would be appropriate. Maybe I’m at a keysigning party, and I have never met any of the people there. Maybe I’ve done online conversations with the individual, but have never met him face-to-face. Asking for identification would be important. But if it’s a close friend, or acquaintance, asking for identification could be insulting to the established relationship, as trust should already be present. Verifying their identity is already accomplished. All I need to do is make sure I have the proper key installed by asking for the fingerprint of his key, then I can sign away.

See the difference? Asking for identification when trust has already been established is redundant, and unnecessary. The whole point of key signing is to establish trust. If trust exists, then asking for identification is not needed. What do you want to know from the ID? That they can drive? That they can leave the country and come back in? This breaks the traditional stance of keysigning, where regardless of the individual, you ask for identification. Well, long-standing traditions should be questioned for validity. Doing something, “because that’s how we’ve always done it”, isn’t necessarily correct.

I know some who will not sign a key without verifying identification, even if they have a long standing relationship with you already. I used to be one of these individuals. You want your key signed? Show me some ID. Now, after the brief, but intense, discussion yesterday, I’ve changed my position. Key signing is about building trust. If you trust the person already, what’s the point of asking for ID? If you don’t, your reasons for verifying the identity of the individual are warranted.

The trick is port forwarding. The idea is that a box will be listening for connections on a port that you specify. If a connection is made, the packets are then transferred through the SSH connection to the box at the other end on a different port that you have specified. So, the obvious is, you need access to an SSH server to make this possible. Let’s take a specific example.

I’m at work. The company mail server is not accessible from the Internet, so when I get home, I can’t read my corporate mail. One specific day during the week, however, I need access. I try to convince the network administrator to punch a hole in the firewall, or at least give me VPN access, but nothing. No ports open for tightest security is his approach. So, seeing as though I have access to an SSH server at home, I open an outbound port that will allow me to connect back in. In otherwords, piggy-backing off of the SSH connection to my home SSH server. I issue the following command from work, just before I leave:

ssh -R 22225:mail.company.com:25 -fN ssh.home.com

What is this saying exactly? It’s saying that the SSH server on ssh.home.com will be listening for mail traffic on port 22225. When a connection is made, the packets will be forwarded through the SSH connection to mail.company.com in the corporate office on port 25. As far as the connection is concerned, mail.company.com received a port 25 packet as if it came from the box internally on the corporate LAN. All I need to do, is launch my favorite email client that supports TCP proxies, and connect to ssh.home.com on port 22225 to make the connection. Simple as pie.

Let’s look at another example:

ssh -R 22222:foo.example.com:22 -fN ssh.home.com

This example is saying that the SSH server on ssh.home.com will be listening for SSH traffic on port 22222. If a connection is made, the packets will be forwarded through the SSH connection to foo.example.com in the corporate office on port 22. This is a great way to get SSH access to machines in the office that are not accessible to the Internet.

Cool, eh? Who would’ve thought that the developers of the most secure-by-default Unix, OpenBSD, would be providing me with simple tools to bypass firewalls?

Now, the question remains, what about the firewall? My only response- what about it? If you have an outbound Internet connection, your only task may be to find out what port is open for the outbound connections. If you have access to an SSH server that you can configure, then change the port on the SSH box to match your corporate outbound port, and you’ve effectively bypassed any and all firewalls that may be in place, both out an in. The only way, the ONLY way you can keep me from bypassing your firewall is to completely cut outbound connections to the Inertnet. Completely, and totally isolate the corporate network. Then, you have a impenetrable firewall.

So, as I mentioned earlier, “What goes out can come back in”.

First, a Freenode cloak and what a it is. When you connect to an IRC server, the server looks up your hostname, and if the servers are in round robin DNS, a server with the least load and shortest ping times is chosen. When connected, your nick, coupled with your hostname, provide a unique identifier for your connection. The only problem is, unless cloaked, anyone can see your hostname, and create a DoS attack on you personally. While rare, and isolated incidents, the exposure makes you vulnerable. Freenode cloaks solve this issue.

What is a cloak? A cloak hides your hostmak, which contains your IP address and/or domain name, keeping others from seeing where your IRC session is connected, and keeping you effectively secure from outside DoS attacks. For example, when you join a channel, your hostmask is displayed as follows:

21:25 -!- lamer [n=user@222.14.84.1] has joined #ubuntu

Here we can plainly see the user “lamer” and his IP address. While that might not be the IP address that he is located at, but rather just his IRC session, he is potentially prone to a DoS attack. Now, image that he was cloaked by Freenode staff:

21:25 -!- lamer [n=user@unaffiliated/lamer] has joined #ubuntu

We know his nick, as is needed to communicate with him, but we know nothing of his domain or IP address. A DoS attack on this user would be ineffective.

Unaffiliated cloaks are handed out with no strings attached. The user is asked to follow a few basic rules before the cloak can be given, but if they are met, they are handed out freely and willingly. However, it would be much appreciated if the user would financially donate to Freenode. Such users are given a special cloak, part of “project cloaks”. The following cloak would be applied if our user “lamer” above donated at the bronze level:

21:25 -!- lamer [n=user@pdpc/supporter/bronze/lamer] has joined #ubuntu

This cloak is a special cloak that can be worn with pride showing that you are helping Freenode keep up with necessary server maintenance and general overhead. There are many other cloaks that can be applied, if you are involved with a certain project. Ubuntu has such cloaks for approved members, which you have probably seen around the network:

21:25 -!- lamer [n=user@ubuntu/member/lamer] has joined #ubuntu

There are many, many other project cloaks that can be applied, such as Gentoo development, Wikipedia editing and even cooking. Regardless of the cloak, your domain/IP is hidden from the users on the network, effectively killing any chance for a personal DoS attack. If anything else, they look cool and show your involvement with a specific project.

Now, I’d like to move on to another topic, effectively securing your connection even further. The topic is avoiding a specific router exploit called the DCC exploit. Rather than go into the details of how it is executed, the DCC exploit is troublesome for large channels, as it causes massive quits from the channel, effectively flooding the channel. Large channels are getting better, and most routers have patched the bug through firmware updates, but there are still users that are being affected.

What happens in most channels, is if you are affected by this exploit, then usually you will be temporarily banned from the channel until you either patch your router’s firmware, or connect to Freenode on a different port. While patching your router’s firmware should be your first priority, it definitely isn’t the easiest, and you could end up with a dead router if executed poorly. The easiest way to patch this bug is to connect to Freenode on port 8001 as the exploit only affects users on port 6667. Check your IRC client’s documentation on how to connect to servers on different ports.Check your IRC client’s documentation on how to connect to servers on different ports.

These two tools secure your connection on Freenode, making it pretty difficult to remove you from the network unless you’re Freenode staff. While your connection is not secured via encryption, and still in plain text on the wire, unless connected to Freenode’s hidden service via tor, you can rest assured that you’ll stay connected, given the fact that you have a stable ISP.

I would HIGHLY recommend taking full advantages of these two services: acquiring a cloak, and connecting on port 8001, if you spend any amount of time on Freenode. Join #freenode for further information regarding these topics.

First, I’m not sure if you are aware, but in your ~/.ssh/config file, you can specify all the servers that you connect to, with their associated port (being that they are running SSH on a non-standard port other than 22). This makes it easy on the typing when sitting at the shell. For example, rather than type this:

aaron@hercules:~$ ssh -p 22222 aaron@some.remote.server.com

I can add the following to my ~/.ssh/config file:

Host some.remote.server.com
Port 22222

Now, I just need to type:

aaron@hercules:~$ ssh aaron@some.remote.server.com

Very nice. Of course, there is a lot more you can put in your SSH config file, and you can have multiple hosts with their associated ports in the file as well. If you look at your /etc/ssh/ssh_config file, you can see a much broader range of options that can exist in your ~/.ssh/config.

Next in line is your SSH keys. You can setup your SSH server to allow key-based authentication rather than the traditional user/password. Which means, that rather than enter your password every time you try to connect to a remote SSH server, you can have your SSH key authenticate you automatically. First, you need to generate a key:

aaron@hercules:~$ ssh-keygen -t dsa

Enter a passphrase for your key, and give it the name of the file to save it to (default is fine). Now that you have a DSA SSH key generated, we need to get that key on the remote server, so we don’t have to type our password all the time. So, this is where a really cool tool called ’ssh-copy-id’ comes in. ssh-copy-id is just a script that makes an SSH connection to the remote server specified, secure copies the newly generated key over and appends it to ~/.ssh/authorized_keys. For example:

aaron@hercules:~$ ssh-copy-id -i .id_dsa.pub aaron@some.remote.server.com

It will ask for the user password just once, as you need to verify you are who you say you are. When entered correctly, the key is copied over and appended. You need the ‘-i’ to take your identity with you. This isn’t always needed, but type it anyway in good practice, as it will never hurt anything. Now, when logging into some.remote.server.com, you won’t need to worry about entering your password. The server will look at the SSH keypair, and if they match, you’re set. You should, however, add your SSH identity before connecting, otherwise, you’ll always be prompted to enter your SSH key passphrase. This can easily be done with:-

aaron@hercules:~$ ssh-add

Now, you’ll be asked for your passphrase once. Your SSH identity will be added to the keyring, and you can SSH to the remote server as many times as you like, save your identity is saved in the keyring. Gnome provides this keyring by default, so, if you stay logged into Gnome, so will your SSH identity. As soon as you log out and then back in, you’ll need to re-add it.

So, there you go. Two simple tips to get your OpenSSH behaving the way you want, and with ease. Key based authentication is the only way to go, definitely if developing on the remote server with SVN+SSH. Your password can be a major problem.

1. Gaim
2. Kopete
3. Gajim
4. Gossip
5. aMSN

I look at those clients, and recognize that there isn’t a single standard between any two of them for encrypting your messages. There are just too many options:

• gaim-encryption: Only works with Gaim, or clients implementing the Gaim code.
• otr: a good alternative, working with Gaim, Adium for Mac and Trillian for Windows, but not available for other clients.
• otr-proxy: probably a better alternative than it’s parent, allowing any IM client that can utilize a proxy access. However, at the moment, it only works for AIM and ICQ protocols, alienating many users.
• GnuPG: In my opinion, the best alternative using your personal GnuPG keypair, but, only implemented in Gajim and Psi.

I’m sure there are other options, but I think the point is made. I should be able to choose any IM client, and encrypt my traffic with a standard spec that is implemented across the table, regardless of which client my friends choose.

As mentioned, I personally favor using my private and public GnuPG keypair. To me, that just makes sense. Why keep track of two keys, one for IM, and the other for everything else? But, I would be willing to see otr or otr-proxy as the standard as well. The point is just setting the standard, then implementing it across clients.

As such, here is another poll. Should an encryption standard be set, regardless of IM client or protocol, given the information that I outlined here?

I should mention that I use Jabber as my means of IM communication. Jabber, by default, implements SSL/TLS. So, my traffic is already incrypted on the wire with my friends. However, can I trust that the Jabber server I or my friends connect to are not decrypting and logging the chat sessions? Something to think about.

I have to say that some really interesting solutions came in regards to my problem. Encrypted loopback filesystems, smartcards, splitting the key, and others. I don’t think my solution is superior. Actually, I really like splitting the key that Daniel Silverstone came up with. Trully genius. However, my solution was the best that I could come up with, and probably fairly obvious. So, at any rate…

The solution I came up with allows me to keep my GPG key on one computer at home, with the other two taking advantage of that PC. Here’s what I did to solve the problem:

1. Recognize that I have an SSH port open for remote access.
2. Secured the SSH port a bit by completely disabling username/password authentication, root logins and, of course, obscured it by moving the default port off of 22.
3. Generated SSH keys, using a strong cryptographic passphrase, following this tutorial.
4. Appended the public keys to ~/.ssh/authorized_keys on the remote server.
5. Installed, and configured, following this tutorial, SSHFS.
6. Restarted the remote SSH daemon.
7. Wrote an alias to mount the remote SSFS .gnupg directory to my local .gnupg directory (using compression).

With this, I use the Gnome SSH agent, that is already running, to add my local public SSH key to the agent. Then, with that added, after entering my passphrase, I run the alias I created earlier to mount the SSHFS to my directory. Now, I can use KGpg, Enigmail, and pretty much anything GPG-related on my local machine using my GnuPG key as if it were running locally, and yet take advantage of the remote SSH key. The only thing is, as it is running through SSH, it tends to be a bit slow for encrypting, decrypting and signing. However, I only need to keep one copy of my GPG key, and I can keep it where I know that it is secure. So the decrease in speed performance is worth the saftey and integrity of the key.  Also, I only need to run the process of adding my key to the agent and mounting SSHFS once, which is nice.

DISCLAIMER: Because I mounted SSHFS using public key authentication, the mount exists as long as I stay logged into my box, or if I unmount it using fusermount -u. This could pose a threat, if anyone has access to my workstation. As such, when leaving the computer, I need to remember to lock it every time, or logout. Not keeping in this practice of locking my workstation or logging out, could compromise the key. However, when logged out, the agent dies, thus losing the key in the agent, and unmounting the SSHFS, which means my private GPG key is no longer on the computer. So, either I need to lock the workstation, or logout every time I leave the PC. Fortunately, this is in standard practice with current behavior, so it won’t be a problem.