Fundamentals of Entity Authentication

Entity authentication is the assurance a given entity is involved and currently active in a communication session. This means entity authentication involves assurance of both:

• Identity: The identity of the entity making a claim to be authenticated.

• Freshness: The claimed entity is ‘alive’ and involved in the current session.

If we fail to assure ourselves of identity, we can’t be certain who we are trying to authenticate. If we fail to assure ourselves of freshness, then we could be exposed to replay attacks, which are events in which an attacker captures information used during an entity authentication session and replays it at a later date to falsely pass themselves off as the entity whose information they ‘stole.’

The word entity is complicated. We will avoid philosophical questions and not propose any formal definition other than to comment that an ‘entity’ in the subsequent discussion could be a human user, a device, or even some data. To appreciate the problems of defining a rigorous notion of an ‘entity,’ consider the following question: when someone types their password into a computer, then is the entity being authenticated the person or their password? This essentially relates to the same ‘human-computer gap’ we commented on when discussing digital signatures earlier.

If entity authentication is only used to provide assurance of the identity of one entity to another (and not vice versa), then we refer to it as unilateral entity authentication. If both communicating entities provide each other with assurance of their identity, we call this mutual entity authentication. For example, when someone presents their card and PIN at an ATM, they engage in unilateral entity authentication to the bank. The bank does not authenticate itself to the customer.

Indeed, this ‘weakness’ of ATM authentication has been regularly exploited by attackers who present fake ATMs to bank customers to harvest their card details and PINs. If the entity authentication process had been mutual, the customer would have been able to reject the bank. ATMs attempt to weakly authenticate themselves simply by ‘looking like’ genuine ATMs, but a determined attacker can easily make something that defeats this by also ‘looking like’ a real ATM.

A problem with entity authentication

It’s important to recognize that entity authentication is a security service only provided for an ‘instant in time.’ It establishes the identity of a communicating entity at a specific moment. Still, this entity could be replaced by another entity just seconds later, and we would be none the wiser.

To see how this works, consider the following very simple attack scenario. Alice walks up to an ATM, inserts her payment card, and is asked for her PIN. Alice enters her PIN. This is an example of entity authentication since the card and PIN combination is precisely the information her bank is using to ‘identify’ Alice. As soon as the PIN is entered, Alice is pushed aside by an attacker who takes over the communication session and proceeds to withdraw some cash. The communication session has thus been ‘hijacked.’

Note: There was no failure of the entity authentication mechanism in this example. The only ‘failure’ is that it’s assumed (fairly reasonably in this case) that the communication taking place just a few seconds after the entity authentication check is still with the entity who successfully presented their identity information to the bank via the ATM.

This instantaneous aspect of entity authentication might suggest that for important applications, we’ll have to conduct almost continuous entity authentication to have the assurance of the identity of an entity over a longer period of time. In the case of the ATM, we would have to ask Alice to enter her PIN every time she selects an option on the ATM. This will really annoy Alice. It doesn’t even protect against the above attack since the attacker can still push Alice aside at the end of the transaction and steal her money (but we can at least prevent the attacker from controlling the amount withdrawn).

Fortunately, cryptography can provide a means of prolonging an entity authentication check in many situations. The solution is to combine entity authentication with establishing a cryptographic key. Through entity authentication, we gain assurance that the key was established with the claimed entity. Every time the key is correctly used in the future, then it should be the case that the authenticated entity is involved in that session since nobody else should know the key.

While this doesn’t help us much in our scenario in which the attacker is standing next to Alice at the ATM, it does help us defend against attackers attacking the ATM network and attempting to modify or send spoof messages over it. We’ll look at cryptographic protocols for implementing this process later.

Applications of entity authentication

Entity authentication tends to be employed in two types of situations:

• Access control: Entity authentication is often used to control access to either physical or virtual resources directly. An entity, sometimes a human user, must provide assurance of their identity in real time to have access. The user can then be provided with access to the resources immediately following the instant in time they are authenticated.

• As part of a more complex cryptographic process: Entity authentication is also a common component of more complex cryptographic processes, typically instantiated by a cryptographic protocol. In this case, entity authentication is normally established at the start of a connection. An entity must provide assurance of their identity in real time for the extended protocol to complete satisfactorily.

  For example, the process of establishing a symmetric key commonly involves mutual entity authentication to provide the two communicating entities with the assurance that they have agreed upon a key with the intended partner.