Authentication

Authentication is concerned with whether something is genuine. How can you be sure that something is what it claims to be? In connection with identity, how can you be sure that somebody is who he claims to be?

Users are often verified in the following ways:

• They know something that is unique to them, such as an identifier or a password.

• They possess something that positively identifies them, such as a key or a driver's license.

• Their identity is self-proving an attribute or combination of attributes is enough to establish credibility. For example, a person's fingerprints are unique enough that additional proof isn't necessary.

Passwords

Most of us are familiar with having to provide a password in addition to a user-supplied identifier. The password is a secret that the user and the authenticating system both know about. If the user can successfully produce the secret when asked, the system can assume that the user is who he claims to be. To prevent discovery by eavesdropping, the password is exchanged after it has been encrypted by a one-way function. The password is stored, in hashed form, on the authenticating system to protect it from a possible attack on the database or file.

Note

The examples in this section illustrate communication between a system and a user. However, the principles equally apply to communication between users to other users, systems to other systems, and so on.

Challenge-Response

A variant of this approach called challenge-response uses shared secret keys. In this case, a user is issued a challenge by the authenticating system, to which the user must reply with a correct response. The challenging system sends data to the user that she must encrypt with her secret key and return. Using the same secret key, the authenticating system attempts to decrypt the returned ciphertext to produce the original plaintext. The secret key might be stored at the authenticating system or be exchanged at the beginning of a session.

Using public key cryptography eliminates the need to share a secret key. In this case, the user encrypts the challenge plaintext with his private key and the authenticating system uses his public key to validate the response. This protocol is an example of a mechanism that uses zero knowledge proofs. In performing the authentication, no additional information is revealed to the authenticating system. Zero knowledge proofs permit you to convince somebody about a fact without revealing information to them beyond that which they already know. Protocols based upon zero knowledge proofs are preferable to others. Thus, in the initial challenge-response example using a shared secret key, it will be better to use a stored key rather than to exchange one each session because the authenticating system "learns" the user's secret key during the protocol. Sharing the secret key is more vulnerable to attack. If the authenticating entity is another user, he learns a secret password.

Trusted Third Parties

Often, a trusted third party can be inserted into an authentication scheme to increase security. Here, users communicate with the third party using one of the authentication protocols mentioned earlier. This results in both users being authenticated to the third party. This party then issues one or more session keys for use between the parties. Neither user learns anything about the other in the transaction, except that they are who they claim to be. Peer-to-peer systems can make particular use of trusted third parties or of tokens, as described in the next section. Using trusted third parties, a system can maintain a list of trusted peers that is much smaller than the list of all of the peers that might want to access its services. Any peer that wants to access a resource can simply obtain a session key from a "friend" of the system providing the resource. In this way, peer-to-peer systems can distribute the responsibility for authenticating users among themselves. Later in the chapter, you'll learn more about some systems that can provide the foundations for this kind of authentication.

Tokens

Users who want to authenticate themselves can also present a digital token to the system they want to authenticate with. Possession of the token is sufficient proof of identity, in the same way that having a hotel key with a magnetic stripe allows you to access your hotel room. However, after you've given a copy of the token to someone, how do you prevent him or her from using it? What if the token is stolen?

The token can be stamped with a digital timestamp the expiration of which invalidates the token. The token can also be issued for use in connection with another object, such as a session key.

Although these techniques can help abate the possibility of misusing a token, they cannot do anything in the case where a token, and consequently an identity, is forged. Although the token proves that the sender is able to construct a token, you cannot be certain that something is not masquerading for another. A digital certificate can help alleviate this problem.

Digital Certificates

Digital certificates provide a way to associate an identity with a public key or other attributes that is certified by a trusted party, called a certificate authority. The most common certificates are those based on the International Telecommunications Union (ITU) standard X.509v3. Table 10.1 lists the contents of an X.509 certificate.

Table 10.1. Contents of an X.509 Certificate

Field	Description
X.509 Version	V1, V2 or V3
Serial Number	A number that uniquely identifies the certificate among those issued by the Certificate Authority
Signature Algorithm	The algorithm used by the Certificate Authority to sign the certificate
Issuer	The name of the Certificate Authority
Validity Period	The period for which the certificate is valid, composed of "Valid from" and "Valid to" fields that are made up of a date and a time
Subject	The name of the entity whose public key is being certified
Public Key	The public key of the entity
Issuer's Unique Identifier	A unique identifier representing the issuer (V2 and V3 only)
Subjects Unique Identifier	A unique identifier representing the subject (V2 and V3 only)
Extensions	Additional attributes (V3 only)
Signature	The signature of all the previous fields

As you can see, a certificate has a number of elements that are validated by the certificate authority and confirmed by its digital signature. To obtain a certificate, a user must apply to a certificate authority and prove she is who she claims to be. The certificate authority will then issue a certificate on behalf of the user, who is known as a subject. Because the certificate contains the subject's public key, the subject can encrypt data with her private key and send it, along with her certificate, to another party. The receiver can use the public key contained in the certificate to decrypt the data, with assurance that the data is truly from the subject.