Authentication: How does a host know that a user is who they claim to be? Traditional solution: Passwords - basically a secret known only to the user. * In early versions, this was not true. Passwords were stored on the host, and hence anyone with root access to the host would be assumed to know the passwords as well. * With one-way functions, the password does not need to be stored on the host, only the result f(p) of running a one-way function on it. Basic password protocol: 1. Alice sends the host her password. 2. The host performs a one-way function f on the password p. 3. The result is compared to the stored result f(p) associated with Alice's name. If there is a match, Alice is authenticated. Issues: * System is vulnerable to dictionary attack. * Use of "salt", random bits that are a function of the user id appended to a password, prevents a dictionary attack from being used against multiple passwords simultaneously. * System is vulnerable to anyone listening anywhere on the line before the password gets to the host (and even for some time afterward), because passwords are transmitted in the clear. SKEY: Very clever program that relies on one-way functions for security, but does not suffer from dictionary attack weakness, and is highly resistant to eavesdropping attacks. 1. Alice types in a random number R to the host. 2. The host computes x1 = f(R), x2 = f(f(R)), x3 = f(f(f(R))), ... up to (say) x100, x101. x1 - x100 are printed out and given to Alice. x101 is stored on the host next to Alice's name. All the other values are erased. 3. To log in the first time, Alice types in x100. The host computes f(x100) = x101 and compares it to the store value. 4. If the value matches, the computer lets Alice in, and replaces x101 with x100. 5. Alice crosses x100 off her list, and next time uses x99. 6. When Alice runs out of passwords, she needs to re-initialize the system, or more commonly, get the sys-admin person to do it Issues: * Fairly secure, though Mallory could intercept your login, tell you the system had logged you out again due to a system error, and go on in your place - a basic hijack attack... * Annoying as hell. You have to carry the stupid card. Or some electronic equivalent. And get it renewed periodically. And those passwords you have to type in are long and non-mnemonic. * If you lose the card your are stuck, and might be compromised, depending on who finds it, until you can contact your sys admin. A public key attempt (challenge, response) 1. The host generates a random string and sends it to Alice 2. Alice encrypts the random number with her private key (signs it) and sends it back to the host, with her name. 3. The host decrypts the string with Alice's public key, stored in its database 4. If the decrypted string matches (signature verified) the host allows access to Alice. Issues: * Alice needs a computer to figure out the response to the challenge, and generally this computer will store her (very long) private key, and so she must already have access to some trusted and secure local system. * Some sort of smart card would be a potential solution, but you would still want some access control to it, in case it were lost. Some 4 digit passcode with a 3-consecutive-misses-and-we-zap-the-eprom proviso would probably suffice. A truly hardware-savy adversary (e.g. the CIA) might be able to open up the card and retrieve the private key (even with tamper-resistant hardware) but we are not trying to provide that level of security... * Encrypting arbitrary strings is a bad idea. You can't be certain that the host sent them. * So the host can be sure of Alice, but Alice is not sure of the host. --------------------------------------------------------------------------- Authentication and Key Exchange All these man-in-the-middle problems can be boiled down to a central problem, that has become the focus of a lot of research: ==> How can two parties (Alice and Bob) mutually authenticate themselves and exchange a session key that permits secure communication? * The public-key system using public keys signed by Trent could be used for this, but (as mentioned above) ... * Mallory could pretend to be Alice from the beginning or at a later point, establish a dialogue with Bob, and possibly get information that Bob would give to Alice, but not Mallory. Might be detected later, but the damage could be done. - So Alice signs her original message to Bob. But Mallory records the whole thing and resends it later + So Alice adds a time stamp and/or a unique message id But now Bob has to keep a synchronized clock and/or a database * So there are a whole pile of methods, most involving symmetric cryptosystems which involve trying to transfer the security of two pre-existing secure channels, Alice <--> Trent and Bob <--> Trent into a secure Alice <--> Bob connection. * Some of these are really involved, and non-obvious weaknesses have been found in a lot of them, often years after they were proposed and put into use. * A whole branch of theory has developed involved with trying to devise formal systems that can help with the analysis of protocol security. Examples: A. "Wide Mouth Frog" 1. Alice concatenates a timestamp, Bob's name, and a random session key, encrypts it using a secret key she shares with Trent, and sends it to Trent along with her name Alice ==> [Alice, Ea(Time1, Bob, Key)] ==> Trent 2. Trent decrypts the message, creates a new timestamp, encrypts the Timestamp, Alices name, and the key K , using the secret key he shares with Bob and sends it to Bob. Trent ==> [Eb(Time2, Alice, Key)] ==> Bob. 3. Bob decrypts the message, calls up Alice, and communicates using K Issues: * Trent knows the first message was created by Alice because it is encrypted using Ea. * Trent knows the message is not a resend by Mallory because the timestamp is OK. This is actually a bit hard to ensure, So maybe we could add a unique ID and recent database maintained by Trent to prevent this. Not clear how Mallory would exploit this, but he is in one step if he gets Trent to take some action on the mistaken belief that Alice asked him to. * Bob knows the message is from Trent because it is encrypted using Eb * The timestamp is some assurance that this is not a resend. * Alice needs to generate a good "random" session key. Just to see what some of these end up looking like... B. "Neuman-Stubblebine" 1. Alice sends her name and a random number to Bob Alice ==> [Alice, Ra] ==> Bob 2. Bob encrypts Alice's name, her random number, and a timestamp with the key he shares with Trent, and sends it to Trent along with his name and a new random number Bob ==> [Bob, Rb Eb(Alice, Ra, Tb)] ==> Trent 3. Trent generates a random session key, and sends three items to Alice: Bob's name, Alice's Random number, the session key, and the timestamp, all encrypted with the key Trent shares with Alice; and Alice's name, the key, and the timestamp, all encrypted with the key he shares with Bob; and Bob's random number Trent ==> [Ea(Bob,Ra,K,Tb), Eb(Alice,K,Tb), Rb] ==> Alice 4. Alice extracts K, and confirms Ra. Then she sends Bob Trent's second message (the one encrypted for Bob) and Bob's random number encruypted with K Alice ==> [Eb(Alice,K,Tb), Ek(Rb)] ==> Bob 5. Bob recovers K, decrypts Rb, checks that Tb and Rb are OK, and Alice and Bob are ready to roll.