Authentication - Lamport hash and biometrics

Last time we discussed the use of "something you have" for authentication---in particular, various types of smart cards and cryptographic calculators.

Today, we discuss one final protocol for such a device. This was devised by Leslie Lamport and is sometimes called Lamport's hash or Lamport's password scheme. This method of authentication was popularized as S/KEY. (Note. What follows is modified from what was presented in lecture. The protocol presented in lecture was vulnerable to a intercept/replay attack.)

In what follows, h is assumed to be a cryptographic hash function (see Lecture 10); n and m are natural numbers (initially, n = m = 1000, or so). The scheme works as follows:

user		CPU
user stores: uid,password		server stores: uid,n,m,H = hm(password)
		n := n-1
user computes: hn(password)
		if hm-n(s) = H then m := n; H := s; accept else reject

To understand how the scheme works, assume that an eavesdropper is able to learn the contents of all messages exchanged between the user and the server. After the user has been authenticated, the attacker knows n and hⁿ(password). By the properties of the cryptographic function h, the attacker is able to compute h^m(password) for all m greater than or equal to n but not for any smaller m. However, such values of h^m(password) are useless to the attacker because subsequent authentication challenges send smaller values for n.

Note the following about the scheme:

• Eventually, n = 1. At this point the user must choose a new value for password and n. Then the user must somehow communicate n and hⁿ(password) to the CPU.

• Authentication is not mutual. The user does not know if he/she is talking to the CPU.

• Small n attack": Here, the attacker impersonates the CPU. In response to "uid" from the user, the attacker replies with a small value for n, say 50. >From the user's response to this challenge, the attacker learns h⁵⁰(password). The attacker is now able to authenticate itself to the server whenever the server's challenge is some higher value of n.

  To defend against this attack, the user should keep track of what values of n have already been used for authentication. A challenge that is significantly smaller than what was last requested should be rejected (and authorities notified).

• This protocol does not actually require the use of a cryptographic calculator. The user might have a piece of paper that lists:

  1, h(password)
  2, h2(password)
  3, h3(password)
  ...
  n, hn(password)
  

  On the first login, the user uses the last element in the list and crosses it out. On each subsequent login, the last uncrossed element is used and crossed out.

• By having per CPU salt, it is possible to use the same password on several systems. In this case we use h(password + salt) instead of h(password).

Biometrics - "something you are"

• retinal scan
• fingerprint reader
• handprint reader
• voice print
• keystroke timing
• signature

• Reliability of method. False negatives cause inconvenience to users (you might not be able to log in if your voice is sufficiently different due to a cold). False positives decrease the security of the system.

• Cost and availability of suitable input device. All of the above examples require specialized hardware, which is often expensive.

• Unwillingness of people to interact with such input devices. Most people don't like anything shining light into their eyes for a retinal scan, for example.

• Spoofing. Regardless of how fancy the reader is, in the end it generates a bit string that is used by the CPU for authentication. If an attacker is able to intercept and replay this bit string, then the security of the system will be compromised. This implies that need for close proximity and physical security between the device and the CPU. This is big drawback of this method, as it does not work well over the network.