Analyzing a Simple Protocol

This section will look at a simple cryptographic protocol that has more security goals than we have looked at so far. The reason for studying this simple application is to provide insight into the complexities of cryptographic protocol design rather than to develop proficiency in it. There are two other reasons for studying such an example in some depth:

1. We will see many different ways of designing a cryptographic protocol meeting some specific security goals, each with its slight advantages and disadvantages.

2. While designing proprietary cryptographic protocols is not generally recommended, it’s useful to analyze, at least at a high level, whether a given cryptographic protocol achieves its goals.

A simple application

Let’s now describe a simple security scenario. This scenario is probably too simple to have any real application; however, even this scenario has enough complexity to provide us with an example we can analyze.

The objectives

Let’s suppose Alice and Bob have access to a common network in this scenario. Bob wants to check periodically to make sure Alice is still ‘alive’ and connected to the network. This is our main security objective, which we’ll refer to as a check of liveness.

To make the example slightly more interesting, we assume Alice and Bob are just two entities in a network consisting of many such entities, who all regularly check the liveness of one another, perhaps every few seconds. We therefore set a secondary security objective that whenever Bob receives any confirmation of liveness from Alice, he should be able to determine precisely which liveness query she is responding to.

The protocol goals

We now translate these objectives into concrete protocol goals. Whenever Bob wants to check if Alice is alive, he will need to send a request to Alice, which she will need to respond to with a reply. When designing protocol goals to meet these objectives, it can be helpful to consider what could go wrong, so we’ll motivate each protocol goal with a potential failure of the protocol if this goal isn’t met.

At the end of any run of a suitable cryptographic protocol, the following three goals should have been met:

• Data origin authentication of Alice’s reply: If this isn’t provided, Alice may not be ‘alive’ since an attacker might have created the reply message.

• Freshness of Alice’s reply: If this isn’t provided, then even if there is data origin authentication of the reply, it could be a replay of a previous reply. In other words, an attacker could observe a reply Alice makes when she is ‘alive’ and then send a copy of it to Bob at some stage after Alice has ‘expired.’ This would be a genuine reply created by Alice. But she would not be ‘alive,’ so the protocol would have failed to meet its objectives.

• Assurance that Alice’s reply corresponds to Bob’s request: If this isn’t provided, Bob may receive a reply that corresponds to a different request (either one of his own or another entity in the network).