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:

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:

    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 stores:
    server stores:
    uid,n,m,H = hm(password)
    n := n-1
    user computes:
    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 hn(password). By the properties of the cryptographic function h, the attacker is able to compute hm(password) for all m greater than or equal to n but not for any smaller m. However, such values of hm(password) are useless to the attacker because subsequent authentication challenges send smaller values for n.

    Note the following about the scheme: