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).
