CS 513 System Security -- Trusted Paths and Smart Cards

Authentication - Trusted Paths and Smart Cards

Lecturer: Professor Fred B. Schneider

Lecture notes by Borislav Deianov

Last time we discussed the problem of authenticating people. We decided that we must exploit their strengths and not be foiled by their weaknesses. We talked about the use of secrets (in the form of passwords), i.e "something you know".

Suppose we have taken the necessary measures and an attacker cannot guess a password. What can the attacker do beyond guessing? The obvious gambit is theft.

Consider the following scenario: a user is presented with a login window and asked for a password. The user enters the password. But this window is a fake, being run by a program that emails the typed password to an attacker. The defense: confidence that the login window being displayed (apparently) by the operating system is not, in reality, from a malicious program. And one implementation of this defense is to build a trusted path---an authenticated, secrecy- and integrity-protected channel between the reference monitor (or security kernel) and the user.

To build a trusted path, we identify a key on the keyboard (in Windows NT this is the key combination Ctrl-Alt-Delete) and make it special. Whenever this key is pressed, the security kernel gets control and monitors what is typed on the keyboard. There is no way to hijack the key that opens the trusted path.

Note, we do need to make some assumptions about the system. We know that Ctrl-Alt-Delete invokes the Windows-NT security kernel, but how can we be certain that Windows NT is running? Rebooting the computer would ensure that---provided Windows-NT is properly installed. And how do we know that Windows-NT is installed on the hard drive? This is a physical security question. In general, we strive to reduce computer security questions to tractible physical security questions, for without a modicum of physical security very little is possible.

Authentication based on "something you have"

In today's computing systems, authentication is based almost exclusively on "something you know". Authentication based on "something you have" will become increasingly prevelant in the near-term future. The "something you have" refers to a physical device that a person carries and uses for authentication. Such devices are subject to theft, so they should only be used together with some other authentication mechanism (e.g. a PIN). Examples of something you might have include physical keys and credit cards. Notice that these require a special hardware "reader" for communicating with a computer.

A more sophisticated example of "something you have" is the smart card. There are several types of smart cards in use today:

PIN-protected memory cards. Information stored in the memory of such a card can be read only after a PIN has been typed into the card.
Cryptographic challenge/response cards. These cards have on-board memory and processors. Thus, they can store keys as well as performing encryption and decryption.

Here are two ways that a cryptographic challenge/response card might be used for authentication.

Shared key scheme: both the user and the CPU need to know a shared secret key K. There is a separate key for each user. The CPU sends a number r to the user (the "challenge"). The user (i.e. the smart card) encrypts r with K and sends the result (the "response") back to the CPU. The CPU also independently encrypts r with K and compares that result with the response provided by the user. If the two match, then whoever generated the response "knows" the shared secret and, therefore, is presumed to be the user (since nobody else posseses secret key K).

Public key scheme: The user picks a private key k and tells the CPU the corresponding public key K. The CPU chooses a number r (the "challenge"), encrypts it with K, and then sends that to the user. The user decrypts the challenge with k and sends the result (the "response") back to the CPU. The CPU is able to compare the number r it chose for the challenge with the response received from the user. If the two match, then whowever generated the response "knows" the private key and, therefore, is presumed to be the user (since nobody else posseses private key k).

Note on notation: {r}_K means r encrypted with a public key K, K{r} means r encrypted with a shared key K.

A third "something" that you might have is:

Cryptographic calculator. This is similar to a challenge/response card but requires no special reader; instead it has a small keyboard and display. The computer furnishes a challenge, the user types that challenge into the card, the calculator displays a response, and then the user types that response into the computer. A variant, which saves user typing, has a clock in the card. Here, the calculator periodically displays the encrypted time, the user types that encrypted time into to the computer. Thus, this is a challenge/response protocol where the challenge is never sent explicitly, but rather is understood by both parties to be the current time. Obviously, this scheme only works if the clocks are approximately synchronized and if an attacker cannot reset the clock on the computing system.

One final protocol for such a device was devised by Leslie Lamport and is sometimes called Lamport's hash or Lamport's password scheme.

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 = h^m(password)

n := n-1

user computes:
hⁿ(password)

if h^m-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, h²(password)
3, h³(password)
...
n, hⁿ(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).

user		CPU
user stores: `uid,password`		server stores: `uid,n,m,H = h^m(password)`

		`n := n-1`

user computes: `hⁿ(password)`

		if h^m-n(s) = H then m := n; H := s; accept else reject