[ Site Index] [ Linux Index] [ Feedback ]
Cryptography is the science of making your data unreadable to other people in a reliably reversible manner. Originally the tool of spies laboriously poring over code books and cipher charts, cryptography has become essential in the computing field because computers let us compile and move around large amounts of data -- and let bad guys read it with great ease.
First, let's set a couple of misconceptions straight. All operating systems support cryptographic operations; there's nothing magical about it. You can perform public key cryptography with nothing more than a deck of cards, a pencil, and paper: computers just make the whole process a lot less tedious. Secondly, propaganda to the contrary, terrorists don't use cryptography or the internet in planning their attacks: if Osama bin Laden's kamikazes had been emailing encrypted plans back and forth it's highly likely that the NSA would have noticed the unusual traffic and consequently wouldn't have been taken by surprise. This article isn't about enabling Shopper readers to go out and plan criminal atrocities. Rather, it's about sensible ways of securing your data, verifying that the people you send and receive email with are who they say they are, and ensuring that if your laptop is stolen the thief won't be able to read all your company's plans.
Cryptography is essential to all UNIX systems (including Linux) because they are, by design, multi-user computers. Data belonging to one user shouldn't be accessible to another. When you type your password into a Linux system to log in, you are using cryptography: passwords are stored in an encrypted format in the /etc/shadow file, so that ordinary users can't read each other's password. The login process encrypts your password when you type it, and compares it to the stored, encrypted copy. If they match, you're in.
This use of encryption is termed "authentication"; you have a secret identifier (the password) which is shared with the computer, and by presenting your identifying token to it you can confirm that you are who you say you are. Encryption is used to cloak your copy of the shared secret, to prevent eavesdroppers from catching your authentication token and subsequently masquerading as you.
We've therefore got two tasks that encryption is used for: concealing data from intruders, and protecting authentication mechanisms that verify our identities. (As the old saying goes, "on the internet nobody knows you're a dog". Authentication becomes critically important when you're dealing with computers, as opposed to people who know you by sight.) A third use of encryption is to secure communications channels between computers. It's not much use to use encryption to cloak your password if you type it over a telnet connection -- which is unencrypted and vulnerable to network snooping.
Password, Password, burning bright
Your password is an authentication token; it's supposed to be secret (unlike your user name), and this is supposed to prevent strangers from getting access to your machine. (The same goes for the root password, only in spades.)
Unfortunately, it is possible to try and log in as somebody else by guessing their password. A startling proportion of users pick their first name, their spouse or children's first names, their birthday, their phone number, 'jesus', 'aaaaa', 'superstud', ' ' (yes, blank spaces), or some other identifier from a list of about twenty common 'idiot passwords'. A larger number use a dictionary word -- something that is memorable for some reason. A tool such as Crack along with one of the large dictionaries of password candidates circulating on the net (such as this one) will allow a determined cracker with a copy of your system's password file to identify users with weak passwords by mounting a 'chosen plaintext' attack -- that is, to serially encrypt a bunch of possible candidate passwords and compare them against the encrypted passwords stored in the system.
A minimal defense against this sort of attack is to use shadow passwords (passwords stored in /etc/shadow, rather than in /etc/passwd as is traditionally the case); this is standard on most Linux distributions these days. A secondary defense is to switch on password checking. There's a copy of crack built into the 'passwd' program (which lets users change their password), and it can be configured to reject weak (easily guessed) passwords and to insist on regular password changes.
However, even if your password security is fine, you may be at risk. Telnet and rlogin can be used to give you a text console on a Linux system, from which any task can be carried out. These protocols are unencrypted; if you type your password in via a telnet session, even though you can't see it on screen it's being transmitted in plain text, so a bad fuy with a packet sniffer can subsequently use it and masquerade as you.
You can prevent this happening in two ways. Firstly, you can use an encrypted login session (see "Ssh, it's a secret" below); your password will be encrypted (along with everything else you type). Secondly, for really, really secure systems you can use a one-time password system based on S/Key.
S/Key (and relatives) replaces the standard "enter your login; now enter your password" style of dialogue with a different one. When you enter your username, the S/Key login process prints a challenge (an eight digit number). It's your job to feed the challenge number to an S/Key client, which also takes your secret password as input. The result is another number, which you type in as a response. The server then verifies that the response is correct. Each time you log in, the challenge number changes, because it's being generated each time using a one-way function: the S/Key system keeps track of how many time's you've logged in and forces you to generate a new secret regularly. The S/Key client is a small program that you can run on a Palm Pilot, an HP scientific calculator, a PC, or a dedicated CryptoCard (that looks a bit like a pocket calculator); the benefit of this system is that a replay attack (in which the attacker replays the network packets you sent to the system you're logging in at) won't work because the same password challenge is never seen twice.
S/Key isn't a standard component of Linux, but can be compiled and installed on Linux systems where security is a priority -- quite a few ISPs use it for their core servers (which administrators may have to log into over the public internet). You can find the S/Key source distribution at Bellcore or in the Munitions cryptography archive.
Alternatives to S/Key exist, including the more recent SRP. SRP, the Secure Remote Password protocol, looks superficially similar to S/Key; the big difference a user will notice is that there are two challenge/response cycles. But behind the scenes, rather than relying on a shared secret, the client and server are using public key cryptography to authenticate themselves to each other. The first challenge/response is used to exchange some transient data which is then encrypted using both sides' private keys and returned to the other side, so that they can verify the identity of their correspondent using a copy of their public key. The protocol is described in this paper; suffice to say that it's more secure against certain types of attack than S/Key, albeit more laborious.
However, a crucial point to remember when thinking about advanced password authentication systems is this: as Bruce Schneier notes, "all authentication does is certify to the server that the client computer is what it says it is". If you're authenticating yourself using SRP-3, someone can still steal your Palm Pilot with the private key on board; it's just like stealing your front door keys. And if they subsequently use it to log in and masquerade as you, the damage could be more serious than if your business is using an ordinary password system, precisely because we tend to trust strong security systems more. In the long term, the only really secure login system is one that uses biometric information (fingerprints, voiceprints, DNA fingerprinting, and so on) ... or a guy in a blue suit with a bunch of keys standing outside the terminal room door.
Securing files: PGP and GPG
PGP should need no introduction; Pretty Good Privacy, created by Phil Zimmerman in 1992 or thereabouts, has become the de-facto public key encryption tool. The principle of PGP is that you use highly secure public-key encryption (specifically RSA or IDEA) to protect the key for a faster (but not so secure at the key exchange level) symmetric stream cipher. This is then used to encode or decode files. The public key protocol in PGP can also be used to digitally sign messages (ensuring that anyone with access to the signer's public key can verify that they and only they created the file, and nobody has changed its contents). In conjunction with an email client that can invoke PGP on the contents of a PGP-encrypted attachment, this provides a security layer for email.
Because PGP is a public key cryptosystem, a lot of thought went into how PGP decides whether or not to trust a public key. (See "PGP, GPG and the web of trust" below.)
While PGP was originally open source software, PGP Inc was bought out a couple of times and is now owned by Symantec. To ensure that the facilitiies of the free PGP system remained available, an IETF standard for encryption using the PGP protocols was created. Now most free operating systems ship with GPG, GNU Privacy Guard -- which just happens to be a free software implementation of the OpenPGP standard outlined in RFC2440.
The user interface of GPG is essentially identical to that of PGP 2.6. Note that GPG is not compatible with PGP 2 -- PGP 2 uses the IDEA algorithm, which is patented, and the GNU implementation is intended to be free of such encumbrances. You'll probably find the raw command-line version of GPG less than useful; however a number of GPG graphical front-ends exist, including GPA (the GNU Privacy Assistant), kPGPCrypt, or GPG Keys for KDE, although they're primarily aimed at securing your keyring and helping you with encrypted email rather than simply locking up files.
If you're planning to use PGP to encrypt individual files, you can be fairly sure that they'll be hard for anyone to open -- as long as they can't get their hands on your private key. Key management is critical to the safe running of a public key encryption system, and if you're going to run PGP you must read the manual (or the O'Reilly and Associates Nutshell guide to PGP)! I can't stress this too strongly: if you don't secure your keys correctly, all GPG will do is give you a false sense of security. And you don't secure your keys by leaving them on the same filesystem as your data, with a passphrase set to "STUDMUFFIN".
Ssh, it's a secret
As noted earlier, telnet and rlogin let you interactively type commands that essentially give you full control over a UNIX system. But these protocols are insecure. Given access to the same ethernet backbone that the server is attached to, a bad guy can run a packet sniffing application that will filter out all telnet or rlogin packets going to or from the server -- and they'll be able to read your password as you type it. Even if you use S/Key or SRP-3, they'll be able to see what you're reading and writing on the machine -- which is often as useful to an attacker as being able to obtain a root password.
The way to deal with this problem is to abandon telnet and rlogin as fast as possible and switch to ssh. Ssh, developed originally by SSH Communications Security of Finland, is two things: an internet protocol and a piece of software (just as telnet and ftp are both protocols and programs that use those protocols).
The ssh protocol defines a mechanism similar to telnet that allows for a client program to talk to a server using encryption. The ssh programs provide tools that do this, allowing you to log into an ssh server using an encrypted connection, transfer files via encrypted sessions (using scp, secure copy, or sftp, secure ftp), run an X11 desktop session on a remote server that is securely encrypted, wrap any type of TCP/IP session you want up in a secure encryption layer, and manage encryption keys for ssh connections.
Like PGP, ssh uses public key encryption to set up an exchange of symmetric keys that are used by the much faster encryption algorithm used for the actual interactive session. If you place your public ssh identity (key) on the server, you can do away with password-based logins entirely: you authenticate yourself to your local ssh client (by entering the passphrase to your ssh keys), and the client then authenticates you to the server (using the public ssh key you placed on the server). The weak point in this system is that you have to physically send ssh keys to all the machines that you want a guaranteed-secure connection to; but if you do this, you've got a system that's nearly as strong as Kerberos (see below) and that provides authentication and encrypted login and session services. Even if you don't physically move your ssh keys onto the server, a server that uses S/Key or SRP in conjunction with ssh (for encrypting the interactive sessions) is probably about as secure as anyone needs to go.
Like PGP, SSH is a commercial product although an early version was made available in source form for non-commercial use. The OpenBSD project picked up the old SSH sources and stripped out all proprietary content, then re-wrote the protocol back into it; the OpenSSH package is now the standard form of SSH used by free operating systems. (If you are using a recent Linux distribution, OpenSSH is almost certainly installed on your system.)
In a nutshell, use ssh wherever you would use telnet or rlogin -- and stop using the older protocols wherever possible. They're insecure; ssh isn't. It's as simple as that.
losetup, loopback, and encrypted filesystems
Encrypting files or encrypting a login session is all very well, but what if an attacker gets their hands on your hardware? The answer used to be "you're up shit creek without a paddle" -- but this has been changing lately. In particular, it's possible to encrypt your entire filesystem so that someone who steals your computer won't be able to get at the files without knowing (or guessing) a passphrase.
The way it works is this: on Linux (and other UNIXes), every piece of hardware is represented by a file; you get data from a peripheral or send data to it by reading/writing its corresponding file (or device node) in /dev. This includes hard disk partitions, where filesystems (equivalent to the Windows C: drive or D: drive) are located. It was a short step from using a device node that looks like a file, to using a real file, to store a filesystem; and since kernel 2.0 it's been possible to do just that. You can create an empty file of, say, 1000000 kilobytes, using the dd command like this:
dd if=/dev/zero of=/tmp/my_new_filesystem bs=1024 count=1000000
Which reads from /dev/zero -- a source of empty bytes -- and writes a file called /tmp/my_new_filesystem consisting of 1000000 blocks of 1024 bytes each. You can then format your "filesystem":
/sbin/mke2fs /tmp/my_new_filesystem
And mount it:
mount -o loop /tmp/my_new_filesystem /mnt/loopback
(This makes the new filesystem show up under /mnt/loopback, assuming a directory of that name exists). We refer to these filesystem as "loopback" filesystems because, rather than occupying real hard disk space, they "loop back" and point to a file.
In addition to mounting the filesystem-containing file directly, we can associate /tmp/my_new_filesystem with a kernel device node called /dev/loop0 like this:
/sbin/losetup /dev/loop0 /tmp/my_new_filesystem
Thereafter, access to /tmp/my_new_filesystem goes through any device drivers associated with /dev/loop0 -- for example, by invoking losetup with a kernel module as a parameter:
/sbin/losetup -e blowfish /dev/loop0 /tmp/my_new_filesystem
Modules -- such as the blowfish module -- are provided that allow the kernel to do streaming encryption and decryption on a block device. So this tells the kernel to apply blowfish encryption/decryption to a filesystem stored in the file /tmp/my_new_filesystem.
SuSE 7.2 and newer distributions (and Redhat 7.3 and later) include support for encrypted filesystems. When you designate a partition as containing an encrypted filesystem, the system administration scripts create a large empty file in it, use losetup to connect it to a loopback device via an encryption layer, and format it; thereafter you have to enter the correct password at system startup time or the filesystem will remain inaccessible. If you're using a distribution that doesn't include scripts for encrypted filesystem support, you can add it by hand: details of the losetup command are given in the man page for losetup(8), and the actual encryption code is part of the Linux kernel itself.
One use of the encrypted loopback filesystems that bears mentioning is key management. If you use PGP or ssh, your keys are your identity -- someone who gets them can masquerade as you. But you can set up a laptop (or a PC) to automatically mount and unmount an encrypted filesystem stored on a CF card or Sony Memory Stick, or similar. Such a system can be quite small, and strongly encrypted -- and you can keep your personal keys on it, for use at the desktop or in your laptop. Just treat the small carrier like your front-door keys. Mount the encrypted filesystem on it under ~/.pgp or ~/.ssh whenever you need to use them, and keep it in your wallet the rest of the timek that way, if somebody makes off with your machine, they won't have stolen your signature and your identity in the process.
PGP, GPG, and the web of trust
Using PGP or GPG to secure your personal files is all very well, but if you want to use one of them to send and receive encrypted email you run into a major issue. How do you know that the encrypted mail you received from Bob was actually sent by Bob himself? Sure you've got his public key -- he emailed it to you! But what if it was in fact sent to you by the evil Fred, who has grabbed Bob's outgoing mail and substituted Fred's own key for Bob's? If you reply with your own public key, Fred will get it, and then he'll be in a position to listen in on both sides of your encrypted conversation (a so-called "man in the middle" attack).
If you want to use GPG in email, you face a problem: who do you trust? Someone can put their GPG public key on a website, but how do you know whether it's genuine or not? The answer is to use digital signatures and a web of trust.
Consider handshakes. How many handshakes are you away from Tony Blair? Or Margaret Thatcher? Or Adolf Hitler, or Bill Clinton? The odds are that the number is between one and five -- surprisingly few! This is because most people know a wide circle of friends, and several distant acquaintances -- distant parts of the network are connected, short- circuiting the apparent distance between people. (It has been estimated that no two on earth today are more than nine handshakes apart.)
You may not have met your correspondent Bob, but you've met Chuck, and Chuck has met Bob. Not only has Chuck met Bob; Chuck has used GPG to digitally sign Bob's keys, certifying that Chuck believes them to be valid. You, in turn, have a copy of Chuck's key that you trust, because he gave it to you himself. It follows that you can check Chuck's signature on the key that purportedly belongs to Bob, and this will tell you if it's genuine or not. You, Bob, and Chuck all exist in a "web of trust" -- A trusts B's key, B trusts C's key, therefore A can trust C's key. And by the handshake analogy, nobody who uses PGP is ever more than a few digital handshakes away.
One of the core concepts that most beginners miss with GPG (and PGP) is that the program is actually a database, designed to keep track of other people's public keys. When you receive a key in the form of a text file, you import it into your GPG database (either with the 'gpg --import' command or using a front-end such as GPA, the GNU Privacy Assistant). You can then assign a trust value to it by editing the key -- indicating whether you know the owner and they gave it to you in person printed on a parchment scroll, or whether it's just something you found on a website somewhere. Keys are annotated with the identities of the people who have signed them. For a longer discussion of the web of trust and key signing, see the manual (and be sure to read it properly before you start using GPG for email!).
In a business setting you may be able to centralize everybody's public keys on, say, a CDROM, and pass copies out by hand. Life gets a bit harder if you need to deal with strangers. To make things run smoother, there exist public key servers that you can go to and place your public keys on; they act as clearing houses that enable you to search for and retrieve keys for people you need to communicate with. You can tell your copy of GPG to send your keys to a key server by using the --send-keys command; you can also retrieve the public keys for someone whose message you're decrypting with --recv-keys, which searches the keyservers for the public keys matching the sender's ID.
stunnel -- encrypting internet connections
Ssh provides a way of running a remote login session via an encrypted connection. You can also use ssh to forward a connection on one port to a different port on another machine running an ssh server -- for example, to divert connections to your local machine on port 110 (POP3) to a remote machine on port 995 (the port for SSL-encrypted POP3 communications). This port forwarding encrypts the data at the same time; you can use it to provide encrypted X11 sessions over the public internet, or to collect your email, by way of example. But it's not the only tool in the arsenal for letting you connect two computers via an encrypted link. Probably a better tool for this job (wrapping an encryption layer around an arbitrary pre-existing TCP/IP connection) is provided by stunnel, the secure tunnel server.
stunnel provides SSL encryption (the same variety used for secure web sessions) for network servers. You can use stunnel in conjunction with inetd, or a standalone server program, to provide encryption around POP3, IMAP4, SMTP (mail) and NNTP (news) connections. If you have an SSL-aware client program (like Netscape Communicator or Mozilla) you can then use these services.
On a broader scale, you can tunnel PPP packets over the public internet via stunnel. This technique can be used to build a VPN (virtual private network). First, you establish an stunnel-wrapped PPP connection between your client machine and a server running pppd. Then you start using the client PPP connection as your default network gateway. Thereafter, all your traffic -- whatever port it's running on, and whatever destination it's intended for -- is forwarded via the encrypted SSL connection to the server system.
Note that SSL-based servers require a site certificate in order to authenticate themselves to the client. If you're going to use stunnel to maintain a VPN within your company, you can generate your own certificate -- but if it's going to go public, you will need to get your certificate signed by Verisign (who currently occupy an effective monopoly as the sole public certificate authority).
Stunnel isn't the only tool for creating VPNs that you can use on Linux. There's a full-blown HOWTO describing how to manage VPNs on Linux which focusses on the use of ssh; meanwhile, the Linux kernel includes support for Microsoft's PPTP tunnelling system and CIPE, Cryptographic IPx. CIPE was invented specifically to address problems associated with running tunnels over ssh or SSL.
In a nutshell, if you tunnel a TCP/IP layer (such as a PPP connection, carrying your VPN) over another TCP/IP based connection (such as ssh), you can run into serious performance problems; TCP/IP wasn't designed to be nestable, and under some circumstances the upper layer of the two can end up queueing up failed packets for retransmission faster than the lower layer can deliver them. CIPE uses encrypted UDP packets (with no retransmission and no vulnerability to this type of congestion) and is designed to be fast and lightweight. However, you should note that CIPE is still in development and prone to change.
What tools come with a standard Linux distribution?
Linux distributions from the USA prior to 1999 came with very limited cryptography support; this was because US export rules classified tools like PGP as munitions and made it an offense to export them.
Since 2000, all Linux distributions have shipped with extensive cryptography support. You should be able to find copies of OpenSSH, GPG, and related tools already installed on your system. SuSE 7.2 and later, and some other recent distributions, are configured to provide encrypted filesystems at install time.
If you're looking for encryption tools for Linux, a good first stop is the Munitions archive and other mirrors contain roughly 200Mb of UNIX and Linux encryption tools, including S/Key, SRP-3, GPG, and a slew of other utilities that duplicate the functionality of the ones discussed in this feature.
One fact can't be over-emphasized: if you use encryption tools without understanding how they're meant to work, you run the risk of exposing your most important secrets in public. You should therefore ensure that you read the manuals before using the software, and for general background reading it would be a very good idea to read at least two books: "Practical UNIX and Internet Security (2nd edition)" by Simson and Garfinkel (pub. O'Reilly and Associates, ISBN 1-56592-148-8), and, if you're feeling brave, "Applied Cryptography (2nd edition)" by Bruce Schneier (pub. John Wiley & Sons, ISBN 0471117099) -- the definitive publicly available text on the theory and practice cryptography.
What is the legal status of encryption?
Encryption used to be a matter of interest only to banks and governments: it is only since the advent of the internet that it has really become relevant to the rest of us. This is because for the first time it has become possible to scan huge volumes of network traffic for keywords or data from known individuals; most people don't appreciate that their business email, when it is sent in plaintext, is about as secure as a postcard.
Because encryption tools used to be a preoccupation of the military, their legal status tended to be ambiguous. Until 1998, the US government classified tools such as PGP (regardless of its status as open source software) as munitions, in the same category as missiles and guns for purposes of requiring export licenses. Since then, a more reasonable attitude has prevailed -- but encryption still tends to give rise to appallingly broken pieces of legislation.
One such law is the Regulation of Investigatory Powers Act (2000), in force in England and Wales. This law ostensibly allows the police to requisition your encryption keys; if you refuse to hand them over you're liable to spend quite some time in pokey. It also provides for the police to serve an order on you for disclosure of the contents of electronic communications. The trouble is, the drafters of this law evidently didn't understand how public key encryption works: it is possible to have a key that allows you to encrypt a message, but to not posess the corresponding ability to decrypt it. Furthermore, posession of a public key for someone's GPG messages confers upon the posessor the ability to masquerade as that individual: it's an authentication tool, not just a way of locking up files.
Luckily the law provides a loophole, if you can prove that you genuinely don't have the ability to decrypt a message. But the onus is on the accused to prove this, and the implication of allowing the police to requisition keys probably goes far further than the lawmakers intended.
The bottom line with cryptography is: you're allowed to do it, on government's sufferance. If they think you're doing something dodgy, they can order you to hand your keys over and make life unpleasant if you refuse to cooperate. "If you're innocent, what have you got to hide?" is the question you can expect to be asked. (The answer "I don't want the postman to read my confidential email" is evidently not well understood by the Home Office.) For more information on this worrying trend in government, see Cyber Rights and Cyber Liberties.
[ Site Index] [ Linux Index] [ Feedback ]