Remove Redundancies

Real world protocols often have messages of different lengths. In some cases messages may contain few items because few items are available to the sender for inclusion. In other cases, it may actually be imprudent or useless to send particular data items. In other cases it may be efficient to bundle up many items in a single message. Our particular representation fixes the number of beliefs, but allows redundancy in the inclusion of beliefs in messages. Suppose we fix the number of beliefs per message at 3. Then the message {B1, B1, B1} is semantically the same as a message

5.2 From Logic Level to Concrete Level

with the single belief {B1}, {B1, B2, B1} is semantically equivalent to the message{B1, B2}and whereas{B1, B2, B3} is a message with three distinct beliefs. Our approach thus allows protocols with different numbers of distinct beliefs per message to be represented. The sender is not forced to send elements without good reason (to fill a message) and messages lengths do not become an explicit part of the search framework.

We investigate removing redundancies from concrete level messages. The rules for removing redundancies are heuristic and serve to make the concrete protocol more efficient. Some of them are inspired by Abadi and Needham’s protocol design principles discussed in section 2.4. Note that the rules reported in this section cannot be used in general, even though they work for the abstract protocols that are generated by our protocol synthesis framework.

At the concrete level, each message consists of one or more of the following three distinguishable types of data: principal identifiers, keys, and nonces. We have redundancy removing rules to deal with each type of datum respectively.

Remove Redundant Identifiers

The rules we propose in this section optimise messages by safely removing redundant principal identifiers from the content of messages. Identifiers in a concrete level message serve three purposes: to indicate origin of the message; to indicate intended destination of the message; to indicate other principals that will be involved in this run of the protocol.

We define a redundant principal identifier as: after we remove a principal identifier from a message, if the origin and destination of the message are still clear without making any ambitious assumptions, and principals who are currently involved in the run of the protocol still know who will be involved in the run, then the identifier we removed is redundant and can be removed safely.

There are five situations in total we need to deal with. Examples of the five situations are listed in Table 5.2 and explained below.

Chapter 5 Refinement of Security Protocols

Type of Key Which Message with Message After Is Used to “Encrypt” Redundant Applying Rules

Messages Identifiers 1 Symmetric Key A →B : A →B : Between Sender {A, B, X1. . . Xn}Kab {A, X1. . . Xn}Kab and Receiver 2 Private Key A →B : A →B : of The Sender {A, B, X1. . . Xn}_K−1 a {B, X1. . . Xn}Ka−1 3 Public Key A →B : A →B : of The Receiver {A, B, X1. . . Xn}Kb {A, B, X1. . . Xn}Kb 4 “Null” Key A →B : A →B : (Plaintext Message) A, B, X1. . . Xn A, B, X1. . . Xn 5 Applicable to All A →B : A →B : Types of Key A, B, S, X1. . . Xn A, B, X1. . . Xn Table 5.2: Rules for Removing Redundant Identifiers

1. If the message is encrypted by a symmetric key shared between the sender and the receiver, then we can remove the receiver’s identifier from the message. This is safe if the sender’s identifier is recognisable by the receiver. Indeed, for symmetric key encryption, this is a reasonable assumption. By checking the sender’s identifier in the message after decryption, the receiver is ensured of the origin and the intended destination of the message;

2. If the message is signed by the sender’s private key, then we can safely remove the sender’s identifier from the message, because the origin of the message is guaranteed by the sender’s digital signature; 3. If the message is encrypted by the receiver’s public key, then we keep all the principal identifiers. Note that if the sender’s identifier is recognisable by the receiver, then we may safely remove the receiver’s identifier from the message. But for public key encryption, it is not prudent to assume the receiver can always recognise the sender’s identifier;

4. If the message is a plaintext message, there is no reason to recognise redundant principal identifiers, and so all identifiers are kept; 5. If we are designing a key distribution protocol with a key distribution

5.2 From Logic Level to Concrete Level

known and recognisable. Thus, if there is only one server, we can always remove the server’s identifier from a message.

Remove Redundant Keys

The second set of rules is used to remove redundant keys from the content of messages.

All protocols that are generated by our protocol synthesis framework are feasible protocols.3 Consequently, a sender may send out his beliefs to a re- ceiver even if the receiver does not necessarily require the belief to proceed with the protocol. For example, a sender may legitimately distribute his public key even though the receiver already possesses his public key. In such a case, the public key is redundant and can be safely removed from the message. With respect to the protocol synthesis framework, there are four situations in total we need to deal with:

1. If we are designing a key distribution protocol with a key distribution server using asymmetric keys, we can reasonably assume that the server’s public key is publicly known (actually, this is an assumption in the protocol specification we used to synthesise the protocol). Thus, we can safely remove the server’s public key if it appears in a message.

2. We can assume that every principal knows its own public key. Thus, we can always remove the receiver’s public key if it appears in a message.

3. We can safely remove keys, which are in the possession of the receiver at the start of the run of the protocol.

4. Any key in a message encrypted by itself can be removed from the content of the message. For example, we can remove the Kab from the ciphertext{Kab, X1. . . Xn}Kab to get {X1. . . Xn}Kab.

Chapter 5 Refinement of Security Protocols 1. A→B : A, B, Na 2. B→S :{B, Na, Nb, A}Kbs 3. S→B :{Nb, A, Kab}Kbs 4. S→A :{B, Na, Kab}Kas 5. A→B :{A}_K ab 6. B→A :{B, Nb}Kab

Figure 5.5: Final Concrete Symmetric Key Protocol

Remove Redundant Nonces

In many practical security protocols, nonces serve two purposes: to indicate whether a message was sent recently or to indicate whether a message was sent from a particular principal (that is, the nonce was used as a shared secret between principals).

Protocols that are generated by our protocol synthesis framework use nonces only to allow the receiver of a message to verify the timelines of the message.4 Use of nonces as shared secrets requires additional assumptions and is often over ambitious in many practical situations (that is, the principal who generates the nonce must trust the principal he sends the nonce to not to disclose the nonce to anyone else in any situation) and hence causes flaws. The Needham Schroeder public key protocol is an example of using a nonce as a shared secret carelessly, though whether the protocol is flawed or not is a controversial issue (see section 2.2.2).

There is only one rule for removing redundant nonces: if a nonce is sent by its generator to the same receiver in many messages, we can keep the nonce in the first message which contains the nonce and remove it from the other messages. For example, we can keep Nb in the first message of protocol in Figure 5.4 but remove Nb from the third message of the protocol.

4_{Our protocol synthesis framework uses different notation for shared secrets, which is}

5.3 From Concrete Level to Code Level