This talk by Peter Billam of P J B Computing was presented to the 1997 Summer Seminar of AUUG Tasmania on 19th Feb 1997.
This talk discusses some serious weaknesses in traditional computer security, and some new tools based on strong encryption, such as ssh and pgp, which address these weaknesses. It then describes the different way you have to set up your computer in order to realise this improved security, and a migration path which allows you to work in this way within an established, less secure, site, whether you are a user or just the System Administrator.
Back when Unix was invented, in the days of Minicomputers and Terminals, each user had a private length of serial wire leading to a multi-user computer; the interior of the computer was a relatively public place. Thus the password is kept on the computer in encrypted form, and transmitted down the wire in plaintext.
Nowadays, the wire is a public resource, and yet people still transmit passwords down it in cleartext. This is completely inappropriate behaviour.
Usernames and Passwords provide only weak authentication; adequate to encourage normal operating procedures within a co-operative environment, but not to enforce security.
Now imagine that as a result of your actions as a System Administrator, a loop of trust exists, such that computer A trusts computer B, computer B trusts computer C, and computer C trusts computer A.
Is computer A secure ? well, it depends on B; is B secure ? well, it depends on C; is C secure ? well, it depends on A. So is computer A secure then ? Well, you don't know; they might all be secure, in which case they're all secure, or they might all be insecure, in which case they're all insecure. What you have constructed, as a result of your actions as a System Administrator, is a bi-stable, which could be in one of two states, but you have no way of knowing which state it might actually be in.
Loops of Trust are a Bad Thing, which you must eliminate if you wish to know your security status.
Inherently vulnerable to uid-spoofing:
NFS, rsh, rlogin, rcp.
Inherently vulnerable to password-snooping: telnet, SNMP, ftp.
Inherently vulnerable to IP-address spoofing: NFS, DNS, NIS.
Inherently vulnerable to password cracking: NIS.
Inherently vulnerable to session hi-jacking: telnet, ftp, rlogin.
Inherently vulnerable to e-mail bombs written in WordBasic: Microsoft Word6.
A few years ago, on the other side of the router was a fairly civilised environment, like a University corridor.
These days it's Street-Level at best; at worst it's a War Zone.
The user generates a pair of keys, one public and one private. Crucially, the mathematics are such that although the two keys are uniquely related, there is no way of deducing the private key from the public key. The relationship between the keys is such that a message encrypted with the recipient's public key, which everyone knows because the recipient has published it, can only be decrypted with the corresponding private key, which only the recipient knows. This encryption functions as a (highly opaque) envelope.
The same process will also run backwards; if the sender encrypts a message with his own private key, which only he knows, everyone else can decrypt it with the senders public key, and thus verify that the message must have come from the sender. This encryption functions as a (unforgeable) signature.
See PGP, Simson Garfinkel, O'Reilly books.
Courtesy of Phil Zimmerman. Provides Public-Key (and also secret-key) encryption, but not the means of transmission; so first you encrypt, and then you send the encrypted data by some pre-existing channel, typically e-mail. Various front-end menus and interfaces to existing mail clients are available. PGP provides a means of certifying (signing) the keys of people you know, thus building up a web of keys known to correspond to real personal identities.
Some commands you'll need to know (on Unix or DOS) are:
The magic files are (by default) $HOME/.pgp/secring.pgp, where your secret key is kept, and $HOME/.pgp/pubring.pgp, which is where all the public keys of everyone you correspond with are kept.
See PGP, Simson Garfinkel, O'Reilly books, and also comp.security.pgp.announce. Available from ftp://ftp.cc.adfa.oz.au/pub/security/
Courtesty of Tatu Ylonen, ssh provides drop-in replacements for rsh, rcp and rlogin, which use strong encryption and authentication in a very transparent way. Both the host and the user have key-pairs and are strongly authenticated. Nifty features include automatic setting of $DISPLAY, automatic Xauthority, general port forwarding, compression of all network traffic.
The server runs a daemon sshd which listens on port 22.
Some client commands you'll want to know are:
The magic files are $HOME/.ssh/identity, which is your secret key, $HOME/.ssh/identity.pub, which is your public key, $HOME/.ssh/authorized_keys, which is where you keep the public keys of all the users on all the hosts that you wish to allow to log in as you, and $HOME/.ssh/known_hosts, which is where the public keys of all the hosts you log in to are kept.
The corresponding files for the host are /etc/ssh_host_key, which is the host's secret key, /etc/ssh_host_key.pub, which is the host's public key, /etc/known_hosts, which is where the public keys of all the publicly known hosts are kept.
See also comp.security.ssh, and the FAQ at http://www.uni-karlsruhe.de/~ig25/ssh-faq/.
Someone is coming in over the network. Who is it ? Criteria for Computers to authenticate Humans can be sorted into three classes. A good authentication procedure uses criteria from more than one of these classes.
So to do the "Something you Have" method, it looks like you're probably going to need a trustworthy computer anyway.
A trustworthy host in a site allows loops of trust to be broken.
Computer A is trustworthy if it trusts no other host, so that the answer to the question "is computer A secure ?" is "Yes, regardless of whether any other computer, such as B, might be secure".
There must be at least one trustworthy host at each site, so the System Administrator has a base from which to distribute configuration information, or check the integrity of other hosts. Other hosts can then avoid falling into a Loop of Trust by trusting only the Trustwothy Host.
However, a site can have more than one Trustworthy host; in practice each System Administrator should run one, and indeed every user can have one.
If the intruder has physical access to your computer, you (the defence) are lost anyway. The real guru knows that the quickest way to erase a disc is with a hammer ! Within the Site Perimiter, you can concentrate on defining normal operating procedures; don't waste time trying to enforce security against physical access.
Don't worry about physical access to your computers as a threat; look on it as the crucial advantage that you have over malevolent intruders by virtue of the fact that you own the computer and they don't. You can switch the machine off and on, you can insert a CD into the drive and boot from it, you can press ESCAPE during reboot, or Stop-A or Ctrl-Alt-Del while running; no outside hacker, however expert, can do these things.
Security comes from the leverage you can generate from your ownership, your physical access. For example, you can then put some Secret Keys on your computer.
A host which has recently been rebuilt from CD, and has since then run only in single-user mode and/or offered no services to the network, is trustworthy. It can be maintained in a trustworthy state by not executing any program coming from outside.
If any outsider is able to program the computer, (in sh, perl, machine code, DOS Batch, WordBasic, or whatever) then the computer loses its trustworthy status. A few year's work experience in a Kosher kitchen would be an advantage; there are rules to be kept, and if ever one is broken, the machine must be re-built.
These are some of the rules which ensure that no outsider gets access to any programming language . . .
Your trustworthy host containing your HOME directory will probably have to interwork in a site which has insecure infrastructure. This poses a whole series of practical system administration questions relating to files like ~/.forward, ~/.afpvols, and functionality questions relating to your access to the facilities of the site. Here is one way to do it . . .
Assume you come from a site where you have an NFS, automounted HOME called /home/bloggs, and use YP passwd and group maps and YP automounter maps, so it's about as bad an environment as you could devise. Probably pretty typical, though.
So . . . your trustable host runs no nework daemons at all. No inetd, no nfsd, no telnetd, no tftpd, not even sshd; refuses connections on all ports. On this machine, have an /etc/passwd entry putting your $HOME there on local unexported disc. This local $HOME contains your secret keys, such as ~/.ssh/identity and ~/.pgp/secring.pgp; the other hosts can't see it. For convenience, it can also contain ~/home which is a symlink to /home/bloggs, your site-wide NFS home.
/home/bloggs/.ssh contains only authorized_keys, not identity, so the sshd's running on the other site hosts allow you to ssh everywhere and do what needs to be done outside your home machine.
For mail, either
In effect, this uses the default insecure home directory to broadcast your public keys, while keeping your secret keys in your real home directory on unexported local disc. It's a fairly practical way of working, you don't have to redesign the environment (which has a lot of inertia even if you're the SysAdmin !).
If your trustable host must export information, then you will have to run some network daemons. If you're careful, you can still maintain the trustable status of your host. For example, read-only NFS or httpd can be set up securely. Run them chroot'ed if you can. Don't use the portmapper, which has security holes.
Then you will be able to have confidence in the integrity of the information you're exporting. Of course, other hosts using that information won't be quite so confident, because some third party may be impersonating your IP address.
Excellent tools are now available to
Whether you are user or system administrator, you may install these tools without disruption to an existing site.