Basic factors for identification – Entity Authentication

5.1.2 Basic factors for identification

In information security, there are three basic ways for a legitimate party, say Alice, to prove their identity:

• Something Alice knows. Identity is proven based on some unique knowledge that no one except Alice is supposed to have. Examples of this type of identity proof include passwords, personal identification numbers, and secret cryptographic keys.
• Something Alice has. Identity is proven based on the possession of a unique item that, by design, only Alice can have. Examples of this type of identity proof include passports, magnetic-striped cards, hardware keys (such as FIDO), chip cards contained in badges, or handheld password or PIN generators (for example, the ones found in chipTAN schemes).
• Something Alice is. Identity is proven based on an intrinsic or inherent feature that is unique to Alice. Examples include human fingerprints, human DNA, and biometrics such as handwriting, voice, retinal patterns, or hand geometries, and typing timings on a keyboard. In this case, a so-called feature vector is extracted from the actually measured data, which is supposed to be robust (that is, it basically looks the same) against changes in lighting conditions, distance from the sensor, and so on. This feature vector is then matched against corresponding entries in a database.

Often, these factors are combined in what is called multi-factor authentication. For example, to withdraw money from an ATM, you need your credit card (something you have), but you also need your PIN (something you know). The basic idea behind multi-factor authentication is very simple: in order to break such a scheme, an attacker would have to attack several channels instead of one, which significantly raises the effort and lowers the success probability of the attack.

5.2 Authorization and authenticated key establishment

In computer security, the main purpose of entity authentication is to control access to an asset or a resource, say a money withdrawal from an ATM, a file on the disk, or an administrative interface of a web application. This is because access rights – what a user is allowed to do and what not – are typically tied to the user’s identity. The property of computing resources being available only to authorized entities is called authorization [173]– another important security objective that relies heavily on entity authentication.

Entity authentication is also necessary to establish a secure channel. If Alice wants to securely communicate with Bob, she not only needs to protect the messages transmitted between her and Bob over an insecure communication channel but also ensure that she is indeed talking to Bob. As illustrated in Figure 5.2, if Eve can impersonate Bob, all security would be lost even if the messages themselves can neither be decrypted nor manipulated. For this reason, entity authentication is typically an integral part of key establishment protocols.

While key exchange without entity authentication (so-called anonymous key exchange) is possible in principle, it has the huge drawback that you cannot be sure about who you have exchanged the key with. On the other hand, you can certainly do entity authentication without key exchange (the authentication process at the ATM is an example of this), but there is a certain danger that the connection is hijacked after the authentication, meaning an attacker replaces Alice without Bob noticing. Both attacks can be avoided if Alice and Bob agree on a shared (and authenticated) key as part of the authentication protocol.

A protocol that provides key authentication is called authenticated key establishment. Key authentication guarantees that only specifically identified parties get hold of the secret key established during a key exchange. In other words, if Alice and Bob perform an authenticated key establishment, Alice is assured that no one except Bob can learn that secret key. This implies that Bob needs to authenticate himself to Alice. If Bob also needs assurance that only Alice can gain access to the secret key, this can be done by performing an authenticated key exchange with mutual authentication.

Related to key authentication, key confirmation is the assurance that the other communicating party is in possession of a particular secret key. As an example, if Alice and Bob have previously established a secret key k, then, later on, Bob can perform key confirmation to reassure himself that Alice is still in possession of k.

To perform key confirmation, Bob would typically send Alice a message containing (mathematical) evidence that Bob is indeed in possession of key k. There are several ways that Bob can demonstrate this. As an example, Bob can either compute a one-way hash of k, use k in a keyed hash function, or encrypt known plaintext using k.

Alternatively, Bob can use a so-called zero-knowledge proof. Zero-knowledge proofs can be used to demonstrate the possession of a key without leaking any additional information about its value.

By combining key authentication and key confirmation, Alice and Bob achieve explicit key authentication. With explicit key authentication in place, Alice can verify that Bob actually possesses key k (and vice versa).